Re: arm64 build broken on linux next 20201021 - include/uapi/asm-generic/unistd.h:862:26: error: array index in initializer exceeds array bounds
Hi Naresh, On Wed, 21 Oct 2020 10:35:10 +0530 Naresh Kamboju wrote: > > arm64 build broken while building linux next 20201021 tag. > > include/uapi/asm-generic/unistd.h:862:26: error: array index in > initializer exceeds array bounds > #define __NR_watch_mount 441 Yeah, the __NR_syscalls in include/uapi/asm-generic/unistd.h needed to be fixed up in the notifications tree merge to be 442. Sorry about that, I will use the correct merge resolution tomorrow. -- Cheers, Stephen Rothwell pgpyidW4vGuHm.pgp Description: OpenPGP digital signature
Re: Segfault in pahole 1.18 when building kernel 5.9.1 for arm64
On 20. 10. 20, 19:15, Andrii Nakryiko wrote: On Tue, Oct 20, 2020 at 3:51 AM Jiri Slaby wrote: Hi, On 19. 10. 20, 1:18, Érico Rolim wrote: I'm trying to build kernel 5.9.1 for arm64, and my dotconfig has `CONFIG_DEBUG_INFO_BTF=y`, which requires pahole for building. However, pahole version 1.18 segfaults during the build, as can be seen below: PAHOLE: Error: Found symbol of zero size when encoding btf (sym: '__kvm_nvhe_arm64_ssbd_callback_required', cu: 'arch/arm64/kernel/cpu_errata.c'). The symbol is an alias coming from arch/arm64/kernel/vmlinux.lds: __kvm_nvhe_arm64_ssbd_callback_required = arm64_ssbd_callback_required;; What's readelf's output for that symbol? If it's legal for SST_OBJECT to have size zero, then we should just skip those in pahole. But it shouldn't crash in either case, of course. But as Arnaldo mentioned, that code changed significantly recently, so please check with latest pahole from tmp.libbtf_encoder branch. ... Yeah, I observe the very same. I reported it at: https://bugzilla.suse.com/show_bug.cgi?id=1177921 If you looked here, you would see: > $ readelf -Ws vml |grep arm64_ssbd_callback_re > 154271: 80001133e000 0 OBJECT GLOBAL DEFAULT 22 __kvm_nvhe_arm64_ssbd_callback_required > 159609: 80001133e000 8 OBJECT WEAK DEFAULT 22 arm64_ssbd_callback_required Yes, its zero-sized. And yes, the error happens even with tmp.libbtf_encoder, but pahole doesn't crash and the build finishes fine. thanks, -- js
Re: [Regression] "tpm: Require that all digests are present in TCG_PCR_EVENT2 structures" causes null pointer dereference
On 2020-10-20 17:07:50, Mimi Zohar wrote: > On Tue, 2020-09-29 at 13:52 -0400, Mimi Zohar wrote: > > On Mon, 2020-09-28 at 22:16 +0800, Kai-Heng Feng wrote: > > > Hi Jarkko, > > > > > > > On Sep 28, 2020, at 22:06, Jarkko Sakkinen > > > > wrote: > > > > > > > > On Mon, Sep 28, 2020 at 08:31:04PM +0800, Kai-Heng Feng wrote: > > > >> Commit 7f3d176f5f7e "tpm: Require that all digests are present in > > > >> TCG_PCR_EVENT2 structures" causes a null pointer dereference on all > > > >> laptops I have: > > > > > > > > ... > > > > > > > >> [ 17.868849] BUG: kernel NULL pointer dereference, address: > > > >> 002c > > > >> [ 17.868852] #PF: supervisor read access in kernel mode > > > >> [ 17.868854] #PF: error_code(0x) - not-present page > > > >> [ 17.868855] PGD 0 P4D 0 > > > >> [ 17.868858] Oops: [#1] SMP PTI > > > >> [ 17.868860] CPU: 0 PID: 1873 Comm: fwupd Not tainted 5.8.0-rc6+ #25 > > > >> [ 17.868861] Hardware name: LENOVO 20LAZ3TXCN/20LAZ3TXCN, BIOS > > > >> N27ET38W (1.24 ) 11/28/2019 > > > >> [ 17.868866] RIP: 0010:tpm2_bios_measurements_start+0x38/0x1f0 > > > >> [ 17.868868] Code: 55 41 54 53 48 83 ec 30 4c 8b 16 65 48 8b 04 25 > > > >> 28 00 00 00 48 89 45 d0 48 8b 47 70 4c 8b a0 d0 06 00 00 48 8b 88 d8 > > > >> 06 00 00 <41> 8b 5c 24 1c 48 89 4d b0 48 89 d8 48 83 c3 20 4d 85 d2 75 > > > >> 31 4c > > > >> [ 17.868869] RSP: 0018:9da500a9fde0 EFLAGS: 00010282 > > > >> [ 17.868871] RAX: 917d03dc4000 RBX: RCX: > > > >> 0010 > > > >> [ 17.868872] RDX: 1000 RSI: 917c99b19460 RDI: > > > >> 917c99b19438 > > > >> [ 17.868873] RBP: 9da500a9fe38 R08: bda4ffa33fc0 R09: > > > >> 917cbfeae4c0 > > > >> [ 17.868874] R10: R11: 0002 R12: > > > >> 0010 > > > >> [ 17.868875] R13: 917c99b19438 R14: 917c99b19460 R15: > > > >> 917c99b19470 > > > >> [ 17.868876] FS: 7f9d80988b00() GS:917d0740() > > > >> knlGS: > > > >> [ 17.868877] CS: 0010 DS: ES: CR0: 80050033 > > > >> [ 17.868878] CR2: 002c CR3: 000219b12004 CR4: > > > >> 003606f0 > > > >> [ 17.868879] Call Trace: > > > >> [ 17.868884] seq_read+0x95/0x470 > > > >> [ 17.868887] ? security_file_permission+0x150/0x160 > > > >> [ 17.868889] vfs_read+0xaa/0x190 > > > >> [ 17.868891] ksys_read+0x67/0xe0 > > > >> [ 17.868893] __x64_sys_read+0x1a/0x20 > > > >> [ 17.868896] do_syscall_64+0x52/0xc0 > > > >> [ 17.868898] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > >> [ 17.868900] RIP: 0033:0x7f9d83be91dc > > > >> [ 17.868901] Code: Bad RIP value. > > > >> [ 17.868902] RSP: 002b:7fff7f5e0250 EFLAGS: 0246 ORIG_RAX: > > > >> > > > >> [ 17.868903] RAX: ffda RBX: 5651d262f420 RCX: > > > >> 7f9d83be91dc > > > >> [ 17.868904] RDX: 1000 RSI: 7fff7f5e0350 RDI: > > > >> 0010 > > > >> [ 17.868905] RBP: 7f9d83cc54a0 R08: R09: > > > >> 5651d26c1830 > > > >> [ 17.868906] R10: 5651d2582010 R11: 0246 R12: > > > >> 1000 > > > >> [ 17.868907] R13: 7fff7f5e0350 R14: 0d68 R15: > > > >> 7f9d83cc48a0 > > > >> [ 17.868909] Modules linked in: rfcomm ccm cmac algif_hash > > > >> algif_skcipher af_alg snd_hda_codec_hdmi snd_hda_codec_realtek > > > >> snd_hda_codec_generic bnep joydev mei_hdcp wmi_bmof intel_rapl_msr > > > >> intel_wmi_thunderbolt x86_pkg_temp_thermal intel_powerclamp coretemp > > > >> nls_iso8859_1 kvm_intel kvm crct10dif_pclmul crc32_pclmul > > > >> ghash_clmulni_intel aesni_intel glue_helper crypto_simd cryptd rapl > > > >> input_leds intel_cstate snd_hda_intel snd_intel_dspcfg rmi_smbus > > > >> iwlmvm snd_hda_codec serio_raw snd_hwdep mac80211 rmi_core > > > >> snd_hda_core libarc4 uvcvideo snd_pcm videobuf2_vmalloc btusb > > > >> videobuf2_memops iwlwifi videobuf2_v4l2 btrtl btbcm videobuf2_common > > > >> btintel thunderbolt i915 bluetooth mei_me videodev thinkpad_acpi nvram > > > >> cfg80211 ledtrig_audio mei mc ecdh_generic ecc i2c_algo_bit > > > >> processor_thermal_device snd_seq_midi drm_kms_helper > > > >> snd_seq_midi_event intel_soc_dts_iosf syscopyarea sysfillrect > > > >> snd_rawmidi intel_pch_thermal sysimgblt intel_rapl_common > > > >> intel_xhci_usb_role_switch fb_sys_fops > u > > cs > > > i_acpi r > > > o > > > > les cec > > > >> [ 17.868935] typec_ucsi typec nxp_nci_i2c snd_seq nxp_nci wmi nci > > > >> nfc snd_timer snd_seq_device snd int3403_thermal soundcore > > > >> int340x_thermal_zone video mac_hid int3400_thermal acpi_pad > > > >> acpi_thermal_rel sch_fq_codel parport_pc ppdev lp parport drm > > > >> ip_tables x_tables autofs4 btrfs blake2b_generic libcrc32c xor > > > >> zstd_compress raid6_pq uas usb_storage psmouse e1000e nvme i2c_i801 > > > >> i2c_smbus nvme_core
Re: [PATCH v7 1/4] KEYS: trusted: Add generic trusted keys framework
Thanks Mimi for your comments.
On Wed, 21 Oct 2020 at 08:51, Mimi Zohar wrote:
>
> On Wed, 2020-10-07 at 15:37 +0530, Sumit Garg wrote:
>
> > +/*
> > + * trusted_destroy - clear and free the key's payload
> > + */
> > +static void trusted_destroy(struct key *key)
> > +{
> > + kfree_sensitive(key->payload.data[0]);
> > +}
> > +
> > +struct key_type key_type_trusted = {
> > + .name = "trusted",
> > + .instantiate = trusted_instantiate,
> > + .update = trusted_update,
> > + .destroy = trusted_destroy,
> > + .describe = user_describe,
> > + .read = trusted_read,
> > +};
> > +EXPORT_SYMBOL_GPL(key_type_trusted);
> > +
> > +static int __init init_trusted(void)
> > +{
> > + int i, ret = 0;
> > +
> > + for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
> > + if (trusted_key_source &&
> > + strncmp(trusted_key_source, trusted_key_sources[i].name,
> > + strlen(trusted_key_sources[i].name)))
> > + continue;
> > +
> > + trusted_key_ops = trusted_key_sources[i].ops;
> > +
> > + ret = trusted_key_ops->init();
> > + if (!ret)
> > + break;
> > + }
>
> In the case when the module paramater isn't specified and both TPM and
> TEE are enabled, trusted_key_ops is set to the last source initialized.
I guess there is some misunderstanding. Here it's only a single trust
source (TPM *or* TEE) is initialized and only that trust source would
be active at runtime. And trusted_key_ops would be initialized to the
first trust source whose initialization is successful (see check: "if
(!ret)").
> After patch 2/4, the last trusted source initialized is TEE. If the
> intention is to limit it to either TPM or TEE, then trusted_key_ops
> should have a default value, which could be overwritten at runtime.
> That would address Luke Hind's concerns of making the decision at
> compile time.
I think traversing the trust source list with the initial value being
TPM would be default value.
>
> trusted_key_ops should be defined as __ro_after_init, like is currently
> done for other LSM structures.
Sure, will do.
>
> > +
> > + /*
> > + * encrypted_keys.ko depends on successful load of this module even if
> > + * trusted key implementation is not found.
> > + */
> > + if (ret == -ENODEV)
> > + return 0;
> > +
> > + return ret;
> > +}
> > +
> > +static void __exit cleanup_trusted(void)
> > +{
> > + trusted_key_ops->exit();
>
> If the intention is really to support both TPM and TEE trusted keys at
> the same time, as James suggested, then the same "for" loop as in
> init_trusted() is needed here and probably elsewhere.
Current intention is to only support a single trust source (TPM or
TEE) at runtime. But in future if there are use-cases then framework
can be extended to support multiple trust sources at runtime as well.
-Sumit
>
> thanks,
>
> Mimi
>
Re: [PATCH 2/2] ARM: dts: tacoma: Add reserved memory for ramoops
On Wed, 21 Oct 2020, at 15:35, Joel Stanley wrote:
> On Fri, 16 Oct 2020 at 04:36, Andrew Jeffery wrote:
> >
> > Reserve a 1.5MiB region of memory to record kmsg dumps, console and
> > userspace message state into 16kiB ring-buffer slots. The sizing allows
> > for up to 32 dumps to be captured and read out.
> >
> > Set max-reason to KMSG_DUMP_EMERG to capture bad-path reboots.
> >
> > Signed-off-by: Andrew Jeffery
> > ---
> > arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> > b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> > index 46f2f538baba..4f7e9b490e1a 100644
> > --- a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> > +++ b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> > @@ -26,6 +26,15 @@ reserved-memory {
> > #size-cells = <1>;
> > ranges;
> >
> > + ramoops@b9e8 {
> > + compatible = "ramoops";
> > + reg = <0xb9e8 0x18>;
>
> I take that r-b back. When booting, we see:
>
> [0.00] region@ba00 (0xb800--0xbc00) overlaps with
> ramoops@b9e8 (0xb9e8--0xba00)
>
> Which appears to be a true statement.
Yep:
>
> > + record-size = <0x4000>;
> > + console-size = <0x4000>;
> > + pmsg-size = <0x4000>;
> > + max-reason = <3>; /* KMSG_DUMP_EMERG */
> > + };
> > +
> > flash_memory: region@ba00 {
> > no-map;
> > reg = <0xb800 0x400>; /* 64M */
Looks like I derived the ramoops address from the flash_memory node label, but
that's mismatched with its reg value.
[PATCH] btrfs: ref-verify: Fix memleak in btrfs_ref_tree_mod
There is one error handling path does not free ref, which may cause a memory leak. Signed-off-by: Dinghao Liu --- fs/btrfs/ref-verify.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/ref-verify.c b/fs/btrfs/ref-verify.c index 7f03dbe5b609..78693d3dd15b 100644 --- a/fs/btrfs/ref-verify.c +++ b/fs/btrfs/ref-verify.c @@ -860,6 +860,7 @@ int btrfs_ref_tree_mod(struct btrfs_fs_info *fs_info, "dropping a ref for a root that doesn't have a ref on the block"); dump_block_entry(fs_info, be); dump_ref_action(fs_info, ra); + kfree(ref); kfree(ra); goto out_unlock; } -- 2.17.1
RE: [PATCH V4 0/6] can: flexcan: add stop mode support for i.MX8QM
> -Original Message- > From: Joakim Zhang > Sent: 2020年10月21日 13:25 > To: m...@pengutronix.de; robh...@kernel.org; shawn...@kernel.org; > s.ha...@pengutronix.de > Cc: ker...@pengutronix.de; dl-linux-imx ; Ying Liu > ; linux-...@vger.kernel.org; net...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: [PATCH V4 0/6] can: flexcan: add stop mode support for i.MX8QM > > The first patch from Liu Ying aims to export SCU symbols for SoCs w/wo SCU, so > that no need to check CONFIG_IMX_SCU in the specific driver. > > The following patches are flexcan fixes and add stop mode support for > i.MX8QM. Hi Shawnguo, Could you please help review patch 1/6 and 5/6? Since flexcan driver depends on these. Thanks. For patch 1/6, it will benefit other drivers which cover SoCs w/wo SCU, such as i.MX Ethernet Controller driver (drivers/net/ethernet/freescale/fec_main.c). Best Regards, Joakim Zhang
Re: WARNING in md_ioctl
On Mon, Oct 19, 2020 at 12:03 AM Dae R. Jeong wrote:
>
> > diff --git i/drivers/md/md.c w/drivers/md/md.c
> > index 6072782070230..49442a3f4605b 100644
> > --- i/drivers/md/md.c
> > +++ w/drivers/md/md.c
> > @@ -7591,8 +7591,10 @@ static int md_ioctl(struct block_device *bdev,
> > fmode_t mode,
> > err = -EBUSY;
> > goto out;
> > }
> > - WARN_ON_ONCE(test_bit(MD_CLOSING, >flags));
> > - set_bit(MD_CLOSING, >flags);
> > + if (test_and_set_bit(MD_CLOSING, >flags)) {
> > + err = -EBUSY;
> > + goto out;
> > + }
> > did_set_md_closing = true;
> > mutex_unlock(>open_mutex);
> > sync_blockdev(bdev);
> >
> > Could you please test whether this fixes the issue?
>
> Since >open_mutex is held when testing a bit of mddev->flags, I
> modified the code just a little bit by putting mutex_unlock() as
> belows.
Good catch! The fix looks good. Would you like to submit a patch for it?
Thanks,
Song
Re: [PATCH v2 1/4] block: keyslot-manager: Introduce passthrough keyslot manager
On Tue, Oct 20, 2020 at 09:44:23PM -0700, Eric Biggers wrote: > On Fri, Oct 16, 2020 at 08:20:44AM +0100, Christoph Hellwig wrote: > > And this just validates my argument that calling the inline crypto work > > directly from the block layer instead of just down below in blk-mq was > > wrong. We should not require any support from stacking drivers at the > > keyslot manager level. > > I'm not sure what you're referring to here; could you clarify? > > It's true that device-mapper devices don't need the actual keyslot management. > But they do need the ability to expose crypto capabilities as well as a key > eviction function. And those are currently handled by > "struct blk_keyslot_manager". Hence the need for a "passthrough keyslot > manager" that does those other things but not the actual keyslot management. > > FWIW, I suggested splitting these up, but you disagreed and said you wanted > the > crypto capabilities to remain part of the blk_keyslot_manager > (https://lkml.kernel.org/linux-block/20200327170047.ga24...@infradead.org/). > If you've now changed your mind, please be clear about it. > I thought what Christoph meant (and of course, please let us know if I'm misunderstanding you, Christoph) was that if blk-mq handled all the blk-crypto stuff including deciding whether to use the blk-crypto-fallback, and blk-mq was responsible for calling out to blk-crypto-fallback if required, then the device mapper wouldn't need to expose any capabilities at all... or at least not for bio-based device mapper devices, since bios would go through the device mapper and eventually hit blk-mq which would then handle crypto appropriately. We couldn't do that because the crypto ciphers for the blk-crypto-fallback couldn't be allocated on the data path (so we needed fscrypt to ask blk-crypto to check whether the underlying device supported the crypto capabilities it required, and allocate ciphers appropriately, before the data path required the ciphers). I'm checking to see if anything has changed w.r.t allocating crypto ciphers on the data path (and checking if memalloc_noio_save/restore() helps with that). > - Eric
[PATCH V4 6/6] can: flexcan: add CAN wakeup function for i.MX8QM
The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX). SCU driver manages the IPC interface
between host CPU and the SCU firmware running on M4.
For i.MX8QM, stop mode request is controlled by System Controller Unit(SCU)
firmware, this patch introduces FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW quirk
for this function.
Signed-off-by: Joakim Zhang
---
drivers/net/can/flexcan.c | 123 --
1 file changed, 106 insertions(+), 17 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 8f578c867493..1f2adbc606f5 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -9,6 +9,7 @@
//
// Based on code originally by Andrey Volkov
+#include
#include
#include
#include
@@ -17,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -242,6 +244,8 @@
#define FLEXCAN_QUIRK_SUPPORT_FD BIT(9)
/* support memory detection and correction */
#define FLEXCAN_QUIRK_SUPPORT_ECC BIT(10)
+/* Setup stop mode with SCU firmware to support wakeup */
+#define FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW BIT(11)
/* Structure of the message buffer */
struct flexcan_mb {
@@ -347,6 +351,7 @@ struct flexcan_priv {
u8 mb_count;
u8 mb_size;
u8 clk_src; /* clock source of CAN Protocol Engine */
+ u8 scu_idx;
u64 rx_mask;
u64 tx_mask;
@@ -358,6 +363,9 @@ struct flexcan_priv {
struct regulator *reg_xceiver;
struct flexcan_stop_mode stm;
+ /* IPC handle when setup stop mode by System Controller firmware(scfw)
*/
+ struct imx_sc_ipc *sc_ipc_handle;
+
/* Read and Write APIs */
u32 (*read)(void __iomem *addr);
void (*write)(u32 val, void __iomem *addr);
@@ -387,7 +395,7 @@ static const struct flexcan_devtype_data
fsl_imx6q_devtype_data = {
static const struct flexcan_devtype_data fsl_imx8qm_devtype_data = {
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
FLEXCAN_QUIRK_USE_OFF_TIMESTAMP |
FLEXCAN_QUIRK_BROKEN_PERR_STATE |
- FLEXCAN_QUIRK_SUPPORT_FD,
+ FLEXCAN_QUIRK_SUPPORT_FD | FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW,
};
static struct flexcan_devtype_data fsl_imx8mp_devtype_data = {
@@ -546,18 +554,42 @@ static void flexcan_enable_wakeup_irq(struct flexcan_priv
*priv, bool enable)
priv->write(reg_mcr, >mcr);
}
+static int flexcan_stop_mode_enable_scfw(struct flexcan_priv *priv, bool
enabled)
+{
+ u8 idx = priv->scu_idx;
+ u32 rsrc_id, val;
+
+ rsrc_id = IMX_SC_R_CAN(idx);
+
+ if (enabled)
+ val = 1;
+ else
+ val = 0;
+
+ /* stop mode request via scu firmware */
+ return imx_sc_misc_set_control(priv->sc_ipc_handle, rsrc_id,
+ IMX_SC_C_IPG_STOP, val);
+}
+
static inline int flexcan_enter_stop_mode(struct flexcan_priv *priv)
{
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg_mcr;
+ int ret;
reg_mcr = priv->read(>mcr);
reg_mcr |= FLEXCAN_MCR_SLF_WAK;
priv->write(reg_mcr, >mcr);
/* enable stop request */
- regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
- 1 << priv->stm.req_bit, 1 << priv->stm.req_bit);
+ if (priv->devtype_data->quirks & FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW) {
+ ret = flexcan_stop_mode_enable_scfw(priv, true);
+ if (ret < 0)
+ return ret;
+ } else {
+ regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
+ 1 << priv->stm.req_bit, 1 <<
priv->stm.req_bit);
+ }
return flexcan_low_power_enter_ack(priv);
}
@@ -566,10 +598,17 @@ static inline int flexcan_exit_stop_mode(struct
flexcan_priv *priv)
{
struct flexcan_regs __iomem *regs = priv->regs;
u32 reg_mcr;
+ int ret;
/* remove stop request */
- regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
- 1 << priv->stm.req_bit, 0);
+ if (priv->devtype_data->quirks & FLEXCAN_QUIRK_SETUP_STOP_MODE_SCFW) {
+ ret = flexcan_stop_mode_enable_scfw(priv, false);
+ if (ret < 0)
+ return ret;
+ } else {
+ regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
+ 1 << priv->stm.req_bit, 0);
+ }
reg_mcr = priv->read(>mcr);
reg_mcr &= ~FLEXCAN_MCR_SLF_WAK;
@@ -1838,7 +1877,7 @@ static void unregister_flexcandev(struct net_device *dev)
unregister_candev(dev);
}
-static int flexcan_setup_stop_mode(struct platform_device *pdev)
+static int flexcan_setup_stop_mode_gpr(struct platform_device
[PATCH V4 0/6] can: flexcan: add stop mode support for i.MX8QM
The first patch from Liu Ying aims to export SCU symbols for SoCs w/wo SCU, so that no need to check CONFIG_IMX_SCU in the specific driver. The following patches are flexcan fixes and add stop mode support for i.MX8QM. ChangeLogs: V3->V4: * can_idx->scu_idx. * return imx_scu_get_handle(>sc_ipc_handle); * failed_canregister->failed_setup_stop_mode. V2->V3: * define IMX_SC_R_CAN(x) in rsrc.h * remove error message on -EPROBE_DEFER. * split disable wakeup patch into separate one. V1->V2: * split ECC fix patches into separate patches. * free can dev if failed to setup stop mode. * disable wakeup on flexcan_remove. * add FLEXCAN_IMX_SC_R_CAN macro helper. * fsl,can-index->fsl,scu-index. * move fsl,scu-index and priv->can_idx into * flexcan_setup_stop_mode_scfw() * prove failed if failed to setup stop mode. Joakim Zhang (5): dt-bindings: can: flexcan: fix fsl,clk-source property dt-bindings: can: flexcan: add fsl,scu-index property to indicate a resource can: flexcan: rename macro FLEXCAN_QUIRK_SETUP_STOP_MODE -> FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR dt-bindings: firmware: add IMX_SC_R_CAN(x) macro for CAN can: flexcan: add CAN wakeup function for i.MX8QM Liu Ying (1): firmware: imx: always export SCU symbols .../bindings/net/can/fsl-flexcan.txt | 8 +- drivers/net/can/flexcan.c | 131 +++--- include/dt-bindings/firmware/imx/rsrc.h | 1 + include/linux/firmware/imx/ipc.h | 15 ++ include/linux/firmware/imx/svc/misc.h | 23 +++ 5 files changed, 156 insertions(+), 22 deletions(-) -- 2.17.1
[PATCH V4 5/6] dt-bindings: firmware: add IMX_SC_R_CAN(x) macro for CAN
Add IMX_SC_R_CAN(x) macro for CAN. Suggested-by: Marc Kleine-Budde Signed-off-by: Joakim Zhang --- include/dt-bindings/firmware/imx/rsrc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/firmware/imx/rsrc.h b/include/dt-bindings/firmware/imx/rsrc.h index 54278d5c1856..43885056557c 100644 --- a/include/dt-bindings/firmware/imx/rsrc.h +++ b/include/dt-bindings/firmware/imx/rsrc.h @@ -111,6 +111,7 @@ #define IMX_SC_R_CAN_0 105 #define IMX_SC_R_CAN_1 106 #define IMX_SC_R_CAN_2 107 +#define IMX_SC_R_CAN(x)(IMX_SC_R_CAN_0 + (x)) #define IMX_SC_R_DMA_1_CH0 108 #define IMX_SC_R_DMA_1_CH1 109 #define IMX_SC_R_DMA_1_CH2 110 -- 2.17.1
[PATCH V4 1/6] firmware: imx: always export SCU symbols
From: Liu Ying
Always export SCU symbols for both SCU SoCs and non-SCU SoCs to avoid
build error.
Signed-off-by: Liu Ying
Signed-off-by: Peng Fan
Signed-off-by: Joakim Zhang
---
include/linux/firmware/imx/ipc.h | 15 +++
include/linux/firmware/imx/svc/misc.h | 23 +++
2 files changed, 38 insertions(+)
diff --git a/include/linux/firmware/imx/ipc.h b/include/linux/firmware/imx/ipc.h
index 891057434858..300fa253fc30 100644
--- a/include/linux/firmware/imx/ipc.h
+++ b/include/linux/firmware/imx/ipc.h
@@ -34,6 +34,7 @@ struct imx_sc_rpc_msg {
uint8_t func;
};
+#if IS_ENABLED(CONFIG_IMX_SCU)
/*
* This is an function to send an RPC message over an IPC channel.
* It is called by client-side SCFW API function shims.
@@ -55,4 +56,18 @@ int imx_scu_call_rpc(struct imx_sc_ipc *ipc, void *msg, bool
have_resp);
* @return Returns an error code (0 = success, failed if < 0)
*/
int imx_scu_get_handle(struct imx_sc_ipc **ipc);
+
+#else
+static inline int
+imx_scu_call_rpc(struct imx_sc_ipc *ipc, void *msg, bool have_resp)
+{
+ return -EIO;
+}
+
+static inline int imx_scu_get_handle(struct imx_sc_ipc **ipc)
+{
+ return -EIO;
+}
+#endif
+
#endif /* _SC_IPC_H */
diff --git a/include/linux/firmware/imx/svc/misc.h
b/include/linux/firmware/imx/svc/misc.h
index 031dd4d3c766..d255048f17de 100644
--- a/include/linux/firmware/imx/svc/misc.h
+++ b/include/linux/firmware/imx/svc/misc.h
@@ -46,6 +46,7 @@ enum imx_misc_func {
* Control Functions
*/
+#if IS_ENABLED(CONFIG_IMX_SCU)
int imx_sc_misc_set_control(struct imx_sc_ipc *ipc, u32 resource,
u8 ctrl, u32 val);
@@ -55,4 +56,26 @@ int imx_sc_misc_get_control(struct imx_sc_ipc *ipc, u32
resource,
int imx_sc_pm_cpu_start(struct imx_sc_ipc *ipc, u32 resource,
bool enable, u64 phys_addr);
+#else
+static inline int
+imx_sc_misc_set_control(struct imx_sc_ipc *ipc, u32 resource,
+ u8 ctrl, u32 val)
+{
+ return -EIO;
+}
+
+static inline int
+imx_sc_misc_get_control(struct imx_sc_ipc *ipc, u32 resource,
+ u8 ctrl, u32 *val)
+{
+ return -EIO;
+}
+
+static inline int imx_sc_pm_cpu_start(struct imx_sc_ipc *ipc, u32 resource,
+ bool enable, u64 phys_addr)
+{
+ return -EIO;
+}
+#endif
+
#endif /* _SC_MISC_API_H */
--
2.17.1
[PATCH V4 2/6] dt-bindings: can: flexcan: fix fsl,clk-source property
Correct fsl,clk-source example since flexcan driver uses "of_property_read_u8"
to get this property.
Fixes: 9d733992772d ("dt-bindings: can: flexcan: add PE clock source property
to device tree")
Signed-off-by: Joakim Zhang
---
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index e10b6eb955e1..6af67f5e581c 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -53,5 +53,5 @@ Example:
interrupts = <48 0x2>;
interrupt-parent = <>;
clock-frequency = <2>; // filled in by bootloader
- fsl,clk-source = <0>; // select clock source 0 for PE
+ fsl,clk-source = /bits/ 8 <0>; // select clock source 0 for PE
};
--
2.17.1
[PATCH V4 4/6] can: flexcan: rename macro FLEXCAN_QUIRK_SETUP_STOP_MODE -> FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR
This patch intends to rename FLEXCAN_QUIRK_SETUP_STOP_MODE quirk
to FLEXCAN_QUIRK_SETUP_STOP_MODE_GRP for non-scu SoCs, coming patch will
add quirk for scu SoCs.
For non-scu SoCs, setup stop mode with GPR register.
For scu SoCs, setup stop mode with SCU firmware.
Signed-off-by: Joakim Zhang
---
drivers/net/can/flexcan.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index 881799bd9c5e..8f578c867493 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -236,8 +236,8 @@
#define FLEXCAN_QUIRK_BROKEN_PERR_STATE BIT(6)
/* default to BE register access */
#define FLEXCAN_QUIRK_DEFAULT_BIG_ENDIAN BIT(7)
-/* Setup stop mode to support wakeup */
-#define FLEXCAN_QUIRK_SETUP_STOP_MODE BIT(8)
+/* Setup stop mode with GPR to support wakeup */
+#define FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR BIT(8)
/* Support CAN-FD mode */
#define FLEXCAN_QUIRK_SUPPORT_FD BIT(9)
/* support memory detection and correction */
@@ -381,7 +381,7 @@ static const struct flexcan_devtype_data
fsl_imx28_devtype_data = {
static const struct flexcan_devtype_data fsl_imx6q_devtype_data = {
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
FLEXCAN_QUIRK_USE_OFF_TIMESTAMP |
FLEXCAN_QUIRK_BROKEN_PERR_STATE |
- FLEXCAN_QUIRK_SETUP_STOP_MODE,
+ FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR,
};
static const struct flexcan_devtype_data fsl_imx8qm_devtype_data = {
@@ -393,7 +393,7 @@ static const struct flexcan_devtype_data
fsl_imx8qm_devtype_data = {
static struct flexcan_devtype_data fsl_imx8mp_devtype_data = {
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_USE_OFF_TIMESTAMP |
- FLEXCAN_QUIRK_BROKEN_PERR_STATE | FLEXCAN_QUIRK_SETUP_STOP_MODE
|
+ FLEXCAN_QUIRK_BROKEN_PERR_STATE |
FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR |
FLEXCAN_QUIRK_SUPPORT_FD | FLEXCAN_QUIRK_SUPPORT_ECC,
};
@@ -2043,7 +2043,7 @@ static int flexcan_probe(struct platform_device *pdev)
of_can_transceiver(dev);
devm_can_led_init(dev);
- if (priv->devtype_data->quirks & FLEXCAN_QUIRK_SETUP_STOP_MODE) {
+ if (priv->devtype_data->quirks & FLEXCAN_QUIRK_SETUP_STOP_MODE_GPR) {
err = flexcan_setup_stop_mode(pdev);
if (err)
dev_dbg(>dev, "failed to setup stop-mode\n");
--
2.17.1
[PATCH V4 3/6] dt-bindings: can: flexcan: add fsl,scu-index property to indicate a resource
For SoCs with SCU support, need setup stop mode via SCU firmware, so this property can help indicate a resource in SCU firmware. Signed-off-by: Joakim Zhang --- Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt index 6af67f5e581c..38a7da4fef3f 100644 --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt @@ -43,6 +43,11 @@ Optional properties: 0: clock source 0 (oscillator clock) 1: clock source 1 (peripheral clock) +- fsl,scu-index: The scu index of CAN instance. + For SoCs with SCU support, need setup stop mode via SCU firmware, + so this property can help indicate a resource. It supports up to + 3 CAN instances now, so the value should be 0, 1, or 2. + - wakeup-source: enable CAN remote wakeup Example: @@ -54,4 +59,5 @@ Example: interrupt-parent = <>; clock-frequency = <2>; // filled in by bootloader fsl,clk-source = /bits/ 8 <0>; // select clock source 0 for PE + fsl,scu-index = /bits/ 8 <1>; // the second CAN instance }; -- 2.17.1
Re: [PATCH v5 1/5] arm64: Add framework to turn IPI as NMI
On Tue, 20 Oct 2020 at 18:02, Marc Zyngier wrote: > > On 2020-10-20 13:25, Daniel Thompson wrote: > > On Tue, Oct 20, 2020 at 04:52:43PM +0530, Sumit Garg wrote: > > [...] > > >> So in general, IPI as a normal IRQ is still useful for debugging but > >> it can't debug a core which is stuck in deadlock with interrupts > >> disabled. > >> > >> And since we choose override default implementations for pseudo NMI > >> support, we need to be backwards compatible for platforms which don't > >> possess pseudo NMI support. > > > > Do the fallback implementations require a new IPI? The fallbacks > > could rely on existing mechanisms such as the smp_call_function > > family. > > Indeed. I'd be worried of using that mechanism for NMIs, but normal > IPIs should stick to the normal cross-call stuff. Yes, the fallback implementations could rely on existing cross-call stuff but current framework only allows this fallback choice at compile time and to make this choice at runtime, we need additional framework changes like allowing arch_trigger_cpumask_backtrace() to return a boolean in order to switch to fallback mode, similar would be the case for kgdb. I think this should be doable but I am still not sure regarding the advantages of using existing IPI vs new IPI (which we will already use in case of pseudo NMI support) as normal IRQ. > > The jury is still out on why this is a good idea, given that it > doesn't work in the only interesting case (deadlocked CPUs). I think CPU soft-lockups (interrupts enabled) is an interesting case to debug as well. -Sumit > > M. > -- > Jazz is not dead. It just smells funny...
[PATCH] can: vxcan: Fix memleak in vxcan_newlink
When rtnl_configure_link() fails, peer needs to be freed just like when register_netdevice() fails. Signed-off-by: Dinghao Liu --- drivers/net/can/vxcan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c index d6ba9426be4d..aefc5a61d239 100644 --- a/drivers/net/can/vxcan.c +++ b/drivers/net/can/vxcan.c @@ -244,6 +244,7 @@ static int vxcan_newlink(struct net *net, struct net_device *dev, unregister_network_device: unregister_netdevice(peer); + free_netdev(peer); return err; } -- 2.17.1
Re: [PATCH v2] fat: Add KUnit tests for checksums and timestamps
David Gow writes: >> Hm, can this export only if FAT_KUNIT_TEST is builtin or module (maybe >> #if IS_ENABLED(...))? And #if will also be worked as the comment too. >> > > That's possible, but I'd prefer to export it unconditionally for two reasons: > 1. It'd make it possible to build the fat_test module without having > to rebuild the whole kernel/fat. > 2. It'd be consistent with fat_time_unix2fat(), which is exported for > use in vfat/msdos anyway. > > Neither of those are dealbreakers, though, so if you'd still prefer > this to be behind an ifdef, I'll change it. OK. If nobody complain, let's export. However, then, can you add the comment instead of ifdef to mark for kunit? Thanks. -- OGAWA Hirofumi
Re: [PATCH] firmware: gsmi: Drop the use of dma_pool_* API functions
On Tue, Oct 20, 2020 at 10:01:41PM -0700, Furquan Shaikh wrote: > GSMI driver uses dma_pool_* API functions for buffer allocation > because it requires that the SMI buffers are allocated within 32-bit > physical address space. However, this does not work well with IOMMU > since there is no real device and hence no domain associated with the > device. > > Since this is not a real device, it does not require any device > address(IOVA) for the buffer allocations. The only requirement is to > ensure that the physical address allocated to the buffer is within > 32-bit physical address space. This change allocates a page using > `get_zeroed_page()` and passes in GFP_DMA32 flag to ensure that the > page allocation is done in the DMA32 zone. All the buffer allocation > requests for gsmi_buf are then satisfed using this pre-allocated page > for the device. Are you sure that "GFP_DMA32" really does what you think it does? A "normal" call with GFP_KERNEL" will give you memory that is properly dma-able. We should not be adding new GFP_DMA* users in the kernel in these days, just call dma_alloc*() and you should be fine. thanks, greg k-h
Re: [PATCH v2 12/14] perf arm-spe: Add more sub classes for operation packet
On Tue, Oct 20, 2020 at 10:54:57PM +0100, André Przywara wrote:
> On 29/09/2020 14:39, Leo Yan wrote:
>
> Hi,
>
> > For the operation type packet payload with load/store class, it misses
> > to support these sub classes:
> >
> > - A load/store targeting the general-purpose registers;
> > - A load/store targeting unspecified registers;
> > - The ARMv8.4 nested virtualisation extension can redirect system
> > register accesses to a memory page controlled by the hypervisor.
> > The SPE profiling feature in newer implementations can tag those
> > memory accesses accordingly.
> >
> > Add the bit pattern describing load/store sub classes, so that the perf
> > tool can decode it properly.
> >
> > Inspired by Andre Przywara, refined the commit log and code for more
> > clear description.
> >
> > Co-developed-by: Andre Przywara
> > Signed-off-by: Leo Yan
> > ---
> > .../util/arm-spe-decoder/arm-spe-pkt-decoder.c| 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index a848c784f4cf..57a2d5494838 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -378,6 +378,21 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt *packet,
> > char *buf,
> > ret = arm_spe_pkt_snprintf(, , "
> > SIMD-FP");
> > if (ret < 0)
> > return ret;
> > + } else if ((payload & SPE_OP_PKT_LDST_SUBCLASS_MASK) ==
>
> These three and the one above use the same mask, should this go into a
> switch case? Move this block to the end, then do:
> switch (payload & SPE_OP_PKT_LDST_SUBCLASS_MASK) {
> case SPE_OP_PKT_LDST_SUBCLASS_GP_REG:
> ...
> case SPE_OP_PKT_LDST_SUBCLASS_UNSPEC_REG:
> ...
> Maybe even assign just a string pointer inside, then have one snprintf.
> Haven't checked it that *really* looks better, though.
Good point, will follow up this suggestion.
> Also those later checks are quite indented, shall those be moved to
> helper functions? Again just an idea
Yeah, I also considered to divide into small functions to handle
different types of packets so can avoid deep indention. Will tweak
patches for this.
Very appreciate for your detailed reviewing and suggestions throughout
the patch set!
Leo
Re: [PATCH v2 14/14] perf arm-spe: Add support for ARMv8.3-SPE
On Tue, Oct 20, 2020 at 10:54:44PM +0100, André Przywara wrote:
> On 29/09/2020 14:39, Leo Yan wrote:
>
> Hi,
>
> > From: Wei Li
> >
> > This patch is to support Armv8.3 extension for SPE, it adds alignment
> > field in the Events packet and it supports the Scalable Vector Extension
> > (SVE) for Operation packet and Events packet with two additions:
> >
> > - The vector length for SVE operations in the Operation Type packet;
> > - The incomplete predicate and empty predicate fields in the Events
> > packet.
> >
> > Signed-off-by: Wei Li
> > Signed-off-by: Leo Yan
> > ---
> > .../arm-spe-decoder/arm-spe-pkt-decoder.c | 84 ++-
> > .../arm-spe-decoder/arm-spe-pkt-decoder.h | 6 ++
> > 2 files changed, 87 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index 05a4c74399d7..3ec381fddfcb 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -342,14 +342,73 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt
> > *packet, char *buf,
> > return ret;
> > }
> > }
> > + if (idx > 2) {
>
> As I mentioned in the other patch, I doubt this extra comparison is
> useful. Does that protect us from anything?
It's the same reason with Event packet which have explained for replying
patch 10, the condition is to respect the SPE specifiction:
E[11], byte 1, bit [11], when SZ == 0b10 , or SZ == 0b11
Alignment.
...
Otherwise this bit reads-as-zero.
So we gives higher priority for checking payload size than the Event
bit setting; if you have other thinking for this, please let me know.
> > + if (payload & SPE_EVT_PKT_ALIGNMENT) {
>
> Mmh, but this is bit 11, right?
Yes.
> So would need to go into the (idx > 1)
> section (covering bits 8-15)? Another reason to ditch this comparison above.
As has explained in patch 10, idx is not the same thing with "sz"
field; "idx" stands for payload length in bytes, so:
idx = 1 << sz
The spec defines the sz is 2 or 3, thus idx is 4 or 8; so this is why
here use the condition "(idx > 2)".
I think here need to refine code for more explict expression so can
avoid confusion. So I think it's better to condition such like:
if (payload_len >= 4) {
...
}
> > + ret = snprintf(buf, buf_len, " ALIGNMENT");
> > + if (ret < 0)
> > + return ret;
> > + buf += ret;
> > + blen -= ret;
>
> Shouldn't we use the new arm_spe_pkt_snprintf() function here as well?
> Or is there a reason that this doesn't work?
Goot point. Will change to use arm_spe_pkt_snprintf().
> > + }
> > + if (payload & SPE_EVT_PKT_SVE_PARTIAL_PREDICATE) {
> > + ret = snprintf(buf, buf_len, "
> > SVE-PARTIAL-PRED");
> > + if (ret < 0)
> > + return ret;
> > + buf += ret;
> > + blen -= ret;
> > + }
> > + if (payload & SPE_EVT_PKT_SVE_EMPTY_PREDICATE) {
> > + ret = snprintf(buf, buf_len, " SVE-EMPTY-PRED");
> > + if (ret < 0)
> > + return ret;
> > + buf += ret;
> > + blen -= ret;
> > + }
> > + }
> > +
> > return buf_len - blen;
> >
> > case ARM_SPE_OP_TYPE:
> > switch (idx) {
> > case SPE_OP_PKT_HDR_CLASS_OTHER:
> > - return arm_spe_pkt_snprintf(, ,
> > - payload &
> > SPE_OP_PKT_OTHER_SUBCLASS_COND ?
> > - "COND-SELECT" : "INSN-OTHER");
> > + if ((payload & SPE_OP_PKT_OTHER_SVE_SUBCLASS_MASK) ==
> > + SPE_OP_PKT_OTHER_SUBCLASS_SVG_OP) {
> > +
> > + ret = arm_spe_pkt_snprintf(, ,
> > "SVE-OTHER");
> > + if (ret < 0)
> > + return ret;
> > +
> > + /* Effective vector length: step is 32 bits */
> > + ret = arm_spe_pkt_snprintf(, , " EVLEN
> > %d",
> > + 32 << ((payload &
> > SPE_OP_PKT_SVE_EVL_MASK) >>
> > + SPE_OP_PKT_SVE_EVL_SHIFT));
>
> Can you move this into a macro, and add a comment about how this works?
> People might get confused over the "32 << something".
Yeah, will refine for it.
Thanks,
Leo
Re: [PATCH] FROMLIST: input: add 2 kind of switch
On Wed, Oct 21, 2020 at 12:12:16PM +0900, HyungJae Im wrote:
> >From ec9859ee01b7bc0e04255971e0fe97348847dab7 Mon Sep 17 00:00:00 2001
You sent this 3 times, why?
And why is this in the body of the email, have you read the "how to send
your first kernel patch" document at kernelnewbies.org?
> From: "hj2.im"
> Date: Tue, 20 Oct 2020 16:57:04 +0900
> Subject: [PATCH] FROMLIST: input: add 2 kind of switch
What does "FROMLIST:" mean?
>
> We need support to various accessories on the device,
> some switch does not exist in switch list.
> So added switch for the following purpose.
>
> SW_COVER_ATTACHED is for the checking the cover
> attached or not on the device. SW_EXT_PEN_ATTACHED is for the
> checking the external pen attached or not on the device
>
> Signed-off-by: hj2.im
As per the kernel documentation, you need to use your real name here,
please do so.
> ---
> include/linux/mod_devicetable.h| 2 +-
> include/uapi/linux/input-event-codes.h | 4 +++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 5b08a473cdba..897f5a3e7721 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -320,7 +320,7 @@ struct pcmcia_device_id {
> #define INPUT_DEVICE_ID_LED_MAX 0x0f
> #define INPUT_DEVICE_ID_SND_MAX 0x07
> #define INPUT_DEVICE_ID_FF_MAX 0x7f
> -#define INPUT_DEVICE_ID_SW_MAX 0x10
> +#define INPUT_DEVICE_ID_SW_MAX 0x12
> #define INPUT_DEVICE_ID_PROP_MAX 0x1f
>
> #define INPUT_DEVICE_ID_MATCH_BUS1
> diff --git a/include/uapi/linux/input-event-codes.h
> b/include/uapi/linux/input-event-codes.h
> index 0c2e27d28e0a..8ca2acee1f92 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -889,7 +889,9 @@
> #define SW_MUTE_DEVICE 0x0e /* set = device disabled */
> #define SW_PEN_INSERTED 0x0f /* set = pen inserted */
> #define SW_MACHINE_COVER 0x10 /* set = cover closed */
> -#define SW_MAX 0x10
> +#define SW_COVER_ATTACHED0x11 /* set = cover attached */
> +#define SW_EXT_PEN_ATTACHED 0x12 /* set = external pen attached */
Is there an in-kernel user for these values anywhere? Please submit
this patch along with the users at the same time, otherwise this change
makes no sense at all.
thanks,
greg k-h
Re: [PATCH 2/2] ARM: dts: tacoma: Add reserved memory for ramoops
On Fri, 16 Oct 2020 at 04:36, Andrew Jeffery wrote:
>
> Reserve a 1.5MiB region of memory to record kmsg dumps, console and
> userspace message state into 16kiB ring-buffer slots. The sizing allows
> for up to 32 dumps to be captured and read out.
>
> Set max-reason to KMSG_DUMP_EMERG to capture bad-path reboots.
>
> Signed-off-by: Andrew Jeffery
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> index 46f2f538baba..4f7e9b490e1a 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> @@ -26,6 +26,15 @@ reserved-memory {
> #size-cells = <1>;
> ranges;
>
> + ramoops@b9e8 {
> + compatible = "ramoops";
> + reg = <0xb9e8 0x18>;
I take that r-b back. When booting, we see:
[0.00] region@ba00 (0xb800--0xbc00) overlaps with
ramoops@b9e8 (0xb9e8--0xba00)
Which appears to be a true statement.
> + record-size = <0x4000>;
> + console-size = <0x4000>;
> + pmsg-size = <0x4000>;
> + max-reason = <3>; /* KMSG_DUMP_EMERG */
> + };
> +
> flash_memory: region@ba00 {
> no-map;
> reg = <0xb800 0x400>; /* 64M */
> --
> 2.25.1
>
arm64 build broken on linux next 20201021 - include/uapi/asm-generic/unistd.h:862:26: error: array index in initializer exceeds array bounds
arm64 build broken while building linux next 20201021 tag. include/uapi/asm-generic/unistd.h:862:26: error: array index in initializer exceeds array bounds #define __NR_watch_mount 441 ^ Reported-by: Naresh Kamboju build error log on arm64: include/uapi/asm-generic/unistd.h:862:26: error: array index in initializer exceeds array bounds #define __NR_watch_mount 441 ^ arch/arm64/kernel/sys.c:56:29: note: in definition of macro '__SYSCALL' #define __SYSCALL(nr, sym) [nr] = __arm64_##sym, ^~ include/uapi/asm-generic/unistd.h:863:11: note: in expansion of macro '__NR_watch_mount' __SYSCALL(__NR_watch_mount, sys_watch_mount) ^~~~ include/uapi/asm-generic/unistd.h:862:26: note: (near initialization for 'sys_call_table') #define __NR_watch_mount 441 ^ arch/arm64/kernel/sys.c:56:29: note: in definition of macro '__SYSCALL' #define __SYSCALL(nr, sym) [nr] = __arm64_##sym, ^~ include/uapi/asm-generic/unistd.h:863:11: note: in expansion of macro '__NR_watch_mount' __SYSCALL(__NR_watch_mount, sys_watch_mount) ^~~~ arch/arm64/kernel/sys.c:56:35: warning: excess elements in array initializer #define __SYSCALL(nr, sym) [nr] = __arm64_##sym, ^ include/uapi/asm-generic/unistd.h:863:1: note: in expansion of macro '__SYSCALL' __SYSCALL(__NR_watch_mount, sys_watch_mount) ^ arch/arm64/kernel/sys.c:56:35: note: (near initialization for 'sys_call_table') #define __SYSCALL(nr, sym) [nr] = __arm64_##sym, ^ include/uapi/asm-generic/unistd.h:863:1: note: in expansion of macro '__SYSCALL' __SYSCALL(__NR_watch_mount, sys_watch_mount) ^ scripts/Makefile.build:283: recipe for target 'arch/arm64/kernel/sys.o' failed | make[3]: *** [arch/arm64/kernel/sys.o] Error 1 scripts/Makefile.build:500: recipe for target 'arch/arm64/kernel' failed | make[2]: *** [arch/arm64/kernel] Error 2 full test log, https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-next/DISTRO=lkft,MACHINE=hikey,label=docker-lkft/882/consoleText -- Linaro LKFT https://lkft.linaro.org
[PATCH] firmware: gsmi: Drop the use of dma_pool_* API functions
GSMI driver uses dma_pool_* API functions for buffer allocation
because it requires that the SMI buffers are allocated within 32-bit
physical address space. However, this does not work well with IOMMU
since there is no real device and hence no domain associated with the
device.
Since this is not a real device, it does not require any device
address(IOVA) for the buffer allocations. The only requirement is to
ensure that the physical address allocated to the buffer is within
32-bit physical address space. This change allocates a page using
`get_zeroed_page()` and passes in GFP_DMA32 flag to ensure that the
page allocation is done in the DMA32 zone. All the buffer allocation
requests for gsmi_buf are then satisfed using this pre-allocated page
for the device.
In addition to that, all the code for managing the dma_pool for GSMI
platform device is dropped.
Signed-off-by: Furquan Shaikh
Reviewed-by: Prashant Malani
---
drivers/firmware/google/gsmi.c | 100 +++--
1 file changed, 71 insertions(+), 29 deletions(-)
diff --git a/drivers/firmware/google/gsmi.c b/drivers/firmware/google/gsmi.c
index 7d9367b22010..054c47346900 100644
--- a/drivers/firmware/google/gsmi.c
+++ b/drivers/firmware/google/gsmi.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -46,7 +45,6 @@
#define DRIVER_VERSION "1.0"
#define GSMI_GUID_SIZE 16
#define GSMI_BUF_SIZE 1024
-#define GSMI_BUF_ALIGN sizeof(u64)
#define GSMI_CALLBACK 0xef
/* SMI return codes */
@@ -85,10 +83,15 @@
struct gsmi_buf {
u8 *start; /* start of buffer */
size_t length; /* length of buffer */
- dma_addr_t handle; /* dma allocation handle */
u32 address;/* physical address of buffer */
};
+struct gsmi_page {
+ unsigned long base_address; /* Base address of allocated page */
+ size_t alloc_size; /* Size of allocation */
+ size_t alloc_used; /* Amount of allocation that is used */
+};
+
static struct gsmi_device {
struct platform_device *pdev; /* platform device */
struct gsmi_buf *name_buf; /* variable name buffer */
@@ -97,7 +100,7 @@ static struct gsmi_device {
spinlock_t lock;/* serialize access to SMIs */
u16 smi_cmd;/* SMI command port */
int handshake_type; /* firmware handler interlock type */
- struct dma_pool *dma_pool; /* DMA buffer pool */
+ struct gsmi_page *page_info;/* page allocated for GSMI buffers */
} gsmi_dev;
/* Packed structures for communicating with the firmware */
@@ -146,9 +149,57 @@ MODULE_PARM_DESC(spincount,
static bool s0ix_logging_enable;
module_param(s0ix_logging_enable, bool, 0600);
+static struct gsmi_page *gsmi_page_alloc(void)
+{
+ struct gsmi_page *page_info;
+
+ page_info = kzalloc(sizeof(*page_info), GFP_KERNEL);
+ if (!page_info) {
+ printk(KERN_ERR "gsmi: out of memory\n");
+ return NULL;
+ }
+
+ page_info->base_address = get_zeroed_page(GFP_KERNEL | GFP_DMA32);
+ if (!page_info->base_address) {
+ printk(KERN_ERR "gsmi: failed to allocate page for buffers\n");
+ return NULL;
+ }
+
+ /* Ensure the entire buffer is allocated within 32bit address space */
+ if (virt_to_phys((void *)(page_info->base_address + PAGE_SIZE - 1))
+ >> 32) {
+ printk(KERN_ERR "gsmi: allocation not within 32-bit physical
address space\n");
+ free_page(page_info->base_address);
+ kfree(page_info);
+ return NULL;
+ }
+
+ page_info->alloc_size = PAGE_SIZE;
+
+ return page_info;
+}
+
+static unsigned long gsmi_page_allocate_buffer(void)
+{
+ struct gsmi_page *page_info = gsmi_dev.page_info;
+ unsigned long buf_offset = page_info->alloc_used;
+
+ if (buf_offset + GSMI_BUF_SIZE > page_info->alloc_size) {
+ printk(KERN_ERR "gsmi: out of space for buffer allocation\n");
+ return 0;
+ }
+
+ page_info->alloc_used = buf_offset + GSMI_BUF_SIZE;
+ return page_info->base_address + buf_offset;
+}
+
static struct gsmi_buf *gsmi_buf_alloc(void)
{
struct gsmi_buf *smibuf;
+ u8 *buf_addr = (u8 *)gsmi_page_allocate_buffer();
+
+ if (!buf_addr)
+ return NULL;
smibuf = kzalloc(sizeof(*smibuf), GFP_KERNEL);
if (!smibuf) {
@@ -156,14 +207,7 @@ static struct gsmi_buf *gsmi_buf_alloc(void)
return NULL;
}
- /* allocate buffer in 32bit address space */
- smibuf->start = dma_pool_alloc(gsmi_dev.dma_pool, GFP_KERNEL,
- >handle);
- if (!smibuf->start) {
- printk(KERN_ERR "gsmi: failed to
Re: [f2fs-dev] [PATCH] f2fs: add compr_inode and compr_blocks sysfs nodes
Both values are from memory values. 2020년 10월 21일 (수) 오후 1:36, Eric Biggers 님이 작성: > > On Fri, Oct 16, 2020 at 02:14:55PM +0900, Daeho Jeong wrote: > > From: Daeho Jeong > > > > Added compr_inode to show compressed inode count and compr_blocks to > > show compressed block count in sysfs. > > > > Signed-off-by: Daeho Jeong > > --- > > Documentation/ABI/testing/sysfs-fs-f2fs | 10 ++ > > fs/f2fs/sysfs.c | 17 + > > 2 files changed, 27 insertions(+) > > > > diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs > > b/Documentation/ABI/testing/sysfs-fs-f2fs > > index 834d0becae6d..a01c26484c69 100644 > > --- a/Documentation/ABI/testing/sysfs-fs-f2fs > > +++ b/Documentation/ABI/testing/sysfs-fs-f2fs > > @@ -350,3 +350,13 @@ Date:April 2020 > > Contact: "Daeho Jeong" > > Description: Give a way to change iostat_period time. 3secs by default. > > The new iostat trace gives stats gap given the period. > > + > > +What:/sys/fs/f2fs//compr_inode > > +Date:October 2020 > > +Contact: "Daeho Jeong" > > +Description: Show compressed inode count > > + > > +What:/sys/fs/f2fs//compr_blocks > > +Date:October 2020 > > +Contact: "Daeho Jeong" > > +Description: Show compressed block count > > Is it the count in memory, or on disk? > > - Eric
Re: [PATCH v2 10/14] perf arm-spe: Refactor event type handling
On Tue, Oct 20, 2020 at 10:54:16PM +0100, André Przywara wrote:
> On 29/09/2020 14:39, Leo Yan wrote:
>
> Hi,
>
> > Use macros instead of the enum values for event types, this is more
> > directive and without bit shifting when parse packet.
> >
> > Signed-off-by: Leo Yan
> > ---
> > .../util/arm-spe-decoder/arm-spe-decoder.c| 16 +++---
> > .../util/arm-spe-decoder/arm-spe-decoder.h| 17 --
> > .../arm-spe-decoder/arm-spe-pkt-decoder.c | 22 +--
> > .../arm-spe-decoder/arm-spe-pkt-decoder.h | 16 ++
> > 4 files changed, 35 insertions(+), 36 deletions(-)
> >
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
> > index 9d3de163d47c..ac66e7f42a58 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.c
> > @@ -168,31 +168,31 @@ static int arm_spe_read_record(struct arm_spe_decoder
> > *decoder)
> > case ARM_SPE_OP_TYPE:
> > break;
> > case ARM_SPE_EVENTS:
> > - if (payload & BIT(EV_L1D_REFILL))
> > + if (payload & SPE_EVT_PKT_L1D_REFILL)
>
> Not sure this (and the others below) are an improvement? I liked the
> enum below, and reading BIT() here tells me that it's a bitmask.
Agreed.
> > decoder->record.type |= ARM_SPE_L1D_MISS;
> >
> > - if (payload & BIT(EV_L1D_ACCESS))
> > + if (payload & SPE_EVT_PKT_L1D_ACCESS)
> > decoder->record.type |= ARM_SPE_L1D_ACCESS;
> >
> > - if (payload & BIT(EV_TLB_WALK))
> > + if (payload & SPE_EVT_PKT_TLB_WALK)
> > decoder->record.type |= ARM_SPE_TLB_MISS;
> >
> > - if (payload & BIT(EV_TLB_ACCESS))
> > + if (payload & SPE_EVT_PKT_TLB_ACCESS)
> > decoder->record.type |= ARM_SPE_TLB_ACCESS;
> >
> > if ((idx == 2 || idx == 4 || idx == 8) &&
> > - (payload & BIT(EV_LLC_MISS)))
> > + (payload & SPE_EVT_PKT_LLC_MISS))
> > decoder->record.type |= ARM_SPE_LLC_MISS;
> >
> > if ((idx == 2 || idx == 4 || idx == 8) &&
> > - (payload & BIT(EV_LLC_ACCESS)))
> > + (payload & SPE_EVT_PKT_LLC_ACCESS))
> > decoder->record.type |= ARM_SPE_LLC_ACCESS;
> >
> > if ((idx == 2 || idx == 4 || idx == 8) &&
> > - (payload & BIT(EV_REMOTE_ACCESS)))
> > + (payload & SPE_EVT_PKT_REMOTE_ACCESS))
> > decoder->record.type |= ARM_SPE_REMOTE_ACCESS;
> >
> > - if (payload & BIT(EV_MISPRED))
> > + if (payload & SPE_EVT_PKT_MISPREDICTED)
> > decoder->record.type |= ARM_SPE_BRANCH_MISS;
> >
> > break;
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> > b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> > index a5111a8d4360..24727b8ca7ff 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
> > @@ -13,23 +13,6 @@
> >
> > #include "arm-spe-pkt-decoder.h"
> >
> > -enum arm_spe_events {
> > - EV_EXCEPTION_GEN= 0,
> > - EV_RETIRED = 1,
> > - EV_L1D_ACCESS = 2,
> > - EV_L1D_REFILL = 3,
> > - EV_TLB_ACCESS = 4,
> > - EV_TLB_WALK = 5,
> > - EV_NOT_TAKEN= 6,
> > - EV_MISPRED = 7,
> > - EV_LLC_ACCESS = 8,
> > - EV_LLC_MISS = 9,
> > - EV_REMOTE_ACCESS= 10,
> > - EV_ALIGNMENT= 11,
> > - EV_PARTIAL_PREDICATE= 17,
> > - EV_EMPTY_PREDICATE = 18,
> > -};
>
> So what about keeping this, but moving it into the other header file?
Will do. This is more directive, especially if we consider every bit
indicates an event type :)
> coding-style.rst says: "Enums are preferred when defining several
> related constants."
Thanks for pasting the coding style, it's useful. I agree that using
BIT() + enum is better form, will refine the patch for this.
> > -
> > enum arm_spe_sample_type {
> > ARM_SPE_L1D_ACCESS = 1 << 0,
> > ARM_SPE_L1D_MISS= 1 << 1,
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index ed0f4c74dfc5..b8f343320abf 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -284,58 +284,58 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt
> > *packet, char *buf,
> > if (ret < 0)
> >
Re: [PATCH v2 3/5] scsi: ufs: use WQ_HIGHPRI for gating work
On 10/21, Can Guo wrote: > On 2020-10-21 03:52, Jaegeuk Kim wrote: > > From: Jaegeuk Kim > > > > Must have WQ_MEM_RECLAIM > > ``WQ_MEM_RECLAIM`` > > All wq which might be used in the memory reclaim paths **MUST** > > have this flag set. The wq is guaranteed to have at least one > > execution context regardless of memory pressure. > > > > You misunderstood my point. I meant you need to give more info about why > we are adding WQ_HIGHPRI flag but not why WQ_MEM_RECLAIM must be there. Oh, I thought that WQ_HIGHPRI is telling everything tho. > > Thanks, > > Can Guo. > > > Cc: Alim Akhtar > > Cc: Avri Altman > > Cc: Can Guo > > Signed-off-by: Jaegeuk Kim > > --- > > drivers/scsi/ufs/ufshcd.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > > index feb10ebf7a35..0858c0b55eac 100644 > > --- a/drivers/scsi/ufs/ufshcd.c > > +++ b/drivers/scsi/ufs/ufshcd.c > > @@ -1867,7 +1867,7 @@ static void ufshcd_init_clk_gating(struct ufs_hba > > *hba) > > snprintf(wq_name, ARRAY_SIZE(wq_name), "ufs_clk_gating_%d", > > hba->host->host_no); > > hba->clk_gating.clk_gating_workq = alloc_ordered_workqueue(wq_name, > > - WQ_MEM_RECLAIM); > > + WQ_MEM_RECLAIM | WQ_HIGHPRI); > > > > hba->clk_gating.is_enabled = true;
Re: [PATCH v2 5/5] scsi: ufs: fix clkgating on/off correctly
On 10/21, Can Guo wrote: > On 2020-10-21 03:52, Jaegeuk Kim wrote: > > The below call stack prevents clk_gating at every IO completion. > > We can remove the condition, ufshcd_any_tag_in_use(), since > > clkgating_work > > will check it again. > > > > I think checking ufshcd_any_tag_in_use() in either ufshcd_release() or > gate_work() can break UFS clk gating's functionality. > > ufshcd_any_tag_in_use() was introduced to replace hba->lrb_in_use. However, > they are not exactly same - ufshcd_any_tag_in_use() returns true if any tag > assigned from block layer is still in use, but tags are released > asynchronously > (through block softirq), meaning it does not reflect the real occupation of > UFS host. > That is after UFS host finishes all tasks, ufshcd_any_tag_in_use() can still > return true. > > This change only removes the check of ufshcd_any_tag_in_use() in > ufshcd_release(), > but having the check of it in gate_work() can still prevent gating from > happening. > The current change works for you maybe because the tags are release before > hba->clk_gating.delay_ms expires, but if hba->clk_gating.delay_ms is shorter > or > somehow block softirq is retarded, gate_work() may have chance to see > ufshcd_any_tag_in_use() > returns true. What do you think? I don't think this breaks clkgating, but fix the wrong condition check which prevented gate_work at all. As you mentioned, even if this schedules gate_work by racy conditions, gate_work will handle it as a last resort. > > Thanks, > > Can Guo. > > In __ufshcd_transfer_req_compl > Ihba->lrb_in_use is cleared immediately when UFS driver > finishes all tasks > > > ufshcd_complete_requests(struct ufs_hba *hba) > > ufshcd_transfer_req_compl() > > __ufshcd_transfer_req_compl() > > __ufshcd_release(hba) > > if (ufshcd_any_tag_in_use() == 1) > >return; > > ufshcd_tmc_handler(hba); > > blk_mq_tagset_busy_iter(); > > > > Cc: Alim Akhtar > > Cc: Avri Altman > > Cc: Can Guo > > Signed-off-by: Jaegeuk Kim > > --- > > drivers/scsi/ufs/ufshcd.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > > index b5ca0effe636..cecbd4ace8b4 100644 > > --- a/drivers/scsi/ufs/ufshcd.c > > +++ b/drivers/scsi/ufs/ufshcd.c > > @@ -1746,7 +1746,7 @@ static void __ufshcd_release(struct ufs_hba *hba) > > > > if (hba->clk_gating.active_reqs || hba->clk_gating.is_suspended || > > hba->ufshcd_state != UFSHCD_STATE_OPERATIONAL || > > - ufshcd_any_tag_in_use(hba) || hba->outstanding_tasks || > > + hba->outstanding_tasks || > > hba->active_uic_cmd || hba->uic_async_done) > > return;
Re: [PATCH 0/2] ARM: dts: Enable ramoops for Rainier and Tacoma
On Fri, 16 Oct 2020 at 04:36, Andrew Jeffery wrote: > > Hi, > > We're looking to improve our crash data capture for the BMC on some IBM > platforms. This small series enables ramoops for Rainier and Tacoma. > > Please review. Reviewed-by: Joel Stanley > > Andrew > > Andrew Jeffery (2): > ARM: dts: rainier: Add reserved memory for ramoops > ARM: dts: tacoma: Add reserved memory for ramoops > > arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 9 + > arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts | 9 + > 2 files changed, 18 insertions(+) > > -- > 2.25.1 >
Re: [PATCH v2 1/4] block: keyslot-manager: Introduce passthrough keyslot manager
On Fri, Oct 16, 2020 at 08:20:44AM +0100, Christoph Hellwig wrote: > And this just validates my argument that calling the inline crypto work > directly from the block layer instead of just down below in blk-mq was > wrong. We should not require any support from stacking drivers at the > keyslot manager level. I'm not sure what you're referring to here; could you clarify? It's true that device-mapper devices don't need the actual keyslot management. But they do need the ability to expose crypto capabilities as well as a key eviction function. And those are currently handled by "struct blk_keyslot_manager". Hence the need for a "passthrough keyslot manager" that does those other things but not the actual keyslot management. FWIW, I suggested splitting these up, but you disagreed and said you wanted the crypto capabilities to remain part of the blk_keyslot_manager (https://lkml.kernel.org/linux-block/20200327170047.ga24...@infradead.org/). If you've now changed your mind, please be clear about it. - Eric
Re: [PATCH v2 1/5] scsi: ufs: atomic update for clkgating_enable
On 10/21, Can Guo wrote:
> On 2020-10-21 03:52, Jaegeuk Kim wrote:
> > From: Jaegeuk Kim
> >
> > When giving a stress test which enables/disables clkgating, we hit
> > device
> > timeout sometimes. This patch avoids subtle racy condition to address
> > it.
> >
> > Cc: Alim Akhtar
> > Cc: Avri Altman
> > Cc: Can Guo
> > Signed-off-by: Jaegeuk Kim
>
> Reviewed-by: Can Guo
>
> Next time can you have a cover letter in case of multiple patches?
Ah, it seems I had to cc you here as well.
https://lore.kernel.org/linux-scsi/20201020195258.2005605-1-jaeg...@kernel.org/T/#mb4e43f3bd03a6b7bc136bea21ac805041c1417a2
>
> Thanks,
>
> Can Guo.
>
> > ---
> > drivers/scsi/ufs/ufshcd.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index b8f573a02713..7344353a9167 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -1807,19 +1807,19 @@ static ssize_t
> > ufshcd_clkgate_enable_store(struct device *dev,
> > return -EINVAL;
> >
> > value = !!value;
> > +
> > + spin_lock_irqsave(hba->host->host_lock, flags);
> > if (value == hba->clk_gating.is_enabled)
> > goto out;
> >
> > - if (value) {
> > - ufshcd_release(hba);
> > - } else {
> > - spin_lock_irqsave(hba->host->host_lock, flags);
> > + if (value)
> > + __ufshcd_release(hba);
> > + else
> > hba->clk_gating.active_reqs++;
> > - spin_unlock_irqrestore(hba->host->host_lock, flags);
> > - }
> >
> > hba->clk_gating.is_enabled = value;
> > out:
> > + spin_unlock_irqrestore(hba->host->host_lock, flags);
> > return count;
> > }
Re: [f2fs-dev] [PATCH] f2fs: add compr_inode and compr_blocks sysfs nodes
On Fri, Oct 16, 2020 at 02:14:55PM +0900, Daeho Jeong wrote: > From: Daeho Jeong > > Added compr_inode to show compressed inode count and compr_blocks to > show compressed block count in sysfs. > > Signed-off-by: Daeho Jeong > --- > Documentation/ABI/testing/sysfs-fs-f2fs | 10 ++ > fs/f2fs/sysfs.c | 17 + > 2 files changed, 27 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs > b/Documentation/ABI/testing/sysfs-fs-f2fs > index 834d0becae6d..a01c26484c69 100644 > --- a/Documentation/ABI/testing/sysfs-fs-f2fs > +++ b/Documentation/ABI/testing/sysfs-fs-f2fs > @@ -350,3 +350,13 @@ Date:April 2020 > Contact: "Daeho Jeong" > Description: Give a way to change iostat_period time. 3secs by default. > The new iostat trace gives stats gap given the period. > + > +What:/sys/fs/f2fs//compr_inode > +Date:October 2020 > +Contact: "Daeho Jeong" > +Description: Show compressed inode count > + > +What:/sys/fs/f2fs//compr_blocks > +Date:October 2020 > +Contact: "Daeho Jeong" > +Description: Show compressed block count Is it the count in memory, or on disk? - Eric
RE: [PATCH] scsi: ufs: make sure scan sequence for multiple hosts
Hi, > -Original Message- > From: Bart Van Assche > Sent: Wednesday, October 21, 2020 12:15 PM > To: Chanho Park ; j...@linux.ibm.com; > martin.peter...@oracle.com > Cc: alim.akh...@samsung.com; avri.alt...@wdc.com; linux- > s...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] scsi: ufs: make sure scan sequence for multiple hosts > > On 10/20/20 12:05 AM, Chanho Park wrote: > > By doing scan as asynchronous way, scsi device scannning can be out of > > order execution. It is no problem if there is a ufs host but the scsi > > device name of each host can be changed according to the scan sequences. > > > > Ideal Case) host0 scan first > > host0 will be started from /dev/sda > > -> /dev/sdb (BootLUN0 of host0) > > -> /dev/sdc (BootLUN1 of host1) > > host1 will be started from /dev/sdd > > > > This might be an ideal case and we can easily find the host device by > > this mappinng. > > > > However, Abnormal Case) host1 scan first, > > host1 will be started from /dev/sda and host0 will be followed later. > > > > To make sure the scan sequences according to the host, we can use a > > bitmap which hosts are scanned and wait until previous hosts are > > finished to scan. > > This sounds completely wrong to me. No code should depend on the order in > which LUNs are scanned. Please use the soft links created by udev instead > of serializing LUN scanning. > Thanks for your review. Did you mean /dev/disk/by-[part]label/ symlink? It's quite reasonable to use them by udev in userspace such as initramfs but some cases does not use initramfs or initrd. In that case, we need to load the root device(/dev/sda[N]) directly from kernel. Anyway, scsi disk(sd) case, the scan order will not be changed until the port has changed so they'll have permanent device names. I'd like to make permanent UFS device names. Best Regards, Chanho Park <>
Re: [PATCH] arm64: NUMA: Kconfig: Increase max number of nodes
On 10/20/2020 11:39 PM, Valentin Schneider wrote: > > Hi, > > Nit on the subject: this only increases the default, the max is still 2¹⁰. Agreed. > > On 20/10/20 18:34, Vanshidhar Konda wrote: >> The current arm64 max NUMA nodes default to 4. Today's arm64 systems can >> reach or exceed 16. Increase the number to 64 (matching x86_64). >> >> Signed-off-by: Vanshidhar Konda >> --- >> arch/arm64/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 893130ce1626..3e69d3c981be 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -980,7 +980,7 @@ config NUMA >> config NODES_SHIFT >> int "Maximum NUMA Nodes (as a power of 2)" >> range 1 10 >> -default "2" >> +default "6" > > This leads to more statically allocated memory for things like node to CPU > maps (see uses of MAX_NUMNODES), but that shouldn't be too much of an > issue. The smaller systems should not be required to waste those memory in a default case, unless there is a real and available larger system with those increased nodes. > > AIUI this also directly correlates to how many more page->flags bits are > required: are we sure the max 10 works on any aarch64 platform? I'm We will have to test that. Besides 256 (2 ^ 8) is the first threshold to be crossed here. > genuinely asking here, given that I'm mostly a stranger to the mm > world. The default should be something we're somewhat confident works > everywhere. Agreed. Do we really need to match X86 right now ? Do we really have systems that has 64 nodes ? We should not increase the default node value and then try to solve some new problems, when there might not be any system which could even use that. I would suggest increase NODES_SHIFT value upto as required by a real and available system. > >> depends on NEED_MULTIPLE_NODES >> help >> Specify the maximum number of NUMA Nodes available on the target >
linux-next: Tree for Oct 21
Hi all, Since the merge window is open, please do not add any v5.11 material to your linux-next included branches until after v5.10-rc1 has been released. Changes since 20201016: The ext4 tree gained a conflict against Linus' tree. The pm tree gained a conflict against the arm-soc tree. The rpmsg tree lost its build failure. The notifications tree gained conflicts against Linus' tree. Non-merge commits (relative to Linus' tree): 2526 2790 files changed, 354749 insertions(+), 44466 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig and htmldocs. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 329 trees (counting Linus' and 86 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (38525c6919e2 Merge tag 'for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply) Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1) Merging kbuild-current/fixes (e30d694c3381 Documentation/llvm: Fix clang target examples) Merging arc-current/for-curr (6364d1b41cc3 arc: include/asm: fix typos of "themselves") Merging arm-current/fixes (9123e3a74ec7 Linux 5.9-rc1) Merging arm64-fixes/for-next/fixes (39e4716caa59 crypto: arm64: Use x16 with indirect branch to bti_c) Merging arm-soc-fixes/arm/fixes (6869f774b1cd Merge tag 'omap-for-v5.9/fixes-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes) Merging uniphier-fixes/fixes (48778464bb7d Linux 5.8-rc2) Merging drivers-memory-fixes/fixes (7ff3a2a626f7 memory: jz4780_nemc: Fix an error pointer vs NULL check in probe()) Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver to platform driver) Merging powerpc-fixes/fixes (d1781f237047 selftests/powerpc: Make alignment handler test P9N DD2.1 vector CI load workaround) Merging s390-fixes/fixes (549738f15da0 Linux 5.9-rc8) Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro) Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty inodes after removing key) Merging net/master (618355cc6a0d nfc: remove unneeded break) Merging bpf/master (8568c3cefd51 bpf: selftest: Ensure the return value of the bpf_per_cpu_ptr() must be checked) Merging ipsec/master (7fe94612dd4c xfrm: interface: fix the priorities for ipip and ipv6 tunnels) Merging netfilter/master (31cc578ae2de netfilter: nftables_offload: KASAN slab-out-of-bounds Read in nft_flow_rule_create) Merging ipvs/master (48d072c4e8cd selftests: netfilter: add time counter check) Merging wireless-drivers/master (df41c19abbea drivers/net/wan/hdlc_fr: Move the skb_headroom check out of fr_hard_header) Merging mac80211/master (9ff9b0d392ea Merge tag 'net-next-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next) Merging rdma-fixes/for-rc (a1b8638ba132 Linux 5.9-rc7) Merging sound-current/for-linus (7da4c510abff ALSA: usb-audio: Line6 Pod Go interface requires static clock rate quirk) Merging sound-asoc-fixes/for-linus (8101e3024d76 Merge remote-tracking branch 'asoc/for-5.10' into asoc-linus) Merging regmap-fixes/for-linus (549738f15da0 Linux 5.9-rc8) Merging regulator-fixes/for-linus (b7c11f48ff81 Merge remote-tracking branch 'regulator/for-5.10' into regulator-linus) Merging spi-fixes/for-linus (d4f3a651ab82 Merge remote-tracking branch 'spi/for-5.9' into spi-linus) Merging
Re: [PATCH v2] Documentation: kunit: Update Kconfig parts for KUNIT's module support
On Tue, Oct 13, 2020 at 2:38 PM 'SeongJae Park' via KUnit Development
wrote:
>
> From: SeongJae Park
>
> If 'CONFIG_KUNIT=m', letting kunit tests that do not support loadable
> module build depends on 'KUNIT' instead of 'KUNIT=y' result in compile
> errors. This commit updates the document for this.
>
> Fixes: 9fe124bf1b77 ("kunit: allow kunit to be loaded as a module")
> Signed-off-by: SeongJae Park
Sorry for the delay in looking at this. Apart from another minuscule
typo below, this looks good to me.
Reviewed-by: David Gow
Cheers,
-- David
> ---
>
> Changes from v1
> (https://lore.kernel.org/linux-kselftest/20201012105420.5945-1-sjp...@amazon.com/):
> - Fix a typo (Marco Elver)
>
> ---
> Documentation/dev-tools/kunit/start.rst | 2 +-
> Documentation/dev-tools/kunit/usage.rst | 5 +
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/dev-tools/kunit/start.rst
> b/Documentation/dev-tools/kunit/start.rst
> index d23385e3e159..454f307813ea 100644
> --- a/Documentation/dev-tools/kunit/start.rst
> +++ b/Documentation/dev-tools/kunit/start.rst
> @@ -197,7 +197,7 @@ Now add the following to ``drivers/misc/Kconfig``:
>
> config MISC_EXAMPLE_TEST
> bool "Test for my example"
> - depends on MISC_EXAMPLE && KUNIT
> + depends on MISC_EXAMPLE && KUNIT=y
>
> and the following to ``drivers/misc/Makefile``:
>
> diff --git a/Documentation/dev-tools/kunit/usage.rst
> b/Documentation/dev-tools/kunit/usage.rst
> index 3c3fe8b5fecc..b331f5a5b0b9 100644
> --- a/Documentation/dev-tools/kunit/usage.rst
> +++ b/Documentation/dev-tools/kunit/usage.rst
> @@ -556,6 +556,11 @@ Once the kernel is built and installed, a simple
>
> ...will run the tests.
>
> +.. note::
> + Note that you should make your test depends on ``KUNIT=y`` in Kconfig if
> the
nit: Grammatically, this should technically be either "depend" (2nd
person), or something like "make sure [that] your test depends".
> + test does not support module build. Otherwise, it will trigger compile
> + errors if ``CONFIG_KUNIT`` is ``m``.
> +
Someday it'd be nice to better discuss the reasons a test suite might
not be compilable as a module. It's probably outside the scope of this
commit to do it properly, though.
> Writing new tests for other architectures
> -
>
> --
> 2.17.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "KUnit Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kunit-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kunit-dev/20201013063743.32179-1-sjpark%40amazon.com.
Re: [PATCH] net: dsa: bcm_sf2: make const array static, makes object smaller
On Tue, 20 Oct 2020 09:51:39 -0700 Florian Fainelli wrote: > On 10/20/20 9:50 AM, Colin King wrote: > > From: Colin Ian King > > > > Don't populate the const array rate_table on the stack but instead it > > static. Makes the object code smaller by 46 bytes. > > > > Before: > >textdata bss dec hex filename > > 298123824 192 338288424 drivers/net/dsa/bcm_sf2.o > > > > After: > >textdata bss dec hex filename > > 296703920 192 3378283f6 drivers/net/dsa/bcm_sf2.o > > > > (gcc version 10.2.0) > > > > Signed-off-by: Colin Ian King > > Acked-by: Florian Fainelli Applied, thanks!
Re: [PATCH] mptcp: MPTCP_IPV6 should depend on IPV6 instead of selecting it
On Tue, 20 Oct 2020 11:26:34 +0200 Matthieu Baerts wrote: > On 20/10/2020 09:38, Geert Uytterhoeven wrote: > > MPTCP_IPV6 selects IPV6, thus enabling an optional feature the user may > > not want to enable. Fix this by making MPTCP_IPV6 depend on IPV6, like > > is done for all other IPv6 features. > > Here again, the intension was to select IPv6 from MPTCP but I understand > the issue: if we enable MPTCP, we will select IPV6 as well by default. > Maybe not what we want on some embedded devices with very limited memory > where IPV6 is already off. We should instead enable MPTCP_IPV6 only if > IPV6=y. LGTM then! > > Reviewed-by: Matthieu Baerts Applied, thanks!
Re: [PATCH v2 09/14] perf arm-spe: Refactor counter packet handling
On Tue, Oct 20, 2020 at 10:53:47PM +0100, André Przywara wrote:
> On 29/09/2020 14:39, Leo Yan wrote:
>
> Hi,
>
> > This patch defines macros for counter packet header, and uses macro to
> > replace hard code values for packet parsing.
> >
> > Signed-off-by: Leo Yan
> > ---
> > .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 17 ++---
> > .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 9 +
> > 2 files changed, 19 insertions(+), 7 deletions(-)
> >
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index 00a2cd1af422..ed0f4c74dfc5 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -150,10 +150,13 @@ static int arm_spe_get_counter(const unsigned char
> > *buf, size_t len,
> >const unsigned char ext_hdr, struct arm_spe_pkt
> > *packet)
> > {
> > packet->type = ARM_SPE_COUNTER;
> > - if (ext_hdr)
> > - packet->index = ((buf[0] & 0x3) << 3) | (buf[1] & 0x7);
> > - else
> > - packet->index = buf[0] & 0x7;
> > + if (ext_hdr) {
> > + packet->index = (buf[1] & SPE_CNT_PKT_HDR_INDEX_MASK);
> > + packet->index |= ((buf[0] & SPE_CNT_PKT_HDR_EXT_INDEX_MASK)
> > + << SPE_CNT_PKT_HDR_EXT_INDEX_SHIFT);
> > + } else {
> > + packet->index = buf[0] & SPE_CNT_PKT_HDR_INDEX_MASK;
>
> That looks suspiciously similar to the extended header in the address
> packet. Can you use the same name for that?
Checked for counter packet and address packet, they are using the same
format for index. Will use the same name.
> And, similar to the address packet, what about:
> packet->index |= SPE_PKT_EXT_HEADER_INDEX(buf[0]);
Will do.
> (merging the mask and the shift in the macro definition)
>
> > + }
> >
> > return arm_spe_get_payload(buf, len, ext_hdr, packet);
> > }
> > @@ -431,17 +434,17 @@ int arm_spe_pkt_desc(const struct arm_spe_pkt
> > *packet, char *buf,
> > return ret;
> >
> > switch (idx) {
> > - case 0:
> > + case SPE_CNT_PKT_HDR_INDEX_TOTAL_LAT:
> > ret = arm_spe_pkt_snprintf(, , "TOT");
> > if (ret < 0)
> > return ret;
> > break;
> > - case 1:
> > + case SPE_CNT_PKT_HDR_INDEX_ISSUE_LAT:
> > ret = arm_spe_pkt_snprintf(, , "ISSUE");
> > if (ret < 0)
> > return ret;
> > break;
> > - case 2:
> > + case SPE_CNT_PKT_HDR_INDEX_TRANS_LAT:
> > ret = arm_spe_pkt_snprintf(, , "XLAT");
> > if (ret < 0)
> > return ret;
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > index 62db4ff91832..18667a63f5ba 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > @@ -89,6 +89,15 @@ struct arm_spe_pkt {
> > /* Context packet header */
> > #define SPE_CTX_PKT_HDR_INDEX_MASK GENMASK_ULL(1, 0)
> >
> > +/* Counter packet header */
> > +#define SPE_CNT_PKT_HDR_INDEX_MASK GENMASK_ULL(2, 0)
> > +#define SPE_CNT_PKT_HDR_INDEX_TOTAL_LAT(0x0)
> > +#define SPE_CNT_PKT_HDR_INDEX_ISSUE_LAT(0x1)
> > +#define SPE_CNT_PKT_HDR_INDEX_TRANS_LAT(0x2)
>
> I think the Linux kernel coding style does not mention parentheses just
> around numbers, so just 0x2 would suffice, for instance.
> See section 12) in Documentation/process/coding-style.rst
Yeah, it gives example as "#define CONSTANT 0x4000"; will follow the
coding style.
Thanks for suggestions!
Leo
Re: [PATCH v7 2/4] powerpc: Refactor kexec functions to move arch independent code to ima
Hi Lakshmi, On Tue, 2020-10-20 at 19:38 -0700, Lakshmi Ramasubramanian wrote: > On 10/20/20 1:01 PM, Mimi Zohar wrote: > > On Wed, 2020-09-30 at 13:59 -0700, Lakshmi Ramasubramanian wrote: > >> The functions ima_get_kexec_buffer() and ima_free_kexec_buffer(), > >> that handle carrying forward the IMA measurement logs on kexec for > >> powerpc do not have architecture specific code, but they are currently > >> defined for powerpc only. > >> > >> Move ima_get_kexec_buffer() and ima_free_kexec_buffer() to IMA > >> subsystem. A later patch in this series will use these functions for > >> carrying forward the IMA measurement log for ARM64. > >> > >> With the above refactoring arch/powerpc/kexec/ima.c contains only > >> functions used when CONFIG_IMA_KEXEC is enabled. Update Makefile > >> in arch/powerpc/kexec to include arch/powerpc/kexec/ima.c only > >> when CONFIG_IMA_KEXEC is enabled. > >> > >> Move ima_dump_measurement_list() and ima_add_kexec_buffer() to > >> a new file namely ima_kexec_fdt.c in IMA. Update > >> security/integrity/ima/Makefile to include ima_kexec_fdt.c only > >> when CONFIG_IMA_KEXEC is enabled. > >> > >> Co-developed-by: Prakhar Srivastava > >> Signed-off-by: Prakhar Srivastava > >> Signed-off-by: Lakshmi Ramasubramanian > > > > The existing support for carrying the IMA measurement list across kexec > > is limited to powerpc. This patch set is adding similar support for > > arm64, making as much of the existing code as generic as possible. > > However ima_dump_measurement_list() is already generic, but for some > > reason this patch moves it to ima_kexec_fdt.c. ima_kexec_fdt.c should > > be limited to device tree specific code. > > I wanted to split the functions defined under CONFIG_HAVE_IMA_KEXEC and > CONFIG_IMA_KEXEC to separate files so that we can get rid of #ifdef in C > file and instead conditionally compile the C files (using Makefile). > > ima_dump_measurement_list() need to be defined only when > CONFIG_IMA_KEXEC is defined. I moved it to ima_kexec_fdt.c In this case, everything in ima_kexec.c relates to carrying or restoring the measurement list. It's a logical unit. Separating them doesn't make sense. > > Instead of ima_kexec_fdt.c, where ima_dump_measurement_list() and > ima_add_kexec_buffer() are defined, perhaps I can change the file name > to "ima_kexec_buffer.c". Would that be better? I don't understand why adding support for carrying the IMA measurement across kexec on ARM64, should require any changes in the IMA loading and restoring the measurement list code itself. Please minimize the changes. thanks, Mimi
Re: [PATCH v2] fat: Add KUnit tests for checksums and timestamps
On Tue, Oct 20, 2020 at 2:51 PM OGAWA Hirofumi wrote: > > David Gow writes: > > > diff --git a/fs/fat/misc.c b/fs/fat/misc.c > > index f1b2a1fc2a6a..445ad3542e74 100644 > > --- a/fs/fat/misc.c > > +++ b/fs/fat/misc.c > > @@ -229,6 +229,7 @@ void fat_time_fat2unix(struct msdos_sb_info *sbi, > > struct timespec64 *ts, > > ts->tv_nsec = 0; > > } > > } > > +EXPORT_SYMBOL_GPL(fat_time_fat2unix); > > Hm, can this export only if FAT_KUNIT_TEST is builtin or module (maybe > #if IS_ENABLED(...))? And #if will also be worked as the comment too. > That's possible, but I'd prefer to export it unconditionally for two reasons: 1. It'd make it possible to build the fat_test module without having to rebuild the whole kernel/fat. 2. It'd be consistent with fat_time_unix2fat(), which is exported for use in vfat/msdos anyway. Neither of those are dealbreakers, though, so if you'd still prefer this to be behind an ifdef, I'll change it. -- David
[tip:timers/urgent] BUILD SUCCESS a4fd8414659bf470e2146b352574bbd274e54b7a
-64bit_defconfig armmps2_defconfig arm omap2plus_defconfig powerpc acadia_defconfig arm mainstone_defconfig mipsmalta_qemu_32r6_defconfig powerpc g5_defconfig powerpc tqm8555_defconfig xtensa virt_defconfig arm eseries_pxa_defconfig shtitan_defconfig arm assabet_defconfig shmigor_defconfig ia64 alldefconfig armvt8500_v6_v7_defconfig openriscdefconfig mips malta_defconfig xtensaxip_kc705_defconfig m68k amiga_defconfig arc nsimosci_hs_defconfig mips cavium_octeon_defconfig sh polaris_defconfig arm am200epdkit_defconfig mipsnlm_xlr_defconfig arm integrator_defconfig sh alldefconfig powerpc cm5200_defconfig arm vf610m4_defconfig mips rt305x_defconfig m68k m5249evb_defconfig xtensa iss_defconfig powerpc mpc866_ads_defconfig ia64generic_defconfig arm versatile_defconfig powerpccell_defconfig sh lboxre2_defconfig arm pxa3xx_defconfig nios2alldefconfig powerpc mpc8560_ads_defconfig arm s3c6400_defconfig powerpc sequoia_defconfig armoxnas_v6_defconfig sh rsk7201_defconfig armzeus_defconfig xtensa cadence_csp_defconfig arc allyesconfig mips ip27_defconfig m68kmac_defconfig mips tb0226_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a001-20201021 x86_64 randconfig-a002-20201021 x86_64 randconfig-a003-20201021 x86_64 randconfig-a006-20201021 x86_64 randconfig-a005-20201021 x86_64 randconfig-a004-20201021 i386 randconfig-a002-20201020 i386 randconfig-a005-20201020 i386 randconfig-a003-20201020 i386 randconfig-a001-20201020 i386 randconfig-a006-20201020 i386 randconfig-a004-20201020 i386 randconfig-a002-20201021 i386 randconfig-a005-20201021 i386 randconfig-a003-20201021 i386 randconfig-a001-20201021 i386 randconfig-a006-20201021 i386 randconfig-a004-20201021 x86_64 randconfig-a011-20201020 x86_64 randconfig-a013-20201020 x86_64 randconfig-a016-20201020 x86_64 randconfig-a015-20201020 x86_64 randconfig-a012-20201020 x86_64 randconfig-a014-20201020 i386 randconfig-a016-20201020 i386 randconfig-a014-20201020 i386 randconfig-a015-20201020 i386 randconfig-a013-20201020 i386 randconfig-a012-20201020 i386 randconfig-a011-20201020 i386 randconfig-a016-20201021 i386
Re: [PATCH] lib: add basic KUnit test for lib/math
On Tue, Oct 20, 2020 at 6:46 AM Daniel Latypov wrote:
>
> Add basic test coverage for files that don't require any config options:
> * gcd.c
> * lcm.c
> * int_sqrt.c
> * reciprocal_div.c
> (Ignored int_pow.c since it's a simple textbook algorithm.)
>
I don't see a particular reason why int_pow.c being a simple algorithm
means it shouldn't be tested. I'm not saying it has to be tested by
this particular change -- and I doubt the test would be
earth-shatteringly interesting -- but there's no real reason against
testing it.
> These tests aren't particularly interesting, but
> * they're chosen as easy to understand examples of how to write tests
> * provides a place to add tests for any new files in this dir
> * written so adding new test cases to cover edge cases should be easy
I think these tests can stand on their own merits, rather than just as
examples (though I do think they do make good additional examples for
how to test these sorts of functions).
So, I'd treat this as an actual test of the maths functions (and
you've got what seems to me a decent set of test cases for that,
though there are a couple of comments below) first, and any use it
gains as an example is sort-of secondary to that (anything that makes
it a better example is likely to make it a better test anyway).
In any case, modulo the comments below, this seems good to me.
-- David
> Signed-off-by: Daniel Latypov
> ---
> lib/math/Kconfig | 5 ++
> lib/math/Makefile| 2 +
> lib/math/math_test.c | 197 +++
> 3 files changed, 204 insertions(+)
> create mode 100644 lib/math/math_test.c
>
> diff --git a/lib/math/Kconfig b/lib/math/Kconfig
> index f19bc9734fa7..6ba8680439c1 100644
> --- a/lib/math/Kconfig
> +++ b/lib/math/Kconfig
> @@ -15,3 +15,8 @@ config PRIME_NUMBERS
>
> config RATIONAL
> bool
> +
> +config MATH_KUNIT_TEST
> + tristate "KUnit test for lib/math" if !KUNIT_ALL_TESTS
> + default KUNIT_ALL_TESTS
> + depends on KUNIT
> diff --git a/lib/math/Makefile b/lib/math/Makefile
> index be6909e943bd..fba6fe90f50b 100644
> --- a/lib/math/Makefile
> +++ b/lib/math/Makefile
> @@ -4,3 +4,5 @@ obj-y += div64.o gcd.o lcm.o int_pow.o int_sqrt.o
> reciprocal_div.o
> obj-$(CONFIG_CORDIC) += cordic.o
> obj-$(CONFIG_PRIME_NUMBERS)+= prime_numbers.o
> obj-$(CONFIG_RATIONAL) += rational.o
> +
> +obj-$(CONFIG_MATH_KUNIT_TEST) += math_test.o
> diff --git a/lib/math/math_test.c b/lib/math/math_test.c
> new file mode 100644
> index ..6f4681ea7c72
> --- /dev/null
> +++ b/lib/math/math_test.c
> @@ -0,0 +1,197 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Simple KUnit suite for math helper funcs that are always enabled.
> + *
> + * Copyright (C) 2020, Google LLC.
> + * Author: Daniel Latypov
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Generic test case for unsigned long inputs. */
> +struct test_case {
> + unsigned long a, b;
> + unsigned long result;
> +};
> +
> +static void gcd_test(struct kunit *test)
> +{
> + const char *message_fmt = "gcd(%lu, %lu)";
> + int i;
> +
> + struct test_case test_cases[] = {
> + {
> + .a = 0, .b = 1,
> + .result = 1,
> + },
> + {
> + .a = 2, .b = 2,
> + .result = 2,
> + },
> + {
> + .a = 2, .b = 4,
> + .result = 2,
> + },
> + {
> + .a = 3, .b = 5,
> + .result = 1,
> + },
> + {
> + .a = 3*9, .b = 3*5,
> + .result = 3,
> + },
> + {
> + .a = 3*5*7, .b = 3*5*11,
> + .result = 15,
> + },
> + {
> + .a = (1 << 21) - 1,
> + .b = (1 << 22) - 1,
It might be worth noting the factors of these (7^2*127*337 and
3*23*89*683) in a comment.
They aren't mersenne primes, if that's what you were going for, though
they are coprime.
> + .result = 1,
> + },
> + };
> +
> + for (i = 0; i < ARRAY_SIZE(test_cases); ++i) {
> + KUNIT_EXPECT_EQ_MSG(test, test_cases[i].result,
> + gcd(test_cases[i].a, test_cases[i].b),
> + message_fmt, test_cases[i].a,
> + test_cases[i].b);
> +
> + /* gcd(a,b) == gcd(b,a) */
> + KUNIT_EXPECT_EQ_MSG(test, test_cases[i].result,
> + gcd(test_cases[i].b, test_cases[i].a),
> + message_fmt, test_cases[i].b,
> + test_cases[i].a);
> + }
> +}
> +
>
Re: cgroup and FALLOC_FL_PUNCH_HOLE: WARNING: CPU: 13 PID: 2438 at mm/page_counter.c:57 page_counter_uncharge+0x4b/0x5
On 10/20/20 6:38 AM, David Hildenbrand wrote:
>
> I'm bisecting the warning right now. Looks like it was introduced in v5.7.
I found the following bugs in the cgroup reservation accounting. The ones
in region_del are pretty obvious as the number of pages to uncharge would
always be zero. The one on alloc_huge_page needs racing code to expose.
With these fixes, my testing is showing consistent/correct results for
hugetlb reservation cgroup accounting.
It would be good if Mina (at least) would look these over. Would also
be interesting to know if these fixes address the bug seen with the qemu
use case.
I'm still doing more testing and code inspection to look for other issues.
>From 861bcd7d0443f18a5fed3c3ddc5f1c71e78c4ef4 Mon Sep 17 00:00:00 2001
From: Mike Kravetz
Date: Tue, 20 Oct 2020 20:21:42 -0700
Subject: [PATCH] hugetlb_cgroup: fix reservation accounting
Signed-off-by: Mike Kravetz
---
mm/hugetlb.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 67fc6383995b..c92366313780 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -685,17 +685,17 @@ static long region_del(struct resv_map *resv, long f,
long t)
}
if (f <= rg->from) {/* Trim beginning of region */
- del += t - rg->from;
- rg->from = t;
-
hugetlb_cgroup_uncharge_file_region(resv, rg,
t - rg->from);
- } else {/* Trim end of region */
- del += rg->to - f;
- rg->to = f;
+ del += t - rg->from;
+ rg->from = t;
+ } else {/* Trim end of region */
hugetlb_cgroup_uncharge_file_region(resv, rg,
rg->to - f);
+
+ del += rg->to - f;
+ rg->to = f;
}
}
@@ -2454,6 +2454,9 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
rsv_adjust = hugepage_subpool_put_pages(spool, 1);
hugetlb_acct_memory(h, -rsv_adjust);
+ if (deferred_reserve)
+ hugetlb_cgroup_uncharge_page_rsvd(hstate_index(h),
+ pages_per_huge_page(h), page);
}
return page;
--
2.25.4
Re: [PATCH] net: ftgmac100: Ensure tx descriptor updates are visible
On Wed, 21 Oct 2020 at 00:00, Benjamin Herrenschmidt
wrote:
>
> On Wed, 2020-10-21 at 08:36 +1030, Joel Stanley wrote:
> > We must ensure the tx descriptor updates are visible before updating
> > the tx pointer.
> >
> > This resolves the tx hangs observed on the 2600 when running iperf:
>
> To clarify the comment here. This doesn't ensure they are visible to
> the hardware but to other CPUs. This is the ordering vs start_xmit and
> tx_complete.
Thanks. Let me know if this makes sense, or if I'm completely off the mark.
How is this for the commit message:
This resolves the tx hangs observed on the 2600 when running iperf.
This is ensuring the setting of the OWN bit in txdes0 of the
descriptor is visible to other CPUs before updating the pointer. Doing
this provides ordering between start_xmit and tx_complete.
and then I'll put:
/* Ensure the descriptor config is visible to other CPUs before setting
* the tx pointer. This ensures ordering against start_xmit which checks
* the OWN bit before proceeding.
*/
and similar for tx_complete?
>
> Cheers,
> Ben.
>
> > root@ast2600:~# iperf3 -c 192.168.86.146 -R
> > Connecting to host 192.168.86.146, port 5201
> > Reverse mode, remote host 192.168.86.146 is sending
> > [ 5] local 192.168.86.173 port 43886 connected to 192.168.86.146
> > port 5201
> > [ ID] Interval Transfer Bitrate
> > [ 5] 0.00-1.00 sec 90.7 MBytes 760 Mbits/sec
> > [ 5] 1.00-2.00 sec 91.7 MBytes 769 Mbits/sec
> > [ 5] 2.00-3.00 sec 91.7 MBytes 770 Mbits/sec
> > [ 5] 3.00-4.00 sec 91.7 MBytes 769 Mbits/sec
> > [ 5] 4.00-5.00 sec 91.8 MBytes 771 Mbits/sec
> > [ 5] 5.00-6.00 sec 91.8 MBytes 771 Mbits/sec
> > [ 5] 6.00-7.00 sec 91.9 MBytes 771 Mbits/sec
> > [ 5] 7.00-8.00 sec 91.4 MBytes 767 Mbits/sec
> > [ 5] 8.00-9.00 sec 91.3 MBytes 766 Mbits/sec
> > [ 5] 9.00-10.00 sec 91.9 MBytes 771 Mbits/sec
> > [ 5] 10.00-11.00 sec 91.8 MBytes 770 Mbits/sec
> > [ 5] 11.00-12.00 sec 91.8 MBytes 770 Mbits/sec
> > [ 5] 12.00-13.00 sec 90.6 MBytes 761 Mbits/sec
> > [ 5] 13.00-14.00 sec 45.2 KBytes 370 Kbits/sec
> > [ 5] 14.00-15.00 sec 0.00 Bytes 0.00 bits/sec
> > [ 5] 15.00-16.00 sec 0.00 Bytes 0.00 bits/sec
> > [ 5] 16.00-17.00 sec 0.00 Bytes 0.00 bits/sec
> > [ 5] 17.00-18.00 sec 0.00 Bytes 0.00 bits/sec
> > [ 67.031671] [ cut here ]
> > [ 67.036870] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:442
> > dev_watchdog+0x2dc/0x300
> > [ 67.046123] NETDEV WATCHDOG: eth2 (ftgmac100): transmit queue 0
> > timed out
> >
> > Fixes: 52c0cae87465 ("ftgmac100: Remove tx descriptor accessors")
> > Signed-off-by: Joel Stanley
> > ---
> > drivers/net/ethernet/faraday/ftgmac100.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/faraday/ftgmac100.c
> > b/drivers/net/ethernet/faraday/ftgmac100.c
> > index 331d4bdd4a67..15cdfeb135b0 100644
> > --- a/drivers/net/ethernet/faraday/ftgmac100.c
> > +++ b/drivers/net/ethernet/faraday/ftgmac100.c
> > @@ -653,6 +653,11 @@ static bool ftgmac100_tx_complete_packet(struct
> > ftgmac100 *priv)
> > ftgmac100_free_tx_packet(priv, pointer, skb, txdes, ctl_stat);
> > txdes->txdes0 = cpu_to_le32(ctl_stat & priv-
> > >txdes0_edotr_mask);
> >
> > + /* Ensure the descriptor config is visible before setting the
> > tx
> > + * pointer.
> > + */
> > + smp_wmb();
> > +
> > priv->tx_clean_pointer = ftgmac100_next_tx_pointer(priv,
> > pointer);
> >
> > return true;
> > @@ -806,6 +811,11 @@ static netdev_tx_t
> > ftgmac100_hard_start_xmit(struct sk_buff *skb,
> > dma_wmb();
> > first->txdes0 = cpu_to_le32(f_ctl_stat);
> >
> > + /* Ensure the descriptor config is visible before setting the
> > tx
> > + * pointer.
> > + */
> > + smp_wmb();
> > +
> > /* Update next TX pointer */
> > priv->tx_pointer = pointer;
> >
>
[PATCH kernel 0/2] powerpc/dma: Fallback to dma_ops when persistent memory present
This allows mixing direct DMA (to/from RAM) and IOMMU (to/from apersistent memory) on the PPC64/pseries platform. This was supposed to be a single patch but unexpected move of direct DMA functions happened. This is based on sha1 7cf726a59435 Linus Torvalds "Merge tag 'linux-kselftest-kunit-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest". Please comment. Thanks. Alexey Kardashevskiy (2): Revert "dma-mapping: move large parts of to kernel/dma" powerpc/dma: Fallback to dma_ops when persistent memory present include/linux/dma-direct.h | 106 ++ kernel/dma/direct.h| 119 - arch/powerpc/kernel/dma-iommu.c| 68 +- arch/powerpc/platforms/pseries/iommu.c | 41 +++-- kernel/dma/direct.c| 2 +- kernel/dma/mapping.c | 2 +- 6 files changed, 207 insertions(+), 131 deletions(-) delete mode 100644 kernel/dma/direct.h -- 2.17.1
[PATCH kernel 2/2] powerpc/dma: Fallback to dma_ops when persistent memory present
So far we have been using huge DMA windows to map all the RAM available.
The RAM is normally mapped to the VM address space contiguously, and
there is always a reasonable upper limit for possible future hot plugged
RAM which makes it easy to map all RAM via IOMMU.
Now there is persistent memory ("ibm,pmemory" in the FDT) which (unlike
normal RAM) can map anywhere in the VM space beyond the maximum RAM size
and since it can be used for DMA, it requires extending the huge window
up to MAX_PHYSMEM_BITS which requires hypervisor support for:
1. huge TCE tables;
2. multilevel TCE tables;
3. huge IOMMU pages.
Certain hypervisors cannot do either so the only option left is
restricting the huge DMA window to include only RAM and fallback to
the default DMA window for persistent memory.
This checks if the system has persistent memory. If it does not,
the DMA bypass mode is selected, i.e.
* dev->bus_dma_limit = 0
* dev->dma_ops_bypass = true <- this avoid calling dma_ops for mapping.
If there is such memory, this creates identity mapping only for RAM and
disables the DMA bypass mode which makes generic DMA code use indirect
dma_ops which may have performance impact:
* dev->bus_dma_limit = bus_offset + max_ram_size
for example 0x0800..8000. for a 2GB VM
* dev->dma_ops_bypass = false <- this forces indirect calls to dma_ops for
every mapping which then directs these to small or huge window.
This should not change the existing behaviour when no persistent memory.
Signed-off-by: Alexey Kardashevskiy
---
Without reverting 19c65c3d30bb5a97170, I could have added
I can repost if this is preferrable. Thanks.
---
Changelog:
v2:
* rebased on current upstream with the device::bypass added and DMA
direct code movement reverted
---
arch/powerpc/kernel/dma-iommu.c| 68 +-
arch/powerpc/platforms/pseries/iommu.c | 41 +---
2 files changed, 99 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index a1c744194018..9a2a3b95f72d 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -10,6 +10,16 @@
#include
#include
+static inline bool can_map_direct(struct device *dev, phys_addr_t addr)
+{
+ return dev->bus_dma_limit >= phys_to_dma(dev, addr);
+}
+
+static inline bool dma_handle_direct(struct device *dev, dma_addr_t dma_handle)
+{
+ return dma_handle >= dev->archdata.dma_offset;
+}
+
/*
* Generic iommu implementation
*/
@@ -44,6 +54,12 @@ static dma_addr_t dma_iommu_map_page(struct device *dev,
struct page *page,
enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit &&
+ can_map_direct(dev, (phys_addr_t) page_to_phys(page) +
+ offset + size))
+ return dma_direct_map_page(dev, page, offset, size, direction,
+ attrs);
+
return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
size, dma_get_mask(dev), direction, attrs);
}
@@ -53,6 +69,12 @@ static void dma_iommu_unmap_page(struct device *dev,
dma_addr_t dma_handle,
size_t size, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit &&
+ dma_handle_direct(dev, dma_handle + size)) {
+ dma_direct_unmap_page(dev, dma_handle, size, direction, attrs);
+ return;
+ }
+
iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
attrs);
}
@@ -62,6 +84,22 @@ static int dma_iommu_map_sg(struct device *dev, struct
scatterlist *sglist,
int nelems, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit) {
+ struct scatterlist *s;
+ bool direct = true;
+ int i;
+
+ for_each_sg(sglist, s, nelems, i) {
+ direct = can_map_direct(dev,
+ sg_phys(s) + s->offset + s->length);
+ if (!direct)
+ break;
+ }
+ if (direct)
+ return dma_direct_map_sg(dev, sglist, nelems, direction,
+attrs);
+ }
+
return ppc_iommu_map_sg(dev, get_iommu_table_base(dev), sglist, nelems,
dma_get_mask(dev), direction, attrs);
}
@@ -70,6 +108,24 @@ static void dma_iommu_unmap_sg(struct device *dev, struct
scatterlist *sglist,
int nelems, enum dma_data_direction direction,
unsigned long attrs)
{
+ if (dev->bus_dma_limit) {
+ struct scatterlist *s;
+ bool direct
[PATCH kernel 1/2] Revert "dma-mapping: move large parts of to kernel/dma"
This reverts commit 19c65c3d30bb5a97170e425979d2e44ab2096c7d which
was a right move but sadly there is a POWERPC/pseries hardware config
which uses a mixture of direct and IOMMU DMA but bringing this
logic to the generic code won't benefit anybody else. The user of
this revert comes in the next patch.
Signed-off-by: Alexey Kardashevskiy
---
include/linux/dma-direct.h | 106 +
kernel/dma/direct.h| 119 -
kernel/dma/direct.c| 2 +-
kernel/dma/mapping.c | 2 +-
4 files changed, 108 insertions(+), 121 deletions(-)
delete mode 100644 kernel/dma/direct.h
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 18aade195884..e388b77e0048 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -120,8 +120,114 @@ struct page *dma_direct_alloc_pages(struct device *dev,
size_t size,
void dma_direct_free_pages(struct device *dev, size_t size,
struct page *page, dma_addr_t dma_addr,
enum dma_data_direction dir);
+int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs);
+bool dma_direct_can_mmap(struct device *dev);
+int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t dma_addr, size_t size,
+ unsigned long attrs);
int dma_direct_supported(struct device *dev, u64 mask);
+bool dma_direct_need_sync(struct device *dev, dma_addr_t dma_addr);
+int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
+ enum dma_data_direction dir, unsigned long attrs);
dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
size_t size, enum dma_data_direction dir, unsigned long attrs);
+size_t dma_direct_max_mapping_size(struct device *dev);
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
+defined(CONFIG_SWIOTLB)
+void dma_direct_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir);
+#else
+static inline void dma_direct_sync_sg_for_device(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction dir)
+{
+}
+#endif
+
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
+defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL) || \
+defined(CONFIG_SWIOTLB)
+void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sgl,
+ int nents, enum dma_data_direction dir, unsigned long attrs);
+void dma_direct_sync_sg_for_cpu(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction
dir);
+#else
+static inline void dma_direct_unmap_sg(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+}
+static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
+ struct scatterlist *sgl, int nents, enum dma_data_direction dir)
+{
+}
+#endif
+
+static inline void dma_direct_sync_single_for_device(struct device *dev,
+ dma_addr_t addr, size_t size, enum dma_data_direction dir)
+{
+ phys_addr_t paddr = dma_to_phys(dev, addr);
+
+ if (unlikely(is_swiotlb_buffer(paddr)))
+ swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE);
+
+ if (!dev_is_dma_coherent(dev))
+ arch_sync_dma_for_device(paddr, size, dir);
+}
+
+static inline void dma_direct_sync_single_for_cpu(struct device *dev,
+ dma_addr_t addr, size_t size, enum dma_data_direction dir)
+{
+ phys_addr_t paddr = dma_to_phys(dev, addr);
+
+ if (!dev_is_dma_coherent(dev)) {
+ arch_sync_dma_for_cpu(paddr, size, dir);
+ arch_sync_dma_for_cpu_all();
+ }
+
+ if (unlikely(is_swiotlb_buffer(paddr)))
+ swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_CPU);
+
+ if (dir == DMA_FROM_DEVICE)
+ arch_dma_mark_clean(paddr, size);
+}
+
+static inline dma_addr_t dma_direct_map_page(struct device *dev,
+ struct page *page, unsigned long offset, size_t size,
+ enum dma_data_direction dir, unsigned long attrs)
+{
+ phys_addr_t phys = page_to_phys(page) + offset;
+ dma_addr_t dma_addr = phys_to_dma(dev, phys);
+
+ if (unlikely(swiotlb_force == SWIOTLB_FORCE))
+ return swiotlb_map(dev, phys, size, dir, attrs);
+
+ if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
+ if (swiotlb_force != SWIOTLB_NO_FORCE)
+ return swiotlb_map(dev, phys, size, dir, attrs);
+
+ dev_WARN_ONCE(dev, 1,
+"DMA addr %pad+%zu overflow (mask %llx, bus limit
%llx).\n",
+_addr, size, *dev->dma_mask,
dev->bus_dma_limit);
+
Re: [GIT PULL] prandom32 changes for v5.10
Hi Linus, On Tue, Oct 20, 2020 at 04:08:03PM -0700, Linus Torvalds wrote: > On Tue, Oct 20, 2020 at 12:26 PM Amit Klein wrote: > > > > Quick question: is this patch still planned for inclusion in 5.10-rc1? > > It doesn't even build for me, so no. It clearly hasn't been in > linux-next or anything like that. > > Hint: grep for prandom_seed_early. I'm a bit surprised, as it worked for me, but thanks for checking. Given the lack of responses from many participants on these patches, on several occations I feel that this series is really not welcome. Initially I just tried to test and fix Spelvin's patch, but if there's not that much interest in it, or even reluctance, I'd rather stop. If it's just that the current state is ugly with the two PRNGs side by side, I can get back to completely removing the original one as I did in my first series, and propose a larger series. Or if nobody's interested, I'd rather know so that I don't have to put more time on it :-/ Thanks for letting me know, Willy
Re: [PATCH 1/1] kobject: Don't emit change events if not in sysfs
Hi Greg, I was debugging without a live repro and I was told this patch improved behavior but it's only by chance (someone bisected a Dell D6000 dock's displayport issue to this commit and this change seemed to help; udev logs later shows that's not the case). I took another look at device_init_wakeup and I can see that device_set_wakeup_capable does indeed check for device_is_registered before adding the wakeup attributes so the ordering of events I suspected cannot occur. Thanks for pushing back Greg. It made me take a deeper look at an assumption I hadn't challenged. Please consider this patch abandoned. Abhishek On Mon, Oct 19, 2020 at 10:56 PM Greg Kroah-Hartman wrote: > > On Mon, Oct 19, 2020 at 03:32:57PM -0700, Abhishek Pandit-Subedi wrote: > > Add a check to make sure the kobj is created and in sysfs before sending > > a change event notification. Otherwise, udev rules that depend on the > > change notification may find that the path that changed doesn't actually > > exist. > > Why is the user of the kobject trying to emit a uevent before it is > registered? Shouldn't we fix the root problem here instead? Otherwise > the event is still "gone", the caller will not know what to do about it. > > Please fix the root problem here. > > thanks, > > greg k-h
[PATCH] mm: bio_alloc never fails when set GFP_NOIO, GFP_KERNEL
bio_alloc with __GFP_DIRECT_RECLAIM(which is included in GFP_NOIO,
GFP_KERNEL) never fails, as stated in the comments of bio_alloc_bioset.
So we can remove multiple unneeded null checks of bio_alloc and simplify
the code.
We have done it in fs/ext4/readpage.c, fs/ext4/page-io.c, fs/direct-io.c,
and so forth.
Signed-off-by: Xianting Tian
---
mm/page_io.c | 31 +++
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/mm/page_io.c b/mm/page_io.c
index e485a6e8a..9215bb356 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -30,18 +30,20 @@ static struct bio *get_swap_bio(gfp_t gfp_flags,
struct page *page, bio_end_io_t end_io)
{
struct bio *bio;
+ struct block_device *bdev;
+ /*
+* bio_alloc will _always_ be able to allocate a bio if
+* __GFP_DIRECT_RECLAIM is set, see comments for bio_alloc_bioset().
+*/
bio = bio_alloc(gfp_flags, 1);
- if (bio) {
- struct block_device *bdev;
+ bio->bi_iter.bi_sector = map_swap_page(page, );
+ bio_set_dev(bio, bdev);
+ bio->bi_iter.bi_sector <<= PAGE_SHIFT - 9;
+ bio->bi_end_io = end_io;
- bio->bi_iter.bi_sector = map_swap_page(page, );
- bio_set_dev(bio, bdev);
- bio->bi_iter.bi_sector <<= PAGE_SHIFT - 9;
- bio->bi_end_io = end_io;
+ bio_add_page(bio, page, thp_size(page), 0);
- bio_add_page(bio, page, thp_size(page), 0);
- }
return bio;
}
@@ -351,19 +353,13 @@ int __swap_writepage(struct page *page, struct
writeback_control *wbc,
ret = 0;
bio = get_swap_bio(GFP_NOIO, page, end_write_func);
- if (bio == NULL) {
- set_page_dirty(page);
- unlock_page(page);
- ret = -ENOMEM;
- goto out;
- }
bio->bi_opf = REQ_OP_WRITE | REQ_SWAP | wbc_to_write_flags(wbc);
bio_associate_blkg_from_page(bio, page);
count_swpout_vm_event(page);
set_page_writeback(page);
unlock_page(page);
submit_bio(bio);
-out:
+
return ret;
}
@@ -416,11 +412,6 @@ int swap_readpage(struct page *page, bool synchronous)
ret = 0;
bio = get_swap_bio(GFP_KERNEL, page, end_swap_bio_read);
- if (bio == NULL) {
- unlock_page(page);
- ret = -ENOMEM;
- goto out;
- }
disk = bio->bi_disk;
/*
* Keep this task valid during swap readpage because the oom killer may
--
2.17.1
Re: [PATCH v7 1/4] KEYS: trusted: Add generic trusted keys framework
On Wed, 2020-10-07 at 15:37 +0530, Sumit Garg wrote:
> +/*
> + * trusted_destroy - clear and free the key's payload
> + */
> +static void trusted_destroy(struct key *key)
> +{
> + kfree_sensitive(key->payload.data[0]);
> +}
> +
> +struct key_type key_type_trusted = {
> + .name = "trusted",
> + .instantiate = trusted_instantiate,
> + .update = trusted_update,
> + .destroy = trusted_destroy,
> + .describe = user_describe,
> + .read = trusted_read,
> +};
> +EXPORT_SYMBOL_GPL(key_type_trusted);
> +
> +static int __init init_trusted(void)
> +{
> + int i, ret = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
> + if (trusted_key_source &&
> + strncmp(trusted_key_source, trusted_key_sources[i].name,
> + strlen(trusted_key_sources[i].name)))
> + continue;
> +
> + trusted_key_ops = trusted_key_sources[i].ops;
> +
> + ret = trusted_key_ops->init();
> + if (!ret)
> + break;
> + }
In the case when the module paramater isn't specified and both TPM and
TEE are enabled, trusted_key_ops is set to the last source initialized.
After patch 2/4, the last trusted source initialized is TEE. If the
intention is to limit it to either TPM or TEE, then trusted_key_ops
should have a default value, which could be overwritten at runtime.
That would address Luke Hind's concerns of making the decision at
compile time.
trusted_key_ops should be defined as __ro_after_init, like is currently
done for other LSM structures.
> +
> + /*
> + * encrypted_keys.ko depends on successful load of this module even if
> + * trusted key implementation is not found.
> + */
> + if (ret == -ENODEV)
> + return 0;
> +
> + return ret;
> +}
> +
> +static void __exit cleanup_trusted(void)
> +{
> + trusted_key_ops->exit();
If the intention is really to support both TPM and TEE trusted keys at
the same time, as James suggested, then the same "for" loop as in
init_trusted() is needed here and probably elsewhere.
thanks,
Mimi
Re: [PATCH v7 1/4] powerpc: Refactor kexec functions to move arch independent code to kernel
On Tue, 2020-10-20 at 19:25 -0700, Lakshmi Ramasubramanian wrote: > On 10/20/20 1:00 PM, Mimi Zohar wrote: > > Hi Lakshmi, > > > > On Wed, 2020-09-30 at 13:59 -0700, Lakshmi Ramasubramanian wrote: > >> The functions remove_ima_buffer() and delete_fdt_mem_rsv() that handle > >> carrying forward the IMA measurement logs on kexec for powerpc do not > >> have architecture specific code, but they are currently defined for > >> powerpc only. > >> > >> remove_ima_buffer() and delete_fdt_mem_rsv() are used to remove > >> the IMA log entry from the device tree and free the memory reserved > >> for the log. These functions need to be defined even if the current > >> kernel does not support carrying forward IMA log across kexec since > >> the previous kernel could have supported that and therefore the current > >> kernel needs to free the allocation. > >> > >> Rename remove_ima_buffer() to remove_ima_kexec_buffer(). > >> Define remove_ima_kexec_buffer() and delete_fdt_mem_rsv() in kernel. > >> A later patch in this series will use these functions to free > >> the allocation, if any, made by the previous kernel for ARM64. > >> > >> Define FDT_PROP_IMA_KEXEC_BUFFER for the chosen node, namely > >> "linux,ima-kexec-buffer", that is added to the DTB to hold > >> the address and the size of the memory reserved to carry > >> the IMA measurement log. > > > >> Co-developed-by: Prakhar Srivastava > >> Signed-off-by: Prakhar Srivastava > >> Signed-off-by: Lakshmi Ramasubramanian > >> Reported-by: kernel test robot error: implicit > >> declaration of function 'delete_fdt_mem_rsv' > >> [-Werror,-Wimplicit-function-declaration] > > > > Much better! This version limits unnecessarily changing the existing > > code to adding a couple of debugging statements, but that looks to be > > about it. > Yes Mimi - that's correct. > > > > > Based on Chester Lin's "ima_arch" support for arm64 discussion, the IMA > > generic > > EFI support will be defined in ima/ima-efi.c. Similarly, I think it would > > make sense to put the generic device tree support in ima/ima_kexec_fdt.c or > > ima/ima_fdt.c, as opposed to kernel/. (Refer to my comments on 2/4 about > > the new file named ima_kexec_fdt.c.) > > The functions remove_ima_kexec_buffer() and delete_fdt_mem_rsv(), which > are defined in kernel/ima_kexec.c and kernel/kexec_file_fdt.c > respectively, are needed even when CONFIG_IMA is not defined. These > functions need to be called by the current kernel to free the ima kexec > buffer resources allocated by the previous kernel. This is the reason, > these functions are defined under "kernel" instead of > "security/integrity/ima". > > If there is a better location to move the above C files, please let me > know. I'll move them. Freeing the previous kernel measurement list is currently called from ima_load_kexec_buffer(), only after the measurement list has been restored. The only other time the memory is freed is when the allocated memory size isn't sufficient to hold the measurement list, which could happen if there is a delay between loading and executing the kexec. thanks, Mimi
Re: [PATCH] scsi: ufs: make sure scan sequence for multiple hosts
On 10/20/20 12:05 AM, Chanho Park wrote: > By doing scan as asynchronous way, scsi device scannning can be out of > order execution. It is no problem if there is a ufs host but the scsi > device name of each host can be changed according to the scan sequences. > > Ideal Case) host0 scan first > host0 will be started from /dev/sda > -> /dev/sdb (BootLUN0 of host0) > -> /dev/sdc (BootLUN1 of host1) > host1 will be started from /dev/sdd > > This might be an ideal case and we can easily find the host device by > this mappinng. > > However, Abnormal Case) host1 scan first, > host1 will be started from /dev/sda and host0 will be followed later. > > To make sure the scan sequences according to the host, we can use a > bitmap which hosts are scanned and wait until previous hosts are > finished to scan. This sounds completely wrong to me. No code should depend on the order in which LUNs are scanned. Please use the soft links created by udev instead of serializing LUN scanning. Thanks, Bart.
[PATCH] FROMLIST: input: add 2 kind of switch
>From ec9859ee01b7bc0e04255971e0fe97348847dab7 Mon Sep 17 00:00:00 2001
From: "hj2.im"
Date: Tue, 20 Oct 2020 16:57:04 +0900
Subject: [PATCH] FROMLIST: input: add 2 kind of switch
We need support to various accessories on the device,
some switch does not exist in switch list.
So added switch for the following purpose.
SW_COVER_ATTACHED is for the checking the cover
attached or not on the device. SW_EXT_PEN_ATTACHED is for the
checking the external pen attached or not on the device
Signed-off-by: hj2.im
---
include/linux/mod_devicetable.h| 2 +-
include/uapi/linux/input-event-codes.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 5b08a473cdba..897f5a3e7721 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -320,7 +320,7 @@ struct pcmcia_device_id {
#define INPUT_DEVICE_ID_LED_MAX0x0f
#define INPUT_DEVICE_ID_SND_MAX0x07
#define INPUT_DEVICE_ID_FF_MAX 0x7f
-#define INPUT_DEVICE_ID_SW_MAX 0x10
+#define INPUT_DEVICE_ID_SW_MAX 0x12
#define INPUT_DEVICE_ID_PROP_MAX 0x1f
#define INPUT_DEVICE_ID_MATCH_BUS 1
diff --git a/include/uapi/linux/input-event-codes.h
b/include/uapi/linux/input-event-codes.h
index 0c2e27d28e0a..8ca2acee1f92 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -889,7 +889,9 @@
#define SW_MUTE_DEVICE 0x0e /* set = device disabled */
#define SW_PEN_INSERTED0x0f /* set = pen inserted */
#define SW_MACHINE_COVER 0x10 /* set = cover closed */
-#define SW_MAX 0x10
+#define SW_COVER_ATTACHED 0x11 /* set = cover attached */
+#define SW_EXT_PEN_ATTACHED0x12 /* set = external pen attached */
+#define SW_MAX 0x12
#define SW_CNT (SW_MAX+1)
/*
--
2.11.0
[PATCH] FROMLIST: input: add 2 kind of switch
From ec9859ee01b7bc0e04255971e0fe97348847dab7 Mon Sep 17 00:00:00 2001
From: "hj2.im"
Date: Tue, 20 Oct 2020 16:57:04 +0900
Subject: [PATCH] FROMLIST: input: add 2 kind of switch
We need support to various accessories on the device,
some switch does not exist in switch list.
So added switch for the following purpose.
SW_COVER_ATTACHED is for the checking the cover
attached or not on the device. SW_EXT_PEN_ATTACHED is for the
checking the external pen attached or not on the device
Signed-off-by: hj2.im
---
include/linux/mod_devicetable.h| 2 +-
include/uapi/linux/input-event-codes.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 5b08a473cdba..897f5a3e7721 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -320,7 +320,7 @@ struct pcmcia_device_id {
#define INPUT_DEVICE_ID_LED_MAX0x0f
#define INPUT_DEVICE_ID_SND_MAX0x07
#define INPUT_DEVICE_ID_FF_MAX0x7f
-#define INPUT_DEVICE_ID_SW_MAX0x10
+#define INPUT_DEVICE_ID_SW_MAX0x12
#define INPUT_DEVICE_ID_PROP_MAX0x1f
#define INPUT_DEVICE_ID_MATCH_BUS1
diff --git a/include/uapi/linux/input-event-codes.h
b/include/uapi/linux/input-event-codes.h
index 0c2e27d28e0a..8ca2acee1f92 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -889,7 +889,9 @@
#define SW_MUTE_DEVICE0x0e /* set = device disabled */
#define SW_PEN_INSERTED0x0f /* set = pen inserted */
#define SW_MACHINE_COVER0x10 /* set = cover closed */
-#define SW_MAX0x10
+#define SW_COVER_ATTACHED0x11 /* set = cover attached */
+#define SW_EXT_PEN_ATTACHED0x12 /* set = external pen attached */
+#define SW_MAX0x12
#define SW_CNT(SW_MAX+1)
/*
--
2.11.0
[PATCH v2] Bluetooth: btusb: Add support for LG LGSBWAC92/TWCM-K505D
The LG LGSBWAC92/TWCM-K505D/EAT64454801/EAT64454802 (it goes by many
names) is a combo WiFi/Bluetooth module that's used in several models of
LG TVs. It uses the MediaTek MT7668AUN, which is already supported in
btusb, but this device has a non-MediaTek USB VID so to get it to work
we just need to add it to the list of devices to probe.
Device from /sys/kernel/debug/usb/devices:
T: Bus=09 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=043e ProdID=3109 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=0
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Forest Crossman
---
Changes from v1:
- Added /sys/kernel/debug/usb/devices info.
- Specify device with USB_DEVICE_AND_INTERFACE_INFO instead of just
USB_DEVICE.
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5f022e9cf667..fbc7b87f0190 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -366,6 +366,8 @@ static const struct usb_device_id blacklist_table[] = {
/* MediaTek Bluetooth devices */
{ USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, 0xe0, 0x01, 0x01),
.driver_info = BTUSB_MEDIATEK },
+ { USB_DEVICE_AND_INTERFACE_INFO(0x043e, 0x3109, 0xe0, 0x01, 0x01),
+ .driver_info = BTUSB_MEDIATEK },
/* Additional Realtek 8723AE Bluetooth devices */
{ USB_DEVICE(0x0930, 0x021d), .driver_info = BTUSB_REALTEK },
--
2.20.1
[PATCH] thermal: replace spin_lock_irqsave by spin_lock in hard IRQ
The code has been in a irq-disabled context since it is hard IRQ. There
is no necessity to do it again.
Signed-off-by: Tian Tao
---
drivers/thermal/rcar_thermal.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 5c2a13b..6ae757d 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -409,16 +409,15 @@ static irqreturn_t rcar_thermal_irq(int irq, void *data)
{
struct rcar_thermal_common *common = data;
struct rcar_thermal_priv *priv;
- unsigned long flags;
u32 status, mask;
- spin_lock_irqsave(>lock, flags);
+ spin_lock(>lock);
mask= rcar_thermal_common_read(common, INTMSK);
status = rcar_thermal_common_read(common, STR);
rcar_thermal_common_write(common, STR, 0x000F0F0F & mask);
- spin_unlock_irqrestore(>lock, flags);
+ spin_unlock(>lock);
status = status & ~mask;
--
2.7.4
arch/mips/bmips/dma.c:43:12: warning: no previous prototype for 'phys_to_dma'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c4d6fe7311762f2e03b3c27ad38df7c40c80cc93
commit: 5ceda74093a5c1c3f42a02b894df031f3bbc9af1 dma-direct: rename and cleanup
__phys_to_dma
date: 6 weeks ago
config: mips-randconfig-r022-20201021 (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5ceda74093a5c1c3f42a02b894df031f3bbc9af1
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 5ceda74093a5c1c3f42a02b894df031f3bbc9af1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> arch/mips/bmips/dma.c:43:12: warning: no previous prototype for
>> 'phys_to_dma' [-Wmissing-prototypes]
43 | dma_addr_t phys_to_dma(struct device *dev, phys_addr_t pa)
|^~~
arch/mips/bmips/dma.c:55:13: warning: no previous prototype for
'dma_to_phys' [-Wmissing-prototypes]
55 | phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
| ^~~
arch/mips/bmips/dma.c:67:6: warning: no previous prototype for
'arch_sync_dma_for_cpu_all' [-Wmissing-prototypes]
67 | void arch_sync_dma_for_cpu_all(void)
| ^
vim +/phys_to_dma +43 arch/mips/bmips/dma.c
42
> 43 dma_addr_t phys_to_dma(struct device *dev, phys_addr_t pa)
44 {
45 struct bmips_dma_range *r;
46
47 for (r = bmips_dma_ranges; r && r->size; r++) {
48 if (pa >= r->child_addr &&
49 pa < (r->child_addr + r->size))
50 return pa - r->child_addr + r->parent_addr;
51 }
52 return pa;
53 }
54
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] FROMLIST: input: add 2 kind of switch
>From ec9859ee01b7bc0e04255971e0fe97348847dab7 Mon Sep 17 00:00:00 2001
From: "hj2.im"
Date: Tue, 20 Oct 2020 16:57:04 +0900
Subject: [PATCH] FROMLIST: input: add 2 kind of switch
We need support to various accessories on the device,
some switch does not exist in switch list.
So added switch for the following purpose.
SW_COVER_ATTACHED is for the checking the cover
attached or not on the device. SW_EXT_PEN_ATTACHED is for the
checking the external pen attached or not on the device
Signed-off-by: hj2.im
---
include/linux/mod_devicetable.h| 2 +-
include/uapi/linux/input-event-codes.h | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 5b08a473cdba..897f5a3e7721 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -320,7 +320,7 @@ struct pcmcia_device_id {
#define INPUT_DEVICE_ID_LED_MAX0x0f
#define INPUT_DEVICE_ID_SND_MAX0x07
#define INPUT_DEVICE_ID_FF_MAX 0x7f
-#define INPUT_DEVICE_ID_SW_MAX 0x10
+#define INPUT_DEVICE_ID_SW_MAX 0x12
#define INPUT_DEVICE_ID_PROP_MAX 0x1f
#define INPUT_DEVICE_ID_MATCH_BUS 1
diff --git a/include/uapi/linux/input-event-codes.h
b/include/uapi/linux/input-event-codes.h
index 0c2e27d28e0a..8ca2acee1f92 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -889,7 +889,9 @@
#define SW_MUTE_DEVICE 0x0e /* set = device disabled */
#define SW_PEN_INSERTED0x0f /* set = pen inserted */
#define SW_MACHINE_COVER 0x10 /* set = cover closed */
-#define SW_MAX 0x10
+#define SW_COVER_ATTACHED 0x11 /* set = cover attached */
+#define SW_EXT_PEN_ATTACHED0x12 /* set = external pen attached */
+#define SW_MAX 0x12
#define SW_CNT (SW_MAX+1)
/*
--
2.11.0
Re: [PATCH v3 01/16] dt-bindings: usb: usb-hcd: Convert generic USB properties to DT schema
On Tue, 2020-10-20 at 14:20 +0300, Serge Semin wrote:
> The generic USB HCD properties have been described in the legacy bindings
> text file: Documentation/devicetree/bindings/usb/generic.txt . Let's
> convert it' content into the USB HCD DT schema properties so all USB DT
^ its?
> nodes would be validated to have them properly utilized.
>
> Signed-off-by: Serge Semin
> Reviewed-by: Rob Herring
>
> ---
>
> Changelog v2:
> - Discard '|' in all the new properties, since we don't need to preserve
> the text formatting.
> - Convert abbreviated form of the "maximum-speed" enum restriction into
> the multi-lined version of the list.
> - Drop quotes from around the string constants.
> ---
> .../devicetree/bindings/usb/generic.txt | 57
> .../devicetree/bindings/usb/usb-hcd.yaml | 88 +++
Do we need change the file name or modify it's title?
the title is "Generic USB Host Controller Device Tree Bindings", but
some generic properties, such as, dr_mode, usb-role-switch, otg related
ones, are usually used by DRD controller, this may cause some confusion.
> 2 files changed, 88 insertions(+), 57 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/generic.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> b/Documentation/devicetree/bindings/usb/generic.txt
> deleted file mode 100644
> index ba472e7aefc9..
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ /dev/null
> @@ -1,57 +0,0 @@
> -Generic USB Properties
> -
> -Optional properties:
> - - maximum-speed: tells USB controllers we want to work up to a certain
> - speed. Valid arguments are "super-speed-plus",
> - "super-speed", "high-speed", "full-speed" and
> - "low-speed". In case this isn't passed via DT, USB
> - controllers should default to their maximum HW
> - capability.
> - - dr_mode: tells Dual-Role USB controllers that we want to work on a
> - particular mode. Valid arguments are "host",
> - "peripheral" and "otg". In case this attribute isn't
> - passed via DT, USB DRD controllers should default to
> - OTG.
> - - phy_type: tells USB controllers that we want to configure the core to
> support
> - a UTMI+ PHY with an 8- or 16-bit interface if UTMI+ is
> - selected. Valid arguments are "utmi" and "utmi_wide".
> - In case this isn't passed via DT, USB controllers should
> - default to HW capability.
> - - otg-rev: tells usb driver the release number of the OTG and EH supplement
> - with which the device and its descriptors are compliant,
> - in binary-coded decimal (i.e. 2.0 is 0200H). This
> - property is used if any real OTG features(HNP/SRP/ADP)
> - is enabled, if ADP is required, otg-rev should be
> - 0x0200 or above.
> - - companion: phandle of a companion
> - - hnp-disable: tells OTG controllers we want to disable OTG HNP, normally
> HNP
> - is the basic function of real OTG except you want it
> - to be a srp-capable only B device.
> - - srp-disable: tells OTG controllers we want to disable OTG SRP, SRP is
> - optional for OTG device.
> - - adp-disable: tells OTG controllers we want to disable OTG ADP, ADP is
> - optional for OTG device.
> - - usb-role-switch: boolean, indicates that the device is capable of
> assigning
> - the USB data role (USB host or USB device) for a given
> - USB connector, such as Type-C, Type-B(micro).
> - see connector/usb-connector.yaml.
> - - role-switch-default-mode: indicating if usb-role-switch is enabled, the
> - device default operation mode of controller while usb
> - role is USB_ROLE_NONE. Valid arguments are "host" and
> - "peripheral". Defaults to "peripheral" if not
> - specified.
> -
> -
> -This is an attribute to a USB controller such as:
> -
> -dwc3@4a03 {
> - compatible = "synopsys,dwc3";
> - reg = <0x4a03 0xcfff>;
> - interrupts = <0 92 4>
> - usb-phy = <_phy>, <,phy>;
> - maximum-speed = "super-speed";
> - dr_mode = "otg";
> - phy_type = "utmi_wide";
> - otg-rev = <0x0200>;
> - adp-disable;
> -};
> diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> index 7263b7f2b510..ee7ea205c71d 100644
> --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml
> @@ -22,9 +22,97 @@ properties:
> description:
>Name specifier for the USB PHY
>
[PATCH v2 2/6] spi: cadence-quadspi: Disable the DAC for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
On Intel Lightning Mountain(LGM) SoCs QSPI controller do not use
Direct Access Controller(DAC).
This patch adds a quirk to disable the Direct Access Controller
for data transfer instead it uses indirect data transfer.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/spi-cadence-quadspi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index d7b10c46fa70..3d017b484114 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1106,6 +1106,13 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ /* Disable direct access controller */
+ if (!cqspi->use_direct_mode) {
+ reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
+ reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ }
+
cqspi_controller_enable(cqspi, 1);
}
@@ -1388,6 +1395,10 @@ static const struct cqspi_driver_platdata am654_ospi = {
.quirks = CQSPI_NEEDS_WR_DELAY,
};
+static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .quirks = CQSPI_DISABLE_DAC_MODE,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
@@ -1403,6 +1414,7 @@ static const struct of_device_id cqspi_dt_ids[] = {
},
{
.compatible = "intel,lgm-qspi",
+ .data = _lgm_qspi,
},
{ /* end of table */ }
};
--
2.11.0
[PATCH v2 6/6] dt-bindings: spi: Add compatible for Intel LGM SoC
From: Ramuthevar Vadivel Murugan Add compatible string for Intel LGM SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- Documentation/devicetree/bindings/spi/cadence-quadspi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml index 57be1a730e7b..44378d2d2b9e 100644 --- a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml +++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml @@ -19,6 +19,7 @@ properties: - const: cdns,qspi-nor - const: ti,k2g-qspi, cdns,qspi-nor - const: ti,am654-ospi, cdns,qspi-nor + - const: intel,lgm-qspi, cdns,qspi-nor reg: items: -- 2.11.0
[PATCH v2 4/6] spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi
From: Ramuthevar Vadivel Murugan
Move the Documentation/devicetree/bindings/mtd/cadence-quadspi.txt to
Documentation/devicetree/bindings/spi/
Signed-off-by: Ramuthevar Vadivel Murugan
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/{mtd => spi}/cadence-quadspi.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{mtd => spi}/cadence-quadspi.txt
(100%)
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
rename to Documentation/devicetree/bindings/spi/cadence-quadspi.txt
--
2.11.0
[PATCH v2 3/6] spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add multiple chipselect support for Intel LGM SoCs,
currently QSPI-NOR and QSPI-NAND supported.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/spi-cadence-quadspi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index 3d017b484114..3bf6d3697631 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -38,6 +38,7 @@
/* Capabilities */
#define CQSPI_SUPPORTS_OCTAL BIT(0)
+#define CQSPI_SUPPORTS_MULTI_CHIPSELECT BIT(1)
struct cqspi_st;
@@ -75,6 +76,7 @@ struct cqspi_st {
boolis_decoded_cs;
u32 fifo_depth;
u32 fifo_width;
+ u32 num_chipselect;
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
@@ -1070,6 +1072,14 @@ static int cqspi_of_get_pdata(struct cqspi_st *cqspi)
return -ENXIO;
}
+ if (!cqspi->use_direct_mode) {
+ if (of_property_read_u32(np, "num-chipselect",
+>num_chipselect)) {
+ dev_err(dev, "couldn't determine number of cs\n");
+ return -ENXIO;
+ }
+ }
+
cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
return 0;
@@ -1307,6 +1317,9 @@ static int cqspi_probe(struct platform_device *pdev)
cqspi->current_cs = -1;
cqspi->sclk = 0;
+ if (ddata->hwcaps_mask & CQSPI_SUPPORTS_MULTI_CHIPSELECT)
+ master->num_chipselect = cqspi->num_chipselect;
+
ret = cqspi_setup_flash(cqspi);
if (ret) {
dev_err(dev, "failed to setup flash parameters %d\n", ret);
@@ -1396,6 +1409,7 @@ static const struct cqspi_driver_platdata am654_ospi = {
};
static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .hwcaps_mask = CQSPI_SUPPORTS_MULTI_CHIPSELECT,
.quirks = CQSPI_DISABLE_DAC_MODE,
};
--
2.11.0
[PATCH v2 5/6] dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
From: Ramuthevar Vadivel Murugan
Convert the cadence-quadspi.txt documentation to cadence-quadspi.yaml
remove the cadence-quadspi.txt from Documentation/devicetree/bindings/spi/
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/spi/cadence-quadspi.txt| 67 --
.../devicetree/bindings/spi/cadence-quadspi.yaml | 148 +
2 files changed, 148 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
deleted file mode 100644
index 945be7d5b236..
--- a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Cadence Quad SPI controller
-
-Required properties:
-- compatible : should be one of the following:
- Generic default - "cdns,qspi-nor".
- For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
- For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".
-- reg : Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
-- interrupts : Unit interrupt specifier for the controller interrupt.
-- clocks : phandle to the Quad SPI clock.
-- cdns,fifo-depth : Size of the data FIFO in words.
-- cdns,fifo-width : Bus width of the data FIFO in bytes.
-- cdns,trigger-address : 32-bit indirect AHB trigger address.
-
-Optional properties:
-- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
-- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
-
-Optional subnodes:
-Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
-custom properties:
-- cdns,read-delay : Delay for read capture logic, in clock cycles
-- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
- mode chip select outputs are de-asserted between
- transactions.
-- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
- de-activated and the activation of another.
-- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
- transaction and deasserting the device chip select
- (qspi_n_ss_out).
-- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
- and first bit transfer.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include either "qspi" and/or "qspi-ocp".
-
-Example:
-
- qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa0 0x1000>;
- interrupts = <0 151 4>;
- clocks = <_clk>;
- cdns,is-decoded-cs;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x>;
- resets = < QSPI_RESET>, < QSPI_OCP_RESET>;
- reset-names = "qspi", "qspi-ocp";
-
- flash0: n25q00@0 {
- ...
- cdns,read-delay = <4>;
- cdns,tshsl-ns = <50>;
- cdns,tsd2d-ns = <50>;
- cdns,tchsh-ns = <4>;
- cdns,tslch-ns = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
new file mode 100644
index ..57be1a730e7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/cadence-quadspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence Quad SPI controller
+
+maintainers:
+ - Vadivel Murugan
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: cdns,qspi-nor
+ - const: ti,k2g-qspi, cdns,qspi-nor
+ - const: ti,am654-ospi, cdns,qspi-nor
+
+ reg:
+items:
+ - description: the controller register set
+ - description: the controller data area
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ cdns,fifo-depth:
+description:
+ Size of the data FIFO in words.
+$ref:
[PATCH v2 0/6] spi: cadence-quadspi: Add QSPI controller support for Intel LGM SoC
Add QSPI controller support for Intel LGM SoC. Note from Vignesh(mtd subsystem maintainer): This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX that intended to move cadence-quadspi driver to spi-mem framework Those patches were trying to accomplish too many things in a single set of patches and need to split into smaller patches. This is reduced version of above series. Changes that are intended to make migration easy are split into separate patches. Patches 1 to 3 drop features that cannot be supported under spi-mem at the moment (backward compatibility is maintained). Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to spi-mem and patch 7 moves the driver to drivers/spi folder. I have tested both INDAC mode (used by non TI platforms like Altera SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs. Patches to move move bindings over to "Documentation/devicetree/bindings/spi/" directory and also conversion of bindig doc to YAML will be posted separately. Support for Intel platform would follow that. Reference: https://lkml.org/lkml/2020/6/1/50 --- v2: - Rob's review comments update for dt-bindings - add 'oneOf' for compatible selection - drop un-neccessary descriptions - add the cdns,is-decoded-cs and cdns,rclk-en properties as schema - remove 'allOf' in not required place - add AdditionalProperties false - add minItems/maxItems for qspi reset attributes resend-v1: - As per Mark's suggestion , reorder the patch series 1-3 driver support patches, series 4-6 dt-bindings patches. v1: - initial version Ramuthevar Vadivel Murugan (6): spi: cadence-quadspi: Add QSPI support for Intel LGM SoC spi: cadence-quadspi: Disable the DAC for Intel LGM SoC spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml dt-bindings: spi: Add compatible for Intel LGM SoC .../devicetree/bindings/mtd/cadence-quadspi.txt| 67 - .../devicetree/bindings/spi/cadence-quadspi.yaml | 149 + drivers/spi/Kconfig| 2 +- drivers/spi/spi-cadence-quadspi.c | 29 4 files changed, 179 insertions(+), 68 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt create mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.yaml -- 2.11.0
[PATCH v2 1/6] spi: cadence-quadspi: Add QSPI support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add QSPI controller support for Intel LGM SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/Kconfig | 2 +-
drivers/spi/spi-cadence-quadspi.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index d2c976e55b8b..926da61eee5a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -203,7 +203,7 @@ config SPI_CADENCE
config SPI_CADENCE_QUADSPI
tristate "Cadence Quad SPI controller"
- depends on OF && (ARM || ARM64 || COMPILE_TEST)
+ depends on OF && (ARM || ARM64 || X86 || COMPILE_TEST)
help
Enable support for the Cadence Quad SPI Flash controller.
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index 40938cf3806d..d7b10c46fa70 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1401,6 +1401,9 @@ static const struct of_device_id cqspi_dt_ids[] = {
.compatible = "ti,am654-ospi",
.data = _ospi,
},
+ {
+ .compatible = "intel,lgm-qspi",
+ },
{ /* end of table */ }
};
--
2.11.0
Re: [External] Re: [PATCH] mm/memory.c: Introduce non-atomic __{Set,Clear}PageSwapCache
On 10/20/20 9:08 PM, Muchun Song wrote:
On Tue, Oct 20, 2020 at 7:51 PM Xu, Yanfei wrote:
On 10/19/20 10:58 PM, Muchun Song wrote:
On Mon, Oct 19, 2020 at 8:31 PM Michal Hocko wrote:
On Mon 19-10-20 18:15:20, Muchun Song wrote:
For the exclusive reference page, the non-atomic operations is enough,
so replace them to non-atomic operations.
I do expect you do not see any difference in runtime and this is mostly
driven by the code reading, right? Being explicit about this in the code
would be preferred.
Yeah, just code reading.And the set_bit and __set_bit is actually different
on some architectures. Thanks.
No objection to the change.
Signed-off-by: Muchun Song
With an improved changelog
Acked-by: Michal Hocko
---
include/linux/page-flags.h | 2 ++
mm/memory.c| 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index fbbb841a9346..ec039dde5e4b 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -401,6 +401,8 @@ static __always_inline int PageSwapCache(struct page *page)
}
SETPAGEFLAG(SwapCache, swapcache, PF_NO_TAIL)
CLEARPAGEFLAG(SwapCache, swapcache, PF_NO_TAIL)
+__SETPAGEFLAG(SwapCache, swapcache, PF_NO_TAIL)
+__CLEARPAGEFLAG(SwapCache, swapcache, PF_NO_TAIL)
#else
PAGEFLAG_FALSE(SwapCache)
#endif
diff --git a/mm/memory.c b/mm/memory.c
index 2d267ef6621a..02dd62da26e0 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3128,10 +3128,10 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
set_page_private(page, entry.val);
/* Tell memcg to use swap ownership records */
- SetPageSwapCache(page);
+ __SetPageSwapCache(page);
Good evening, Muchun. I found there are still some places could be
replaced with __SetPageSwapCache（）. Such as shmem_replace_page（）, why
Yeah, thanks for your suggestion.
PG_locked has been set before SetPageSwapCache（） is involved.
In this case, It doesn't matter whether PG_locked is set before
SetPageSwapCache.
Sorry for this mistake. PG_locked is used for disk I/O.
Would you please to check the rest places? :)
Ok, I'll take a look. Thanks.
Thanks
Acked-by: Yanfei Xu
err = mem_cgroup_charge(page, vma->vm_mm,
GFP_KERNEL);
- ClearPageSwapCache(page);
+ __ClearPageSwapCache(page);
if (err) {
ret = VM_FAULT_OOM;
goto out_page;
--
2.20.1
--
Michal Hocko
SUSE Labs
--
Yours,
Muchun
Re: [PATCH 10/11] [DEBUG] firmware: arm_scmi: add custom_dummy SCMI devname
On 10/14/20 11:05 AM, Cristian Marussi wrote:
Add custom_dummy SCMI devname.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/arm_scmi/driver.c
b/drivers/firmware/arm_scmi/driver.c
index 55df134c2338..5c39a738866a 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -993,6 +993,7 @@ static struct scmi_prot_devnames devnames[] = {
{ SCMI_PROTOCOL_CLOCK, { "clocks" },},
{ SCMI_PROTOCOL_SENSOR, { "hwmon" },},
{ SCMI_PROTOCOL_RESET, { "reset" },},
+ { SCMI_PROTOCOL_CUSTOM_DUMMY, { "custom_dummy" },},
Hi Cristian,
Thanks for the sample dummy custom protocol and driver!
The problem with adding scmi devname into the array is that every time a
custom vendor protocol is added, the array has to be extended. Instead
since the scmi spec supports the range 0x80-0xff for custom protocols,
why not check for that range in scmi_create_protocol_devices and go
ahead with registering the creating the protocol device via
scmi_create_protocol_device?
};
static inline void
--
Warm Regards
Thara
Re: [PATCH 06/11] firmware: arm_scmi: add support for protocol modularization
On 10/14/20 11:05 AM, Cristian Marussi wrote: Modify protocol initialization callback adding a new parameter representing a reference to the available xfer core operations and introduce a macro to simply register with the core new protocols as loadable drivers. Keep standard protocols as builtin. Signed-off-by: Cristian Marussi --- drivers/firmware/arm_scmi/base.c| 56 ++ drivers/firmware/arm_scmi/bus.c | 14 - drivers/firmware/arm_scmi/clock.c | 56 +- drivers/firmware/arm_scmi/common.h | 42 +- drivers/firmware/arm_scmi/driver.c | 50 ++-- drivers/firmware/arm_scmi/perf.c| 88 +++-- drivers/firmware/arm_scmi/power.c | 46 --- drivers/firmware/arm_scmi/reset.c | 46 --- drivers/firmware/arm_scmi/sensors.c | 52 + drivers/firmware/arm_scmi/system.c | 16 -- include/linux/scmi_protocol.h | 18 +- 11 files changed, 288 insertions(+), 196 deletions(-) diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c index f40821eeb103..8d7214fd2187 100644 --- a/drivers/firmware/arm_scmi/base.c +++ b/drivers/firmware/arm_scmi/base.c @@ -15,6 +15,8 @@ #define SCMI_BASE_NUM_SOURCES 1 #define SCMI_BASE_MAX_CMD_ERR_COUNT 1024 +static const struct scmi_xfer_ops *ops; Minor nit. I would consider renaming ops to something more meaningful like xfer_ops (or anything that makes sense). ops by itself leads to confusion with ops in scmo_protocol and in scmi_protocol_events. Same suggestion for all other declarations of ops in this patch. -- Warm Regards Thara
Re: [PATCH 01/11] firmware: arm_scmi: review protocol registration interface
Hi Cristian,
Thanks for this series!
On 10/14/20 11:05 AM, Cristian Marussi wrote:
Extend common protocol registration routines and provide some new generic
protocols' init/deinit helpers that tracks protocols' users and automatically
perform the proper initialization/de-initialization on demand.
Convert all protocols to use new registration schema while modifying only Base
protocol to use also the new initialization helpers.
All other standard protocols' initialization is still umodified and bound to
SCMI devices probing.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/base.c| 10 +-
drivers/firmware/arm_scmi/bus.c | 61 +++---
drivers/firmware/arm_scmi/clock.c | 10 +-
drivers/firmware/arm_scmi/common.h | 31 -
drivers/firmware/arm_scmi/driver.c | 168 +++-
drivers/firmware/arm_scmi/notify.c | 3 +-
drivers/firmware/arm_scmi/perf.c| 10 +-
drivers/firmware/arm_scmi/power.c | 10 +-
drivers/firmware/arm_scmi/reset.c | 10 +-
drivers/firmware/arm_scmi/sensors.c | 10 +-
drivers/firmware/arm_scmi/system.c | 8 +-
include/linux/scmi_protocol.h | 6 +-
12 files changed, 298 insertions(+), 39 deletions(-)
diff --git a/drivers/firmware/arm_scmi/base.c b/drivers/firmware/arm_scmi/base.c
index 017e5d8bd869..f19e08ed4369 100644
--- a/drivers/firmware/arm_scmi/base.c
+++ b/drivers/firmware/arm_scmi/base.c
@@ -318,7 +318,7 @@ static const struct scmi_event_ops base_event_ops = {
.fill_custom_report = scmi_base_fill_custom_report,
};
-int scmi_base_protocol_init(struct scmi_handle *h)
+static int scmi_base_protocol_init(struct scmi_handle *h)
{
int id, ret;
u8 *prot_imp;
@@ -365,3 +365,11 @@ int scmi_base_protocol_init(struct scmi_handle *h)
return 0;
}
+
+static struct scmi_protocol scmi_base = {
+ .id = SCMI_PROTOCOL_BASE,
+ .init = _base_protocol_init,
+ .ops = NULL,
+};
+
+DEFINE_SCMI_PROTOCOL_REGISTER_UNREGISTER(base, scmi_base)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 1377ec76a45d..afa2e4818a2b 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -16,7 +16,7 @@
#include "common.h"
static DEFINE_IDA(scmi_bus_id);
-static DEFINE_IDR(scmi_protocols);
+static DEFINE_IDR(scmi_available_protocols);
static DEFINE_SPINLOCK(protocol_lock);
static const struct scmi_device_id *
@@ -51,13 +51,29 @@ static int scmi_dev_match(struct device *dev, struct
device_driver *drv)
return 0;
}
+const struct scmi_protocol *scmi_get_protocol(int protocol_id)
+{
+ const struct scmi_protocol *proto;
+
+ proto = idr_find(_available_protocols, protocol_id);
+ if (!proto) {
+ pr_warn("SCMI Protocol 0x%x not found!\n", protocol_id);
+ return NULL;
+ }
+
+ pr_debug("GOT SCMI Protocol 0x%x\n", protocol_id);
+
+ return proto;
+}
+
static int scmi_protocol_init(int protocol_id, struct scmi_handle *handle)
{
- scmi_prot_init_fn_t fn = idr_find(_protocols, protocol_id);
+ const struct scmi_protocol *proto;
- if (unlikely(!fn))
+ proto = idr_find(_available_protocols, protocol_id);
+ if (!proto)
return -EINVAL;
Any reason not to use the above scmi_get_protocol here ?
- return fn(handle);
+ return proto->init(handle);
}
static int scmi_protocol_dummy_init(struct scmi_handle *handle)
@@ -84,7 +100,7 @@ static int scmi_dev_probe(struct device *dev)
return ret;
/* Skip protocol initialisation for additional devices */
- idr_replace(_protocols, _protocol_dummy_init,
+ idr_replace(_available_protocols, _protocol_dummy_init,
scmi_dev->protocol_id);
return scmi_drv->probe(scmi_dev);
@@ -194,26 +210,45 @@ void scmi_set_handle(struct scmi_device *scmi_dev)
scmi_dev->handle = scmi_handle_get(_dev->dev);
}
-int scmi_protocol_register(int protocol_id, scmi_prot_init_fn_t fn)
+int scmi_protocol_register(struct scmi_protocol *proto)
{
int ret;
+ if (!proto) {
+ pr_err("invalid protocol\n");
+ return -EINVAL;
+ }
+
+ if (!proto->init) {
+ pr_err("missing .init() for protocol 0x%x\n", proto->id);
+ return -EINVAL;
+ }
+
spin_lock(_lock);
- ret = idr_alloc(_protocols, fn, protocol_id, protocol_id + 1,
- GFP_ATOMIC);
+ ret = idr_alloc(_available_protocols, proto,
+ proto->id, proto->id + 1, GFP_ATOMIC);
spin_unlock(_lock);
- if (ret != protocol_id)
- pr_err("unable to allocate SCMI idr slot, err %d\n", ret);
+ if (ret != proto->id) {
+ pr_err("unable to allocate SCMI idr slot for 0x%x - err %d\n",
+ proto->id, ret);
+ return ret;
+ }
+
+
Re: [PATCH 03/11] firmware: arm_scmi: introduce common protocol interface
On 10/14/20 11:05 AM, Cristian Marussi wrote:
Introduce generic get_ops/put_ops handle operations: any protocol, both
standard or custom, now exposes its operations through this common
interface which internally takes care to account for protocols' usage:
protocols' initialization is now performed on demand as soon as the first
user shows up while deinitialization (if any) is performed once
the last user of a protocol has gone.
Registered events' notifier are tracked too against the related protocol.
Convert all SCMI drivers to the new interface too.
Signed-off-by: Cristian Marussi
---
[...]
diff --git a/drivers/firmware/arm_scmi/driver.c
b/drivers/firmware/arm_scmi/driver.c
index bad1d0130e96..049220efd227 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -585,7 +585,7 @@ void *scmi_get_proto_priv(const struct scmi_handle *handle,
u8 protocol_id)
* Return: A reference to an initialized protocol instance or error on
failure.
*/
static struct scmi_protocol_instance * __must_check
-scmi_get_protocol_instance(struct scmi_handle *handle, u8 protocol_id)
+scmi_get_protocol_instance(const struct scmi_handle *handle, u8 protocol_id)
{
int ret = -ENOMEM;
void *gid;
@@ -655,7 +655,7 @@ scmi_get_protocol_instance(struct scmi_handle *handle, u8
protocol_id)
*
* Return: 0 if protocol was acquired successfully.
*/
-int scmi_acquire_protocol(struct scmi_handle *handle, u8 protocol_id)
+int scmi_acquire_protocol(const struct scmi_handle *handle, u8 protocol_id)
{
return IS_ERR(scmi_get_protocol_instance(handle, protocol_id));
}
@@ -668,7 +668,7 @@ int scmi_acquire_protocol(struct scmi_handle *handle, u8
protocol_id)
* Remove one user for the specified protocol and triggers de-initialization
* and resources de-allocation once the last user has gone.
*/
-void scmi_release_protocol(struct scmi_handle *handle, u8 protocol_id)
+void scmi_release_protocol(const struct scmi_handle *handle, u8 protocol_id)
{
struct scmi_info *info = handle_to_scmi_info(handle);
struct scmi_protocol_instance *pi;
@@ -700,6 +700,29 @@ void scmi_release_protocol(struct scmi_handle *handle, u8
protocol_id)
mutex_unlock(>protocols_mtx);
}
+/**
+ * scmi_get_protocol_operations - Get protocol operations
+ * @handle: A reference to the SCMI platform instance.
+ * @protocol_id: The protocol being requested.
+ *
+ * Get hold of a protocol accounting for its usage, eventually triggering its
+ * initialization, and returning the protocol specific operations.
+ *
+ * Return: A reference to the requested protocol operations or error.
+ *Must be checked for errors by caller.
+ */
+static const void __must_check
+*scmi_get_protocol_operations(const struct scmi_handle *handle, u8 protocol_id)
+{
+ struct scmi_protocol_instance *pi;
+
+ pi = scmi_get_protocol_instance(handle, protocol_id);
+ if (IS_ERR(pi))
+ return pi;
+
+ return pi->proto->ops;
+} > +
void scmi_setup_protocol_implemented(const struct scmi_handle *handle,
u8 *prot_imp)
{
@@ -975,6 +998,8 @@ static int scmi_probe(struct platform_device *pdev)
handle = >handle;
handle->dev = info->dev;
handle->version = >version;
+ handle->get_ops = scmi_get_protocol_operations;
+ handle->put_ops = scmi_release_protocol;
Why do you need get_ops and put_ops? Why not have the drivers call
scmi_acquire_protocol and scmi_release_protocol directly and get the ops
from retrieved scmi_get_protocol_instance ? IMHO, this makes it more
readable. Also, this will make the usage of scmi_acquire_protocol and
scmi_release_protocol more consistent. Right now, notify.c uses
scmi_acquire_protocol to acquire protocol because there is no need for
ops and other drivers use get_ops to acquire protocol. Kind of confusing..
--
Warm Regards
Thara
ret = scmi_txrx_setup(info, dev, SCMI_PROTOCOL_BASE);
if (ret)
diff --git a/drivers/firmware/arm_scmi/notify.c
b/drivers/firmware/arm_scmi/notify.c
index eae58b2a92cc..02b00af9b08f 100644
--- a/drivers/firmware/arm_scmi/notify.c
+++ b/drivers/firmware/arm_scmi/notify.c
@@ -367,7 +367,7 @@ static struct scmi_event_handler *
scmi_get_active_handler(struct scmi_notify_instance *ni, u32 evt_key);
static void scmi_put_active_handler(struct scmi_notify_instance *ni,
struct scmi_event_handler *hndl);
-static void scmi_put_handler_unlocked(struct scmi_notify_instance *ni,
+static bool scmi_put_handler_unlocked(struct scmi_notify_instance *ni,
struct scmi_event_handler *hndl);
/**
@@ -899,9 +899,21 @@ static inline int scmi_bind_event_handler(struct
scmi_notify_instance *ni,
if (!r_evt)
return -EINVAL;
- /* Remove from pending and insert into registered */
+ /*
+* Remove from pending and
Re: [PATCH v3 1/2] dt-bindings: arm: cpus: Document 'qcom,freq-domain' property
Hi, Manivannan On Tue, 2020-10-20 at 21:09 +0530, Manivannan Sadhasivam wrote: > Add devicetree documentation for 'qcom,freq-domain' property specific > to Qualcomm CPUs. This property is used to reference the CPUFREQ node > along with Domain ID (0/1). > > Signed-off-by: Manivannan Sadhasivam > --- > Documentation/devicetree/bindings/arm/cpus.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml > b/Documentation/devicetree/bindings/arm/cpus.yaml > index 1222bf1831fa..f40564bf004f 100644 > --- a/Documentation/devicetree/bindings/arm/cpus.yaml > +++ b/Documentation/devicetree/bindings/arm/cpus.yaml > @@ -290,6 +290,12 @@ properties: > >* arm/msm/qcom,kpss-acc.txt > > + qcom,freq-domain: Do you mind to change "qcom, freq-domain" to common naming? or drop the prefix. So that we can use this CPU node and map it to each freq-domain. Thanks a lot. > +$ref: '/schemas/types.yaml#/definitions/phandle-array' > +description: | > + CPUs supporting freq-domain must set their "qcom,freq-domain" property > + with phandle to a cpufreq_hw node followed by the Domain ID(0/1). > + >rockchip,pmu: > $ref: '/schemas/types.yaml#/definitions/phandle' > description: |
Re: [PATCH v7 2/4] powerpc: Refactor kexec functions to move arch independent code to ima
On 10/20/20 1:01 PM, Mimi Zohar wrote: On Wed, 2020-09-30 at 13:59 -0700, Lakshmi Ramasubramanian wrote: The functions ima_get_kexec_buffer() and ima_free_kexec_buffer(), that handle carrying forward the IMA measurement logs on kexec for powerpc do not have architecture specific code, but they are currently defined for powerpc only. Move ima_get_kexec_buffer() and ima_free_kexec_buffer() to IMA subsystem. A later patch in this series will use these functions for carrying forward the IMA measurement log for ARM64. With the above refactoring arch/powerpc/kexec/ima.c contains only functions used when CONFIG_IMA_KEXEC is enabled. Update Makefile in arch/powerpc/kexec to include arch/powerpc/kexec/ima.c only when CONFIG_IMA_KEXEC is enabled. Move ima_dump_measurement_list() and ima_add_kexec_buffer() to a new file namely ima_kexec_fdt.c in IMA. Update security/integrity/ima/Makefile to include ima_kexec_fdt.c only when CONFIG_IMA_KEXEC is enabled. Co-developed-by: Prakhar Srivastava Signed-off-by: Prakhar Srivastava Signed-off-by: Lakshmi Ramasubramanian The existing support for carrying the IMA measurement list across kexec is limited to powerpc. This patch set is adding similar support for arm64, making as much of the existing code as generic as possible. However ima_dump_measurement_list() is already generic, but for some reason this patch moves it to ima_kexec_fdt.c. ima_kexec_fdt.c should be limited to device tree specific code. I wanted to split the functions defined under CONFIG_HAVE_IMA_KEXEC and CONFIG_IMA_KEXEC to separate files so that we can get rid of #ifdef in C file and instead conditionally compile the C files (using Makefile). ima_dump_measurement_list() need to be defined only when CONFIG_IMA_KEXEC is defined. I moved it to ima_kexec_fdt.c Instead of ima_kexec_fdt.c, where ima_dump_measurement_list() and ima_add_kexec_buffer() are defined, perhaps I can change the file name to "ima_kexec_buffer.c". Would that be better? This patch is probably doing the right thing, but the way the patch is formatted it replaces parts of a function with a different function. With the changes suggested above and in 1/4, the next version should be clearer. Like I'd stated above, I wanted to remove "#ifdef" from the C files and hence had to move some functions. But the functionalities haven't been changed. thanks, -lakshmi
Re: [MPTCP][PATCH net-next 0/2] init ahmac and port of mptcp_options_received
Hi Jakub, Jakub Kicinski 于2020年10月21日周三 上午7:39写道： > > On Mon, 19 Oct 2020 18:23:14 +0800 Geliang Tang wrote: > > This patchset deals with initializations of mptcp_options_received's two > > fields, ahmac and port. > > Applied, but two extra comments: > - please make sure the commit messages are in imperative form >e.g. "Initialize x..." rather than "This patches initializes x.." > - I dropped the Fixes tag from patch 2, and only queued patch 1 for >stable - patch 2 is a minor clean up, right? Yes, that's right. Thanks for applying and updating the patches. -Geliang > > Thanks!
[PATCH v2 6/6] dt-bindings: spi: Add compatible for Intel LGM SoC
From: Ramuthevar Vadivel Murugan Add compatible string for Intel LGM SoC. Signed-off-by: Ramuthevar Vadivel Murugan --- Documentation/devicetree/bindings/spi/cadence-quadspi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml index 57be1a730e7b..44378d2d2b9e 100644 --- a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml +++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml @@ -19,6 +19,7 @@ properties: - const: cdns,qspi-nor - const: ti,k2g-qspi, cdns,qspi-nor - const: ti,am654-ospi, cdns,qspi-nor + - const: intel,lgm-qspi, cdns,qspi-nor reg: items: -- 2.11.0
[PATCH v2 3/6] spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi
From: Ramuthevar Vadivel Murugan
Move the Documentation/devicetree/bindings/mtd/cadence-quadspi.txt to
Documentation/devicetree/bindings/spi/
Signed-off-by: Ramuthevar Vadivel Murugan
---
Documentation/devicetree/bindings/{mtd => spi}/cadence-quadspi.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{mtd => spi}/cadence-quadspi.txt
(100%)
diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
rename to Documentation/devicetree/bindings/spi/cadence-quadspi.txt
--
2.11.0
[PATCH v2 4/6] dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
From: Ramuthevar Vadivel Murugan
Convert the cadence-quadspi.txt documentation to cadence-quadspi.yaml
remove the cadence-quadspi.txt from Documentation/devicetree/bindings/spi/
Signed-off-by: Ramuthevar Vadivel Murugan
Acked-by: Rob Herring
---
.../devicetree/bindings/spi/cadence-quadspi.txt| 67 --
.../devicetree/bindings/spi/cadence-quadspi.yaml | 148 +
2 files changed, 148 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
b/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
deleted file mode 100644
index 945be7d5b236..
--- a/Documentation/devicetree/bindings/spi/cadence-quadspi.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Cadence Quad SPI controller
-
-Required properties:
-- compatible : should be one of the following:
- Generic default - "cdns,qspi-nor".
- For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".
- For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".
-- reg : Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
-- interrupts : Unit interrupt specifier for the controller interrupt.
-- clocks : phandle to the Quad SPI clock.
-- cdns,fifo-depth : Size of the data FIFO in words.
-- cdns,fifo-width : Bus width of the data FIFO in bytes.
-- cdns,trigger-address : 32-bit indirect AHB trigger address.
-
-Optional properties:
-- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
-- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
-
-Optional subnodes:
-Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
-custom properties:
-- cdns,read-delay : Delay for read capture logic, in clock cycles
-- cdns,tshsl-ns : Delay in nanoseconds for the length that the master
- mode chip select outputs are de-asserted between
- transactions.
-- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being
- de-activated and the activation of another.
-- cdns,tchsh-ns : Delay in nanoseconds between last bit of current
- transaction and deasserting the device chip select
- (qspi_n_ss_out).
-- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low
- and first bit transfer.
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include either "qspi" and/or "qspi-ocp".
-
-Example:
-
- qspi: spi@ff705000 {
- compatible = "cdns,qspi-nor";
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <0xff705000 0x1000>,
- <0xffa0 0x1000>;
- interrupts = <0 151 4>;
- clocks = <_clk>;
- cdns,is-decoded-cs;
- cdns,fifo-depth = <128>;
- cdns,fifo-width = <4>;
- cdns,trigger-address = <0x>;
- resets = < QSPI_RESET>, < QSPI_OCP_RESET>;
- reset-names = "qspi", "qspi-ocp";
-
- flash0: n25q00@0 {
- ...
- cdns,read-delay = <4>;
- cdns,tshsl-ns = <50>;
- cdns,tsd2d-ns = <50>;
- cdns,tchsh-ns = <4>;
- cdns,tslch-ns = <4>;
- };
- };
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
new file mode 100644
index ..6ed8122a1326
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
@@ -0,0 +1,148 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/cadence-quadspi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence Quad SPI controller
+
+maintainers:
+ - Vadivel Murugan
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+
+properties:
+ compatible:
+items:
+ - const: cdns,qspi-nor
+ - const: ti,k2g-qspi, cdns,qspi-nor
+ - const: ti,am654-ospi, cdns,qspi-nor
+
+description:
+ Should be one of the above supported compatible strings.
+ optional properties
+ "cdns,is-decoded-cs" - Flag to indicate whether decoder is used or not.
+ "cdns,rclk-en" - Flag to indicate that QSPI return clock is used to latch
+ the read data rather than the QSPI
[PATCH v2 2/6] spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add multiple chipselect support for Intel LGM SoCs,
currently QSPI-NOR and QSPI-NAND supported.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/spi-cadence-quadspi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index 3d017b484114..3bf6d3697631 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -38,6 +38,7 @@
/* Capabilities */
#define CQSPI_SUPPORTS_OCTAL BIT(0)
+#define CQSPI_SUPPORTS_MULTI_CHIPSELECT BIT(1)
struct cqspi_st;
@@ -75,6 +76,7 @@ struct cqspi_st {
boolis_decoded_cs;
u32 fifo_depth;
u32 fifo_width;
+ u32 num_chipselect;
boolrclk_en;
u32 trigger_address;
u32 wr_delay;
@@ -1070,6 +1072,14 @@ static int cqspi_of_get_pdata(struct cqspi_st *cqspi)
return -ENXIO;
}
+ if (!cqspi->use_direct_mode) {
+ if (of_property_read_u32(np, "num-chipselect",
+>num_chipselect)) {
+ dev_err(dev, "couldn't determine number of cs\n");
+ return -ENXIO;
+ }
+ }
+
cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
return 0;
@@ -1307,6 +1317,9 @@ static int cqspi_probe(struct platform_device *pdev)
cqspi->current_cs = -1;
cqspi->sclk = 0;
+ if (ddata->hwcaps_mask & CQSPI_SUPPORTS_MULTI_CHIPSELECT)
+ master->num_chipselect = cqspi->num_chipselect;
+
ret = cqspi_setup_flash(cqspi);
if (ret) {
dev_err(dev, "failed to setup flash parameters %d\n", ret);
@@ -1396,6 +1409,7 @@ static const struct cqspi_driver_platdata am654_ospi = {
};
static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .hwcaps_mask = CQSPI_SUPPORTS_MULTI_CHIPSELECT,
.quirks = CQSPI_DISABLE_DAC_MODE,
};
--
2.11.0
[PATCH v2 5/6] dt-bindings: spi: Add compatible for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add compatible string for Intel LGM SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/spi/cadence-quadspi.yaml | 68 +++---
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
index 6ed8122a1326..57be1a730e7b 100644
--- a/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
+++ b/Documentation/devicetree/bindings/spi/cadence-quadspi.yaml
@@ -14,65 +14,61 @@ allOf:
properties:
compatible:
-items:
- - const: cdns,qspi-nor
- - const: ti,k2g-qspi, cdns,qspi-nor
- - const: ti,am654-ospi, cdns,qspi-nor
-
-description:
- Should be one of the above supported compatible strings.
- optional properties
- "cdns,is-decoded-cs" - Flag to indicate whether decoder is used or not.
- "cdns,rclk-en" - Flag to indicate that QSPI return clock is used to latch
- the read data rather than the QSPI clock. Make sure that QSPI return
- clock is populated on the board before using this property.
+oneOf:
+ - items:
+ - const: cdns,qspi-nor
+ - const: ti,k2g-qspi, cdns,qspi-nor
+ - const: ti,am654-ospi, cdns,qspi-nor
reg:
-maxItems: 2
-
-description:
- Contains two entries, each of which is a tuple consisting of a
- physical address and length. The first entry is the address and
- length of the controller register set. The second entry is the
- address and length of the QSPI Controller data area.
+items:
+ - description: the controller register set
+ - description: the controller data area
interrupts:
maxItems: 1
-description:
- Unit interrupt specifier for the controller interrupt.
clocks:
maxItems: 1
-description:
- phandle to the Quad SPI clock.
cdns,fifo-depth:
description:
Size of the data FIFO in words.
-allOf:
- - $ref: "/schemas/types.yaml#/definitions/uint32"
- - enum: [ 128, 256 ]
- - default: 128
+$ref: "/schemas/types.yaml#/definitions/uint32"
+enum: [ 128, 256 ]
+default: 128
cdns,fifo-width:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Bus width of the data FIFO in bytes.
-multipleOf: 4
+default: 4
cdns,trigger-address:
$ref: /schemas/types.yaml#/definitions/uint32
description:
32-bit indirect AHB trigger address.
+ cdns,is-decoded-cs:
+type: boolean
+description:
+ Flag to indicate whether decoder is used or not.
+
+ cdns,rclk-en:
+type: boolean
+description:
+ Flag to indicate that QSPI return clock is used to latch the read
+ data rather than the QSPI clock. Make sure that QSPI return clock
+ is populated on the board before using this property.
+
resets:
- description:
- Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
+maxItems : 2
reset-names:
-description:
- Must include either "qspi" and/or "qspi-ocp".
+minItems: 1
+maxItems: 2
+items:
+ enum: [ qspi, qspi-ocp ]
# subnode's properties
patternProperties:
@@ -114,13 +110,17 @@ required:
- cdns,fifo-depth
- cdns,fifo-width
- cdns,trigger-address
+ - cdns,is-decoded-cs
+ - cdns,rclk-en
- resets
- reset-names
+additionalProperties: false
+
examples:
- |
qspi: spi@ff705000 {
- compatible = "cadence,qspi";
+ compatible = "cadence,qspi","cdns,qpsi-nor";
#address-cells = <1>;
#size-cells = <0>;
reg = <0xff705000 0x1000>,
--
2.11.0
[PATCH v2 0/6] spi: cadence-quadspi: Add QSPI controller support for Intel LGM SoC
Add QSPI controller support for Intel LGM SoC. Note from Vignesh(mtd subsystem maintainer): This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX that intended to move cadence-quadspi driver to spi-mem framework Those patches were trying to accomplish too many things in a single set of patches and need to split into smaller patches. This is reduced version of above series. Changes that are intended to make migration easy are split into separate patches. Patches 1 to 3 drop features that cannot be supported under spi-mem at the moment (backward compatibility is maintained). Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to spi-mem and patch 7 moves the driver to drivers/spi folder. I have tested both INDAC mode (used by non TI platforms like Altera SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs. Patches to move move bindings over to "Documentation/devicetree/bindings/spi/" directory and also conversion of bindig doc to YAML will be posted separately. Support for Intel platform would follow that. Reference: https://lkml.org/lkml/2020/6/1/50 --- v2: - Rob's review comments update for dt-bindings - add 'oneOf' for compatible selection - drop un-neccessary descriptions - add the cdns,is-decoded-cs and cdns,rclk-en properties as schema - remove 'allOf' in not required place - add AdditionalProperties false - add minItems/maxItems for qspi reset attributes resend-v1: - As per Mark's suggestion , reorder the patch series 1-3 driver support patches, series 4-6 dt-bindings patches. v1: - initial version Ramuthevar Vadivel Murugan (6): spi: cadence-quadspi: Disable the DAC for Intel LGM SoC spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml dt-bindings: spi: Add compatible for Intel LGM SoC dt-bindings: spi: Add compatible for Intel LGM SoC .../devicetree/bindings/mtd/cadence-quadspi.txt| 67 - .../devicetree/bindings/spi/cadence-quadspi.yaml | 149 + drivers/spi/spi-cadence-quadspi.c | 26 3 files changed, 175 insertions(+), 67 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt create mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.yaml -- 2.11.0
[PATCH v2 1/6] spi: cadence-quadspi: Disable the DAC for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
On Intel Lightning Mountain(LGM) SoCs QSPI controller do not use
Direct Access Controller(DAC).
This patch adds a quirk to disable the Direct Access Controller
for data transfer instead it uses indirect data transfer.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/spi/spi-cadence-quadspi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/spi/spi-cadence-quadspi.c
b/drivers/spi/spi-cadence-quadspi.c
index d7b10c46fa70..3d017b484114 100644
--- a/drivers/spi/spi-cadence-quadspi.c
+++ b/drivers/spi/spi-cadence-quadspi.c
@@ -1106,6 +1106,13 @@ static void cqspi_controller_init(struct cqspi_st *cqspi)
reg |= CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ /* Disable direct access controller */
+ if (!cqspi->use_direct_mode) {
+ reg = readl(cqspi->iobase + CQSPI_REG_CONFIG);
+ reg &= ~CQSPI_REG_CONFIG_ENB_DIR_ACC_CTRL;
+ writel(reg, cqspi->iobase + CQSPI_REG_CONFIG);
+ }
+
cqspi_controller_enable(cqspi, 1);
}
@@ -1388,6 +1395,10 @@ static const struct cqspi_driver_platdata am654_ospi = {
.quirks = CQSPI_NEEDS_WR_DELAY,
};
+static const struct cqspi_driver_platdata intel_lgm_qspi = {
+ .quirks = CQSPI_DISABLE_DAC_MODE,
+};
+
static const struct of_device_id cqspi_dt_ids[] = {
{
.compatible = "cdns,qspi-nor",
@@ -1403,6 +1414,7 @@ static const struct of_device_id cqspi_dt_ids[] = {
},
{
.compatible = "intel,lgm-qspi",
+ .data = _lgm_qspi,
},
{ /* end of table */ }
};
--
2.11.0
Re: [PATCH v7 1/4] powerpc: Refactor kexec functions to move arch independent code to kernel
On 10/20/20 1:00 PM, Mimi Zohar wrote: Hi Lakshmi, On Wed, 2020-09-30 at 13:59 -0700, Lakshmi Ramasubramanian wrote: The functions remove_ima_buffer() and delete_fdt_mem_rsv() that handle carrying forward the IMA measurement logs on kexec for powerpc do not have architecture specific code, but they are currently defined for powerpc only. remove_ima_buffer() and delete_fdt_mem_rsv() are used to remove the IMA log entry from the device tree and free the memory reserved for the log. These functions need to be defined even if the current kernel does not support carrying forward IMA log across kexec since the previous kernel could have supported that and therefore the current kernel needs to free the allocation. Rename remove_ima_buffer() to remove_ima_kexec_buffer(). Define remove_ima_kexec_buffer() and delete_fdt_mem_rsv() in kernel. A later patch in this series will use these functions to free the allocation, if any, made by the previous kernel for ARM64. Define FDT_PROP_IMA_KEXEC_BUFFER for the chosen node, namely "linux,ima-kexec-buffer", that is added to the DTB to hold the address and the size of the memory reserved to carry the IMA measurement log. Co-developed-by: Prakhar Srivastava Signed-off-by: Prakhar Srivastava Signed-off-by: Lakshmi Ramasubramanian Reported-by: kernel test robot error: implicit declaration of function 'delete_fdt_mem_rsv' [-Werror,-Wimplicit-function-declaration] Much better! This version limits unnecessarily changing the existing code to adding a couple of debugging statements, but that looks to be about it. Yes Mimi - that's correct. Based on Chester Lin's "ima_arch" support for arm64 discussion, the IMA generic EFI support will be defined in ima/ima-efi.c. Similarly, I think it would make sense to put the generic device tree support in ima/ima_kexec_fdt.c or ima/ima_fdt.c, as opposed to kernel/. (Refer to my comments on 2/4 about the new file named ima_kexec_fdt.c.) The functions remove_ima_kexec_buffer() and delete_fdt_mem_rsv(), which are defined in kernel/ima_kexec.c and kernel/kexec_file_fdt.c respectively, are needed even when CONFIG_IMA is not defined. These functions need to be called by the current kernel to free the ima kexec buffer resources allocated by the previous kernel. This is the reason, these functions are defined under "kernel" instead of "security/integrity/ima". If there is a better location to move the above C files, please let me know. I'll move them. thanks, -lakshmi
arch/mips/bmips/dma.c:55:13: warning: no previous prototype for 'dma_to_phys'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: c4d6fe7311762f2e03b3c27ad38df7c40c80cc93
commit: 7bc5c428a660d4d1bc95ba54bf4cb6bccf8c3029 dma-direct: remove
__dma_to_phys
date: 6 weeks ago
config: mips-randconfig-r022-20201021 (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7bc5c428a660d4d1bc95ba54bf4cb6bccf8c3029
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 7bc5c428a660d4d1bc95ba54bf4cb6bccf8c3029
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
arch/mips/bmips/dma.c:43:12: warning: no previous prototype for
'__phys_to_dma' [-Wmissing-prototypes]
43 | dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t pa)
|^
>> arch/mips/bmips/dma.c:55:13: warning: no previous prototype for
>> 'dma_to_phys' [-Wmissing-prototypes]
55 | phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
| ^~~
arch/mips/bmips/dma.c:67:6: warning: no previous prototype for
'arch_sync_dma_for_cpu_all' [-Wmissing-prototypes]
67 | void arch_sync_dma_for_cpu_all(void)
| ^
vim +/dma_to_phys +55 arch/mips/bmips/dma.c
54
> 55 phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
56 {
57 struct bmips_dma_range *r;
58
59 for (r = bmips_dma_ranges; r && r->size; r++) {
60 if (dma_addr >= r->parent_addr &&
61 dma_addr < (r->parent_addr + r->size))
62 return dma_addr - r->parent_addr +
r->child_addr;
63 }
64 return dma_addr;
65 }
66
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] mailbox: qcom: Support building QCOM IPCC driver as module
Change CONFIG_QCOM_IPCC to tristate and add exit function to
support module build for QCOM IPCC driver.
Signed-off-by: Huang Yiwei
---
drivers/mailbox/Kconfig | 2 +-
drivers/mailbox/qcom-ipcc.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 05b1009..78f3006 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -245,7 +245,7 @@ config SPRD_MBOX
you want to build the Spreatrum mailbox controller driver.
config QCOM_IPCC
- bool "Qualcomm Technologies, Inc. IPCC driver"
+ tristate "Qualcomm Technologies, Inc. IPCC driver"
depends on ARCH_QCOM || COMPILE_TEST
help
Qualcomm Technologies, Inc. Inter-Processor Communication Controller
diff --git a/drivers/mailbox/qcom-ipcc.c b/drivers/mailbox/qcom-ipcc.c
index 2d13c72..1ed9a87 100644
--- a/drivers/mailbox/qcom-ipcc.c
+++ b/drivers/mailbox/qcom-ipcc.c
@@ -280,6 +280,12 @@ static int __init qcom_ipcc_init(void)
}
arch_initcall(qcom_ipcc_init);
+static __exit void qcom_ipcc_exit(void)
+{
+ platform_driver_unregister(_ipcc_driver);
+}
+module_exit(qcom_ipcc_exit);
+
MODULE_AUTHOR("Venkata Narendra Kumar Gutta ");
MODULE_AUTHOR("Manivannan Sadhasivam ");
MODULE_DESCRIPTION("Qualcomm Technologies, Inc. IPCC driver");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 5/6] x86/apic/msi: Use Real PCI DMA device when configuring IRTE
On Wed, Oct 21, 2020 at 01:20:24AM +, Derrick, Jonathan wrote:
> On Tue, 2020-10-20 at 15:26 -0500, Bjorn Helgaas wrote:
> > On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
> > > VMD retransmits child device MSI/X with the VMD endpoint's requester-id.
> > > In order to support direct interrupt remapping of VMD child devices,
> > > ensure that the IRTE is programmed with the VMD endpoint's requester-id
> > > using pci_real_dma_dev().
> > >
> > > Reviewed-by: Andy Shevchenko
> > > Signed-off-by: Jon Derrick
> >
> > As Thomas (and Stephen) pointed out, this conflicts with 7ca435cf857d
> > ("x86/irq: Cleanup the arch_*_msi_irqs() leftovers"), which removes
> > native_setup_msi_irqs().
> >
> > Stephen resolved the conflict by dropping this hunk. I would rather
> > just drop this patch completely from the PCI tree. If I keep the
> > patch, (1) Linus will have to resolve the conflict, and worse, (2)
> > it's not clear what happened to the use of pci_real_dma_dev() here.
> > It will just vanish into the ether with no explanation other than
> > "this function was removed."
> >
> > Is dropping this patch the correct thing to do? Or do you need to add
> > pci_real_dma_dev() elsewhere to compensate?
>
> It would still need the pci_real_dma_dev() for IRTE programming.
>
> I think at this point I would rather see 5+6 dropped and this included
> for TGL enablement:
> https://patchwork.kernel.org/project/linux-pci/patch/20200914190128.5114-1-jonathan.derr...@intel.com/
It's too late to add new things for v5.10. I'll drop 5 and I'll be
happy to drop 6, too, if you want. I have several comments/questions
on 6 anyway that I haven't finished writing up.
But if you'd rather have 1-4 + 6 in v5.10 instead of just 1-4, let me
know.
Bjorn
Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: Don't force link when using in-band-status
On 21/10/20 10:18 am, Russell King - ARM Linux admin wrote: > On Tue, Oct 20, 2020 at 09:06:32PM +, Chris Packham wrote: >> On 21/10/20 3:51 am, Marek Behun wrote: >>> On Tue, 20 Oct 2020 15:15:25 +0100 >>> Russell King - ARM Linux admin wrote: >>> On Tue, Oct 20, 2020 at 04:05:35PM +0200, Andrew Lunn wrote: > On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote: >> On Tue, 20 Oct 2020 11:15:52 +0100 >> Russell King - ARM Linux admin wrote: >> >>> On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote: When a port is configured with 'managed = "in-band-status"' don't force the link up, the switch MAC will detect the link status correctly. Signed-off-by: Chris Packham Reviewed-by: Andrew Lunn >>> I thought we had issues with the 88E6390 where the PCS does not >>> update the MAC with its results. Isn't this going to break the >>> 6390? Andrew? >>> >> Russell, I tested this patch on Turris MOX with 6390 on port 9 (cpu >> port) which is configured in devicetree as 2500base-x, in-band-status, >> and it works... >> >> Or will this break on user ports? > User ports is what needs testing, ideally with an SFP. > > There used to be explicit code which when the SERDES reported link up, > the MAC was configured in software with the correct speed etc. With > the move to pcs APIs, it is less obvious how this works now, does it > still software configure the MAC, or do we have the right magic so > that the hardware updates itself. It's still there. The speed/duplex etc are read from the serdes PHY via mv88e6390_serdes_pcs_get_state(). When the link comes up, we pass the negotiated link parameters read from there to the link_up() functions. For ports where mv88e6xxx_port_ppu_updates() returns false (no external PHY) we update the port's speed and duplex setting and (currently, before this patch) force the link up. That was the behaviour before I converted the code, the one that you referred to. I had assumed the code was correct, and _none_ of the speed, duplex, nor link state was propagated from the serdes PCS to the port on the 88E6390 - hence why the code you refer to existed. >>> Russell, you are right. >>> SFP on 88E6390 does not work with this patch applied. >>> So this patch breaks 88E6390. >> Thanks for testing. It sounds like maybe if I make >> mv88e6xxx_port_ppu_updates() return true for the 6097 in serdes mode I >> can avoid the forced link up without affecting the 6390. > Another option would be to make mv88e6xxx_mac_link_up() call a > switch specific implementation function, which is probably way > cleaner than introducing conditionals on the switch type in > functions, and reflects the existing code structure. I've spent most of the day plumbing in the serdes interrupts. And while I have that working I think even with interrupts I still have the problem that on the 88E6097 and similar there is no separation of PCS from the MAC so I'd have to do something like this anyway. So I'll probably look at making the body of mv88e6xxx_mac_link_up a switch specific function.
[PATCH v2] power: suspend: Replace dpm_watchdog by sleep timer
Since dpm_watchdog just cover device power management, we proposed sleep
timer to cover not only device power management hang issues, but also
core power management hand issue.
Add sleep timer and timeout handler to prevent device stuck during suspend/
resume process. The timeout handler will dump disk sleep task at first
round timeout and trigger kernel panic at second round timeout.
The default timer for each round is defined in
CONFIG_PM_SLEEP_TIMER_TIMEOUT.
Signed-off-by: Joseph Jang
---
Changes in v2:
- Add commit message to explain why remove dpm_watchdog.
- Remove dpm_watchdog related functions.
- Move suspend_timer.h from include/linux/ to kernel/power/.
drivers/base/power/main.c| 69 ---
include/linux/console.h | 1 +
kernel/power/Kconfig | 27 ++-
kernel/power/suspend.c | 19
kernel/power/suspend_timer.h | 90
kernel/printk/printk.c | 5 ++
6 files changed, 128 insertions(+), 83 deletions(-)
create mode 100644 kernel/power/suspend_timer.h
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 205a06752ca9..b08f91e31a70 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -496,69 +496,6 @@ static int dpm_run_callback(pm_callback_t cb, struct
device *dev,
return error;
}
-#ifdef CONFIG_DPM_WATCHDOG
-struct dpm_watchdog {
- struct device *dev;
- struct task_struct *tsk;
- struct timer_list timer;
-};
-
-#define DECLARE_DPM_WATCHDOG_ON_STACK(wd) \
- struct dpm_watchdog wd
-
-/**
- * dpm_watchdog_handler - Driver suspend / resume watchdog handler.
- * @t: The timer that PM watchdog depends on.
- *
- * Called when a driver has timed out suspending or resuming.
- * There's not much we can do here to recover so panic() to
- * capture a crash-dump in pstore.
- */
-static void dpm_watchdog_handler(struct timer_list *t)
-{
- struct dpm_watchdog *wd = from_timer(wd, t, timer);
-
- dev_emerg(wd->dev, " DPM device timeout \n");
- show_stack(wd->tsk, NULL, KERN_EMERG);
- panic("%s %s: unrecoverable failure\n",
- dev_driver_string(wd->dev), dev_name(wd->dev));
-}
-
-/**
- * dpm_watchdog_set - Enable pm watchdog for given device.
- * @wd: Watchdog. Must be allocated on the stack.
- * @dev: Device to handle.
- */
-static void dpm_watchdog_set(struct dpm_watchdog *wd, struct device *dev)
-{
- struct timer_list *timer = >timer;
-
- wd->dev = dev;
- wd->tsk = current;
-
- timer_setup_on_stack(timer, dpm_watchdog_handler, 0);
- /* use same timeout value for both suspend and resume */
- timer->expires = jiffies + HZ * CONFIG_DPM_WATCHDOG_TIMEOUT;
- add_timer(timer);
-}
-
-/**
- * dpm_watchdog_clear - Disable suspend/resume watchdog.
- * @wd: Watchdog to disable.
- */
-static void dpm_watchdog_clear(struct dpm_watchdog *wd)
-{
- struct timer_list *timer = >timer;
-
- del_timer_sync(timer);
- destroy_timer_on_stack(timer);
-}
-#else
-#define DECLARE_DPM_WATCHDOG_ON_STACK(wd)
-#define dpm_watchdog_set(x, y)
-#define dpm_watchdog_clear(x)
-#endif
-
/*- Resume routines -*/
/**
@@ -899,7 +836,6 @@ static int device_resume(struct device *dev, pm_message_t
state, bool async)
pm_callback_t callback = NULL;
const char *info = NULL;
int error = 0;
- DECLARE_DPM_WATCHDOG_ON_STACK(wd);
TRACE_DEVICE(dev);
TRACE_RESUME(0);
@@ -916,7 +852,6 @@ static int device_resume(struct device *dev, pm_message_t
state, bool async)
if (!dpm_wait_for_superior(dev, async))
goto Complete;
- dpm_watchdog_set(, dev);
device_lock(dev);
/*
@@ -969,7 +904,6 @@ static int device_resume(struct device *dev, pm_message_t
state, bool async)
Unlock:
device_unlock(dev);
- dpm_watchdog_clear();
Complete:
complete_all(>power.completion);
@@ -1593,7 +1527,6 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
pm_callback_t callback = NULL;
const char *info = NULL;
int error = 0;
- DECLARE_DPM_WATCHDOG_ON_STACK(wd);
TRACE_DEVICE(dev);
TRACE_SUSPEND(0);
@@ -1647,7 +1580,6 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
dev->power.may_skip_resume = true;
dev->power.must_resume = false;
- dpm_watchdog_set(, dev);
device_lock(dev);
if (dev->pm_domain) {
@@ -1699,7 +1631,6 @@ static int __device_suspend(struct device *dev,
pm_message_t state, bool async)
}
device_unlock(dev);
- dpm_watchdog_clear();
Complete:
if (error)
diff --git a/include/linux/console.h b/include/linux/console.h
index 0670d3491e0e..5436d8dc600f 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@
Re: [PATCH v2 1/5] scsi: ufs: atomic update for clkgating_enable
On 2020-10-21 03:52, Jaegeuk Kim wrote:
From: Jaegeuk Kim
When giving a stress test which enables/disables clkgating, we hit
device
timeout sometimes. This patch avoids subtle racy condition to address
it.
Cc: Alim Akhtar
Cc: Avri Altman
Cc: Can Guo
Signed-off-by: Jaegeuk Kim
Reviewed-by: Can Guo
Next time can you have a cover letter in case of multiple patches?
Thanks,
Can Guo.
---
drivers/scsi/ufs/ufshcd.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b8f573a02713..7344353a9167 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1807,19 +1807,19 @@ static ssize_t
ufshcd_clkgate_enable_store(struct device *dev,
return -EINVAL;
value = !!value;
+
+ spin_lock_irqsave(hba->host->host_lock, flags);
if (value == hba->clk_gating.is_enabled)
goto out;
- if (value) {
- ufshcd_release(hba);
- } else {
- spin_lock_irqsave(hba->host->host_lock, flags);
+ if (value)
+ __ufshcd_release(hba);
+ else
hba->clk_gating.active_reqs++;
- spin_unlock_irqrestore(hba->host->host_lock, flags);
- }
hba->clk_gating.is_enabled = value;
out:
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
return count;
}
Re: [PATCH v2 5/5] scsi: ufs: fix clkgating on/off correctly
On 2020-10-21 03:52, Jaegeuk Kim wrote: The below call stack prevents clk_gating at every IO completion. We can remove the condition, ufshcd_any_tag_in_use(), since clkgating_work will check it again. I think checking ufshcd_any_tag_in_use() in either ufshcd_release() or gate_work() can break UFS clk gating's functionality. ufshcd_any_tag_in_use() was introduced to replace hba->lrb_in_use. However, they are not exactly same - ufshcd_any_tag_in_use() returns true if any tag assigned from block layer is still in use, but tags are released asynchronously (through block softirq), meaning it does not reflect the real occupation of UFS host. That is after UFS host finishes all tasks, ufshcd_any_tag_in_use() can still return true. This change only removes the check of ufshcd_any_tag_in_use() in ufshcd_release(), but having the check of it in gate_work() can still prevent gating from happening. The current change works for you maybe because the tags are release before hba->clk_gating.delay_ms expires, but if hba->clk_gating.delay_ms is shorter or somehow block softirq is retarded, gate_work() may have chance to see ufshcd_any_tag_in_use() returns true. What do you think? Thanks, Can Guo. In __ufshcd_transfer_req_compl Ihba->lrb_in_use is cleared immediately when UFS driver finishes all tasks ufshcd_complete_requests(struct ufs_hba *hba) ufshcd_transfer_req_compl() __ufshcd_transfer_req_compl() __ufshcd_release(hba) if (ufshcd_any_tag_in_use() == 1) return; ufshcd_tmc_handler(hba); blk_mq_tagset_busy_iter(); Cc: Alim Akhtar Cc: Avri Altman Cc: Can Guo Signed-off-by: Jaegeuk Kim --- drivers/scsi/ufs/ufshcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index b5ca0effe636..cecbd4ace8b4 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -1746,7 +1746,7 @@ static void __ufshcd_release(struct ufs_hba *hba) if (hba->clk_gating.active_reqs || hba->clk_gating.is_suspended || hba->ufshcd_state != UFSHCD_STATE_OPERATIONAL || - ufshcd_any_tag_in_use(hba) || hba->outstanding_tasks || + hba->outstanding_tasks || hba->active_uic_cmd || hba->uic_async_done) return;
RE: [PATCH 00/15] dmaengine: dw-axi-dmac: support Intel KeemBay AxiDMA
> -Original Message- > From: andriy.shevche...@linux.intel.com > > Sent: 19 October 2020 7:39 PM > To: Sia, Jee Heng > Cc: Eugeniy Paltsev ; > dmaeng...@vger.kernel.org; linux-kernel@vger.kernel.org; vk...@kernel.org; > Alexey Brodkin > Subject: Re: [PATCH 00/15] dmaengine: dw-axi-dmac: support Intel KeemBay > AxiDMA > > On Mon, Oct 19, 2020 at 01:22:03AM +, Sia, Jee Heng wrote: > > > From: Eugeniy Paltsev > > > Sent: 16 October 2020 10:51 PM > > > > Hi Sia, > > > > > > Is this patch series available in some public git repo? > > [>>] We do not have public git repo, but the patch series are tested > > on kernel v5.9 > > Sia, can you fork a kernel repository on GitHub or GitLab and create there a > branch with this series based on v5.9? [>>] Thanks Andy to help to create branch at https://gitlab.com/andy-shev/next/-/tree/topic/dw-dma-axi. Eugeniy, you can start to use this branch and I shall learn to create a public repo. Do let me know if you need anything else. > > > > I want to test it on our HW with DW AXI DMAC. > > Eugeniy, to be honest, it's not a big deal to create one either with help of > lore.kernel.org or patchwork [1]. > > For your convenience (disclaimer, I can't guarantee I haven't missed something > here) I published it here [2]. Note, I didn't compile it. > > [1]: https://patchwork.kernel.org/project/linux- > dmaengine/cover/20201012042200.29787-1-jee.heng@intel.com/ > [2]: https://gitlab.com/andy-shev/next/-/tree/topic/dw-dma-axi > > -- > With Best Regards, > Andy Shevchenko >
linux-next: manual merge of the notifications tree with Linus' tree
Hi all,
Today's linux-next merge of the notifications tree got conflicts in:
arch/alpha/kernel/syscalls/syscall.tbl
arch/arm/tools/syscall.tbl
arch/arm64/include/asm/unistd32.h
arch/ia64/kernel/syscalls/syscall.tbl
arch/m68k/kernel/syscalls/syscall.tbl
arch/microblaze/kernel/syscalls/syscall.tbl
arch/mips/kernel/syscalls/syscall_n32.tbl
arch/mips/kernel/syscalls/syscall_n64.tbl
arch/mips/kernel/syscalls/syscall_o32.tbl
arch/parisc/kernel/syscalls/syscall.tbl
arch/powerpc/kernel/syscalls/syscall.tbl
arch/s390/kernel/syscalls/syscall.tbl
arch/sh/kernel/syscalls/syscall.tbl
arch/sparc/kernel/syscalls/syscall.tbl
arch/x86/entry/syscalls/syscall_32.tbl
arch/x86/entry/syscalls/syscall_64.tbl
arch/xtensa/kernel/syscalls/syscall.tbl
include/uapi/asm-generic/unistd.h
between commit:
ecb8ac8b1f14 ("mm/madvise: introduce process_madvise() syscall: an external
memory hinting API")
from Linus' tree and commit:
4cd92d064cb0 ("watch_queue: Implement mount topology and attribute change
notifications")
from the notifications tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/alpha/kernel/syscalls/syscall.tbl
index ee7b01bb7346,b6cf8403da35..
--- a/arch/alpha/kernel/syscalls/syscall.tbl
+++ b/arch/alpha/kernel/syscalls/syscall.tbl
@@@ -479,4 -478,4 +479,5 @@@
547 common openat2 sys_openat2
548 common pidfd_getfd sys_pidfd_getfd
549 common faccessat2 sys_faccessat2
-550 common watch_mount sys_watch_mount
+550 common process_madvise sys_process_madvise
++551 common watch_mount sys_watch_mount
diff --cc arch/arm/tools/syscall.tbl
index d056a548358e,27cc1f53f4a0..
--- a/arch/arm/tools/syscall.tbl
+++ b/arch/arm/tools/syscall.tbl
@@@ -453,4 -452,4 +453,5 @@@
437 common openat2 sys_openat2
438 common pidfd_getfd sys_pidfd_getfd
439 common faccessat2 sys_faccessat2
-440 common watch_mount sys_watch_mount
+440 common process_madvise sys_process_madvise
++441 common watch_mount sys_watch_mount
diff --cc arch/arm64/include/asm/unistd32.h
index 107f08e03b9f,4f9cf98cdf0f..
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@@ -887,8 -885,8 +887,10 @@@ __SYSCALL(__NR_openat2, sys_openat2
__SYSCALL(__NR_pidfd_getfd, sys_pidfd_getfd)
#define __NR_faccessat2 439
__SYSCALL(__NR_faccessat2, sys_faccessat2)
-#define __NR_watch_mount 440
+#define __NR_process_madvise 440
+__SYSCALL(__NR_process_madvise, sys_process_madvise)
++#define __NR_watch_mount 441
+ __SYSCALL(__NR_watch_mount, sys_watch_mount)
/*
* Please add new compat syscalls above this comment and update
diff --cc arch/ia64/kernel/syscalls/syscall.tbl
index b96ed8b8a508,fc6d87903781..
--- a/arch/ia64/kernel/syscalls/syscall.tbl
+++ b/arch/ia64/kernel/syscalls/syscall.tbl
@@@ -360,4 -359,4 +360,5 @@@
437 common openat2 sys_openat2
438 common pidfd_getfd sys_pidfd_getfd
439 common faccessat2 sys_faccessat2
-440 common watch_mount sys_watch_mount
+440 common process_madvise sys_process_madvise
++441 common watch_mount sys_watch_mount
diff --cc arch/m68k/kernel/syscalls/syscall.tbl
index 625fb6d32842,c671aa0e4d25..
--- a/arch/m68k/kernel/syscalls/syscall.tbl
+++ b/arch/m68k/kernel/syscalls/syscall.tbl
@@@ -439,4 -438,4 +439,5 @@@
437 common openat2 sys_openat2
438 common pidfd_getfd sys_pidfd_getfd
439 common faccessat2 sys_faccessat2
-440 common watch_mount sys_watch_mount
+440 common process_madvise sys_process_madvise
++441 common watch_mount sys_watch_mount
diff --cc arch/microblaze/kernel/syscalls/syscall.tbl
index aae729c95cf9,65cc53f129ef..
--- a/arch/microblaze/kernel/syscalls/syscall.tbl
+++ b/arch/microblaze/kernel/syscalls/syscall.tbl
@@@ -445,4 -444,4 +445,5 @@@
437 common openat2 sys_openat2
438 common pidfd_getfd sys_pidfd_getfd
439 common faccessat2 sys_faccessat2
-440 common watch_mount sys_watch_mount
+440 common process_madvise
[PATCH v2 0/1] clocksource: sp804: add static for functions such as sp804_clockevents_init()
v1 --> v2: Add warning information into the description of this patch. And correct the commit-id of "Fixes:", the old one is come from linux-next, but it's changed when merged into v5.10-rc1. Zhen Lei (1): clocksource: sp804: add static for functions such as sp804_clockevents_init() drivers/clocksource/timer-sp804.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) -- 1.8.3
[PATCH v2 1/1] clocksource: sp804: add static for functions such as sp804_clockevents_init()
Add static for sp804_clocksource_and_sched_clock_init() and
sp804_clockevents_init(), they are only used in timer-sp804.c now.
Otherwise, the following warning will be reported:
drivers/clocksource/timer-sp804.c:68:12: warning: no previous prototype \
for 'sp804_clocksource_and_sched_clock_init' [-Wmissing-prototypes]
drivers/clocksource/timer-sp804.c:162:12: warning: no previous prototype \
for 'sp804_clockevents_init' [-Wmissing-prototypes]
Fixes: 975434f8b24a ("clocksource/drivers/sp804: Delete the leading "__" of
some functions")
Fixes: 65f4d7ddc7b6 ("clocksource/drivers/sp804: Remove unused
sp804_timer_disable() and timer-sp804.h")
Reported-by: kernel test robot
Signed-off-by: Zhen Lei
---
drivers/clocksource/timer-sp804.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/timer-sp804.c
b/drivers/clocksource/timer-sp804.c
index 6e8ad4a4ea3c737..db5330cc49bca72 100644
--- a/drivers/clocksource/timer-sp804.c
+++ b/drivers/clocksource/timer-sp804.c
@@ -117,10 +117,10 @@ static u64 notrace sp804_read(void)
return ~readl_relaxed(sched_clkevt->value);
}
-int __init sp804_clocksource_and_sched_clock_init(void __iomem *base,
- const char *name,
- struct clk *clk,
- int use_sched_clock)
+static int __init sp804_clocksource_and_sched_clock_init(void __iomem *base,
+const char *name,
+struct clk *clk,
+int use_sched_clock)
{
long rate;
struct sp804_clkevt *clkevt;
@@ -216,8 +216,8 @@ static int sp804_set_next_event(unsigned long next,
.rating = 300,
};
-int __init sp804_clockevents_init(void __iomem *base, unsigned int irq,
- struct clk *clk, const char *name)
+static int __init sp804_clockevents_init(void __iomem *base, unsigned int irq,
+struct clk *clk, const char *name)
{
struct clock_event_device *evt = _clockevent;
long rate;
--
1.8.3
Re: [PATCH 5/6] x86/apic/msi: Use Real PCI DMA device when configuring IRTE
On Tue, 2020-10-20 at 15:26 -0500, Bjorn Helgaas wrote:
> On Tue, Jul 28, 2020 at 01:49:44PM -0600, Jon Derrick wrote:
> > VMD retransmits child device MSI/X with the VMD endpoint's requester-id.
> > In order to support direct interrupt remapping of VMD child devices,
> > ensure that the IRTE is programmed with the VMD endpoint's requester-id
> > using pci_real_dma_dev().
> >
> > Reviewed-by: Andy Shevchenko
> > Signed-off-by: Jon Derrick
>
> As Thomas (and Stephen) pointed out, this conflicts with 7ca435cf857d
> ("x86/irq: Cleanup the arch_*_msi_irqs() leftovers"), which removes
> native_setup_msi_irqs().
>
> Stephen resolved the conflict by dropping this hunk. I would rather
> just drop this patch completely from the PCI tree. If I keep the
> patch, (1) Linus will have to resolve the conflict, and worse, (2)
> it's not clear what happened to the use of pci_real_dma_dev() here.
> It will just vanish into the ether with no explanation other than
> "this function was removed."
>
> Is dropping this patch the correct thing to do? Or do you need to add
> pci_real_dma_dev() elsewhere to compensate?
It would still need the pci_real_dma_dev() for IRTE programming.
I think at this point I would rather see 5+6 dropped and this included
for TGL enablement:
https://patchwork.kernel.org/project/linux-pci/patch/20200914190128.5114-1-jonathan.derr...@intel.com/
>
> > ---
> > arch/x86/kernel/apic/msi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
> > index c2b2911feeef..7ca271b8d891 100644
> > --- a/arch/x86/kernel/apic/msi.c
> > +++ b/arch/x86/kernel/apic/msi.c
> > @@ -189,7 +189,7 @@ int native_setup_msi_irqs(struct pci_dev *dev, int
> > nvec, int type)
> >
> > init_irq_alloc_info(, NULL);
> > info.type = X86_IRQ_ALLOC_TYPE_MSI;
> > - info.msi_dev = dev;
> > + info.msi_dev = pci_real_dma_dev(dev);
> >
> > domain = irq_remapping_get_irq_domain();
> > if (domain == NULL)
> > --
> > 2.27.0
> >
Re: [RFCv2 15/16] KVM: Unmap protected pages from direct mapping
On Tue, 2020-10-20 at 15:20 +0200, David Hildenbrand wrote: > On 20.10.20 14:18, David Hildenbrand wrote: > > On 20.10.20 08:18, Kirill A. Shutemov wrote: > > > If the protected memory feature enabled, unmap guest memory from > > > kernel's direct mappings. > > > > Gah, ugly. I guess this also defeats compaction, swapping, ... oh > > gosh. > > As if all of the encrypted VM implementations didn't bring us > > enough > > ugliness already (SEV extensions also don't support reboots, but > > can at > > least kexec() IIRC). > > > > Something similar is done with secretmem [1]. And people don't seem > > to > > like fragmenting the direct mapping (including me). > > > > [1] https://lkml.kernel.org/r/20200924132904.1391-1-r...@kernel.org > > > > I just thought "hey, we might have to replace pud/pmd mappings by > page > tables when calling kernel_map_pages", this can fail with -ENOMEM, > why > isn't there proper error handling. > > Then I dived into __kernel_map_pages() which states: > > "The return value is ignored as the calls cannot fail. Large pages > for > identity mappings are not used at boot time and hence no memory > allocations during large page split." > > I am probably missing something important, but how is calling > kernel_map_pages() safe *after* booting?! I know we use it for > debug_pagealloc(), but using it in a production-ready feature feels > completely irresponsible. What am I missing? > My understanding was that DEBUG_PAGEALLOC maps the direct map at 4k post-boot as well so that kernel_map_pages() can't fail for it, and to avoid having to take locks for splits in interrupts. I think you are on to something though. That function is essentially a set_memory_() functions on x86 at least, and many callers do not check the error codes. Kees Cook has been pushing to fix this actually: https://github.com/KSPP/linux/issues/7 As long as a page has been broken to 4k, it should be able to be re- mapped without failure (like debug page alloc relies on). If an initial call to restrict permissions needs and fails to break a page, its remap does not need to succeed either before freeing the page, since the page never got set with a lower permission. That's my understanding from x86's cpa at least. The problem becomes that the page silently doesn't have its expected protections during use. Unchecked set_memory_() caching property change failures might result in functional problems though. So there is some background if you wanted it, but yea, I agree this feature should handle if the unmap failed. Probably return an error on the IOCTL and maybe the hypercall. kernel_map_pages() also doesn't do a shootdown though, so this direct map protection is more in the best effort category in its current state. For unmapping causing direct map fragmentation. The two techniques floating around, besides breaking indiscriminately, seem to be: 1. Group and cache unmapped pages to minimize the damage (like secret mem) 2. Somehow repair them back to large pages when reset RW (as Kirill had tried earlier this year in another series) I had imagined this usage would want something like that eventually, but neither helps with the other limitations you mentioned (migration, etc).
Re: [PATCH] net: chelsio: inline_crypto: fix Kconfig and build errors
On Mon, 19 Oct 2020 11:10:59 -0700 Randy Dunlap wrote:
> Fix build errors when TLS=m, TLS_TOE=y, and CRYPTO_DEV_CHELSIO_TLS=y.
>
> Having (tristate) CRYPTO_DEV_CHELSIO_TLS depend on (bool) TLS_TOE
> is not strong enough to prevent the bad combination of TLS=m and
> CRYPTO_DEV_CHELSIO_TLS=y, so add a dependency on TLS to prevent the
> problematic kconfig combination.
>
> Fixes these build errors:
>
> hppa-linux-ld: drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_main.o:
> in function `chtls_free_uld':
> drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_main.c:165: undefined
> reference to `tls_toe_unregister_device'
> hppa-linux-ld: drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_main.o:
> in function `chtls_register_dev':
> drivers/net/ethernet/chelsio/inline_crypto/chtls/chtls_main.c:204: undefined
> reference to `tls_toe_register_device'
>
> Fixes: 44fd1c1fd821 ("chelsio/chtls: separate chelsio tls driver from crypto
> driver")
> Reported-by: kernel test robot
> Signed-off-by: Randy Dunlap
Applied, thanks Randy!
But I swapped the Fixes tag for:
Fixes: 53b4414a7003 ("net/tls: allow compiling TLS TOE out")
