Re: [PATCH] net/skbuff: silence warnings under memory pressure
On (09/04/19 15:41), Sergey Senozhatsky wrote: > But the thing is different in case of dump_stack() + show_mem() + > some other output. Because now we ratelimit not a single printk() line, > but hundreds of them. The ratelimit becomes - 10 * $$$ lines in 5 seconds > (IOW, now we talk about thousands of lines). And on devices with slow serial consoles this can be somewhat close to "no ratelimit". *Suppose* that warn_alloc() adds 700 lines each time. Within 5 seconds we can call warn_alloc() 10 times, which will add 7000 lines to the logbuf. If printk() can evict only 6000 lines in 5 seconds then we have a growing number of pending logbuf messages. -ss
Re: [PATCH 4/4] gpio: Update documentation with ast2600 controllers
śr., 4 wrz 2019 o 08:13 Rashmica Gupta napisał(a): > Again, this needs a proper commit description and the subject should start with "dt-bindings: ...". You also need to Cc the device-tree maintainers. Use scripts/get_maintainer.pl to list all people that should get this patch. Bart > Signed-off-by: Rashmica Gupta > --- > Documentation/devicetree/bindings/gpio/gpio-aspeed.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt > b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt > index 7e9b586770b0..cd388797e07c 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt > @@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings > --- > > Required properties: > -- compatible : Either "aspeed,ast2400-gpio" or > "aspeed,ast2500-gpio" > +- compatible : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio", > + "aspeed,ast2600-gpio", or > "aspeed,ast2600-1-8v-gpio" > > - #gpio-cells : Should be two > - First cell is the GPIO line number > -- > 2.20.1 >
Re: [PATCH v3 0/7] add support USB for MT8183
On Wed, Sep 04, 2019 at 09:54:27AM +0800, Chunfeng Yun wrote: > Hi Greg, > > > Please don't try to pick up this series, the dependent ones are still > under public review, I'll fix build warning and send out new version > after the dependent ones are applied > Sorry for inconvenience No problem, now dropped from my review queue. greg k-h
Re: [PATCH 1/6] soundwire: fix startup sequence for Intel/Cadence
On 13-08-19, 16:32, Pierre-Louis Bossart wrote:
> Multiple changes squashed in single patch to avoid tick-tock effect.
>
> 1. Per the hardware documentation, all changes to MCP_CONFIG,
> MCP_CONTROL, MCP_CMDCTRL and MCP_PHYCTRL need to be validated with a
> self-clearing write to MCP_CONFIG_UPDATE. Add a helper and do the
> update when the CONFIG is changed.
>
> 2. Move interrupt enable after interrupt handler registration
>
> 3. Add a new helper to start the hardware bus reset with maximum duration
> to make sure the Slave(s) correctly detect the reset pattern and to
> ensure electrical conflicts can be resolved.
>
> 4. flush command FIFOs
>
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/soundwire/cadence_master.c | 84 +-
> drivers/soundwire/cadence_master.h | 1 +
> drivers/soundwire/intel.c | 14 -
> 3 files changed, 73 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/soundwire/cadence_master.c
> b/drivers/soundwire/cadence_master.c
> index 502ed4ec8f07..046622e4b264 100644
> --- a/drivers/soundwire/cadence_master.c
> +++ b/drivers/soundwire/cadence_master.c
> @@ -231,6 +231,22 @@ static int cdns_clear_bit(struct sdw_cdns *cdns, int
> offset, u32 value)
> return -EAGAIN;
> }
>
> +/*
> + * all changes to the MCP_CONFIG, MCP_CONTROL, MCP_CMDCTRL and MCP_PHYCTRL
> + * need to be confirmed with a write to MCP_CONFIG_UPDATE
> + */
> +static int cdns_update_config(struct sdw_cdns *cdns)
> +{
> + int ret;
> +
> + ret = cdns_clear_bit(cdns, CDNS_MCP_CONFIG_UPDATE,
> + CDNS_MCP_CONFIG_UPDATE_BIT);
> + if (ret < 0)
> + dev_err(cdns->dev, "Config update timedout\n");
> +
> + return ret;
> +}
> +
> /*
> * debugfs
> */
> @@ -752,7 +768,42 @@ EXPORT_SYMBOL(sdw_cdns_thread);
> /*
> * init routines
> */
> -static int _cdns_enable_interrupt(struct sdw_cdns *cdns)
> +
> +/**
> + * sdw_cdns_exit_reset() - Program reset parameters and start bus operations
> + * @cdns: Cadence instance
> + */
> +int sdw_cdns_exit_reset(struct sdw_cdns *cdns)
> +{
> + int ret;
> +
> + /* program maximum length reset to be safe */
> + cdns_updatel(cdns, CDNS_MCP_CONTROL,
> + CDNS_MCP_CONTROL_RST_DELAY,
> + CDNS_MCP_CONTROL_RST_DELAY);
> +
> + /* use hardware generated reset */
> + cdns_updatel(cdns, CDNS_MCP_CONTROL,
> + CDNS_MCP_CONTROL_HW_RST,
> + CDNS_MCP_CONTROL_HW_RST);
> +
> + /* enable bus operations with clock and data */
> + cdns_updatel(cdns, CDNS_MCP_CONFIG,
> + CDNS_MCP_CONFIG_OP,
> + CDNS_MCP_CONFIG_OP_NORMAL);
> +
> + /* commit changes */
> + ret = cdns_update_config(cdns);
> +
> + return ret;
return cdns_update_config() ?
> +}
> +EXPORT_SYMBOL(sdw_cdns_exit_reset);
> +
> +/**
> + * sdw_cdns_enable_interrupt() - Enable SDW interrupts and update config
> + * @cdns: Cadence instance
> + */
> +int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns)
> {
> u32 mask;
>
> @@ -784,24 +835,8 @@ static int _cdns_enable_interrupt(struct sdw_cdns *cdns)
>
> cdns_writel(cdns, CDNS_MCP_INTMASK, mask);
>
> - return 0;
> -}
> -
> -/**
> - * sdw_cdns_enable_interrupt() - Enable SDW interrupts and update config
> - * @cdns: Cadence instance
> - */
> -int sdw_cdns_enable_interrupt(struct sdw_cdns *cdns)
> -{
> - int ret;
> -
> - _cdns_enable_interrupt(cdns);
> - ret = cdns_clear_bit(cdns, CDNS_MCP_CONFIG_UPDATE,
> - CDNS_MCP_CONFIG_UPDATE_BIT);
> - if (ret < 0)
> - dev_err(cdns->dev, "Config update timedout\n");
> -
> - return ret;
> + /* commit changes */
> + return cdns_update_config(cdns);
> }
> EXPORT_SYMBOL(sdw_cdns_enable_interrupt);
>
> @@ -975,6 +1010,10 @@ int sdw_cdns_init(struct sdw_cdns *cdns)
> cdns_writel(cdns, CDNS_MCP_SSP_CTRL0, CDNS_DEFAULT_SSP_INTERVAL);
> cdns_writel(cdns, CDNS_MCP_SSP_CTRL1, CDNS_DEFAULT_SSP_INTERVAL);
>
> + /* flush command FIFOs */
> + cdns_updatel(cdns, CDNS_MCP_CONTROL, CDNS_MCP_CONTROL_CMD_RST,
> + CDNS_MCP_CONTROL_CMD_RST);
> +
> /* Set cmd accept mode */
> cdns_updatel(cdns, CDNS_MCP_CONTROL, CDNS_MCP_CONTROL_CMD_ACCEPT,
>CDNS_MCP_CONTROL_CMD_ACCEPT);
> @@ -997,13 +1036,10 @@ int sdw_cdns_init(struct sdw_cdns *cdns)
> /* Set cmd mode for Tx and Rx cmds */
> val &= ~CDNS_MCP_CONFIG_CMD;
>
> - /* Set operation to normal */
> - val &= ~CDNS_MCP_CONFIG_OP;
> - val |= CDNS_MCP_CONFIG_OP_NORMAL;
> -
> cdns_writel(cdns, CDNS_MCP_CONFIG, val);
>
> - return 0;
> + /* commit changes */
> + return cdns_update_config(cdns);
> }
> EXPORT_SYMBOL(sdw_cdns_init);
>
> diff --git a/drivers/soundwire/cadence_master.h
> b/drivers/soundwire/cadence_master.h
> index 0b72b7094735..1a67728c5000 100644
> --- a/drivers/soundwire/cadence_master.
[PATCH] KVM: s390: Disallow invalid bits in kvm_valid_regs and kvm_dirty_regs
If unknown bits are set in kvm_valid_regs or kvm_dirty_regs, this
clearly indicates that something went wrong in the KVM userspace
application. The x86 variant of KVM already contains a check for
bad bits (and the corresponding kselftest checks this), so let's
do the same on s390x now, too.
Signed-off-by: Thomas Huth
---
arch/s390/include/uapi/asm/kvm.h | 6
arch/s390/kvm/kvm-s390.c | 4 +++
.../selftests/kvm/s390x/sync_regs_test.c | 30 +++
3 files changed, 40 insertions(+)
diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
index 47104e5b47fd..436ec7636927 100644
--- a/arch/s390/include/uapi/asm/kvm.h
+++ b/arch/s390/include/uapi/asm/kvm.h
@@ -231,6 +231,12 @@ struct kvm_guest_debug_arch {
#define KVM_SYNC_GSCB (1UL << 9)
#define KVM_SYNC_BPBC (1UL << 10)
#define KVM_SYNC_ETOKEN (1UL << 11)
+
+#define KVM_SYNC_S390_VALID_FIELDS \
+ (KVM_SYNC_PREFIX | KVM_SYNC_GPRS | KVM_SYNC_ACRS | KVM_SYNC_CRS | \
+KVM_SYNC_ARCH0 | KVM_SYNC_PFAULT | KVM_SYNC_VRS | KVM_SYNC_RICCB | \
+KVM_SYNC_FPRS | KVM_SYNC_GSCB | KVM_SYNC_BPBC | KVM_SYNC_ETOKEN)
+
/* length and alignment of the sdnx as a power of two */
#define SDNXC 8
#define SDNXL (1UL << SDNXC)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 49d779ae..a7d7dedfe527 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -3998,6 +3998,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
if (kvm_run->immediate_exit)
return -EINTR;
+ if (kvm_run->kvm_valid_regs & ~KVM_SYNC_S390_VALID_FIELDS ||
+ kvm_run->kvm_dirty_regs & ~KVM_SYNC_S390_VALID_FIELDS)
+ return -EINVAL;
+
vcpu_load(vcpu);
if (guestdbg_exit_pending(vcpu)) {
diff --git a/tools/testing/selftests/kvm/s390x/sync_regs_test.c
b/tools/testing/selftests/kvm/s390x/sync_regs_test.c
index bbc93094519b..d5290b4ad636 100644
--- a/tools/testing/selftests/kvm/s390x/sync_regs_test.c
+++ b/tools/testing/selftests/kvm/s390x/sync_regs_test.c
@@ -85,6 +85,36 @@ int main(int argc, char *argv[])
run = vcpu_state(vm, VCPU_ID);
+ /* Request reading invalid register set from VCPU. */
+ run->kvm_valid_regs = INVALID_SYNC_FIELD;
+ rv = _vcpu_run(vm, VCPU_ID);
+ TEST_ASSERT(rv < 0 && errno == EINVAL,
+ "Invalid kvm_valid_regs did not cause expected KVM_RUN
error: %d\n",
+ rv);
+ vcpu_state(vm, VCPU_ID)->kvm_valid_regs = 0;
+
+ run->kvm_valid_regs = INVALID_SYNC_FIELD | TEST_SYNC_FIELDS;
+ rv = _vcpu_run(vm, VCPU_ID);
+ TEST_ASSERT(rv < 0 && errno == EINVAL,
+ "Invalid kvm_valid_regs did not cause expected KVM_RUN
error: %d\n",
+ rv);
+ vcpu_state(vm, VCPU_ID)->kvm_valid_regs = 0;
+
+ /* Request setting invalid register set into VCPU. */
+ run->kvm_dirty_regs = INVALID_SYNC_FIELD;
+ rv = _vcpu_run(vm, VCPU_ID);
+ TEST_ASSERT(rv < 0 && errno == EINVAL,
+ "Invalid kvm_dirty_regs did not cause expected KVM_RUN
error: %d\n",
+ rv);
+ vcpu_state(vm, VCPU_ID)->kvm_dirty_regs = 0;
+
+ run->kvm_dirty_regs = INVALID_SYNC_FIELD | TEST_SYNC_FIELDS;
+ rv = _vcpu_run(vm, VCPU_ID);
+ TEST_ASSERT(rv < 0 && errno == EINVAL,
+ "Invalid kvm_dirty_regs did not cause expected KVM_RUN
error: %d\n",
+ rv);
+ vcpu_state(vm, VCPU_ID)->kvm_dirty_regs = 0;
+
/* Request and verify all valid register sets. */
run->kvm_valid_regs = TEST_SYNC_FIELDS;
rv = _vcpu_run(vm, VCPU_ID);
--
2.18.1
Re: [PATCH 2/6] soundwire: cadence_master: add hw_reset capability in debugfs
On 13-08-19, 16:32, Pierre-Louis Bossart wrote:
> Provide debugfs capability to kick link and devices into hard-reset
> (as defined by MIPI). This capability is really useful when some
> devices are no longer responsive and/or to check the software handling
> of resynchronization.
>
> Signed-off-by: Pierre-Louis Bossart
> ---
> drivers/soundwire/cadence_master.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/soundwire/cadence_master.c
> b/drivers/soundwire/cadence_master.c
> index 046622e4b264..bd58d80ff636 100644
> --- a/drivers/soundwire/cadence_master.c
> +++ b/drivers/soundwire/cadence_master.c
> @@ -340,6 +340,23 @@ static int cdns_reg_show(struct seq_file *s, void *data)
> }
> DEFINE_SHOW_ATTRIBUTE(cdns_reg);
>
> +static int cdns_hw_reset(void *data, u64 value)
> +{
> + struct sdw_cdns *cdns = data;
> + int ret;
> +
> + if (value != 1)
> + return 0;
Should this not be EINVAL to indicate invalid value passed?
> +
> + ret = sdw_cdns_exit_reset(cdns);
> +
> + dev_dbg(cdns->dev, "link hw_reset done: %d\n", ret);
> +
> + return ret;
> +}
> +
> +DEFINE_DEBUGFS_ATTRIBUTE(cdns_hw_reset_fops, NULL, cdns_hw_reset, "%llu\n");
> +
> /**
> * sdw_cdns_debugfs_init() - Cadence debugfs init
> * @cdns: Cadence instance
> @@ -348,6 +365,9 @@ DEFINE_SHOW_ATTRIBUTE(cdns_reg);
> void sdw_cdns_debugfs_init(struct sdw_cdns *cdns, struct dentry *root)
> {
> debugfs_create_file("cdns-registers", 0400, root, cdns, &cdns_reg_fops);
> +
> + debugfs_create_file("cdns-hw-reset", 0200, root, cdns,
> + &cdns_hw_reset_fops);
> }
> EXPORT_SYMBOL_GPL(sdw_cdns_debugfs_init);
>
> --
> 2.20.1
--
~Vinod
[PATCH] soc: imx: imx-scu: Getting UID from SCU should have response
The SCU firmware API for getting UID should have response,
otherwise, the message stored in function stack could be
released and then the response data received from SCU will be
stored into that released stack and cause kernel NULL pointer
dump.
Fixes: 73feb4d0f8f1 ("soc: imx-scu: Add SoC UID(unique identifier) support")
Signed-off-by: Anson Huang
---
drivers/soc/imx/soc-imx-scu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c
index 50831eb..c68882e 100644
--- a/drivers/soc/imx/soc-imx-scu.c
+++ b/drivers/soc/imx/soc-imx-scu.c
@@ -46,7 +46,7 @@ static ssize_t soc_uid_show(struct device *dev,
hdr->func = IMX_SC_MISC_FUNC_UNIQUE_ID;
hdr->size = 1;
- ret = imx_scu_call_rpc(soc_ipc_handle, &msg, false);
+ ret = imx_scu_call_rpc(soc_ipc_handle, &msg, true);
if (ret) {
pr_err("%s: get soc uid failed, ret %d\n", __func__, ret);
return ret;
--
2.7.4
Re: [PATCH v4 09/12] docs: Add documentation for Symbol Namespaces
On Tue, Sep 03, 2019 at 04:06:35PM +0100, Matthias Maennich wrote: > Describe using Symbol Namespaces from a perspective of a user. I.e. > module authors or subsystem maintainers. > > Signed-off-by: Matthias Maennich Nice, it's good to have stuff to point people at. Reviewed-by: Greg Kroah-Hartman
Re: [PATCH] tty: n_gsm: avoid recursive locking with async port hangup
On Thu, Aug 29, 2019 at 09:42:31PM +0200, Martin Hundebøll wrote:
> On 22/08/2019 23.56, Martin Hundebøll wrote:
> > When tearing down the n_gsm ldisc while one or more of its child ports
> > are open, a lock dep warning occurs:
> >
> > [ 56.254258] ==
> > [ 56.260447] WARNING: possible circular locking dependency detected
> > [ 56.266641] 5.2.0-00118-g1fd58e20e5b0 #30 Not tainted
> > [ 56.271701] --
> > [ 56.277890] cmux/271 is trying to acquire lock:
> > [ 56.282436] 8215283a (&tty->legacy_mutex){+.+.}, at:
> > __tty_hangup.part.0+0x58/0x27c
> > [ 56.290128]
> > [ 56.290128] but task is already holding lock:
> > [ 56.295970] e9e2b842 (&gsm->mutex){+.+.}, at: gsm_cleanup_mux+0x9c/0x15c
> > [ 56.302699]
> > [ 56.302699] which lock already depends on the new lock.
> > [ 56.302699]
> > [ 56.310884]
> > [ 56.310884] the existing dependency chain (in reverse order) is:
> > [ 56.318372]
> > [ 56.318372] -> #2 (&gsm->mutex){+.+.}:
> > [ 56.323624]mutex_lock_nested+0x1c/0x24
> > [ 56.328079]gsm_cleanup_mux+0x9c/0x15c
> > [ 56.332448]gsmld_ioctl+0x418/0x4e8
> > [ 56.336554]tty_ioctl+0x96c/0xcb0
> > [ 56.340492]do_vfs_ioctl+0x41c/0xa5c
> > [ 56.344685]ksys_ioctl+0x34/0x60
> > [ 56.348535]ret_fast_syscall+0x0/0x28
> > [ 56.352815]0xbe97cc04
> > [ 56.355791]
> > [ 56.355791] -> #1 (&tty->ldisc_sem){}:
> > [ 56.361388]tty_ldisc_lock+0x50/0x74
> > [ 56.365581]tty_init_dev+0x88/0x1c4
> > [ 56.369687]tty_open+0x1c8/0x430
> > [ 56.373536]chrdev_open+0xa8/0x19c
> > [ 56.377560]do_dentry_open+0x118/0x3c4
> > [ 56.381928]path_openat+0x2fc/0x1190
> > [ 56.386123]do_filp_open+0x68/0xd4
> > [ 56.390146]do_sys_open+0x164/0x220
> > [ 56.394257]kernel_init_freeable+0x328/0x3e4
> > [ 56.399146]kernel_init+0x8/0x110
> > [ 56.403078]ret_from_fork+0x14/0x20
> > [ 56.407183]0x0
> > [ 56.409548]
> > [ 56.409548] -> #0 (&tty->legacy_mutex){+.+.}:
> > [ 56.415402]__mutex_lock+0x64/0x90c
> > [ 56.419508]mutex_lock_nested+0x1c/0x24
> > [ 56.423961]__tty_hangup.part.0+0x58/0x27c
> > [ 56.428676]gsm_cleanup_mux+0xe8/0x15c
> > [ 56.433043]gsmld_close+0x48/0x90
> > [ 56.436979]tty_ldisc_kill+0x2c/0x6c
> > [ 56.441173]tty_ldisc_release+0x88/0x194
> > [ 56.445715]tty_release_struct+0x14/0x44
> > [ 56.450254]tty_release+0x36c/0x43c
> > [ 56.454365]__fput+0x94/0x1e8
> >
> > Avoid the warning by doing the port hangup asynchronously.
>
> Any comments?
Sorry, was waiting to see if anyone would review this, I'll go do it
later today...
Re: [PATCH] net/skbuff: silence warnings under memory pressure
On (09/04/19 08:54), Michal Hocko wrote:
> I am sorry, I could have been more explicit when CCing you.
Oh, sorry! My bad!
> Sure the ratelimit is part of the problem. But I was more interested
> in the potential livelock (infinite loop) mentioned by Qian Cai. It
> is not important whether we generate one or more lines of output from
> the softirq context as long as the printk generates more irq processing
> which might end up doing the same. Is this really possible?
Hmm. I need to look at this more... wake_up_klogd() queues work only once
on particular CPU: irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
bool irq_work_queue()
{
/* Only queue if not already pending */
if (!irq_work_claim(work))
return false;
__irq_work_queue_local(work);
}
softirqs are processed in batches, right? The softirq batch can add
lines to printk logbuf, but there will be only one PRINTK_PENDING_WAKEUP
queued. Qian Cai mentioned that "net_rx_action softirqs again which are
plenty due to connected via ssh etc." so the proportion still seems to be
N:1 - we process N softirqs, add 1 printk irq_work.
But need to think more.
Interesting question.
-ss
Re: [PATCH v3 2/2] binder: Validate the default binderfs device names.
On Fri, Aug 09, 2019 at 11:41:12AM -0700, Hridya Valsaraju wrote:
> On Fri, Aug 9, 2019 at 11:14 AM Christian Brauner
> wrote:
> >
> > On Fri, Aug 09, 2019 at 04:55:08PM +0200, Greg Kroah-Hartman wrote:
> > > On Thu, Aug 08, 2019 at 03:27:26PM -0700, Hridya Valsaraju wrote:
> > > > Length of a binderfs device name cannot exceed BINDERFS_MAX_NAME.
> > > > This patch adds a check in binderfs_init() to ensure the same
> > > > for the default binder devices that will be created in every
> > > > binderfs instance.
> > > >
> > > > Co-developed-by: Christian Brauner
> > > > Signed-off-by: Christian Brauner
> > > > Signed-off-by: Hridya Valsaraju
> > > > ---
> > > > drivers/android/binderfs.c | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> > > > index aee46dd1be91..55c5adb87585 100644
> > > > --- a/drivers/android/binderfs.c
> > > > +++ b/drivers/android/binderfs.c
> > > > @@ -570,6 +570,18 @@ static struct file_system_type binder_fs_type = {
> > > > int __init init_binderfs(void)
> > > > {
> > > > int ret;
> > > > + const char *name;
> > > > + size_t len;
> > > > +
> > > > + /* Verify that the default binderfs device names are valid. */
> > >
> > > And by "valid" you only mean "not bigger than BINDERFS_MAX_NAME, right?
> > >
> > > > + name = binder_devices_param;
> > > > + for (len = strcspn(name, ","); len > 0; len = strcspn(name, ",")) {
> > > > + if (len > BINDERFS_MAX_NAME)
> > > > + return -E2BIG;
> > > > + name += len;
> > > > + if (*name == ',')
> > > > + name++;
> > > > + }
> > >
> > > We already tokenize the binderfs device names in binder_init(), why not
> > > check this there instead? Parsing the same string over and over isn't
> > > the nicest.
> >
> > non-binderfs binder devices do not have their limit set to
> > BINDERFS_NAME_MAX. That's why the check has likely been made specific to
> > binderfs binder devices which do have that limit.
>
>
> Thank you Greg and Christian, for taking another look. Yes,
> non-binderfs binder devices not having this limitation is the reason
> why the check was made specific to binderfs devices. Also, when
> CONFIG_ANDROID_BINDERFS is set, patch 1/2 disabled the same string
> being parsed in binder_init().
>
> >
> > But, in practice, 255 is the standard path-part limit that no-one really
> > exceeds especially not for stuff such as device nodes which usually have
> > rather standard naming schemes (e.g. binder, vndbinder, hwbinder, etc.).
> > So yes, we can move that check before both the binderfs binder device
> > and non-binderfs binder device parsing code and treat it as a generic
> > check.
> > Then we can also backport that check as you requested in the other mail.
> > Unless Hridya or Todd have objections, of course.
>
> I do not have any objections to adding a generic check in binder_init()
> instead.
Was this patchset going to be redone based on this?
thanks,
greg k-h
[PATCH v3] mm/hugetlb: avoid looping to the same hugepage if !pages and !vmas
From: Zhigang Lu
When mmapping an existing hugetlbfs file with MAP_POPULATE, we find
it is very time consuming. For example, mmapping a 128GB file takes
about 50 milliseconds. Sampling with perfevent shows it spends 99%
time in the same_page loop in follow_hugetlb_page().
samples: 205 of event 'cycles', Event count (approx.): 136686374
- 99.04% test_mmap_huget [kernel.kallsyms] [k] follow_hugetlb_page
follow_hugetlb_page
__get_user_pages
__mlock_vma_pages_range
__mm_populate
vm_mmap_pgoff
sys_mmap_pgoff
sys_mmap
system_call_fastpath
__mmap64
follow_hugetlb_page() is called with pages=NULL and vmas=NULL, so for
each hugepage, we run into the same_page loop for pages_per_huge_page()
times, but doing nothing. With this change, it takes less then 1
millisecond to mmap a 128GB file in hugetlbfs.
Signed-off-by: Zhigang Lu
Reviewed-by: Haozhong Zhang
Reviewed-by: Zongming Zhang
Reviewed-by: Mike Kravetz
Acked-by: Matthew Wilcox
---
mm/hugetlb.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6d7296d..a096fb3 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4391,6 +4391,21 @@ long follow_hugetlb_page(struct mm_struct *mm, struct
vm_area_struct *vma,
break;
}
}
+
+ /*
+* If subpage information not requested, update counters
+* and skip the same_page loop below.
+*/
+ if (!pages && !vmas && !pfn_offset &&
+ (vaddr + huge_page_size(h) < vma->vm_end) &&
+ (remainder >= pages_per_huge_page(h))) {
+ vaddr += huge_page_size(h);
+ remainder -= pages_per_huge_page(h);
+ i += pages_per_huge_page(h);
+ spin_unlock(ptl);
+ continue;
+ }
+
same_page:
if (pages) {
pages[i] = mem_map_offset(page, pfn_offset);
--
1.8.3.1
Re: [RFC PATCH 3/5] ASoC: SOF: Intel: hda: add SoundWire IP support
On 21-08-19, 15:17, Pierre-Louis Bossart wrote:
> The Core0 needs to be powered before the SoundWire IP is initialized.
>
> Call sdw_intel_init/exit and store the context. We only have one
> context, but depending on the hardware capabilities and BIOS settings
> may enable multiple SoundWire links.
>
> Signed-off-by: Pierre-Louis Bossart
> ---
> sound/soc/sof/intel/hda.c | 40 +--
> sound/soc/sof/intel/hda.h | 5 +
> 2 files changed, 39 insertions(+), 6 deletions(-)
>
> diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c
> index a968890d0754..e754058e3679 100644
> --- a/sound/soc/sof/intel/hda.c
> +++ b/sound/soc/sof/intel/hda.c
> @@ -57,6 +57,8 @@ static int hda_sdw_init(struct snd_sof_dev *sdev)
> {
> acpi_handle handle;
> struct sdw_intel_res res;
> + struct sof_intel_hda_dev *hdev;
> + void *sdw;
>
> handle = ACPI_HANDLE(sdev->dev);
>
> @@ -66,23 +68,32 @@ static int hda_sdw_init(struct snd_sof_dev *sdev)
> res.irq = sdev->ipc_irq;
> res.parent = sdev->dev;
>
> - hda_sdw_int_enable(sdev, true);
> -
> - sdev->sdw = sdw_intel_init(handle, &res);
> - if (!sdev->sdw) {
> + sdw = sdw_intel_init(handle, &res);
should this be called for platforms without sdw, I was hoping that some
checks would be performed.. For example how would skl deal with this?
> + if (!sdw) {
> dev_err(sdev->dev, "SDW Init failed\n");
> return -EIO;
> }
>
> + hda_sdw_int_enable(sdev, true);
> +
> + /* save context */
> + hdev = sdev->pdata->hw_pdata;
> + hdev->sdw = sdw;
> +
> return 0;
> }
>
> static int hda_sdw_exit(struct snd_sof_dev *sdev)
> {
> + struct sof_intel_hda_dev *hdev;
> +
> + hdev = sdev->pdata->hw_pdata;
> +
> hda_sdw_int_enable(sdev, false);
>
> - if (sdev->sdw)
> - sdw_intel_exit(sdev->sdw);
this looks suspect, you are adding sdw calls here so how is this getting
removed? Did I miss something...
> + if (hdev->sdw)
> + sdw_intel_exit(hdev->sdw);
> + hdev->sdw = NULL;
>
> return 0;
> }
> @@ -713,6 +724,21 @@ int hda_dsp_probe(struct snd_sof_dev *sdev)
> /* set default mailbox offset for FW ready message */
> sdev->dsp_box.offset = HDA_DSP_MBOX_UPLINK_OFFSET;
>
> + /* need to power-up core before setting-up capabilities */
> + ret = hda_dsp_core_power_up(sdev, HDA_DSP_CORE_MASK(0));
> + if (ret < 0) {
> + dev_err(sdev->dev, "error: could not power-up DSP subsystem\n");
> + goto free_ipc_irq;
> + }
> +
> + /* initialize SoundWire capabilities */
> + ret = hda_sdw_init(sdev);
> + if (ret < 0) {
> + dev_err(sdev->dev, "error: SoundWire get caps error\n");
> + hda_dsp_core_power_down(sdev, HDA_DSP_CORE_MASK(0));
> + goto free_ipc_irq;
> + }
> +
> return 0;
>
> free_ipc_irq:
> @@ -744,6 +770,8 @@ int hda_dsp_remove(struct snd_sof_dev *sdev)
> snd_hdac_ext_bus_device_remove(bus);
> #endif
>
> + hda_sdw_exit(sdev);
> +
> if (!IS_ERR_OR_NULL(hda->dmic_dev))
> platform_device_unregister(hda->dmic_dev);
>
> diff --git a/sound/soc/sof/intel/hda.h b/sound/soc/sof/intel/hda.h
> index c8f93317aeb4..48e09b7daf0a 100644
> --- a/sound/soc/sof/intel/hda.h
> +++ b/sound/soc/sof/intel/hda.h
> @@ -399,6 +399,11 @@ struct sof_intel_hda_dev {
>
> /* DMIC device */
> struct platform_device *dmic_dev;
> +
> +#if IS_ENABLED(CONFIG_SOUNDWIRE_INTEL)
is this really required, context is a void pointer
> + /* sdw context */
> + void *sdw;
> +#endif
> };
>
> static inline struct hdac_bus *sof_to_bus(struct snd_sof_dev *s)
> --
> 2.20.1
--
~Vinod
Re: [PATCH] ext2: Delete an unnecessary check before brelse()
On Tue 03-09-19 14:44:08, Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 3 Sep 2019 14:40:18 +0200 > > The brelse() function tests whether its argument is NULL > and then returns immediately. > Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Thanks. Added to my tree. Honza > --- > fs/ext2/super.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/ext2/super.c b/fs/ext2/super.c > index baa36c6fb71e..30c630d73f0f 100644 > --- a/fs/ext2/super.c > +++ b/fs/ext2/super.c > @@ -162,8 +162,7 @@ static void ext2_put_super (struct super_block * sb) > } > db_count = sbi->s_gdb_count; > for (i = 0; i < db_count; i++) > - if (sbi->s_group_desc[i]) > - brelse (sbi->s_group_desc[i]); > + brelse(sbi->s_group_desc[i]); > kfree(sbi->s_group_desc); > kfree(sbi->s_debts); > percpu_counter_destroy(&sbi->s_freeblocks_counter); > -- > 2.23.0 > > -- Jan Kara SUSE Labs, CR
Re: [PATCH 1/1] s390: vfio-ap: fix warning reset not completed
On 03.09.19 15:36, Halil Pasic wrote: > The intention seems to be to warn once when we don't wait enough for the > reset to complete. Let's use the right retry counter to accomplish that > semantic. > > Signed-off-by: Halil Pasic Thanks applied. I will let it sit in our tree for some days as I want to see if we actually hit the WARN_ON now. So if there is an rc8 this will be part of the next merge window, otherwise this will somewhat come later. > --- > drivers/s390/crypto/vfio_ap_ops.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/s390/crypto/vfio_ap_ops.c > b/drivers/s390/crypto/vfio_ap_ops.c > index 0604b49a4d32..5c0f53c6dde7 100644 > --- a/drivers/s390/crypto/vfio_ap_ops.c > +++ b/drivers/s390/crypto/vfio_ap_ops.c > @@ -1143,7 +1143,7 @@ int vfio_ap_mdev_reset_queue(unsigned int apid, > unsigned int apqi, > msleep(20); > status = ap_tapq(apqn, NULL); > } > - WARN_ON_ONCE(retry <= 0); > + WARN_ON_ONCE(retry2 <= 0); > return 0; > case AP_RESPONSE_RESET_IN_PROGRESS: > case AP_RESPONSE_BUSY: >
Re: [PATCH v2] HID: apple: Fix stuck function keys when using FN
On Tue, Sep 3, 2019 at 8:33 PM João Moreno wrote:
>
> Hi Benjamin,
>
> On Tue, 3 Sep 2019 at 16:46, Benjamin Tissoires
> wrote:
> >
> > From: Joao Moreno
> >
> > This fixes an issue in which key down events for function keys would be
> > repeatedly emitted even after the user has raised the physical key. For
> > example, the driver fails to emit the F5 key up event when going through
> > the following steps:
> > - fnmode=1: hold FN, hold F5, release FN, release F5
> > - fnmode=2: hold F5, hold FN, release F5, release FN
> >
> > The repeated F5 key down events can be easily verified using xev.
> >
> > Signed-off-by: Joao Moreno
> > Co-developed-by: Benjamin Tissoires
> > Signed-off-by: Benjamin Tissoires
> > ---
> >
> > Hi Joao,
> >
> > last chance to pull back :)
> >
> > If you are still happy, I'll push this version
> >
> > Cheers,
> > Benjamin
> >
>
> Looks great. Thanks a bunch for your help!
>
Thanks.
Applied to for-5.4/apple
Cheers,
Benjamin
> Cheers,
> João
>
> > drivers/hid/hid-apple.c | 49 +++--
> > 1 file changed, 28 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> > index 81df62f48c4c..6ac8becc2372 100644
> > --- a/drivers/hid/hid-apple.c
> > +++ b/drivers/hid/hid-apple.c
> > @@ -54,7 +54,6 @@ MODULE_PARM_DESC(swap_opt_cmd, "Swap the Option (\"Alt\")
> > and Command (\"Flag\")
> > struct apple_sc {
> > unsigned long quirks;
> > unsigned int fn_on;
> > - DECLARE_BITMAP(pressed_fn, KEY_CNT);
> > DECLARE_BITMAP(pressed_numlock, KEY_CNT);
> > };
> >
> > @@ -181,6 +180,8 @@ static int hidinput_apple_event(struct hid_device *hid,
> > struct input_dev *input,
> > {
> > struct apple_sc *asc = hid_get_drvdata(hid);
> > const struct apple_key_translation *trans, *table;
> > + bool do_translate;
> > + u16 code = 0;
> >
> > if (usage->code == KEY_FN) {
> > asc->fn_on = !!value;
> > @@ -189,8 +190,6 @@ static int hidinput_apple_event(struct hid_device *hid,
> > struct input_dev *input,
> > }
> >
> > if (fnmode) {
> > - int do_translate;
> > -
> > if (hid->product >= USB_DEVICE_ID_APPLE_WELLSPRING4_ANSI &&
> > hid->product <=
> > USB_DEVICE_ID_APPLE_WELLSPRING4A_JIS)
> > table = macbookair_fn_keys;
> > @@ -202,25 +201,33 @@ static int hidinput_apple_event(struct hid_device
> > *hid, struct input_dev *input,
> > trans = apple_find_translation (table, usage->code);
> >
> > if (trans) {
> > - if (test_bit(usage->code, asc->pressed_fn))
> > - do_translate = 1;
> > - else if (trans->flags & APPLE_FLAG_FKEY)
> > - do_translate = (fnmode == 2 && asc->fn_on)
> > ||
> > - (fnmode == 1 && !asc->fn_on);
> > - else
> > - do_translate = asc->fn_on;
> > -
> > - if (do_translate) {
> > - if (value)
> > - set_bit(usage->code,
> > asc->pressed_fn);
> > - else
> > - clear_bit(usage->code,
> > asc->pressed_fn);
> > -
> > - input_event(input, usage->type, trans->to,
> > - value);
> > -
> > - return 1;
> > + if (test_bit(trans->from, input->key))
> > + code = trans->from;
> > + else if (test_bit(trans->to, input->key))
> > + code = trans->to;
> > +
> > + if (!code) {
> > + if (trans->flags & APPLE_FLAG_FKEY) {
> > + switch (fnmode) {
> > + case 1:
> > + do_translate = !asc->fn_on;
> > + break;
> > + case 2:
> > + do_translate = asc->fn_on;
> > + break;
> > + default:
> > + /* should never happen */
> > + do_translate = false;
> > + }
> > + } else {
> > + do_translate = asc->fn_on;
> > + }
> > +
> > + code = do_translate ? trans->to :
> > trans->from;
> > }
> > +
> > + input_ev
Re: [PATCH V6 0/3] riscv: Add perf callchain support
Mao Han 於 2019年8月29日 週四 下午2:57寫道： > > This patch set add perf callchain(FP/DWARF) support for RISC-V. > It comes from the csky version callchain support with some > slight modifications. The patchset base on Linux 5.3-rc6. > > Changes since v5: > - use walk_stackframe from stacktrace.c to handle > kernel callchain unwinding(fix invalid mem access) > > Changes since v4: > - Add missing PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET > verified with extra CFLAGS(-Wall -Werror) > > Changes since v3: > - Add more strict check for unwind_frame_kernel > - update for kernel 5.3 > > Changes since v2: > - fix inconsistent comment > - force to build kernel with -fno-omit-frame-pointer if perf > event is enabled > > Changes since v1: > - simplify implementation and code convention > > Cc: Paul Walmsley > Cc: Greentime Hu > Cc: Palmer Dabbelt > Cc: linux-riscv > Cc: Christoph Hellwig > Cc: Guo Ren > > Mao Han (3): > riscv: Add perf callchain support > riscv: Add support for perf registers sampling > riscv: Add support for libdw > > arch/riscv/Kconfig| 2 + > arch/riscv/Makefile | 3 + > arch/riscv/include/uapi/asm/perf_regs.h | 42 > arch/riscv/kernel/Makefile| 4 +- > arch/riscv/kernel/perf_callchain.c| 95 ++ > arch/riscv/kernel/perf_regs.c | 44 > arch/riscv/kernel/stacktrace.c| 2 +- > tools/arch/riscv/include/uapi/asm/perf_regs.h | 42 > tools/perf/Makefile.config| 6 +- > tools/perf/arch/riscv/Build | 1 + > tools/perf/arch/riscv/Makefile| 4 ++ > tools/perf/arch/riscv/include/perf_regs.h | 96 > +++ > tools/perf/arch/riscv/util/Build | 2 + > tools/perf/arch/riscv/util/dwarf-regs.c | 72 > tools/perf/arch/riscv/util/unwind-libdw.c | 57 > 15 files changed, 469 insertions(+), 3 deletions(-) > create mode 100644 arch/riscv/include/uapi/asm/perf_regs.h > create mode 100644 arch/riscv/kernel/perf_callchain.c > create mode 100644 arch/riscv/kernel/perf_regs.c > create mode 100644 tools/arch/riscv/include/uapi/asm/perf_regs.h > create mode 100644 tools/perf/arch/riscv/Build > create mode 100644 tools/perf/arch/riscv/Makefile > create mode 100644 tools/perf/arch/riscv/include/perf_regs.h > create mode 100644 tools/perf/arch/riscv/util/Build > create mode 100644 tools/perf/arch/riscv/util/dwarf-regs.c > create mode 100644 tools/perf/arch/riscv/util/unwind-libdw.c > Tested-by: Greentime Hu I tested this patchset based on v5.3-rc6 and it can use dwarf or fp to backtrace in Unleashed board. # perf record -e cpu-clock --call-graph dwarf ls -l / total 4 drwxr-xr-x2 root root 0 Aug 26 2019 bin drwxr-xr-x5 root root 12720 Jan 1 00:00 dev drwxr-xr-x5 root root 0 Jan 1 00:00 etc -rwxr-xr-x1 root root 178 Aug 26 2019 init drwxr-xr-x2 root root 0 Aug 26 2019 lib lrwxrwxrwx1 root root 3 Aug 19 2019 lib64 -> lib lrwxrwxrwx1 root root11 Aug 19 2019 linuxrc -> bin/busybox drwxr-xr-x2 root root 0 Aug 19 2019 media drwxr-xr-x2 root root 0 Aug 19 2019 mnt drwxr-xr-x2 root root 0 Aug 19 2019 opt dr-xr-xr-x 66 root root 0 Jan 1 00:00 proc drwx--3 root root 0 Jan 1 00:01 root drwxr-xr-x3 root root 140 Jan 1 00:00 run drwxr-xr-x2 root root 0 Aug 19 2019 sbin dr-xr-xr-x 11 root root 0 Jan 1 00:00 sys drwxrwxrwt2 root root60 Jan 1 00:00 tmp drwxr-xr-x6 root root 0 Aug 26 2019 usr drwxr-xr-x4 root root 0 Aug 26 2019 var [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.175 MB perf.data (21 samples) ] # perf record -e cpu-clock --call-graph fp ls -l / total 4 drwxr-xr-x2 root root 0 Aug 26 2019 bin drwxr-xr-x5 root root 12720 Jan 1 00:00 dev drwxr-xr-x5 root root 0 Jan 1 00:00 etc -rwxr-xr-x1 root root 178 Aug 26 2019 init drwxr-xr-x2 root root 0 Aug 26 2019 lib lrwxrwxrwx1 root root 3 Aug 19 2019 lib64 -> lib lrwxrwxrwx1 root root11 Aug 19 2019 linuxrc -> bin/busybox drwxr-xr-x2 root root 0 Aug 19 2019 media drwxr-xr-x2 root root 0 Aug 19 2019 mnt drwxr-xr-x2 root root 0 Aug 19 2019 opt dr-xr-xr-x 66 root root 0 Jan 1 00:00 proc drwx--3 root root 0 Jan 1 00:00 root drwxr-xr-x3 root root 140 Jan 1 00:00 ru
Re: [PATCH v5] perf machine: arm/arm64: Improve completeness for kernel address space
On 2/09/19 5:15 PM, Leo Yan wrote:
> Hi Adrian,
>
> On Mon, Aug 26, 2019 at 08:51:05PM +0800, Leo Yan wrote:
>> Hi Adrian,
>>
>> On Fri, Aug 16, 2019 at 04:00:02PM +0300, Adrian Hunter wrote:
>>> On 16/08/19 4:45 AM, Leo Yan wrote:
Hi Adrian,
On Thu, Aug 15, 2019 at 02:45:57PM +0300, Adrian Hunter wrote:
[...]
>>> How come you cannot use kallsyms to get the information?
>>
>> Thanks for pointing out this. Sorry I skipped your comment "I don't
>> know how you intend to calculate ARM_PRE_START_SIZE" when you reviewed
>> the patch v3, I should use that chance to elaborate the detailed idea
>> and so can get more feedback/guidance before procceed.
>>
>> Actually, I have considered to use kallsyms when worked on the previous
>> patch set.
>>
>> As mentioned in patch set v4's cover letter, I tried to implement
>> machine__create_extra_kernel_maps() for arm/arm64, the purpose is to
>> parse kallsyms so can find more kernel maps and thus also can fixup
>> the kernel start address. But I found the 'perf script' tool directly
>> calls machine__get_kernel_start() instead of running into the flow for
>> machine__create_extra_kernel_maps();
>
> Doesn't it just need to loop through each kernel map to find the lowest
> start address?
Based on your suggestion, I worked out below change and verified it
can work well on arm64 for fixing up start address; please let me know
if the change works for you?
>>>
>>> How does that work if take a perf.data file to a machine with a different
>>> architecture?
>>
>> Sorry I delayed so long to respond to your question; I didn't have
>> confidence to give out very reasonale answer and this is the main reason
>> for delaying.
>
> Could you take chance to review my below replying? I'd like to get
> your confirmation before I send out offical patch.
It is not necessary to do kallsyms__parse for x86_64, so it would be better
to check the arch before calling that.
However in general, having to copy and use kallsyms with perf.data if on a
different arch does not seem very user friendly. But really that is up to
Arnaldo.
>
> Thanks,
> Leo Yan
>
>>
>> For your question for taking a perf.data file to a machine with a
>> different architecture, we can firstly use command 'perf buildid-list'
>> to print out the buildid for kallsyms, based on the dumped buildid we
>> can find out the location for the saved kallsyms file; then we can use
>> option '--kallsyms' to specify the offline kallsyms file and use the
>> offline kallsyms to fixup kernel start address. The detailed commands
>> are listed as below:
>>
>> root@debian:~# perf buildid-list
>> 7b36dfca8317ef74974ebd7ee5ec0a8b35c97640 [kernel.kallsyms]
>> 56b84aa88a1bcfe222a97a53698b92723a3977ca /usr/lib/systemd/systemd
>> 0956b952e9cd673d48ff2cfeb1a9dbd0c853e686
>> /usr/lib/aarch64-linux-gnu/libm-2.28.so
>> [...]
>>
>> root@debian:~# perf script --kallsyms
>> ~/.debug/\[kernel.kallsyms\]/7b36dfca8317ef74974ebd7ee5ec0a8b35c97640/kallsyms
>>
>> The amended patch is as below, please review and always welcome
>> any suggestions or comments!
>>
>> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
>> index 5734460fc89e..593f05cc453f 100644
>> --- a/tools/perf/util/machine.c
>> +++ b/tools/perf/util/machine.c
>> @@ -2672,9 +2672,26 @@ int machine__nr_cpus_avail(struct machine *machine)
>> return machine ? perf_env__nr_cpus_avail(machine->env) : 0;
>> }
>>
>> +static int machine__fixup_kernel_start(void *arg,
>> + const char *name __maybe_unused,
>> + char type,
>> + u64 start)
>> +{
>> +struct machine *machine = arg;
>> +
>> +type = toupper(type);
>> +
>> +/* Fixup for text, weak, data and bss sections. */
>> +if (type == 'T' || type == 'W' || type == 'D' || type == 'B')
>> +machine->kernel_start = min(machine->kernel_start, start);
>> +
>> +return 0;
>> +}
>> +
>> int machine__get_kernel_start(struct machine *machine)
>> {
>> struct map *map = machine__kernel_map(machine);
>> +char filename[PATH_MAX];
>> int err = 0;
>>
>> /*
>> @@ -2696,6 +2713,22 @@ int machine__get_kernel_start(struct machine *machine)
>> if (!err && !machine__is(machine, "x86_64"))
>> machine->kernel_start = map->start;
>> }
>> +
>> +if (symbol_conf.kallsyms_name != NULL) {
>> +strncpy(filename, symbol_conf.kallsyms_name, PATH_MAX);
>> +} else {
>> +machine__get_kallsyms_filename(machine, filename, PATH_MAX);
>> +
>> +if (symbol__restricted_filename(filename, "/proc/kallsyms"))
>> +goto out;
>> +}
>> +
>> +if (kallsyms__parse(filename, machine, machine__fixup_kernel_start))
>> +pr_warning("Fail to fixup kernel start address. skipping...\n");
>> +
RE: [PATCH 1/1] mm/migrate: fix list corruption in migration of non-LRU movable pages
isolate_migratepages_block() from another thread may try to isolate the page
again:
for (; low_pfn < end_pfn; low_pfn++) {
/* ... */
page = pfn_to_page(low_pfn);
/* ... */
if (!PageLRU(page)) {
if (unlikely(__PageMovable(page)) && !PageIsolated(page)) {
/* ... */
if (!isolate_movable_page(page, isolate_mode))
goto isolate_success;
/*... */
isolate_success:
list_add(&page->lru, &cc->migratepages);
And this page will be added to another list.
Or, do you see any reason that the page cannot go through this path?
From: Michal Hocko [mho...@kernel.org]
Sent: Wednesday, September 04, 2019 14:38
To: sunqiuyang
Cc: linux-kernel@vger.kernel.org; linux...@kvack.org
Subject: Re: [PATCH 1/1] mm/migrate: fix list corruption in migration of
non-LRU movable pages
On Wed 04-09-19 02:18:38, sunqiuyang wrote:
> The isolate path of non-lru movable pages:
>
> isolate_migratepages_block
> isolate_movable_page
> trylock_page
> // if PageIsolated, goto out_no_isolated
> a_ops->isolate_page
> __SetPageIsolated
> unlock_page
> list_add(&page->lru, &cc->migratepages)
>
> The migration path:
>
> unmap_and_move
> __unmap_and_move
> lock_page
> move_to_new_page
> a_ops->migratepage
> __ClearPageIsolated
> unlock_page
> /* here, the page could be isolated again by another thread, and added
> into another cc->migratepages,
> since PG_Isolated has been cleared, and not protected by page_lock */
> list_del(&page->lru)
But the page has been migrated already and not freed yet because there
is still a pin on it. So nobody should be touching it at this stage.
Or do I still miss something?
--
Michal Hocko
SUSE Labs
Re: [PATCH] serial: max310x: turn off transmitter before activating AutoCTS or auto transmitter flow control
On Fri, Aug 30, 2019 at 09:58:41AM +, Christoph Vogtländer wrote:
> As documented in the data-sheet, the transmitter must be disabled before
> activating AutoCTS or auto transmitter flow control. Accordingly, the
> transmitter must be enabled after AutoCTS or auto transmitter flow
> control gets deactivated.
>
> Signed-off-by: Christoph Vogtländer
> ---
> drivers/tty/serial/max310x.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> index fb5a7e0e58e9..adfef6dae4a7 100644
> --- a/drivers/tty/serial/max310x.c
> +++ b/drivers/tty/serial/max310x.c
> @@ -860,6 +860,15 @@ static void max310x_set_termios(struct uart_port *port,
> max310x_port_write(port, MAX310X_XON1_REG, termios->c_cc[VSTART]);
> max310x_port_write(port, MAX310X_XOFF1_REG, termios->c_cc[VSTOP]);
>
> +/* Disable transmitter before enabling AutoCTS or auto transmitter
> + * flow control
> + */
> +if (termios->c_cflag & CRTSCTS || termios->c_iflag & IXOFF) {
> +max310x_port_update(port, MAX310X_MODE1_REG,
> +MAX310X_MODE1_TXDIS_BIT,
> +MAX310X_MODE1_TXDIS_BIT);
> +}
> +
> port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS | UPSTAT_AUTOXOFF);
>
> if (termios->c_cflag & CRTSCTS) {
> @@ -878,6 +887,15 @@ static void max310x_set_termios(struct uart_port *port,
> }
> max310x_port_write(port, MAX310X_FLOWCTRL_REG, flow);
>
> +/* Enable transmitter after disabling AutoCTS and auto transmitter
> + * flow control
> + */
> +if (!(termios->c_cflag & CRTSCTS) && !(termios->c_iflag & IXOFF)) {
> +max310x_port_update(port, MAX310X_MODE1_REG,
> +MAX310X_MODE1_TXDIS_BIT,
> +0);
> +}
> +
> /* Get baud rate generator configuration */
> baud = uart_get_baud_rate(port, termios, old,
>port->uartclk / 16 / 0x,
> --
> 2.22.1
>
Same problem here, this is impossible to apply.
greg k-h
Re: [PATCH] serial: max310x: Properly set flags in AutoCTS mode
On Fri, Aug 30, 2019 at 09:58:34AM +, Christoph Vogtländer wrote:
> Commit 391f93f2ec9f ("serial: core: Rework hw-assisted flow control
> support") has changed the way the AutoCTS mode is handled.
>
> According to that change, serial drivers which enable H/W AutoCTS mode must
> set UPSTAT_AUTORTS, UPSTAT_AUTOCTS and UPSTAT_AUTOXOFF to prevent the
> serial core from inadvertently disabling RX or TX. This patch adds proper
> handling of UPSTAT_AUTORTS, UPSTAT_AUTOCTS and UPSTAT_AUTOXOFF flags.
>
> Signed-off-by: Christoph Vogtländer
> ---
> drivers/tty/serial/max310x.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> index 0e24235..fb5a7e0 100644
> --- a/drivers/tty/serial/max310x.c
> +++ b/drivers/tty/serial/max310x.c
> @@ -859,15 +859,23 @@ static void max310x_set_termios(struct uart_port *port,
> /* Configure flow control */
> max310x_port_write(port, MAX310X_XON1_REG, termios->c_cc[VSTART]);
> max310x_port_write(port, MAX310X_XOFF1_REG, termios->c_cc[VSTOP]);
> -if (termios->c_cflag & CRTSCTS)
> +
> +port->status &= ~(UPSTAT_AUTOCTS | UPSTAT_AUTORTS | UPSTAT_AUTOXOFF);
> +
> +if (termios->c_cflag & CRTSCTS) {
> +/* Enable AUTORTS and AUTOCTS */
> +port->status |= UPSTAT_AUTOCTS | UPSTAT_AUTORTS;
> flow |= MAX310X_FLOWCTRL_AUTOCTS_BIT |
> MAX310X_FLOWCTRL_AUTORTS_BIT;
> +}
> if (termios->c_iflag & IXON)
> flow |= MAX310X_FLOWCTRL_SWFLOW3_BIT |
> MAX310X_FLOWCTRL_SWFLOWEN_BIT;
> -if (termios->c_iflag & IXOFF)
> +if (termios->c_iflag & IXOFF) {
> +port->status |= UPSTAT_AUTOXOFF;
> flow |= MAX310X_FLOWCTRL_SWFLOW1_BIT |
> MAX310X_FLOWCTRL_SWFLOWEN_BIT;
> +}
> max310x_port_write(port, MAX310X_FLOWCTRL_REG, flow);
>
> /* Get baud rate generator configuration */
> --
> 2.7.4
Your email client ate all of the leading spaces and tabs and spit out a
patch that is impossible to apply :(
Please fix that up and resend.
thanks,
greg k-h
[PATCH 3/3] perf stat: Add --per-node agregation support
Adding new --per-node option to aggregate counts per NUMA
nodes for system-wide mode measurements.
You can specify --per-node in live mode:
# perf stat -a -I 1000 -e cycles --per-node
# time node cpus counts unit events
1.000542550 N0 20 6,202,097 cycles
1.000542550 N1 20639,559 cycles
2.002040063 N0 20 7,412,495 cycles
2.002040063 N1 20 2,185,577 cycles
3.003451699 N0 20 6,508,917 cycles
3.003451699 N1 20765,607 cycles
...
Or in the record/report stat session:
# perf stat record -a -I 1000 -e cycles
# time counts unit events
1.000536937 10,008,468 cycles
2.002090152 9,578,539 cycles
3.003625233 7,647,869 cycles
4.005135036 7,032,086 cycles
^C 4.340902364 3,923,893 cycles
# perf stat report --per-node
# time node cpus counts unit events
1.000536937 N0 20 9,355,086 cycles
1.000536937 N1 20653,382 cycles
2.002090152 N0 20 7,712,838 cycles
2.002090152 N1 20 1,865,701 cycles
3.003625233 N0 20 6,604,441 cycles
3.003625233 N1 20 1,043,428 cycles
4.005135036 N0 20 6,350,522 cycles
4.005135036 N1 20681,564 cycles
4.340902364 N0 20 3,403,188 cycles
4.340902364 N1 20520,705 cycles
Link: http://lkml.kernel.org/n/tip-h57ftv8vmqrgzz3kdvlvh...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/Documentation/perf-stat.txt | 5 +++
tools/perf/builtin-stat.c | 52 ++
tools/perf/util/cpumap.c | 18 +
tools/perf/util/cpumap.h | 3 ++
tools/perf/util/stat-display.c | 15
tools/perf/util/stat.c | 1 +
tools/perf/util/stat.h | 1 +
7 files changed, 95 insertions(+)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 930c51c01201..277f7e94f7d8 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -217,6 +217,11 @@ core number and the number of online logical processors on
that physical process
Aggregate counts per monitored threads, when monitoring threads (-t option)
or processes (-p option).
+--per-node::
+Aggregate counts per NUMA nodes for system-wide mode measurements. This
+is a useful mode to detect imbalance between NUMA nodes. To enable this
+mode, use --per-node in addition to -a. (system-wide).
+
-D msecs::
--delay msecs::
After starting the program, wait msecs before measuring. This is useful to
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 5bc0c570b7b6..bfade49955ac 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -790,6 +790,8 @@ static struct option stat_options[] = {
"aggregate counts per physical processor core", AGGR_CORE),
OPT_SET_UINT(0, "per-thread", &stat_config.aggr_mode,
"aggregate counts per thread", AGGR_THREAD),
+ OPT_SET_UINT(0, "per-node", &stat_config.aggr_mode,
+"aggregate counts per numa node", AGGR_NODE),
OPT_UINTEGER('D', "delay", &stat_config.initial_delay,
"ms to wait before starting measurement after program
start"),
OPT_CALLBACK_NOOPT(0, "metric-only", &stat_config.metric_only, NULL,
@@ -822,6 +824,12 @@ static int perf_stat__get_core(struct perf_stat_config
*config __maybe_unused,
return cpu_map__get_core(map, cpu, NULL);
}
+static int perf_stat__get_node(struct perf_stat_config *config __maybe_unused,
+ struct perf_cpu_map *map, int cpu)
+{
+ return cpu_map__get_node(map, cpu, NULL);
+}
+
static int perf_stat__get_aggr(struct perf_stat_config *config,
aggr_get_id_t get_id, struct perf_cpu_map *map,
int idx)
{
@@ -856,6 +864,12 @@ static int perf_stat__get_core_cached(struct
perf_stat_config *config,
return perf_stat__get_aggr(config, perf_stat__get_core, map, idx);
}
+static int perf_stat__get_node_cached(struct perf_stat_config *config,
+ struct perf_cpu_map *map, int idx)
+{
+ return perf_stat__get_aggr(config, perf_stat__get_node, map, idx);
+}
+
static bool term_percore_set(void)
{
struct evsel *counter;
@@ -894,6 +908,13 @@ static int perf_stat_init_aggr_mode(void)
}
stat_config.aggr_get_id = perf_stat__get_core_cached;
break;
+ case AGGR_NODE:
+ if (cpu
[PATCHv2 0/3] perf stat: Add --per-node option
hi, adding --per-node option to aggregate stats per NUMA nodes, you can get now use stat command like: # perf stat -a -I 1000 -e cycles --per-node # time node cpus counts unit events 1.000542550 N0 20 6,202,097 cycles 1.000542550 N1 20639,559 cycles 2.002040063 N0 20 7,412,495 cycles 2.002040063 N1 20 2,185,577 cycles 3.003451699 N0 20 6,508,917 cycles 3.003451699 N1 20765,607 cycles ... v2 changes: - use mallox instead of zalloc plus adding comment [Arnaldo] - rename --per-numa to --per-node [Alexey] - rename function names to have node instead of numa Available also in: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/fixes thanks, jirka --- Jiri Olsa (3): libperf: Add perf_cpu_map__max function perf tools: Add perf_env__numa_node function perf stat: Add --per-node agregation support tools/perf/Documentation/perf-stat.txt | 5 + tools/perf/builtin-stat.c | 60 ++-- tools/perf/lib/cpumap.c| 12 tools/perf/lib/include/perf/cpumap.h | 1 + tools/perf/lib/libperf.map | 1 + tools/perf/util/cpumap.c | 18 ++ tools/perf/util/cpumap.h | 3 +++ tools/perf/util/env.c | 40 tools/perf/util/env.h | 6 ++ tools/perf/util/stat-display.c | 15 +++ tools/perf/util/stat.c | 1 + tools/perf/util/stat.h | 1 + 12 files changed, 153 insertions(+), 10 deletions(-)
Re: [PATCH] KVM: s390: Disallow invalid bits in kvm_valid_regs and kvm_dirty_regs
On 9/4/19 9:13 AM, Thomas Huth wrote:
> If unknown bits are set in kvm_valid_regs or kvm_dirty_regs, this
> clearly indicates that something went wrong in the KVM userspace
> application. The x86 variant of KVM already contains a check for
> bad bits (and the corresponding kselftest checks this), so let's
> do the same on s390x now, too.
>
> Signed-off-by: Thomas Huth
I think it would make sense to split the kvm changes from the test.
Reviewed-by: Janosch Frank
> ---
> arch/s390/include/uapi/asm/kvm.h | 6
> arch/s390/kvm/kvm-s390.c | 4 +++
> .../selftests/kvm/s390x/sync_regs_test.c | 30 +++
> 3 files changed, 40 insertions(+)
>
> diff --git a/arch/s390/include/uapi/asm/kvm.h
> b/arch/s390/include/uapi/asm/kvm.h
> index 47104e5b47fd..436ec7636927 100644
> --- a/arch/s390/include/uapi/asm/kvm.h
> +++ b/arch/s390/include/uapi/asm/kvm.h
> @@ -231,6 +231,12 @@ struct kvm_guest_debug_arch {
> #define KVM_SYNC_GSCB (1UL << 9)
> #define KVM_SYNC_BPBC (1UL << 10)
> #define KVM_SYNC_ETOKEN (1UL << 11)
> +
> +#define KVM_SYNC_S390_VALID_FIELDS \
> + (KVM_SYNC_PREFIX | KVM_SYNC_GPRS | KVM_SYNC_ACRS | KVM_SYNC_CRS | \
> + KVM_SYNC_ARCH0 | KVM_SYNC_PFAULT | KVM_SYNC_VRS | KVM_SYNC_RICCB | \
> + KVM_SYNC_FPRS | KVM_SYNC_GSCB | KVM_SYNC_BPBC | KVM_SYNC_ETOKEN)
> +
> /* length and alignment of the sdnx as a power of two */
> #define SDNXC 8
> #define SDNXL (1UL << SDNXC)
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 49d779ae..a7d7dedfe527 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -3998,6 +3998,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
> struct kvm_run *kvm_run)
> if (kvm_run->immediate_exit)
> return -EINTR;
>
> + if (kvm_run->kvm_valid_regs & ~KVM_SYNC_S390_VALID_FIELDS ||
> + kvm_run->kvm_dirty_regs & ~KVM_SYNC_S390_VALID_FIELDS)
> + return -EINVAL;
> +
> vcpu_load(vcpu);
>
> if (guestdbg_exit_pending(vcpu)) {
> diff --git a/tools/testing/selftests/kvm/s390x/sync_regs_test.c
> b/tools/testing/selftests/kvm/s390x/sync_regs_test.c
> index bbc93094519b..d5290b4ad636 100644
> --- a/tools/testing/selftests/kvm/s390x/sync_regs_test.c
> +++ b/tools/testing/selftests/kvm/s390x/sync_regs_test.c
> @@ -85,6 +85,36 @@ int main(int argc, char *argv[])
>
> run = vcpu_state(vm, VCPU_ID);
>
> + /* Request reading invalid register set from VCPU. */
> + run->kvm_valid_regs = INVALID_SYNC_FIELD;
> + rv = _vcpu_run(vm, VCPU_ID);
> + TEST_ASSERT(rv < 0 && errno == EINVAL,
> + "Invalid kvm_valid_regs did not cause expected KVM_RUN
> error: %d\n",
> + rv);
> + vcpu_state(vm, VCPU_ID)->kvm_valid_regs = 0;
> +
> + run->kvm_valid_regs = INVALID_SYNC_FIELD | TEST_SYNC_FIELDS;
> + rv = _vcpu_run(vm, VCPU_ID);
> + TEST_ASSERT(rv < 0 && errno == EINVAL,
> + "Invalid kvm_valid_regs did not cause expected KVM_RUN
> error: %d\n",
> + rv);
> + vcpu_state(vm, VCPU_ID)->kvm_valid_regs = 0;
> +
> + /* Request setting invalid register set into VCPU. */
> + run->kvm_dirty_regs = INVALID_SYNC_FIELD;
> + rv = _vcpu_run(vm, VCPU_ID);
> + TEST_ASSERT(rv < 0 && errno == EINVAL,
> + "Invalid kvm_dirty_regs did not cause expected KVM_RUN
> error: %d\n",
> + rv);
> + vcpu_state(vm, VCPU_ID)->kvm_dirty_regs = 0;
> +
> + run->kvm_dirty_regs = INVALID_SYNC_FIELD | TEST_SYNC_FIELDS;
> + rv = _vcpu_run(vm, VCPU_ID);
> + TEST_ASSERT(rv < 0 && errno == EINVAL,
> + "Invalid kvm_dirty_regs did not cause expected KVM_RUN
> error: %d\n",
> + rv);
> + vcpu_state(vm, VCPU_ID)->kvm_dirty_regs = 0;
> +
> /* Request and verify all valid register sets. */
> run->kvm_valid_regs = TEST_SYNC_FIELDS;
> rv = _vcpu_run(vm, VCPU_ID);
>
signature.asc
Description: OpenPGP digital signature
[PATCH 2/3] perf tools: Add perf_env__numa_node function
To speed up cpu to node lookup, adding perf_env__numa_node
function, that creates cpu array on the first lookup, that
holds numa nodes for each stored cpu.
Link: http://lkml.kernel.org/n/tip-qqwxklhissf3yjyuaszh6...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/env.c | 40
tools/perf/util/env.h | 6 ++
2 files changed, 46 insertions(+)
diff --git a/tools/perf/util/env.c b/tools/perf/util/env.c
index 3baca06786fb..ee53e89a9535 100644
--- a/tools/perf/util/env.c
+++ b/tools/perf/util/env.c
@@ -179,6 +179,7 @@ void perf_env__exit(struct perf_env *env)
zfree(&env->sibling_threads);
zfree(&env->pmu_mappings);
zfree(&env->cpu);
+ zfree(&env->numa_map);
for (i = 0; i < env->nr_numa_nodes; i++)
perf_cpu_map__put(env->numa_nodes[i].map);
@@ -338,3 +339,42 @@ const char *perf_env__arch(struct perf_env *env)
return normalize_arch(arch_name);
}
+
+
+int perf_env__numa_node(struct perf_env *env, int cpu)
+{
+ if (!env->nr_numa_map) {
+ struct numa_node *nn;
+ int i, nr = 0;
+
+ for (i = 0; i < env->nr_numa_nodes; i++) {
+ nn = &env->numa_nodes[i];
+ nr = max(nr, perf_cpu_map__max(nn->map));
+ }
+
+ nr++;
+
+ /*
+* We initialize the numa_map array to prepare
+* it for missing cpus, which return node -1.
+*/
+ env->numa_map = malloc(nr * sizeof(int));
+ if (!env->numa_map)
+ return -1;
+
+ for (i = 0; i < nr; i++)
+ env->numa_map[i] = -1;
+
+ env->nr_numa_map = nr;
+
+ for (i = 0; i < env->nr_numa_nodes; i++) {
+ int tmp, j;
+
+ nn = &env->numa_nodes[i];
+ perf_cpu_map__for_each_cpu(j, tmp, nn->map)
+ env->numa_map[j] = i;
+ }
+ }
+
+ return cpu >= 0 && cpu < env->nr_numa_map ? env->numa_map[cpu] : -1;
+}
diff --git a/tools/perf/util/env.h b/tools/perf/util/env.h
index d8e083d42610..777008f8007a 100644
--- a/tools/perf/util/env.h
+++ b/tools/perf/util/env.h
@@ -86,6 +86,10 @@ struct perf_env {
struct rb_root btfs;
u32 btfs_cnt;
} bpf_progs;
+
+ /* For fast cpu to numa node lookup via perf_env__numa_node */
+ int *numa_map;
+ int nr_numa_map;
};
enum perf_compress_type {
@@ -118,4 +122,6 @@ struct bpf_prog_info_node
*perf_env__find_bpf_prog_info(struct perf_env *env,
__u32 prog_id);
void perf_env__insert_btf(struct perf_env *env, struct btf_node *btf_node);
struct btf_node *perf_env__find_btf(struct perf_env *env, __u32 btf_id);
+
+int perf_env__numa_node(struct perf_env *env, int cpu);
#endif /* __PERF_ENV_H */
--
2.21.0
[PATCH 1/3] libperf: Add perf_cpu_map__max function
So it can be used from multiple places.
Link: http://lkml.kernel.org/n/tip-yp3h5rl9e8piybufq41zq...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-stat.c| 14 +-
tools/perf/lib/cpumap.c | 12
tools/perf/lib/include/perf/cpumap.h | 1 +
tools/perf/lib/libperf.map | 1 +
4 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 7e17bf9f700a..5bc0c570b7b6 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -822,18 +822,6 @@ static int perf_stat__get_core(struct perf_stat_config
*config __maybe_unused,
return cpu_map__get_core(map, cpu, NULL);
}
-static int cpu_map__get_max(struct perf_cpu_map *map)
-{
- int i, max = -1;
-
- for (i = 0; i < map->nr; i++) {
- if (map->map[i] > max)
- max = map->map[i];
- }
-
- return max;
-}
-
static int perf_stat__get_aggr(struct perf_stat_config *config,
aggr_get_id_t get_id, struct perf_cpu_map *map,
int idx)
{
@@ -928,7 +916,7 @@ static int perf_stat_init_aggr_mode(void)
* taking the highest cpu number to be the size of
* the aggregation translate cpumap.
*/
- nr = cpu_map__get_max(evsel_list->core.cpus);
+ nr = perf_cpu_map__max(evsel_list->core.cpus);
stat_config.cpus_aggr_map = perf_cpu_map__empty_new(nr + 1);
return stat_config.cpus_aggr_map ? 0 : -ENOMEM;
}
diff --git a/tools/perf/lib/cpumap.c b/tools/perf/lib/cpumap.c
index 1f0e6f334237..2ca1fafa620d 100644
--- a/tools/perf/lib/cpumap.c
+++ b/tools/perf/lib/cpumap.c
@@ -260,3 +260,15 @@ int perf_cpu_map__idx(struct perf_cpu_map *cpus, int cpu)
return -1;
}
+
+int perf_cpu_map__max(struct perf_cpu_map *map)
+{
+ int i, max = -1;
+
+ for (i = 0; i < map->nr; i++) {
+ if (map->map[i] > max)
+ max = map->map[i];
+ }
+
+ return max;
+}
diff --git a/tools/perf/lib/include/perf/cpumap.h
b/tools/perf/lib/include/perf/cpumap.h
index 8aa995c59498..ac9aa497f84a 100644
--- a/tools/perf/lib/include/perf/cpumap.h
+++ b/tools/perf/lib/include/perf/cpumap.h
@@ -16,6 +16,7 @@ LIBPERF_API void perf_cpu_map__put(struct perf_cpu_map *map);
LIBPERF_API int perf_cpu_map__cpu(const struct perf_cpu_map *cpus, int idx);
LIBPERF_API int perf_cpu_map__nr(const struct perf_cpu_map *cpus);
LIBPERF_API bool perf_cpu_map__empty(const struct perf_cpu_map *map);
+LIBPERF_API int perf_cpu_map__max(struct perf_cpu_map *map);
#define perf_cpu_map__for_each_cpu(cpu, idx, cpus) \
for ((idx) = 0, (cpu) = perf_cpu_map__cpu(cpus, idx); \
diff --git a/tools/perf/lib/libperf.map b/tools/perf/lib/libperf.map
index dc4d66363bc4..cd0d17b996c8 100644
--- a/tools/perf/lib/libperf.map
+++ b/tools/perf/lib/libperf.map
@@ -9,6 +9,7 @@ LIBPERF_0.0.1 {
perf_cpu_map__nr;
perf_cpu_map__cpu;
perf_cpu_map__empty;
+ perf_cpu_map__max;
perf_thread_map__new_dummy;
perf_thread_map__set_pid;
perf_thread_map__comm;
--
2.21.0
Re: [PATCH] soc: imx: imx-scu: Getting UID from SCU should have response
On 2019-09-04 10:14 AM, Anson Huang wrote:
> The SCU firmware API for getting UID should have response,
> otherwise, the message stored in function stack could be
> released and then the response data received from SCU will be
> stored into that released stack and cause kernel NULL pointer
> dump.
This fix looks good, but looking at imx-scu code it seems that passing
the incorrect "have_resp" argument to imx_scu_call_rpc or just receiving
an unexpected message from SCFW will always result in kernel stack
corruption!
This is worth handling inside imx-scu itself: unless a response was
explicitly requested it should ignore and print a warning on rx, for
example by setting imx_sc_ipc to NULL when not waiting for a response.
Holding on to arbitrary stack pointers is bad.
--
Regards,
Leonard
> diff --git a/drivers/soc/imx/soc-imx-scu.c b/drivers/soc/imx/soc-imx-scu.c
> index 50831eb..c68882e 100644
> --- a/drivers/soc/imx/soc-imx-scu.c
> +++ b/drivers/soc/imx/soc-imx-scu.c
> @@ -46,7 +46,7 @@ static ssize_t soc_uid_show(struct device *dev,
> hdr->func = IMX_SC_MISC_FUNC_UNIQUE_ID;
> hdr->size = 1;
>
> - ret = imx_scu_call_rpc(soc_ipc_handle, &msg, false);
> + ret = imx_scu_call_rpc(soc_ipc_handle, &msg, true);
> if (ret) {
> pr_err("%s: get soc uid failed, ret %d\n", __func__, ret);
> return ret;
Re: [PATCH v2] s390: vfio-ap: remove unnecessary calls to disable queue interrupts
Halil,
can you also send this patch as a separate mail. This also requires a much
better
patch description about the why and it certainly should also have an agreement
from
Anthony.
On 30.08.19 18:02, Halil Pasic wrote:
> From: Halil Pasic
> Date: Fri, 30 Aug 2019 17:39:47 +0200
> Subject: [PATCH 2/2] s390: vfio-ap: don't wait after AQIC interpretation
>
> Waiting for the asynchronous part of AQIC to complete as a part
> AQIC implementation is unnecessary and silly.
>
> Let's get rid of vfio_ap_wait_for_irqclear().
>
> Signed-off-by: Halil Pasic
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 50
> ++-
> 1 file changed, 2 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c
> b/drivers/s390/crypto/vfio_ap_ops.c
> index dd07ebf..8d098f0 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -68,47 +68,6 @@ static struct vfio_ap_queue *vfio_ap_get_queue(
> }
>
> /**
> - * vfio_ap_wait_for_irqclear
> - * @apqn: The AP Queue number
> - *
> - * Checks the IRQ bit for the status of this APQN using ap_tapq.
> - * Returns if the ap_tapq function succeeded and the bit is clear.
> - * Returns if ap_tapq function failed with invalid, deconfigured or
> - * checkstopped AP.
> - * Otherwise retries up to 5 times after waiting 20ms.
> - *
> - */
> -static void vfio_ap_wait_for_irqclear(int apqn)
> -{
> - struct ap_queue_status status;
> - int retry = 5;
> -
> - do {
> - status = ap_tapq(apqn, NULL);
> - switch (status.response_code) {
> - case AP_RESPONSE_NORMAL:
> - case AP_RESPONSE_RESET_IN_PROGRESS:
> - if (!status.irq_enabled)
> - return;
> - /* Fall through */
> - case AP_RESPONSE_BUSY:
> - msleep(20);
> - break;
> - case AP_RESPONSE_Q_NOT_AVAIL:
> - case AP_RESPONSE_DECONFIGURED:
> - case AP_RESPONSE_CHECKSTOPPED:
> - default:
> - WARN_ONCE(1, "%s: tapq rc %02x: %04x\n", __func__,
> - status.response_code, apqn);
> - return;
> - }
> - } while (--retry);
> -
> - WARN_ONCE(1, "%s: tapq rc %02x: %04x could not clear IR bit\n",
> - __func__, status.response_code, apqn);
> -}
> -
> -/**
> * vfio_ap_free_aqic_resources
> * @q: The vfio_ap_queue
> *
> @@ -133,14 +92,10 @@ static void vfio_ap_free_aqic_resources(struct
> vfio_ap_queue *q)
> * @q: The vfio_ap_queue
> *
> * Uses ap_aqic to disable the interruption and in case of success, reset
> - * in progress or IRQ disable command already proceeded: calls
> - * vfio_ap_wait_for_irqclear() to check for the IRQ bit to be clear
> - * and calls vfio_ap_free_aqic_resources() to free the resources associated
> + * in progress or IRQ disable command already proceeded :calls
> + * vfio_ap_free_aqic_resources() to free the resources associated
> * with the AP interrupt handling.
> *
> - * In the case the AP is busy, or a reset is in progress,
> - * retries after 20ms, up to 5 times.
> - *
> * Returns if ap_aqic function failed with invalid, deconfigured or
> * checkstopped AP.
> */
> @@ -155,7 +110,6 @@ struct ap_queue_status vfio_ap_irq_disable(struct
> vfio_ap_queue *q)
> switch (status.response_code) {
> case AP_RESPONSE_OTHERWISE_CHANGED:
> case AP_RESPONSE_NORMAL:
> - vfio_ap_wait_for_irqclear(q->apqn);
> goto end_free;
> case AP_RESPONSE_RESET_IN_PROGRESS:
> case AP_RESPONSE_BUSY:
> -- 2.5.5
Re: [RFC PATCH 4/5] ASoC: SOF: Intel: hda: add SoundWire stream config/free callbacks
On 22-08-19, 08:53, Pierre-Louis Bossart wrote: > Thanks for the review Guennadi > > > > +static int sdw_config_stream(void *arg, void *s, void *dai, > > > + void *params, int link_id, int alh_stream_id) > > > > I realise, that these function prototypes aren't being introduced by these > > patches, but just wondering whether such overly generic prototype is really > > a good idea here, whether some of those "void *" pointers could be given > > real types. The first one could be "struct device *" etc. > > In this case the 'arg' parameter is actually a private 'struct snd_sof_dev', > as shown below [1]. We probably want to keep this relatively opaque, this is > a context that doesn't need to be exposed to the SoundWire code. This does look bit ugly. > The dai and params are indeed cases where we could use stronger types, they > are snd_soc_dai and hw_params respectively. I don't recall why the existing > code is this way, Vinod and Sanyog may have the history of this. Yes we wanted to decouple the sdw and audio bits that is the reason why none of the audio types are used here, but I think it should be revisited and perhaps made as: sdw_config_stream(struct device *sdw, struct sdw_callback_ctx *ctx) where the callback context contains all the other args. That would make it look lot neater too and of course use real structs if possible -- ~Vinod
[PATCH net] ipv4: fix ifa_flags reuse problem in using ifconfig tool
When NetworkManager has already set ipv4 address then uses ifconfig set another ipv4 address. It will use previous ifa_flags that will cause device route not be inserted. As NetworkManager has already support IFA_F_NOPREFIXROUTE flag [1], but ifconfig will reuse the ifa_flags. It's weird especially some old scripts or program [2] still use ifconfig. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/ commit/fec80e7473ad16979af75ed299d68103e7aa3fe9 [2] LTP or TAHI Signed-off-by: Su Yanjun --- net/ipv4/devinet.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c index a4b5bd4..56ca339 100644 --- a/net/ipv4/devinet.c +++ b/net/ipv4/devinet.c @@ -1159,6 +1159,7 @@ int devinet_ioctl(struct net *net, unsigned int cmd, struct ifreq *ifr) inet_del_ifa(in_dev, ifap, 0); ifa->ifa_broadcast = 0; ifa->ifa_scope = 0; + ifa->ifa_flags = 0; } ifa->ifa_address = ifa->ifa_local = sin->sin_addr.s_addr; -- 2.7.4
RE: [PATCH] soc: imx: imx-scu: Getting UID from SCU should have response
Hi, Leonard > On 2019-09-04 10:14 AM, Anson Huang wrote: > > The SCU firmware API for getting UID should have response, otherwise, > > the message stored in function stack could be released and then the > > response data received from SCU will be stored into that released > > stack and cause kernel NULL pointer dump. > > This fix looks good, but looking at imx-scu code it seems that passing the > incorrect "have_resp" argument to imx_scu_call_rpc or just receiving an > unexpected message from SCFW will always result in kernel stack corruption! > > This is worth handling inside imx-scu itself: unless a response was explicitly > requested it should ignore and print a warning on rx, for example by setting > imx_sc_ipc to NULL when not waiting for a response. > > Holding on to arbitrary stack pointers is bad. We noticed this issue recently during the development of ON/OFF button support, this UID is lucky, the stack is NOT released when SCU response data is received, but this fix should be applied. We talked to Chuck about adding return value for these special APIs, response data needed but no return value from SCU, so very likely we will need a patch in imx_sc_ipc driver to enhance/handle that, will do a patch for it later. Thanks, Anson
Re: [PATCH] net/skbuff: silence warnings under memory pressure
On (09/04/19 16:19), Sergey Senozhatsky wrote:
> Hmm. I need to look at this more... wake_up_klogd() queues work only once
> on particular CPU: irq_work_queue(this_cpu_ptr(&wake_up_klogd_work));
>
> bool irq_work_queue()
> {
> /* Only queue if not already pending */
> if (!irq_work_claim(work))
> return false;
>
>__irq_work_queue_local(work);
> }
Plus one more check - waitqueue_active(&log_wait). printk() adds
pending irq_work only if there is a user-space process sleeping on
log_wait and irq_work is not already scheduled. If the syslog is
active or there is noone to wakeup then we don't queue irq_work.
-ss
Re: [PATCH] KVM: s390: Disallow invalid bits in kvm_valid_regs and kvm_dirty_regs
On 04.09.19 09:33, Janosch Frank wrote:
> On 9/4/19 9:13 AM, Thomas Huth wrote:
>> If unknown bits are set in kvm_valid_regs or kvm_dirty_regs, this
>> clearly indicates that something went wrong in the KVM userspace
>> application. The x86 variant of KVM already contains a check for
>> bad bits (and the corresponding kselftest checks this), so let's
>> do the same on s390x now, too.
>>
>> Signed-off-by: Thomas Huth
>
> I think it would make sense to split the kvm changes from the test.
Yes, this would allow to backport the non-kselftest part if necessary.
With that
Reviewed-by: Christian Borntraeger
>
> Reviewed-by: Janosch Frank
>
>> ---
>> arch/s390/include/uapi/asm/kvm.h | 6
>> arch/s390/kvm/kvm-s390.c | 4 +++
>> .../selftests/kvm/s390x/sync_regs_test.c | 30 +++
>> 3 files changed, 40 insertions(+)
>>
>> diff --git a/arch/s390/include/uapi/asm/kvm.h
>> b/arch/s390/include/uapi/asm/kvm.h
>> index 47104e5b47fd..436ec7636927 100644
>> --- a/arch/s390/include/uapi/asm/kvm.h
>> +++ b/arch/s390/include/uapi/asm/kvm.h
>> @@ -231,6 +231,12 @@ struct kvm_guest_debug_arch {
>> #define KVM_SYNC_GSCB (1UL << 9)
>> #define KVM_SYNC_BPBC (1UL << 10)
>> #define KVM_SYNC_ETOKEN (1UL << 11)
>> +
>> +#define KVM_SYNC_S390_VALID_FIELDS \
>> +(KVM_SYNC_PREFIX | KVM_SYNC_GPRS | KVM_SYNC_ACRS | KVM_SYNC_CRS | \
>> + KVM_SYNC_ARCH0 | KVM_SYNC_PFAULT | KVM_SYNC_VRS | KVM_SYNC_RICCB | \
>> + KVM_SYNC_FPRS | KVM_SYNC_GSCB | KVM_SYNC_BPBC | KVM_SYNC_ETOKEN)
>> +
>> /* length and alignment of the sdnx as a power of two */
>> #define SDNXC 8
>> #define SDNXL (1UL << SDNXC)
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 49d779ae..a7d7dedfe527 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -3998,6 +3998,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
>> struct kvm_run *kvm_run)
>> if (kvm_run->immediate_exit)
>> return -EINTR;
>>
>> +if (kvm_run->kvm_valid_regs & ~KVM_SYNC_S390_VALID_FIELDS ||
>> +kvm_run->kvm_dirty_regs & ~KVM_SYNC_S390_VALID_FIELDS)
>> +return -EINVAL;
>> +
>> vcpu_load(vcpu);
>>
>> if (guestdbg_exit_pending(vcpu)) {
>> diff --git a/tools/testing/selftests/kvm/s390x/sync_regs_test.c
>> b/tools/testing/selftests/kvm/s390x/sync_regs_test.c
>> index bbc93094519b..d5290b4ad636 100644
>> --- a/tools/testing/selftests/kvm/s390x/sync_regs_test.c
>> +++ b/tools/testing/selftests/kvm/s390x/sync_regs_test.c
>> @@ -85,6 +85,36 @@ int main(int argc, char *argv[])
>>
>> run = vcpu_state(vm, VCPU_ID);
>>
>> +/* Request reading invalid register set from VCPU. */
>> +run->kvm_valid_regs = INVALID_SYNC_FIELD;
>> +rv = _vcpu_run(vm, VCPU_ID);
>> +TEST_ASSERT(rv < 0 && errno == EINVAL,
>> +"Invalid kvm_valid_regs did not cause expected KVM_RUN
>> error: %d\n",
>> +rv);
>> +vcpu_state(vm, VCPU_ID)->kvm_valid_regs = 0;
>> +
>> +run->kvm_valid_regs = INVALID_SYNC_FIELD | TEST_SYNC_FIELDS;
>> +rv = _vcpu_run(vm, VCPU_ID);
>> +TEST_ASSERT(rv < 0 && errno == EINVAL,
>> +"Invalid kvm_valid_regs did not cause expected KVM_RUN
>> error: %d\n",
>> +rv);
>> +vcpu_state(vm, VCPU_ID)->kvm_valid_regs = 0;
>> +
>> +/* Request setting invalid register set into VCPU. */
>> +run->kvm_dirty_regs = INVALID_SYNC_FIELD;
>> +rv = _vcpu_run(vm, VCPU_ID);
>> +TEST_ASSERT(rv < 0 && errno == EINVAL,
>> +"Invalid kvm_dirty_regs did not cause expected KVM_RUN
>> error: %d\n",
>> +rv);
>> +vcpu_state(vm, VCPU_ID)->kvm_dirty_regs = 0;
>> +
>> +run->kvm_dirty_regs = INVALID_SYNC_FIELD | TEST_SYNC_FIELDS;
>> +rv = _vcpu_run(vm, VCPU_ID);
>> +TEST_ASSERT(rv < 0 && errno == EINVAL,
>> +"Invalid kvm_dirty_regs did not cause expected KVM_RUN
>> error: %d\n",
>> +rv);
>> +vcpu_state(vm, VCPU_ID)->kvm_dirty_regs = 0;
>> +
>> /* Request and verify all valid register sets. */
>> run->kvm_valid_regs = TEST_SYNC_FIELDS;
>> rv = _vcpu_run(vm, VCPU_ID);
>>
>
>
Re: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode
Hi, On Wed, Sep 4, 2019 at 9:47 AM wrote: > > The power budget for SuperSpeed mode should be 900 mA > > according to USB3.0 specification, so set the power > > budget to 900 mA for dummy_start_ss which is only used > > for SuperSpeed mode. > > > > If the max power consumption of SuperSpeed device is > > larger than 500 mA, insufficient available bus power > > error happens in usb_choose_configuration function > > when the device connects to dummy hcd. > > > > Signed-off-by: Jacky Cao You must send plain/text emails. I'm not receiving this via the mailing list. Please, fix your email client or use git send-email -- balbi
Re: [PATCH] i2c: stm32f7: Make structure stm32f7_i2c_algo constant
Hi Wolfram
Sorry for the delay.
Acked-by: Pierre-Yves MORDRET
BR
On 9/3/19 8:05 PM, Wolfram Sang wrote:
> On Thu, Aug 15, 2019 at 11:28:57AM +0530, Nishka Dasgupta wrote:
>> Static structure stm32f7_i2c_algo, of type i2c_algorithm, is used only
>> when it is assigned to constant field algo of a variable having type
>> i2c_adapter. As stm32f7_i2c_algo is therefore never modified, make it
>> const as well to protect it from unintended modification.
>> Issue found with Coccinelle.
>>
>> Signed-off-by: Nishka Dasgupta
>> ---
>
> Are you guys okay with this patch?
>
>> drivers/i2c/busses/i2c-stm32f7.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-stm32f7.c
>> b/drivers/i2c/busses/i2c-stm32f7.c
>> index 266d1c269b83..d36cf08461f7 100644
>> --- a/drivers/i2c/busses/i2c-stm32f7.c
>> +++ b/drivers/i2c/busses/i2c-stm32f7.c
>> @@ -1809,7 +1809,7 @@ static u32 stm32f7_i2c_func(struct i2c_adapter *adap)
>> I2C_FUNC_SMBUS_I2C_BLOCK;
>> }
>>
>> -static struct i2c_algorithm stm32f7_i2c_algo = {
>> +static const struct i2c_algorithm stm32f7_i2c_algo = {
>> .master_xfer = stm32f7_i2c_xfer,
>> .smbus_xfer = stm32f7_i2c_smbus_xfer,
>> .functionality = stm32f7_i2c_func,
>> --
>> 2.19.1
>>
Re: [PATCH] fs-udf: Delete an unnecessary check before brelse()
On Tue 03-09-19 21:15:58, Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 3 Sep 2019 21:12:09 +0200 > > The brelse() function tests whether its argument is NULL > and then returns immediately. > Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Thanks for the patch. Added to my tree. Honza > --- > fs/udf/super.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/fs/udf/super.c b/fs/udf/super.c > index 56da1e1680ea..0cd0be642a2f 100644 > --- a/fs/udf/super.c > +++ b/fs/udf/super.c > @@ -273,8 +273,7 @@ static void udf_sb_free_bitmap(struct udf_bitmap *bitmap) > int nr_groups = bitmap->s_nr_groups; > > for (i = 0; i < nr_groups; i++) > - if (bitmap->s_block_bitmap[i]) > - brelse(bitmap->s_block_bitmap[i]); > + brelse(bitmap->s_block_bitmap[i]); > > kvfree(bitmap); > } > -- > 2.23.0 > > -- Jan Kara SUSE Labs, CR
[PATCH -next] ASoC: amd: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot Signed-off-by: YueHaibing --- sound/soc/amd/acp-pcm-dma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c index d26653f..52225b4 100644 --- a/sound/soc/amd/acp-pcm-dma.c +++ b/sound/soc/amd/acp-pcm-dma.c @@ -1251,8 +1251,7 @@ static int acp_audio_probe(struct platform_device *pdev) if (!audio_drv_data) return -ENOMEM; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - audio_drv_data->acp_mmio = devm_ioremap_resource(&pdev->dev, res); + audio_drv_data->acp_mmio = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(audio_drv_data->acp_mmio)) return PTR_ERR(audio_drv_data->acp_mmio); -- 2.7.4
[PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode
The power budget for SuperSpeed mode should be 900 mA according to USB3.0 specification, so set the power budget to 900 mA for dummy_start_ss which is only used for SuperSpeed mode. If the max power consumption of SuperSpeed device is larger than 500 mA, insufficient available bus power error happens in usb_choose_configuration function when the device connects to dummy hcd. Signed-off-by: Jacky Cao --- drivers/usb/gadget/udc/dummy_hcd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c index 8414fac..52f2cf5 100644 --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -48,6 +48,7 @@ #define DRIVER_VERSION "02 May 2005" #define POWER_BUDGET 500 /* in mA; use 8 for low-power port testing */ +#define POWER_BUDGET_3_0 900 /* in mA */ static const char driver_name[] = "dummy_hcd"; static const char driver_desc[] = "USB Host+Gadget Emulator"; @@ -2432,7 +2433,7 @@ static int dummy_start_ss(struct dummy_hcd *dum_hcd) dum_hcd->rh_state = DUMMY_RH_RUNNING; dum_hcd->stream_en_ep = 0; INIT_LIST_HEAD(&dum_hcd->urbp_list); - dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET; + dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET_3_0; dummy_hcd_to_hcd(dum_hcd)->state = HC_STATE_RUNNING; dummy_hcd_to_hcd(dum_hcd)->uses_new_polling = 1; #ifdef CONFIG_USB_OTG -- 2.7.4
Re: [PATCH v3 4/7] serial: fsl_linflexuart: Be consistent with the name
On Fri, Aug 23, 2019 at 07:11:37PM +, Stefan-gabriel Mirea wrote: > For consistency reasons, spell the controller name as "LINFlexD" in > comments and documentation. > > Signed-off-by: Stefan-Gabriel Mirea > --- > Documentation/admin-guide/kernel-parameters.txt | 2 +- > drivers/tty/serial/Kconfig | 8 > drivers/tty/serial/fsl_linflexuart.c| 4 ++-- > include/uapi/linux/serial_core.h| 4 ++-- > 4 files changed, 9 insertions(+), 9 deletions(-) Doesn't apply to my tty-next tree :(
Re: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode
Hi, writes: > The power budget for SuperSpeed mode should be 900 mA > according to USB3.0 specification, so set the power > budget to 900 mA for dummy_start_ss which is only used > for SuperSpeed mode. > > If the max power consumption of SuperSpeed device is > larger than 500 mA, insufficient available bus power > error happens in usb_choose_configuration function > when the device connects to dummy hcd. > > Signed-off-by: Jacky Cao > --- > drivers/usb/gadget/udc/dummy_hcd.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/udc/dummy_hcd.c > b/drivers/usb/gadget/udc/dummy_hcd.c > index 8414fac..52f2cf5 100644 > --- a/drivers/usb/gadget/udc/dummy_hcd.c > +++ b/drivers/usb/gadget/udc/dummy_hcd.c > @@ -48,6 +48,7 @@ > #define DRIVER_VERSION "02 May 2005" > > #define POWER_BUDGET 500 /* in mA; use 8 for low-power port testing */ > +#define POWER_BUDGET_3_0 900 /* in mA */ > > static const char driver_name[] = "dummy_hcd"; > static const char driver_desc[] = "USB Host+Gadget Emulator"; > @@ -2432,7 +2433,7 @@ static int dummy_start_ss(struct dummy_hcd *dum_hcd) > dum_hcd->rh_state = DUMMY_RH_RUNNING; > dum_hcd->stream_en_ep = 0; > INIT_LIST_HEAD(&dum_hcd->urbp_list); > - dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET; > + dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET_3_0; > dummy_hcd_to_hcd(dum_hcd)->state = HC_STATE_RUNNING; > dummy_hcd_to_hcd(dum_hcd)->uses_new_polling = 1; > #ifdef CONFIG_USB_OTG Alan, I suppose you're okay with this change? -- balbi signature.asc Description: PGP signature
[PATCH 2/2] mmc: block: add CMD13 polling for ioctl() cmd with R1B response
currently there is no CMD13 polling and other code to wait card
change to transfer state after R1B command completed. and this
polling operation cannot do in user space, because other request
may coming before the CMD13 from user space.
Signed-off-by: Chaotian Jing
---
drivers/mmc/core/block.c | 107 ---
1 file changed, 55 insertions(+), 52 deletions(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index aa7c19f7e298..9d6f7a5612b5 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -468,6 +468,58 @@ static int ioctl_do_sanitize(struct mmc_card *card)
return err;
}
+static inline bool mmc_blk_in_tran_state(u32 status)
+{
+ /*
+* Some cards mishandle the status bits, so make sure to check both the
+* busy indication and the card state.
+*/
+ return status & R1_READY_FOR_DATA &&
+ (R1_CURRENT_STATE(status) == R1_STATE_TRAN);
+}
+
+static int card_busy_detect(struct mmc_card *card, unsigned int timeout_ms,
+ u32 *resp_errs)
+{
+ unsigned long timeout = jiffies + msecs_to_jiffies(timeout_ms);
+ int err = 0;
+ u32 status;
+
+ do {
+ bool done = time_after(jiffies, timeout);
+
+ err = __mmc_send_status(card, &status, 5);
+ if (err) {
+ dev_err(mmc_dev(card->host),
+ "error %d requesting status\n", err);
+ return err;
+ }
+
+ /* Accumulate any response error bits seen */
+ if (resp_errs)
+ *resp_errs |= status;
+
+ /*
+* Timeout if the device never becomes ready for data and never
+* leaves the program state.
+*/
+ if (done) {
+ dev_err(mmc_dev(card->host),
+ "Card stuck in wrong state! %s status: %#x\n",
+__func__, status);
+ return -ETIMEDOUT;
+ }
+
+ /*
+* Some cards mishandle the status bits,
+* so make sure to check both the busy
+* indication and the card state.
+*/
+ } while (!mmc_blk_in_tran_state(status));
+
+ return err;
+}
+
static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md,
struct mmc_blk_ioc_data *idata)
{
@@ -623,6 +675,9 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card,
struct mmc_blk_data *md,
__func__, status, err);
}
+ if (!err && (cmd.flags & MMC_RSP_R1B))
+ err = card_busy_detect(card, MMC_BLK_TIMEOUT_MS, NULL);
+
return err;
}
@@ -970,58 +1025,6 @@ static unsigned int mmc_blk_data_timeout_ms(struct
mmc_host *host,
return ms;
}
-static inline bool mmc_blk_in_tran_state(u32 status)
-{
- /*
-* Some cards mishandle the status bits, so make sure to check both the
-* busy indication and the card state.
-*/
- return status & R1_READY_FOR_DATA &&
- (R1_CURRENT_STATE(status) == R1_STATE_TRAN);
-}
-
-static int card_busy_detect(struct mmc_card *card, unsigned int timeout_ms,
- u32 *resp_errs)
-{
- unsigned long timeout = jiffies + msecs_to_jiffies(timeout_ms);
- int err = 0;
- u32 status;
-
- do {
- bool done = time_after(jiffies, timeout);
-
- err = __mmc_send_status(card, &status, 5);
- if (err) {
- dev_err(mmc_dev(card->host),
- "error %d requesting status\n", err);
- return err;
- }
-
- /* Accumulate any response error bits seen */
- if (resp_errs)
- *resp_errs |= status;
-
- /*
-* Timeout if the device never becomes ready for data and never
-* leaves the program state.
-*/
- if (done) {
- dev_err(mmc_dev(card->host),
- "Card stuck in wrong state! %s status: %#x\n",
-__func__, status);
- return -ETIMEDOUT;
- }
-
- /*
-* Some cards mishandle the status bits,
-* so make sure to check both the busy
-* indication and the card state.
-*/
- } while (!mmc_blk_in_tran_state(status));
-
- return err;
-}
-
static int mmc_blk_reset(struct mmc_blk_data *md, struct mmc_host *host,
int type)
{
--
2.18.0
Re: [PATCH] KVM: s390: Disallow invalid bits in kvm_valid_regs and kvm_dirty_regs
On Wed, 4 Sep 2019 09:13:08 +0200 Thomas Huth wrote: > If unknown bits are set in kvm_valid_regs or kvm_dirty_regs, this > clearly indicates that something went wrong in the KVM userspace > application. The x86 variant of KVM already contains a check for > bad bits (and the corresponding kselftest checks this), so let's > do the same on s390x now, too. > > Signed-off-by: Thomas Huth > --- > arch/s390/include/uapi/asm/kvm.h | 6 > arch/s390/kvm/kvm-s390.c | 4 +++ > .../selftests/kvm/s390x/sync_regs_test.c | 30 +++ > 3 files changed, 40 insertions(+) With splitting out the selftest, Reviewed-by: Cornelia Huck
fix device in programming state after ioctl()
the user space program may access eMMC by ioctl(), after the ioctl() was completed, it should ensure that eMMC is in transfer state, or it will cause other thread which access eMMC got timeout error, as it assume that card was in transfer state. this patch add CMD13 polling for R1B command to avoid this issue. Chaotian Jing (2): mmc: block: make the card_busy_detect() more generic mmc: block: add CMD13 polling for ioctl() cmd with R1B response drivers/mmc/core/block.c | 111 --- 1 file changed, 57 insertions(+), 54 deletions(-) -- 2.18.0
Re: [PATCH v2 0/3] soc: qcom: llcc cleanups
On Wed, Sep 4, 2019 at 10:13 AM Bjorn Andersson
wrote:
>
> On Tue 27 Aug 04:01 PDT 2019, Vivek Gautam wrote:
>
> > On Fri, Aug 2, 2019 at 11:43 AM Vivek Gautam
> > wrote:
> > >
> > > On Thu, Jul 18, 2019 at 6:33 PM Vivek Gautam
> > > wrote:
> > > >
> > > > To better support future versions of llcc, consolidating the
> > > > driver to llcc-qcom driver file, and taking care of the dependencies.
> > > > v1 series is availale at:
> > > > https://lore.kernel.org/patchwork/patch/1099573/
> > > >
> > > > Changes since v1:
> > > > Addressing Bjorn's comments -
> > > > * Not using llcc-plat as the platform driver rather using a single
> > > >driver file now - llcc-qcom.
> > > > * Removed SCT_ENTRY macro.
> > > > * Moved few structure definitions from include/linux path to llcc-qcom
> > > >driver as they are not exposed to other subsystems.
> > >
> > > Hi Bjorn,
> > >
> > > How does this cleanup look now? Let me know if there are any
> > > improvements to make here.
> > >
> >
> > Hi Bjorn,
> >
> > Are you planning to pull this series in the next merge window?
> > There's a dt patch as well for llcc on sdm845 [1] that has been lying
> > around.
> >
> > Let me know if you have concerns with this series. I will be happy to
> > incorporate the suggestions.
> >
>
> No concerns, this is exactly what we discussed before. Sorry for missing
> it. I've picked the patches now.
>
> > [1] https://lore.kernel.org/patchwork/patch/1099318/
> >
>
> This is part of the v5.4 pull request.
Thanks a lot Bjorn.
Best regards
Vivek
>
> Thanks,
> Bjorn
>
> > Thanks & Regards
> > Vivek
> >
> > > Best Regards
> > > Vivek
> > > >
> > > > Vivek Gautam (3):
> > > > soc: qcom: llcc cleanup to get rid of sdm845 specific driver file
> > > > soc: qcom: Rename llcc-slice to llcc-qcom
> > > > soc: qcom: Make llcc-qcom a generic driver
> > > >
> > > > drivers/soc/qcom/Kconfig | 14 +--
> > > > drivers/soc/qcom/Makefile | 3 +-
> > > > drivers/soc/qcom/{llcc-slice.c => llcc-qcom.c} | 155
> > > > +++--
> > > > drivers/soc/qcom/llcc-sdm845.c | 100
> > > > include/linux/soc/qcom/llcc-qcom.h | 104 -
> > > > 5 files changed, 152 insertions(+), 224 deletions(-)
> > > > rename drivers/soc/qcom/{llcc-slice.c => llcc-qcom.c} (64%)
> > > > delete mode 100644 drivers/soc/qcom/llcc-sdm845.c
> > > >
> >
> >
> >
> > --
> > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> > of Code Aurora Forum, hosted by The Linux Foundation
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/2] mmc: block: make the card_busy_detect() more generic
to use the card_busy_detect() to wait card levae the programming state,
there may be do not have the "struct request *" argument.
Signed-off-by: Chaotian Jing
---
drivers/mmc/core/block.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 2c71a434c915..aa7c19f7e298 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -981,7 +981,7 @@ static inline bool mmc_blk_in_tran_state(u32 status)
}
static int card_busy_detect(struct mmc_card *card, unsigned int timeout_ms,
- struct request *req, u32 *resp_errs)
+ u32 *resp_errs)
{
unsigned long timeout = jiffies + msecs_to_jiffies(timeout_ms);
int err = 0;
@@ -992,8 +992,8 @@ static int card_busy_detect(struct mmc_card *card, unsigned
int timeout_ms,
err = __mmc_send_status(card, &status, 5);
if (err) {
- pr_err("%s: error %d requesting status\n",
- req->rq_disk->disk_name, err);
+ dev_err(mmc_dev(card->host),
+ "error %d requesting status\n", err);
return err;
}
@@ -1006,9 +1006,9 @@ static int card_busy_detect(struct mmc_card *card,
unsigned int timeout_ms,
* leaves the program state.
*/
if (done) {
- pr_err("%s: Card stuck in wrong state! %s %s status:
%#x\n",
- mmc_hostname(card->host),
- req->rq_disk->disk_name, __func__, status);
+ dev_err(mmc_dev(card->host),
+ "Card stuck in wrong state! %s status: %#x\n",
+__func__, status);
return -ETIMEDOUT;
}
@@ -1671,7 +1671,7 @@ static int mmc_blk_fix_state(struct mmc_card *card,
struct request *req)
mmc_blk_send_stop(card, timeout);
- err = card_busy_detect(card, timeout, req, NULL);
+ err = card_busy_detect(card, timeout, NULL);
mmc_retune_release(card->host);
@@ -1895,7 +1895,7 @@ static int mmc_blk_card_busy(struct mmc_card *card,
struct request *req)
if (mmc_host_is_spi(card->host) || rq_data_dir(req) == READ)
return 0;
- err = card_busy_detect(card, MMC_BLK_TIMEOUT_MS, req, &status);
+ err = card_busy_detect(card, MMC_BLK_TIMEOUT_MS, &status);
/*
* Do not assume data transferred correctly if there are any error bits
--
2.18.0
RE: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode
Hi >You must send plain/text emails. I'm not receiving this via the mailing list. >Please, fix your email client or use git send-email Thank you for your information. I resend mail with text format, would you kind confirm the patch, thank you. Best Regards Jacky -Original Message- From: Felipe Balbi Sent: Wednesday, September 4, 2019 3:47 PM To: Cao, Jacky Cc: Greg KH ; linux-...@vger.kernel.org; Kernel development list ; Kobayashi, Kento (Sony) Subject: Re: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode Hi, On Wed, Sep 4, 2019 at 9:47 AM wrote: > > The power budget for SuperSpeed mode should be 900 mA > > according to USB3.0 specification, so set the power > > budget to 900 mA for dummy_start_ss which is only used > > for SuperSpeed mode. > > > > If the max power consumption of SuperSpeed device is > > larger than 500 mA, insufficient available bus power > > error happens in usb_choose_configuration function > > when the device connects to dummy hcd. > > > > Signed-off-by: Jacky Cao You must send plain/text emails. I'm not receiving this via the mailing list. Please, fix your email client or use git send-email -- balbi
[PATCH] sched/core: Fix uclamp ABI bug, clean up and robustify sched_read_attr() ABI logic and code
* Thadeu Lima de Souza Cascardo wrote:
> After commit a509a7cd7974 (sched/uclamp: Extend sched_setattr() to support
> utilization clamping), using sched_getattr with size 48 will return E2BIG.
>
> This breaks, for example, chrt.
> $ chrt -p $$
> chrt: failed to get pid 26306's policy: Argument list too long
> $
>
> With this fix, when using the old size, the utilization clamping values will
> be
> absent from sched_attr. When using the new size or some larger size, they will
> be present.
>
> After the fix, chrt works again.
> $ chrt -p $$
> pid 4649's current scheduling policy: SCHED_OTHER
> pid 4649's current scheduling priority: 0
> $
>
> The drawback with this solution is that userspace will ignore there are
> non-default utilization clamps, but it's arguable whether returning E2BIG in
> this case makes sense when that same userspace doesn't know about those values
> anyway.
a509a7cd7974 breaks the ABI when CONFIG_UCLAMP_TASK=y, so there's really
no choice here but to fix it.
But this is not the right fix:
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5183,8 +5183,10 @@ SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct
> sched_attr __user *, uattr,
> attr.sched_nice = task_nice(p);
>
> #ifdef CONFIG_UCLAMP_TASK
> - attr.sched_util_min = p->uclamp_req[UCLAMP_MIN].value;
> - attr.sched_util_max = p->uclamp_req[UCLAMP_MAX].value;
> + if (size >= SCHED_ATTR_SIZE_VER1) {
> + attr.sched_util_min = p->uclamp_req[UCLAMP_MIN].value;
> + attr.sched_util_max = p->uclamp_req[UCLAMP_MAX].value;
> + }
> #endif
The real bug is that the whole sched_read_attr() logic of checking
non-zero bits in new ABI components is arguably broken, and pretty much
any extension of the ABI will spuriously break the ABI as you just found
out. That's way too fragile.
Instead how about something like the patch below? It cleans up the ABI
logic:
- if user-attributes have the same size as kernel attributes then the
logic is unchanged.
- if user-attributes are larger than the kernel knows about then simply
skip the extra bits, but set attr->size to the (smaller) kernel size
so that tooling can (in principle) handle older kernel as well.
- if user-attributes are smaller than the kernel knows about then just
copy whatever user-space can accept.
Also clean up the whole logic:
- Simplify the code flow - there's no need for 'ret' for example.
- Standardize on 'kattr/uattr' and 'ksize/usize' naming to make sure we
always know which side we are dealing with.
- Why is it called 'read' when what it does is to copy to user? This
code is so far away from VFS read() semantics that the naming is
actively confusing. Name it sched_attr_copy_to_user() instead, which
mirrors other copy_to_user() functionality.
- Move the attr->size assignment from the head of sched_getattr() to the
sched_attr_copy_to_user() function. Nothing else within the kernel
should care about the size of the structure.
With this patch I believe the sched_getattr() syscall now nicely supports
an extensible ABI in both a forward and backward compatible fashion, and
will also fix the bug.
As an added bonus the bogus -EFBIG return is removed as well.
This needs to be fixed before v5.3 is released.
NOTE: one additional open question is whether to set attr->size to the
*larger* value if the kernel has a newer ABI. This would allow
user-space to detect a new ABI.
I've also Cc:-ed perf tooling ABI experts, which handles things in a
similar fashion. (And if it doesn't or shouldn't then please chime in.)
Thanks,
Ingo
--
Subject: sched/core: Fix uclamp ABI bug, clean up and robustify
sched_read_attr() ABI logic and code
From: Ingo Molnar
Date: Sat Aug 24 17:41:57 CEST 2019
Reported-by: Thadeu Lima de Souza Cascardo
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar
---
kernel/sched/core.c | 80 ++--
1 file changed, 40 insertions(+), 40 deletions(-)
Index: linux/kernel/sched/core.c
===
--- linux.orig/kernel/sched/core.c
+++ linux/kernel/sched/core.c
@@ -5299,37 +5299,40 @@ out_unlock:
return retval;
}
-static int sched_read_attr(struct sched_attr __user *uattr,
- struct sched_attr *attr,
- unsigned int usize)
+/*
+ * Copy the kernel size attribute structure (which might be larger
+ * than what user-space knows about) to user-space.
+ *
+ * Note that all cases are valid: user-space buffer can be larger or
+ * smaller than the kernel-space buffer. The usual case is that both
+ * have the same size.
+ */
+static int
+sched_attr_copy_to_user(struct sched_attr __user *uattr,
+ struct sched_attr *kattr,
+ unsigned int usize)
{
- int ret;
+ unsigned i
Re: [PATCH] eeprom: Deprecate the legacy eeprom driver
On Mon, Sep 02, 2019 at 10:48:38AM +0200, Jean Delvare wrote: > Time has come to get rid of the old eeprom driver. The at24 driver > should be used instead. So mark the eeprom driver as deprecated and > give users some time to migrate. Then we can remove the legacy > eeprom driver completely. > > Signed-off-by: Jean Delvare > Cc: Arnd Bergmann > --- > drivers/misc/eeprom/Kconfig |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) You might also want to add a big printk() message when the driver is loaded that it shouldn't be used. thanks, greg k-h
Re: [PATCH] USB: dummy-hcd: fix power budget for SuperSpeed mode
On Wed, Sep 04, 2019 at 10:54:28AM +0300, Felipe Balbi wrote: > > Hi, > > writes: > > > The power budget for SuperSpeed mode should be 900 mA > > according to USB3.0 specification, so set the power > > budget to 900 mA for dummy_start_ss which is only used > > for SuperSpeed mode. > > > > If the max power consumption of SuperSpeed device is > > larger than 500 mA, insufficient available bus power > > error happens in usb_choose_configuration function > > when the device connects to dummy hcd. > > > > Signed-off-by: Jacky Cao > > --- > > drivers/usb/gadget/udc/dummy_hcd.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/usb/gadget/udc/dummy_hcd.c > > b/drivers/usb/gadget/udc/dummy_hcd.c > > index 8414fac..52f2cf5 100644 > > --- a/drivers/usb/gadget/udc/dummy_hcd.c > > +++ b/drivers/usb/gadget/udc/dummy_hcd.c > > @@ -48,6 +48,7 @@ > > #define DRIVER_VERSION "02 May 2005" > > > > #define POWER_BUDGET 500 /* in mA; use 8 for low-power port testing */ > > +#define POWER_BUDGET_3_0 900 /* in mA */ > > > > static const char driver_name[] = "dummy_hcd"; > > static const char driver_desc[] = "USB Host+Gadget Emulator"; > > @@ -2432,7 +2433,7 @@ static int dummy_start_ss(struct dummy_hcd *dum_hcd) > > dum_hcd->rh_state = DUMMY_RH_RUNNING; > > dum_hcd->stream_en_ep = 0; > > INIT_LIST_HEAD(&dum_hcd->urbp_list); > > - dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET; > > + dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET_3_0; > > dummy_hcd_to_hcd(dum_hcd)->state = HC_STATE_RUNNING; > > dummy_hcd_to_hcd(dum_hcd)->uses_new_polling = 1; > > #ifdef CONFIG_USB_OTG > > Alan, I suppose you're okay with this change? I'm not ok with the whitespace damage making this patch impossible to apply :)
dma api errors with swiotlb
Hi, Cristoph. Another DMA related question before I start to post patches in this area again.. Our virtual SCSI device (which BTW is fully DMA compliant) has a large queue depth and therefore runs out of SWIOTLB space => The scsi middle layer behaves nicely and asks the driver to retry the dma mapping operation. All fine. The problem is that while this happens, the kernel log spits out a number of dma- and SWIOTLB errors, which are really harmless. While one could probably just say go and increase the SWIOTLB size, but on some systems that might not be doable. We could reduce the queue depth when SEV is active, which is probably one of those hacky solutions you dislike. We could silence the dma- and swiotlb errors? At least selectively for some devices? Do you have any guidance into the best solution here? Thanks, Thomas.
Re: [PATCH v1 1/2] clk: intel: Add CGU clock driver for a new SoC
Hi Martin, On 4/9/2019 2:53 AM, Martin Blumenstingl wrote: My understanding is that if we do not use syscon, then there is no point in using regmap because this driver uses simple 32 bit register access. Can directly read/write registers using readl() & writel(). Would you agree ? if there was only the LGM SoC then I would say: drop regmap however, last year a driver for the GRX350/GRX550 SoCs was proposed: [0] this was never updated but it seems to use the same "framework" as the LGM driver with this in mind I am for keeping regmap support because. I think it will be easier to add support for old SoCs like GRX350/GRX550 (but also VRX200), because the PLL sub-driver (I am assuming that it is similar on all SoCs) or some other helpers can be re-used across various SoCs instead of "duplicating" code (where one variant would use regmap and the other readl/writel). Earlier, we had discussed about it in our team. There are no plans to upstream mips based platform code, past up-streaming efforts for mips platforms were also dropped. GRX350/GRX550/VRX200 are all mips based platforms. Plan is to upstream only x86 based platforms. In-fact, i had removed GRX & other older SoCs support from this driver before sending for review. So we can consider only x86 based LGM family of SoCs for this driver & all of them will be reusing same IP. [...] + select OF_EARLY_FLATTREE there's not a single other "select OF_EARLY_FLATTREE" in driver/clk I'm not saying this is wrong but it makes me curious why you need this We need OF_EARLY_FLATTREE for LGM. But adding a new x86 platform for LGM is discouraged because that would lead to too many platforms. Only differentiating factor for LGM is CPU model ID but it can differentiate only at run time. So i had no option other then enabling it with some LGM specific core system module driver and CGU seemed perfect for this purpose. so when my x86 kernel maintainer enables CONFIG_INTEL_LGM_CGU_CLK then OF_EARLY_FLATTREE is enabled as well. does this hurt any existing x86 platform? if not: why can't we enable it for x86 unconditionally? IMHO, it will not hurt any other existing x86 platform but enabling it for x86 unconditionally also doesn't sound like a good idea. I now get your point that enabling OF_EARLY_FLATTREE here is a bit odd. I will remove it in next patch. Regards, Rahul I went through meson & qcom regmap clock code. Agree, it can be reused for mux, divider and gate. But as mentioned above, i am now considering to move away from using regmap. thank you for evaluating them. let's continue the discussion above whether regmap should be used - after that we decide (if needed) which regmap implementation to use Martin [0] https://patchwork.kernel.org/patch/10554401/
Re: [PATCH 3/3] dt-bindings: regulator: add regulator-fixed-clock binding
On Tue, 2019-09-03 at 09:45 +0100, Rob Herring wrote: > On Tue, Sep 3, 2019 at 9:03 AM Philippe Schenker > wrote: > > This adds the documentation to the compatible regulator-fixed-clock > > Please explain what that is in this patch. Hi Rob and thanks for your comments. I will change this commit message for a possible v2 into this: This adds the documentation to the compatible regulator-fixed-clock. This binding is a special binding of regulator-fixed and adds the ability to add a clock to regulator-fixed, so the regulator can be enabled and disabled with that clock. If the special compatible regulator-fixed-clock is used it is mandatory to supply a clock. > > > > > Signed-off-by: Philippe Schenker > > > > --- > > > > .../bindings/regulator/fixed-regulator.yaml| 18 > > +- > > 1 file changed, 17 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/regulator/fixed- > > regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed- > > regulator.yaml > > index a650b457085d..5fd081e80b43 100644 > > --- a/Documentation/devicetree/bindings/regulator/fixed- > > regulator.yaml > > +++ b/Documentation/devicetree/bindings/regulator/fixed- > > regulator.yaml > > @@ -19,9 +19,19 @@ description: > > allOf: > >- $ref: "regulator.yaml#" > > > > +select: > > + properties: > > +compatible: > > + contains: > > +const: regulator-fixed-clock > > + required: > > +- clocks > > You don't need this. > > If you add a new compatible, then this should probably be a new schema > doc. Is the 'gpio' property valid in this case as if a clock is the > enable, can you also have a gpio enable? That said, it seems like the > new compatible is only for validating the DT in the driver. You could > just use a clock if present and default to current behavior if not. > It's not the kernel's job to validate DTs. The gpio property is valid with this compatible. I added regulator- fixed-clock to regulator-fixed hence I also don't want to create a new schema file. With the above select statement I wanted to state clocks as required when the compatible regulator-fixed-clock is given. > > > properties: > >compatible: > > -const: regulator-fixed > > +items: > > + - const: regulator-fixed > > + - const: regulator-fixed-clock > > This says you must have 'compatible = "regulator-fixed", > "regulator-fixed-clock";'. > > What you want is: > > enum: > - regulator-fixed > - regulator-fixed-clock Thanks, this was exactly what I wanted to do. > > >regulator-name: true > > > > @@ -29,6 +39,12 @@ properties: > > description: gpio to use for enable control > > maxItems: 1 > > > > + clocks: > > +description: > > + clock to use for enable control. This binding is only > > available if > > + the compatible is chosen to regulator-fixed-clock. The clock > > binding > > + is mandatory if compatible is chosen to regulator-fixed- > > clock. > > Need to define how many clocks (maxItems: 1). Will do for a possible v2. I want to wait what Mark Brown says about the addition in general, maybe I have to change all over how this speciality is added into regulator subsystem and therefore also the binding will change. Philippe > > > + > >startup-delay-us: > > description: startup time in microseconds > > $ref: /schemas/types.yaml#/definitions/uint32 > > -- > > 2.23.0 > >
Re: [PATCH 1/2] ftrace: Fix NULL pointer dereference in t_probe_next()
Steven Rostedt wrote: On Thu, 4 Jul 2019 20:04:41 +0530 "Naveen N. Rao" wrote: kernel/trace/ftrace.c | 4 1 file changed, 4 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 7b037295a1f1..0791eafb693d 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -3093,6 +3093,10 @@ t_probe_next(struct seq_file *m, loff_t *pos) hnd = &iter->probe_entry->hlist; hash = iter->probe->ops.func_hash->filter_hash; + + if (!hash) + return NULL; + size = 1 << hash->size_bits; retry: OK, I added this, but I'm also adding this on top: Thanks, the additional comments do make this much clearer. Regards, Naveen
Re: [PATCH] platform/chrome: chromeos_tbmc : Report wake events.
Hi Ravi,
Many thanks for this patch.
On 31/8/19 1:14, Ravi Chandra Sadineni wrote:
> Mark chromeos_tbmc as wake capable and report wake events. This helps to
> abort suspend on seeing a tablet mode switch event when kernel is
> suspending. This also helps identifying if chroemos_tbmc is the wake
> source.
>
> Signed-off-by: Ravi Chandra Sadineni
The patch looks good to me, I'll wait a bit before pick the patch for I can get
a Tested-by from someone as I don't think I have the hardware to test this (no
x86/tablet devices on my hand)
For my own reference:
Acked-for-chrome-by: Enric Balletbo i Serra
Thanks,
Enric
> ---
> drivers/platform/chrome/chromeos_tbmc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/platform/chrome/chromeos_tbmc.c
> b/drivers/platform/chrome/chromeos_tbmc.c
> index ce259ec9f990..d1cf8f3463ce 100644
> --- a/drivers/platform/chrome/chromeos_tbmc.c
> +++ b/drivers/platform/chrome/chromeos_tbmc.c
> @@ -47,6 +47,7 @@ static __maybe_unused int chromeos_tbmc_resume(struct
> device *dev)
>
> static void chromeos_tbmc_notify(struct acpi_device *adev, u32 event)
> {
> + acpi_pm_wakeup_event(&adev->dev);
> switch (event) {
> case 0x80:
> chromeos_tbmc_query_switch(adev, adev->driver_data);
> @@ -90,6 +91,7 @@ static int chromeos_tbmc_add(struct acpi_device *adev)
> dev_err(dev, "cannot register input device\n");
> return ret;
> }
> + device_init_wakeup(dev, true);
> return 0;
> }
>
>
Re: [RFC,v2 2/6] i2c: add I2C Address Translator (ATR) support
Hi! [ Sorry about my absence. I've been meaning to comment on this series for a long time, but work and family keep interfering... ] On 2019-09-03 09:31, Luca Ceresoli wrote: > Hi Jacopo, > > thanks for your feedback. > > On 01/09/19 16:31, jacopo mondi wrote: >> Hi Luca, >>thanks for keep pushing this series! I hope we can use part of this >> for the (long time) on-going GMSL work... >> >> I hope you will be patient enough to provide (another :) overview >> of this work during the BoF Wolfram has organized at LPC for the next >> week. > > Sure! > >> In the meantime I would have some comments after having a read at the >> series and trying to apply its concept to GMSL >> >> On Tue, Jul 23, 2019 at 10:37:19PM +0200, Luca Ceresoli wrote: >>> An ATR is a device that looks similar to an i2c-mux: it has an I2C >>> slave "upstream" port and N master "downstream" ports, and forwards >>> transactions from upstream to the appropriate downstream port. But is >>> is different in that the forwarded transaction has a different slave >>> address. The address used on the upstream bus is called the "alias" >>> and is (potentially) different from the physical slave address of the >>> downstream chip. >>> >>> Add a helper file (just like i2c-mux.c for a mux or switch) to allow >>> implementing ATR features in a device driver. The helper takes care or >>> adapter creation/destruction and translates addresses at each transaction. >>> >>> Signed-off-by: Luca Ceresoli >>> >>> --- >>> >>> Changes RFCv1 -> RFCv2: >>> >>> RFCv1 was implemented inside i2c-mux.c and added yet more complexity >>> there. RFCv2 creates a new file on its own, i2c-atr.c. Since many ATR >>> features are not in a MUX and vice versa, the overlapping is low. This was >>> almost a complete rewrite, but for the records here are the main >>> differences from the old implementation: >> >> I'm not an i2c expert, but this looks very similar to me to an >> augmented i2c-mux with the following additional features: >> - automatic selection of the i2c address to use for the children >> behind the mux >> - automatic translation of the addresses the logical aliases to >> the actual physical addresses of the slaves (with the help of the >> deserializer address translation feature in this case). > > A notable difference in the hardware is that a mux needs an explicit > procedure to select a port. That's why the select() op is mandatory for > muxes. The ATR, at least in the DS90UB9xx case, selects the port > automatically based on the slave address. So I added an optional > select() op in the atr, but I suspect it's useless for "real" ATRs. > > More differences derive from how Linux implements muxes. The i2c-mux > code has several flags for different locking schemes, and it has a It's two locking schemes if you count them carefully, so several is a bit of an exaggeration. But agreed, two is more than I prefer. > fairly complex DT parsing scheme. These are mostly a historical burden. > Adding the ATR features to i2c-mux.c was very tricky and error-prone due > to all of this code, that's why I have moved ATR to its own file in RFCv2. Anyway, the locking in i2c-mux may be complex, but it does solve real problems. The way I read this series, these problems are not dealt with and therefore the ATR code will not function in all surroundings. Some things to think about: - What happens when you put a mux behind an ATR? - What happens when you put an ATR behind a mux? - What happens when you put an ATR between two muxes? - Does it make a difference if the mux is parent-locked or mux-locked? - What happens if client drivers lock the adapter in order to silence the bus for some reason or to keep two xfers together or something, and then do unlocked xfers? - Can you put an ATR behind another ATR? etc I'm not saying that these things must be handled, and maybe they are handled already, and maybe some of the combinations are not valid at all. But the possibilities and limitations should be understood. And preferably documented. My gut feeling (without spending much time on it) is that ATR as implemented in this series behave approximately like mux-locked muxes, meaning that it is not obviously safe to put a parent-locked mux behind an ATR and making it impossible for client devices behind an ATR to force xfers to happen back-to-back from the root adapter. And finally, I feel that it is not wise to introduce a third locking scheme in the I2C topology. It's bad enough with two. Why not make the ATR locking exactly match the mux-locked scheme to reduce the number of cases one needs to consider? But maybe that's just me? Cheers, Peter
Re: [PATCH 1/1] mm/migrate: fix list corruption in migration of non-LRU movable pages
Do not top post please
On Wed 04-09-19 07:27:25, sunqiuyang wrote:
> isolate_migratepages_block() from another thread may try to isolate the page
> again:
>
> for (; low_pfn < end_pfn; low_pfn++) {
> /* ... */
> page = pfn_to_page(low_pfn);
> /* ... */
> if (!PageLRU(page)) {
> if (unlikely(__PageMovable(page)) && !PageIsolated(page)) {
> /* ... */
> if (!isolate_movable_page(page, isolate_mode))
> goto isolate_success;
> /*... */
> isolate_success:
> list_add(&page->lru, &cc->migratepages);
>
> And this page will be added to another list.
> Or, do you see any reason that the page cannot go through this path?
The page shouldn't be __PageMovable after the migration is done. All the
state should have been transfered to the new page IIUC.
--
Michal Hocko
SUSE Labs
Re: [PATCH v5 1/2] rpmsg: core: add API to get message length
Hi Suman
On 9/3/19 6:06 PM, Suman Anna wrote:
Hi Arnaud,
On 9/3/19 4:49 AM, Arnaud Pouliquen wrote:
hi Suman
On 8/29/19 12:34 AM, Suman Anna wrote:
Hi Arnaud,
On 8/28/19 10:19 AM, Arnaud Pouliquen wrote:
Return the rpmsg buffer size for sending message, so rpmsg users
can split a long message in several sub rpmsg buffers.
Thanks for the patch, I also have a need for the same to be able to
compute permissible payload size. Minor comments below.
Thanks for your review. i will update it ASAP. Then if you need it and
ack it, i suppose that we could request Bjorn to integrate it in a first
step, if the rpmsg tty driver has not a level of quality sufficient to
be accepted...
Yeah, this patch can always be merged independently ahead of the rpmsg
tty driver. Anyways, the tty patch will have to be picked up by a
separate maintainer right. So, it would be nice to get the revised
version get into 5.4
Sure, I plan to send a new version of the series today.
I would prefer not to split the series, just to simplify the review and
the tests. if this patch is cherry-picked and integrated independently
by Bjorn, I will simply sent a new version of the rpmsg tty driver
without it.
Regards
Arnaud
regards
Suman
Regards
Arnaud
Signed-off-by: Arnaud Pouliquen
---
V4 to V5 :
- rename rpmsg_get_buf_payload_size to rpmsg_get_mtu
drivers/rpmsg/rpmsg_core.c | 21 +
drivers/rpmsg/rpmsg_internal.h | 2 ++
drivers/rpmsg/virtio_rpmsg_bus.c | 10 ++
include/linux/rpmsg.h | 10 ++
4 files changed, 43 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index 8122807db380..daca2e24fc71 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -283,6 +283,27 @@ int rpmsg_trysend_offchannel(struct
rpmsg_endpoint *ept, u32 src, u32 dst,
}
EXPORT_SYMBOL(rpmsg_trysend_offchannel);
+/**
+ * rpmsg_get_mtu() - get maximum transmission buffer size for
sending message.
+ * @ept: the rpmsg endpoint
+ *
+ * This function returns maximum buffer size available for a single
message.
+ *
+ * Return: the maximum transmission size on success and an
appropriate error
+ * value on failure.
+ */
+
+ssize_t rpmsg_get_mtu(struct rpmsg_endpoint *ept)
+{
+ if (WARN_ON(!ept))
+ return -EINVAL;
+ if (!ept->ops->get_buf_mtu)
How about calling the ops just get_mtu or rename the function to follow
the ops name, like all the others.
+ return -ENXIO;
Perhaps ENOTSUPP or EOPNOTSUPP.
+
+ return ept->ops->get_buf_mtu(ept);
+}
+EXPORT_SYMBOL(rpmsg_get_mtu);
+
/*
* match an rpmsg channel with a channel info struct.
* this is used to make sure we're not creating rpmsg devices for
channels
diff --git a/drivers/rpmsg/rpmsg_internal.h
b/drivers/rpmsg/rpmsg_internal.h
index 0d791c30b7ea..645c402569ac 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -46,6 +46,7 @@ struct rpmsg_device_ops {
* @trysend: see @rpmsg_trysend(), required
* @trysendto: see @rpmsg_trysendto(), optional
* @trysend_offchannel: see @rpmsg_trysend_offchannel(), optional
+ * @get_buf_payload_size: see @rpmsg_get_buf_payload_size(), optional
Missed updating the kerneldoc to the new name.
*
* Indirection table for the operations that a rpmsg backend should
implement.
* In addition to @destroy_ept, the backend must at least implement
@send and
@@ -65,6 +66,7 @@ struct rpmsg_endpoint_ops {
void *data, int len);
__poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp,
poll_table *wait);
+ ssize_t (*get_buf_mtu)(struct rpmsg_endpoint *ept);
};
int rpmsg_register_device(struct rpmsg_device *rpdev);
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
b/drivers/rpmsg/virtio_rpmsg_bus.c
index e757f0038a1c..f80b1ad23e7e 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -178,6 +178,7 @@ static int virtio_rpmsg_trysendto(struct
rpmsg_endpoint *ept, void *data,
int len, u32 dst);
static int virtio_rpmsg_trysend_offchannel(struct rpmsg_endpoint
*ept, u32 src,
u32 dst, void *data, int len);
+static ssize_t virtio_get_buf_mtu(struct rpmsg_endpoint *ept);
Minor nit, virtio_rpmsg_ prefix similar to all the other ops.
regards
Suman
static const struct rpmsg_endpoint_ops virtio_endpoint_ops = {
.destroy_ept = virtio_rpmsg_destroy_ept,
@@ -187,6 +188,7 @@ static const struct rpmsg_endpoint_ops
virtio_endpoint_ops = {
.trysend = virtio_rpmsg_trysend,
.trysendto = virtio_rpmsg_trysendto,
.trysend_offchannel = virtio_rpmsg_trysend_offchannel,
+ .get_buf_mtu = virtio_get_buf_mtu,
};
/**
@@ -702,6 +704,14 @@ static int
virtio_rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src,
return rpmsg_send_offchannel_raw(rpdev, src, dst, data, len,
false);
}
Re: [PATCH 2/2] sched/debug: add sched_update_nr_running tracepoint
On Wed, Sep 04, 2019 at 12:23:10AM -0400, Joel Fernandes wrote: > On Tue, Sep 03, 2019 at 05:05:47PM +0100, Valentin Schneider wrote: > > On 03/09/2019 16:43, Radim Krčmář wrote: > > > The paper "The Linux Scheduler: a Decade of Wasted Cores" used several > > > custom data gathering points to better understand what was going on in > > > the scheduler. > > > Red Hat adapted one of them for the tracepoint framework and created a > > > tool to plot a heatmap of nr_running, where the sched_update_nr_running > > > tracepoint is being used for fine grained monitoring of scheduling > > > imbalance. > > > The tool is available from https://github.com/jirvoz/plot-nr-running. > > > > > > The best place for the tracepoints is inside the add/sub_nr_running, > > > which requires some shenanigans to make it work as they are defined > > > inside sched.h. > > > The tracepoints have to be included from sched.h, which means that > > > CREATE_TRACE_POINTS has to be defined for the whole header and this > > > might cause problems if tree-wide headers expose tracepoints in sched.h > > > dependencies, but I'd argue it's the other side's misuse of tracepoints. > > > > > > Moving the import sched.h line lower would require fixes in s390 and ppc > > > headers, because they don't include dependecies properly and expect > > > sched.h to do it, so it is simpler to keep sched.h there and > > > preventively undefine CREATE_TRACE_POINTS right after. > > > > > > Exports of the pelt tracepoints remain because they don't need to be > > > protected by CREATE_TRACE_POINTS and moving them closer would be > > > unsightly. > > > > > > > Pure trace events are frowned upon in scheduler world, try going with > > trace points. Quite; I hate tracepoints for the API constraints they impose. Been bitten by that, not want to ever have to deal with that again. > > Qais did something very similar recently: > > > > https://lore.kernel.org/lkml/20190604111459.2862-1-qais.you...@arm.com/ > > > > You'll have to implement the associated trace events in a module, which > > lets you define your own event format and doesn't form an ABI :). > > Is that really true? eBPF programs loaded from userspace can access > tracepoints through BPF_RAW_TRACEPOINT_OPEN, which is UAPI: > https://github.com/torvalds/linux/blob/master/include/uapi/linux/bpf.h#L103 > > I don't have a strong opinion about considering tracepoints as ABI / API or > not, but just want to get the facts straight :) eBPF can access all sorts of kernel internals; if we were to deem eBPF and API we'd be fscked.
Re: [PATCH V7 1/3] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory()
On 03.09.19 11:45, Anshuman Khandual wrote: > Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs > entries between memory block and node. It first checks pfn validity with > pfn_valid_within() before fetching nid. With CONFIG_HOLES_IN_ZONE config > (arm64 has this enabled) pfn_valid_within() calls pfn_valid(). > > pfn_valid() is an arch implementation on arm64 (CONFIG_HAVE_ARCH_PFN_VALID) > which scans all mapped memblock regions with memblock_is_map_memory(). This > creates a problem in memory hot remove path which has already removed given > memory range from memory block with memblock_[remove|free] before arriving > at unregister_mem_sect_under_nodes(). Hence get_nid_for_pfn() returns -1 > skipping subsequent sysfs_remove_link() calls leaving node <-> memory block > sysfs entries as is. Subsequent memory add operation hits BUG_ON() because > of existing sysfs entries. Since commit 60bb462fc7adb06ebee3beb5a4af6c7e6182e248 Author: David Hildenbrand Date: Wed Aug 28 13:57:15 2019 +1000 drivers/base/node.c: simplify unregister_memory_block_under_nodes() that problem should be gone. There is no get_nid_for_pfn() call anymore. So this patch should no longer be necessary - but as I said during earlier versions of this patch, the re-ordering might still make sense for consistency (removing stuff in the reverse order they were added). You'll have to rephrase the description then. > > [ 62.007176] NUMA: Unknown node for memory at 0x68000, assuming node 0 > [ 62.052517] [ cut here ] > [ 62.053211] kernel BUG at mm/memory_hotplug.c:1143! > [ 62.053868] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > [ 62.054589] Modules linked in: > [ 62.054999] CPU: 19 PID: 3275 Comm: bash Not tainted > 5.1.0-rc2-4-g28cea40b2683 #41 > [ 62.056274] Hardware name: linux,dummy-virt (DT) > [ 62.057166] pstate: 4045 (nZcv daif +PAN -UAO) > [ 62.058083] pc : add_memory_resource+0x1cc/0x1d8 > [ 62.058961] lr : add_memory_resource+0x10c/0x1d8 > [ 62.059842] sp : 168b3ce0 > [ 62.060477] x29: 168b3ce0 x28: 8005db546c00 > [ 62.061501] x27: x26: > [ 62.062509] x25: 111ef000 x24: 111ef5d0 > [ 62.063520] x23: x22: 0006bfff > [ 62.064540] x21: ffef x20: 006c > [ 62.065558] x19: 0068 x18: 0024 > [ 62.066566] x17: x16: > [ 62.067579] x15: x14: 8005e412e890 > [ 62.068588] x13: 8005d6b105d8 x12: > [ 62.069610] x11: 8005d6b10490 x10: 0040 > [ 62.070615] x9 : 8005e412e898 x8 : 8005e412e890 > [ 62.071631] x7 : 8005d6b105d8 x6 : 8005db546c00 > [ 62.072640] x5 : 0001 x4 : 0002 > [ 62.073654] x3 : 8005d7049480 x2 : 0002 > [ 62.074666] x1 : 0003 x0 : ffef > [ 62.075685] Process bash (pid: 3275, stack limit = 0xd754280f) > [ 62.076930] Call trace: > [ 62.077411] add_memory_resource+0x1cc/0x1d8 > [ 62.078227] __add_memory+0x70/0xa8 > [ 62.078901] probe_store+0xa4/0xc8 > [ 62.079561] dev_attr_store+0x18/0x28 > [ 62.080270] sysfs_kf_write+0x40/0x58 > [ 62.080992] kernfs_fop_write+0xcc/0x1d8 > [ 62.081744] __vfs_write+0x18/0x40 > [ 62.082400] vfs_write+0xa4/0x1b0 > [ 62.083037] ksys_write+0x5c/0xc0 > [ 62.083681] __arm64_sys_write+0x18/0x20 > [ 62.084432] el0_svc_handler+0x88/0x100 > [ 62.085177] el0_svc+0x8/0xc > > Re-ordering memblock_[free|remove]() with arch_remove_memory() solves the > problem on arm64 as pfn_valid() behaves correctly and returns positive > as memblock for the address range still exists. arch_remove_memory() > removes applicable memory sections from zone with __remove_pages() and > tears down kernel linear mapping. Removing memblock regions afterwards > is safe because there is no other memblock (bootmem) allocator user that > late. So nobody is going to allocate from the removed range just to blow > up later. Also nobody should be using the bootmem allocated range else > we wouldn't allow to remove it. So reordering is indeed safe. > > Reviewed-by: David Hildenbrand > Reviewed-by: Oscar Salvador > Acked-by: Mark Rutland > Acked-by: Michal Hocko > Signed-off-by: Anshuman Khandual > --- > mm/memory_hotplug.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index c73f09913165..355c466e0621 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1770,13 +1770,13 @@ static int __ref try_remove_memory(int nid, u64 > start, u64 size) > > /* remove memmap entry */ > firmware_map_remove(start, start + size, "System RAM"); > - memblock_free(start, size); > - memblock_remove(start, size); > > /* remove memory block devices before removing memory
[PATCH] microblaze: Enable Xilinx AXI emac driver by default
Enable Xilinx AXI emac ethernet driver for Microblaze. Signed-off-by: Michal Simek --- arch/microblaze/configs/mmu_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/microblaze/configs/mmu_defconfig b/arch/microblaze/configs/mmu_defconfig index 000da33365c4..43ede33da900 100644 --- a/arch/microblaze/configs/mmu_defconfig +++ b/arch/microblaze/configs/mmu_defconfig @@ -45,6 +45,7 @@ CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_NETDEVICES=y CONFIG_XILINX_EMACLITE=y +CONFIG_XILINX_AXI_EMAC=y CONFIG_XILINX_LL_TEMAC=y # CONFIG_INPUT is not set # CONFIG_SERIO is not set -- 2.17.1
[PATCH] USB: usbfs: check cpu address range before remap
In usbfs mmap, usb_alloc_coherent is used to allocate memory.
This Memory is then remapped to user space memory using remap_pfn_range.
remap_pfn_range needs phy address of memory, for which virt_to_phy API
is used. This API works only if memory is allocated using kmalloc. But
usb_alloc_coherent can allocate memory in vmalloc range and this causes
wrong remap of user memory.
Check if address returned by usb_alloc_coherent failed in vmalloc range
and if yes, use remap_vmalloc_range API, else use remap_pfn_range to remap
address to user space.
Signed-off-by: Nagarjuna Kristam
---
drivers/usb/core/devio.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index a945ad7..20999de 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -250,7 +250,12 @@ static int usbdev_mmap(struct file *file, struct
vm_area_struct *vma)
usbm->vma_use_count = 1;
INIT_LIST_HEAD(&usbm->memlist);
- if (remap_pfn_range(vma, vma->vm_start,
+ if (is_vmalloc_addr(usbm->mem)) {
+ if (remap_vmalloc_range(vma, usbm->mem, 0) < 0) {
+ dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
+ return -EAGAIN;
+ }
+ } else if (remap_pfn_range(vma, vma->vm_start,
virt_to_phys(usbm->mem) >> PAGE_SHIFT,
size, vma->vm_page_prot) < 0) {
dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
--
2.7.4
Re: [PATCH] tty: n_gsm: avoid recursive locking with async port hangup
On 29. 08. 19, 21:42, Martin Hundebøll wrote:
> On 22/08/2019 23.56, Martin Hundebøll wrote:
>> When tearing down the n_gsm ldisc while one or more of its child ports
>> are open, a lock dep warning occurs:
>>
>> [ 56.254258] ==
>> [ 56.260447] WARNING: possible circular locking dependency detected
>> [ 56.266641] 5.2.0-00118-g1fd58e20e5b0 #30 Not tainted
>> [ 56.271701] --
>> [ 56.277890] cmux/271 is trying to acquire lock:
>> [ 56.282436] 8215283a (&tty->legacy_mutex){+.+.}, at:
>> __tty_hangup.part.0+0x58/0x27c
>> [ 56.290128]
>> [ 56.290128] but task is already holding lock:
>> [ 56.295970] e9e2b842 (&gsm->mutex){+.+.}, at:
>> gsm_cleanup_mux+0x9c/0x15c
>> [ 56.302699]
>> [ 56.302699] which lock already depends on the new lock.
>> [ 56.302699]
>> [ 56.310884]
>> [ 56.310884] the existing dependency chain (in reverse order) is:
>> [ 56.318372]
>> [ 56.318372] -> #2 (&gsm->mutex){+.+.}:
>> [ 56.323624] mutex_lock_nested+0x1c/0x24
>> [ 56.328079] gsm_cleanup_mux+0x9c/0x15c
>> [ 56.332448] gsmld_ioctl+0x418/0x4e8
>> [ 56.336554] tty_ioctl+0x96c/0xcb0
>> [ 56.340492] do_vfs_ioctl+0x41c/0xa5c
>> [ 56.344685] ksys_ioctl+0x34/0x60
>> [ 56.348535] ret_fast_syscall+0x0/0x28
>> [ 56.352815] 0xbe97cc04
>> [ 56.355791]
>> [ 56.355791] -> #1 (&tty->ldisc_sem){}:
>> [ 56.361388] tty_ldisc_lock+0x50/0x74
>> [ 56.365581] tty_init_dev+0x88/0x1c4
>> [ 56.369687] tty_open+0x1c8/0x430
>> [ 56.373536] chrdev_open+0xa8/0x19c
>> [ 56.377560] do_dentry_open+0x118/0x3c4
>> [ 56.381928] path_openat+0x2fc/0x1190
>> [ 56.386123] do_filp_open+0x68/0xd4
>> [ 56.390146] do_sys_open+0x164/0x220
>> [ 56.394257] kernel_init_freeable+0x328/0x3e4
>> [ 56.399146] kernel_init+0x8/0x110
>> [ 56.403078] ret_from_fork+0x14/0x20
>> [ 56.407183] 0x0
>> [ 56.409548]
>> [ 56.409548] -> #0 (&tty->legacy_mutex){+.+.}:
>> [ 56.415402] __mutex_lock+0x64/0x90c
>> [ 56.419508] mutex_lock_nested+0x1c/0x24
>> [ 56.423961] __tty_hangup.part.0+0x58/0x27c
>> [ 56.428676] gsm_cleanup_mux+0xe8/0x15c
>> [ 56.433043] gsmld_close+0x48/0x90
>> [ 56.436979] tty_ldisc_kill+0x2c/0x6c
>> [ 56.441173] tty_ldisc_release+0x88/0x194
>> [ 56.445715] tty_release_struct+0x14/0x44
>> [ 56.450254] tty_release+0x36c/0x43c
>> [ 56.454365] __fput+0x94/0x1e8
>>
>> Avoid the warning by doing the port hangup asynchronously.
>
> Any comments?
I did not manage to reply before vacation, and after having "work =
NULL" in my head, I forgot, sorry.
At the same time, I am a bit lost in the lockdep chain above. It mixes
close (#0), open (#1) and ioctl (#2), so how is this a "chain" in the
first place?
BTW, do you see an actual deadlock? And what tty driver do you use for
backend devices? I.e. what ttys do you set this ldisc to?
See also the comment below.
>> Signed-off-by: Martin Hundebøll
>> ---
>> drivers/tty/n_gsm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
>> index d30525946892..36a3eb4ad4c5 100644
>> --- a/drivers/tty/n_gsm.c
>> +++ b/drivers/tty/n_gsm.c
>> @@ -1716,7 +1716,7 @@ static void gsm_dlci_release(struct gsm_dlci *dlci)
>> gsm_destroy_network(dlci);
>> mutex_unlock(&dlci->mutex);
>> - tty_vhangup(tty);
>> + tty_hangup(tty);
>> tty_port_tty_set(&dlci->port, NULL);
I am afraid there is changed semantics now: the scheduled hangup will
likely happen when the tty in tty_port is set to NULL already, so some
operations done in tty->ops->hangup might be a nop now. For example the
commonly used tty_port_hangup won't set TTY_IO_ERROR on the tty and
won't lower DTR and RTS on the line either.
>> tty_kref_put(tty);
thanks,
--
js
suse labs
Re: linux-next: build failure after merge of the net-next tree
On 9/3/19 11:00 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> scripts/link-vmlinux.sh: 74: Bad substitution
>
> Caused by commit
>
>341dfcf8d78e ("btf: expose BTF info through sysfs")
>
> interacting with commit
>
>1267f9d3047d ("kbuild: add $(BASH) to run scripts with bash-extension")
>
> from the kbuild tree.
>
> The change in the net-next tree turned link-vmlinux.sh into a bash script
> (I think).
Hi Stephen,
Sorry about this breakage. Indeed, ${@:2} is BASH-specific extension,
unfortunately. I'm verifying a simple fix with shift and $@, I'll post
and CC you as soon as I've verified everything.
With that your temporary fix shouldn't be necessary.
>
> I have applied the following patch for today:
>
> From: Stephen Rothwell
> Date: Wed, 4 Sep 2019 15:43:41 +1000
> Subject: [PATCH] link-vmlinux.sh is now a bash script
>
> Signed-off-by: Stephen Rothwell
> ---
> Makefile| 4 ++--
> scripts/link-vmlinux.sh | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ac97fb282d99..523d12c5cebe 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1087,7 +1087,7 @@ ARCH_POSTLINK := $(wildcard
> $(srctree)/arch/$(SRCARCH)/Makefile.postlink)
>
> # Final link of vmlinux with optional arch pass after final link
> cmd_link-vmlinux = \
> - $(CONFIG_SHELL) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ;\
> + $(BASH) $< $(LD) $(KBUILD_LDFLAGS) $(LDFLAGS_vmlinux) ;\
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
>
> vmlinux: scripts/link-vmlinux.sh autoksyms_recursive $(vmlinux-deps) FORCE
> @@ -1403,7 +1403,7 @@ clean: rm-files := $(CLEAN_FILES)
> PHONY += archclean vmlinuxclean
>
> vmlinuxclean:
> - $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean
> + $(Q)$(BASH) $(srctree)/scripts/link-vmlinux.sh clean
> $(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean)
>
> clean: archclean vmlinuxclean
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index f7edb75f9806..ea1f8673869d 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -1,4 +1,4 @@
> -#!/bin/sh
> +#!/bin/bash
> # SPDX-License-Identifier: GPL-2.0
> #
> # link vmlinux
>
Re: [PATCH v5 1/4] ftrace: Implement fs notification for tracing_max_latency
On Wed, Sep 04, 2019 at 12:00:39AM -0400, Joel Fernandes wrote: > [ Resending since I messed up my last email's headers! ] > > On Tue, Sep 03, 2019 at 03:25:59PM +0200, Viktor Rosendahl wrote: > > This patch implements the feature that the tracing_max_latency file, > > e.g. /sys/kernel/debug/tracing/tracing_max_latency will receive > > notifications through the fsnotify framework when a new latency is > > available. > > > > One particularly interesting use of this facility is when enabling > > threshold tracing, through /sys/kernel/debug/tracing/tracing_thresh, > > together with the preempt/irqsoff tracers. This makes it possible to > > implement a user space program that can, with equal probability, > > obtain traces of latencies that occur immediately after each other in > > spite of the fact that the preempt/irqsoff tracers operate in overwrite > > mode. > > Adding Paul since RCU faces similar situations, i.e. raising softirq risks > scheduler deadlock in rcu_read_unlock_special() -- but RCU's solution is to > avoid raising the softirq and instead use irq_work. Which is right. > I was wondering, if we can rename __raise_softirq_irqoff() to > raise_softirq_irqoff_no_wake() and call that from places where there is risk > of scheduler related deadlocks. Then I think this can be used from Viktor's > code. Let us discuss - what would happen if the softirq is raised, but > ksoftirqd is not awakened for this latency notification path? Is this really > an issue considering the softirq will execute during the next interrupt exit? You'd get unbounded latency for processing the softirq and warnings on going idle with softirqs pending. I really don't see why we should/want to be using softirq here.
Re: Re: Re: Re: [PATCH] mm: Add nr_free_highatomimic to fix incorrect watermatk routine
On Wed 04-09-19 15:54:57, Park Sangwoo wrote:
> > On Tue 03-09-19 18:59:59, Park Sangwoo wrote:
> > > On Mon 02-09-19 13:34:54, Sangwoo� wrote:
> > >>> On Fri 30-08-19 18:25:53, Sangwoo wrote:
> > The highatomic migrate block can be increased to 1% of Total memory.
> > And, this is for only highorder ( > 0 order). So, this block size is
> > excepted during check watermark if allocation type isn't alloc_harder.
> >
> > It has problem. The usage of highatomic is already calculated at
> > >>> NR_FREE_PAGES.
> > > So, if we except total block size of highatomic, it's twice minus
> > > size of
> > >>> allocated
> > > highatomic.
> > > It's cause allocation fail although free pages enough.
> > >
> > > We checked this by random test on my target(8GB RAM).
> > >
> > > Binder:6218_2: page allocation failure: order:0, mode:0x14200ca
> > >>> (GFP_HIGHUSER_MOVABLE), nodemask=(null)
> > > Binder:6218_2 cpuset=background mems_allowed=0
> >
> > How come this order-0 sleepable allocation fails? The upstream kernel
> > doesn't fail those allocations unless the process context is killed by
> > the oom killer.
> > >>>
> > >>> Most calltacks are zsmalloc, as shown below.
> > >>
> > >> What makes those allocations special so that they fail unlike any other
> > >> normal order-0 requests? Also do you see the same problem with the
> > >> current upstream kernel? Is it possible this is an Android specific
> > >> issue?
> > >
> > > There is the other case of fail order-0 fail.
> > >
> > > hvdcp_opti: page allocation failure: order:0,
> > > mode:0x1004000(GFP_NOWAIT|__GFP_COMP), nodemask=(null)
> >
> > This is an atomic allocation and failing that one is not a problem
> > usually. High atomic reservations might prevent GFP_NOWAIT allocation
> > from suceeding but I do not see that as a problem. This is the primary
> > purpose of the reservation.
>
> Thanks, your answer helped me. However, my suggestion is not to modify the
> use and management of the high atomic region,
> but to calculate the exact free size of the highatomic so that fail does not
> occur for previously shared cases.
>
> In __zone_water_mark_ok(...) func, if it is not atomic allocation, high
> atomic size is excluded.
>
> bool __zone_watermark_ok(struct zone *z,
> ...
> {
> ...
> if (likely(!alloc_harder)) {
> free_pages -= z->nr_reserved_highatomic;
> ...
> }
>
> However, free_page excludes the size already allocated by hiahtomic.
> If highatomic block is small(Under 4GB RAM), it could be no problem.
> But, the larger the memory size, the greater the chance of problems.
> (Becasue highatomic size can be increased up to 1% of memory)
I still do not understand. NR_FREE_PAGES should include the amount of
hhighatomic reserves, right. So reducing the free_pages for normal
allocations just makes sense. Or what do I miss?
I am sorry but I find your reasoning really hard to follow.
--
Michal Hocko
SUSE Labs
Re: [PATCH v5 1/4] ftrace: Implement fs notification for tracing_max_latency
On Tue, Sep 03, 2019 at 03:25:59PM +0200, Viktor Rosendahl wrote: > It seems like it would be possible to simply replace the calls to > latency_fsnotify_enable/disable() with calls to > start/stop_critical_timings(). However, the main problem is that it > would not work for the wakup tracer. The wakeup tracer needs a > facility that postpones the notifications, not one that prevents the > measurements because all its measurements takes place in the middle > of __schedule(). On the other hand, in some places, like in idle and > the console we need start stop functions that prevents the > measurements from being make. Like Joel already mentioned; you can use irq_work here.
[PATCH] media: meson: Add NULL check after the call to kmalloc()
If the kmalloc() return NULL, the NULL pointer dereference will occur.
new_ts->ts = ts;
Add exception check after the call to kmalloc() is made.
Signed-off-by: Austin Kim
---
drivers/staging/media/meson/vdec/vdec_helpers.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/media/meson/vdec/vdec_helpers.c
b/drivers/staging/media/meson/vdec/vdec_helpers.c
index f16948b..e7e56d5 100644
--- a/drivers/staging/media/meson/vdec/vdec_helpers.c
+++ b/drivers/staging/media/meson/vdec/vdec_helpers.c
@@ -206,6 +206,10 @@ void amvdec_add_ts_reorder(struct amvdec_session *sess,
u64 ts, u32 offset)
unsigned long flags;
new_ts = kmalloc(sizeof(*new_ts), GFP_KERNEL);
+ if (!new_ts) {
+ dev_err(sess->core->dev, "Failed to kmalloc()\n");
+ return;
+ }
new_ts->ts = ts;
new_ts->offset = offset;
--
2.6.2
[Patch V8 2/8] phy: tegra: xusb: Add usb3 port fake support on Tegra210
On Tegra210, usb2 only otg/peripheral ports dont work in device mode.
They need an assosciated usb3 port to work in device mode. Identify
an unused usb3 port and assign it as a fake USB3 port to USB2 only
port whose mode is otg/peripheral.
Based on work by BH Hsieh .
Signed-off-by: Nagarjuna Kristam
Acked-by: Thierry Reding
---
drivers/phy/tegra/xusb-tegra210.c | 56 +
drivers/phy/tegra/xusb.c | 65 +++
drivers/phy/tegra/xusb.h | 2 ++
3 files changed, 123 insertions(+)
diff --git a/drivers/phy/tegra/xusb-tegra210.c
b/drivers/phy/tegra/xusb-tegra210.c
index 0351c4a..8c31f03 100644
--- a/drivers/phy/tegra/xusb-tegra210.c
+++ b/drivers/phy/tegra/xusb-tegra210.c
@@ -50,6 +50,7 @@
#define XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP_SHIFT(x) ((x) * 5)
#define XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP_MASK(x) (0x7 << ((x) * 5))
#define XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP(x, v) (((v) & 0x7) << ((x) * 5))
+#define XUSB_PADCTL_SS_PORT_MAP_PORT_DISABLED 0x7
#define XUSB_PADCTL_ELPG_PROGRAM1 0x024
#define XUSB_PADCTL_ELPG_PROGRAM1_AUX_MUX_LP0_VCORE_DOWN (1 << 31)
@@ -944,6 +945,34 @@ static int tegra210_usb2_phy_power_on(struct phy *phy)
priv = to_tegra210_xusb_padctl(padctl);
+ if (port->usb3_port_fake != -1) {
+ value = padctl_readl(padctl, XUSB_PADCTL_SS_PORT_MAP);
+ value &= ~XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP_MASK(
+ port->usb3_port_fake);
+ value |= XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP(
+ port->usb3_port_fake, index);
+ padctl_writel(padctl, value, XUSB_PADCTL_SS_PORT_MAP);
+
+ value = padctl_readl(padctl, XUSB_PADCTL_ELPG_PROGRAM1);
+ value &= ~XUSB_PADCTL_ELPG_PROGRAM1_SSPX_ELPG_VCORE_DOWN(
+ port->usb3_port_fake);
+ padctl_writel(padctl, value, XUSB_PADCTL_ELPG_PROGRAM1);
+
+ usleep_range(100, 200);
+
+ value = padctl_readl(padctl, XUSB_PADCTL_ELPG_PROGRAM1);
+ value &= ~XUSB_PADCTL_ELPG_PROGRAM1_SSPX_ELPG_CLAMP_EN_EARLY(
+ port->usb3_port_fake);
+ padctl_writel(padctl, value, XUSB_PADCTL_ELPG_PROGRAM1);
+
+ usleep_range(100, 200);
+
+ value = padctl_readl(padctl, XUSB_PADCTL_ELPG_PROGRAM1);
+ value &= ~XUSB_PADCTL_ELPG_PROGRAM1_SSPX_ELPG_CLAMP_EN(
+ port->usb3_port_fake);
+ padctl_writel(padctl, value, XUSB_PADCTL_ELPG_PROGRAM1);
+ }
+
value = padctl_readl(padctl, XUSB_PADCTL_USB2_BIAS_PAD_CTL0);
value &= ~((XUSB_PADCTL_USB2_BIAS_PAD_CTL0_HS_SQUELCH_LEVEL_MASK <<
XUSB_PADCTL_USB2_BIAS_PAD_CTL0_HS_SQUELCH_LEVEL_SHIFT) |
@@ -1078,6 +1107,32 @@ static int tegra210_usb2_phy_power_off(struct phy *phy)
mutex_lock(&padctl->lock);
+ if (port->usb3_port_fake != -1) {
+ value = padctl_readl(padctl, XUSB_PADCTL_ELPG_PROGRAM1);
+ value |= XUSB_PADCTL_ELPG_PROGRAM1_SSPX_ELPG_CLAMP_EN_EARLY(
+ port->usb3_port_fake);
+ padctl_writel(padctl, value, XUSB_PADCTL_ELPG_PROGRAM1);
+
+ usleep_range(100, 200);
+
+ value = padctl_readl(padctl, XUSB_PADCTL_ELPG_PROGRAM1);
+ value |= XUSB_PADCTL_ELPG_PROGRAM1_SSPX_ELPG_CLAMP_EN(
+ port->usb3_port_fake);
+ padctl_writel(padctl, value, XUSB_PADCTL_ELPG_PROGRAM1);
+
+ usleep_range(250, 350);
+
+ value = padctl_readl(padctl, XUSB_PADCTL_ELPG_PROGRAM1);
+ value |= XUSB_PADCTL_ELPG_PROGRAM1_SSPX_ELPG_VCORE_DOWN(
+ port->usb3_port_fake);
+ padctl_writel(padctl, value, XUSB_PADCTL_ELPG_PROGRAM1);
+
+ value = padctl_readl(padctl, XUSB_PADCTL_SS_PORT_MAP);
+ value |= XUSB_PADCTL_SS_PORT_MAP_PORTX_MAP(port->usb3_port_fake,
+ XUSB_PADCTL_SS_PORT_MAP_PORT_DISABLED);
+ padctl_writel(padctl, value, XUSB_PADCTL_SS_PORT_MAP);
+ }
+
if (WARN_ON(pad->enable == 0))
goto out;
@@ -2052,6 +2107,7 @@ const struct tegra_xusb_padctl_soc
tegra210_xusb_padctl_soc = {
.ops = &tegra210_xusb_padctl_ops,
.supply_names = tegra210_xusb_padctl_supply_names,
.num_supplies = ARRAY_SIZE(tegra210_xusb_padctl_supply_names),
+ .need_fake_usb3_port = true,
};
EXPORT_SYMBOL_GPL(tegra210_xusb_padctl_soc);
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
index 2ea8497..b4b217e 100644
--- a/drivers/phy/tegra/xusb.c
+++ b/drivers/phy/tegra/xusb.c
@@ -800,9 +800,62 @@ static void __tegra_xusb_remove_ports(struct
tegra_xusb_padctl *padctl)
}
}
+static
[Patch V8 8/8] arm64: defconfig: Enable tegra XUDC driver
Enable support for Nvidia XUSB device mode controller driver. Signed-off-by: Nagarjuna Kristam --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 358b163..e9233df 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -600,6 +600,7 @@ CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y CONFIG_USB_RENESAS_USBHS_UDC=m CONFIG_USB_RENESAS_USB3=m +CONFIG_USB_TEGRA_XUDC=m CONFIG_TYPEC=m CONFIG_TYPEC_HD3SS3220=m CONFIG_MMC=y -- 2.7.4
[Patch V8 7/8] usb: gadget: Add UDC driver for tegra XUSB device mode controller
This patch adds UDC driver for tegra XUSB 3.0 device mode controller. XUSB device mode controller supports SS, HS and FS modes Based on work by: Mark Kuo Hui Fu Andrew Bresticker Signed-off-by: Nagarjuna Kristam Acked-by: Thierry Reding --- drivers/usb/gadget/udc/Kconfig | 12 + drivers/usb/gadget/udc/Makefile |1 + drivers/usb/gadget/udc/tegra-xudc.c | 3791 +++ 3 files changed, 3804 insertions(+) create mode 100644 drivers/usb/gadget/udc/tegra-xudc.c diff --git a/drivers/usb/gadget/udc/Kconfig b/drivers/usb/gadget/udc/Kconfig index d354036..0fe7577 100644 --- a/drivers/usb/gadget/udc/Kconfig +++ b/drivers/usb/gadget/udc/Kconfig @@ -441,6 +441,18 @@ config USB_GADGET_XILINX dynamically linked module called "udc-xilinx" and force all gadget drivers to also be dynamically linked. +config USB_TEGRA_XUDC + tristate "NVIDIA Tegra Superspeed USB 3.0 Device Controller" + depends on ARCH_TEGRA || COMPILE_TEST + depends on PHY_TEGRA_XUSB + select USB_CONN_GPIO + help +Enables NVIDIA Tegra USB 3.0 device mode controller driver. + +Say "y" to link the driver statically, or "m" to build a +dynamically linked module called "tegra_xudc" and force all +gadget drivers to also be dynamically linked. + source "drivers/usb/gadget/udc/aspeed-vhub/Kconfig" # diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile index 897f648..f6777e6 100644 --- a/drivers/usb/gadget/udc/Makefile +++ b/drivers/usb/gadget/udc/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_USB_BCM63XX_UDC) += bcm63xx_udc.o obj-$(CONFIG_USB_FSL_USB2) += fsl_usb2_udc.o fsl_usb2_udc-y := fsl_udc_core.o fsl_usb2_udc-$(CONFIG_ARCH_MXC)+= fsl_mxc_udc.o +obj-$(CONFIG_USB_TEGRA_XUDC) += tegra-xudc.o obj-$(CONFIG_USB_M66592) += m66592-udc.o obj-$(CONFIG_USB_R8A66597) += r8a66597-udc.o obj-$(CONFIG_USB_RENESAS_USB3) += renesas_usb3.o diff --git a/drivers/usb/gadget/udc/tegra-xudc.c b/drivers/usb/gadget/udc/tegra-xudc.c new file mode 100644 index 000..75fa2e1 --- /dev/null +++ b/drivers/usb/gadget/udc/tegra-xudc.c @@ -0,0 +1,3791 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * NVIDIA Tegra XUSB device mode controller + * + * Copyright (c) 2013-2019, NVIDIA CORPORATION. All rights reserved. + * Copyright (c) 2015, Google Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* XUSB_DEV registers */ +#define SPARAM 0x000 +#define SPARAM_ERSTMAX_MASK GENMASK(20, 16) +#define SPARAM_ERSTMAX(x) (((x) << 16) & SPARAM_ERSTMAX_MASK) +#define DB 0x004 +#define DB_TARGET_MASK GENMASK(15, 8) +#define DB_TARGET(x) (((x) << 8) & DB_TARGET_MASK) +#define DB_STREAMID_MASK GENMASK(31, 16) +#define DB_STREAMID(x) (((x) << 16) & DB_STREAMID_MASK) +#define ERSTSZ 0x008 +#define ERSTSZ_ERSTXSZ_SHIFT(x) ((x) * 16) +#define ERSTSZ_ERSTXSZ_MASK GENMASK(15, 0) +#define ERSTXBALO(x) (0x010 + 8 * (x)) +#define ERSTXBAHI(x) (0x014 + 8 * (x)) +#define ERDPLO 0x020 +#define ERDPLO_EHB BIT(3) +#define ERDPHI 0x024 +#define EREPLO 0x028 +#define EREPLO_ECS BIT(0) +#define EREPLO_SEGI BIT(1) +#define EREPHI 0x02c +#define CTRL 0x030 +#define CTRL_RUN BIT(0) +#define CTRL_LSE BIT(1) +#define CTRL_IE BIT(4) +#define CTRL_SMI_EVT BIT(5) +#define CTRL_SMI_DSE BIT(6) +#define CTRL_EWE BIT(7) +#define CTRL_DEVADDR_MASK GENMASK(30, 24) +#define CTRL_DEVADDR(x) (((x) << 24) & CTRL_DEVADDR_MASK) +#define CTRL_ENABLE BIT(31) +#define ST 0x034 +#define ST_RC BIT(0) +#define ST_IP BIT(4) +#define RT_IMOD0x038 +#define RT_IMOD_IMODI_MASK GENMASK(15, 0) +#define RT_IMOD_IMODI(x) ((x) & RT_IMOD_IMODI_MASK) +#define RT_IMOD_IMODC_MASK GENMASK(31, 16) +#define RT_IMOD_IMODC(x) (((x) << 16) & RT_IMOD_IMODC_MASK) +#define PORTSC 0x03c +#define PORTSC_CCS BIT(0) +#define PORTSC_PED BIT(1) +#define PORTSC_PR BIT(4) +#define PORTSC_PLS_SHIFT 5 +#define PORTSC_PLS_MASK GENMASK(8, 5) +#define PORTSC_PLS_U0 0x0 +#define PORTSC_PLS_U2 0x2 +#define PORTSC_PLS_U3 0x3 +#define PORTSC_PLS_DISABLED 0x4 +#define PORTSC_PLS_RXDETECT 0x5 +#define PORTSC_PLS_INACTIVE 0x6 +#define PORTSC_PLS_RESUME 0xf +#define PORTSC_PLS(x) (((x) << PORTSC_PLS_SHIFT) & PORTSC_PLS_MASK) +#define PORTSC_PS_SHIFT 10 +#define PORTSC_PS_MASK GENMASK(13, 10) +#define PORTSC_PS_UNDEFINED 0x0 +#define PORTSC_PS_FS 0x1 +#define PORTSC_PS_LS 0x2 +#define PORTSC_PS_HS 0x3 +#define PORTSC_PS_SS 0x4 +#define PORTSC_LWS BIT(16) +#define PORTSC_CSC BIT(17) +#define PORTSC_WRC BIT(19) +#define PORTSC_PRC BIT(21) +#define PORTSC_PLC BIT(22) +#define PORTSC_CEC BIT(23) +#define PORTSC_WPR BIT(30) +#define PORTSC_CHANGE_MASK (PORTSC_CSC | PORTSC_WRC | PORTSC_PRC | \ +PO
[Patch V8 5/8] arm64: tegra: Add xudc node for Tegra210
Tegra210 has one XUSB device mode controller, which can be operated
HS and SS modes. Add DT support for XUSB device mode controller.
Signed-off-by: Nagarjuna Kristam
Reviewed-by: JC Kuo
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 6597531..5de0b36 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -1203,6 +1203,25 @@
status = "disabled";
};
+ usb@700d {
+ compatible = "nvidia,tegra210-xudc";
+ reg = <0x0 0x700d 0x0 0x8000>,
+ <0x0 0x700d8000 0x0 0x1000>,
+ <0x0 0x700d9000 0x0 0x1000>;
+ reg-names = "base", "fpci", "ipfs";
+ interrupts = ;
+ clocks = <&tegra_car TEGRA210_CLK_XUSB_DEV>,
+<&tegra_car TEGRA210_CLK_XUSB_SS>,
+<&tegra_car TEGRA210_CLK_XUSB_SSP_SRC>,
+<&tegra_car TEGRA210_CLK_XUSB_HS_SRC>,
+<&tegra_car TEGRA210_CLK_XUSB_FS_SRC>;
+ clock-names = "dev", "ss", "ss_src", "hs_src", "fs_src";
+ power-domains = <&pd_xusbdev>, <&pd_xusbss>;
+ power-domain-names = "dev", "ss";
+ nvidia,xusb-padctl = <&padctl>;
+ status = "disabled";
+ };
+
mipi: mipi@700e3000 {
compatible = "nvidia,tegra210-mipi";
reg = <0x0 0x700e3000 0x0 0x100>;
--
2.7.4
[Patch V8 3/8] phy: tegra: xusb: Add vbus override support on Tegra210
Tegra XUSB device control driver needs to control vbus override
during its operations, add API for the support.
Signed-off-by: Nagarjuna Kristam
Acked-by: Thierry Reding
---
drivers/phy/tegra/xusb-tegra210.c | 57 +++
drivers/phy/tegra/xusb.c | 22 +++
drivers/phy/tegra/xusb.h | 2 ++
include/linux/phy/tegra/xusb.h| 4 ++-
4 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/tegra/xusb-tegra210.c
b/drivers/phy/tegra/xusb-tegra210.c
index 8c31f03..9e6f14b 100644
--- a/drivers/phy/tegra/xusb-tegra210.c
+++ b/drivers/phy/tegra/xusb-tegra210.c
@@ -65,6 +65,10 @@
#define XUSB_PADCTL_USB3_PAD_MUX_PCIE_IDDQ_DISABLE(x) (1 << (1 + (x)))
#define XUSB_PADCTL_USB3_PAD_MUX_SATA_IDDQ_DISABLE(x) (1 << (8 + (x)))
+#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPADX_CTL0(x) (0x080 + (x) * 0x40)
+#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL0_ZIP (1 << 18)
+#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL0_ZIN (1 << 22)
+
#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPADX_CTL1(x) (0x084 + (x) * 0x40)
#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_SHIFT 7
#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_MASK 0x3
@@ -227,6 +231,12 @@
#define XUSB_PADCTL_UPHY_USB3_PADX_ECTL6(x) (0xa74 + (x) * 0x40)
#define XUSB_PADCTL_UPHY_USB3_PAD_ECTL6_RX_EQ_CTRL_H_VAL 0xfcf01368
+#define XUSB_PADCTL_USB2_VBUS_ID 0xc60
+#define XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_VBUS_ON (1 << 14)
+#define XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_SHIFT 18
+#define XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_MASK 0xf
+#define XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_FLOATING 8
+
struct tegra210_xusb_fuse_calibration {
u32 hs_curr_level[4];
u32 hs_term_range_adj;
@@ -2016,6 +2026,51 @@ static const struct tegra_xusb_port_ops
tegra210_usb3_port_ops = {
.map = tegra210_usb3_port_map,
};
+static int tegra210_xusb_padctl_vbus_override(struct tegra_xusb_padctl *padctl,
+ bool status)
+{
+ u32 value;
+
+ dev_dbg(padctl->dev, "%s vbus override\n", status ? "set" : "clear");
+
+ value = padctl_readl(padctl, XUSB_PADCTL_USB2_VBUS_ID);
+
+ if (status) {
+ value |= XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_VBUS_ON;
+ value &= ~(XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_MASK <<
+ XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_SHIFT);
+ value |= XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_FLOATING <<
+XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_SHIFT;
+ } else
+ value &= ~XUSB_PADCTL_USB2_VBUS_ID_OVERRIDE_VBUS_ON;
+
+ padctl_writel(padctl, value, XUSB_PADCTL_USB2_VBUS_ID);
+
+ return 0;
+}
+
+static int tegra210_utmi_port_reset(struct phy *phy)
+{
+ struct tegra_xusb_padctl *padctl;
+ struct tegra_xusb_lane *lane;
+ u32 value;
+
+ lane = phy_get_drvdata(phy);
+ padctl = lane->pad->padctl;
+
+ value = padctl_readl(padctl,
+XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPADX_CTL0(lane->index));
+
+ if ((value & XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL0_ZIP) ||
+ (value & XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL0_ZIN)) {
+ tegra210_xusb_padctl_vbus_override(padctl, false);
+ tegra210_xusb_padctl_vbus_override(padctl, true);
+ return 1;
+ }
+
+ return 0;
+}
+
static int
tegra210_xusb_read_fuse_calibration(struct tegra210_xusb_fuse_calibration
*fuse)
{
@@ -2078,6 +2133,8 @@ static const struct tegra_xusb_padctl_ops
tegra210_xusb_padctl_ops = {
.remove = tegra210_xusb_padctl_remove,
.usb3_set_lfps_detect = tegra210_usb3_set_lfps_detect,
.hsic_set_idle = tegra210_hsic_set_idle,
+ .vbus_override = tegra210_xusb_padctl_vbus_override,
+ .utmi_port_reset = tegra210_utmi_port_reset,
};
static const char * const tegra210_xusb_padctl_supply_names[] = {
diff --git a/drivers/phy/tegra/xusb.c b/drivers/phy/tegra/xusb.c
index b4b217e..bf4b008 100644
--- a/drivers/phy/tegra/xusb.c
+++ b/drivers/phy/tegra/xusb.c
@@ -1121,6 +1121,28 @@ int tegra_xusb_padctl_usb3_set_lfps_detect(struct
tegra_xusb_padctl *padctl,
}
EXPORT_SYMBOL_GPL(tegra_xusb_padctl_usb3_set_lfps_detect);
+int tegra_xusb_padctl_set_vbus_override(struct tegra_xusb_padctl *padctl,
+ bool val)
+{
+ if (padctl->soc->ops->vbus_override)
+ return padctl->soc->ops->vbus_override(padctl, val);
+
+ return -ENOTSUPP;
+}
+EXPORT_SYMBOL_GPL(tegra_xusb_padctl_set_vbus_override);
+
+int tegra_phy_xusb_utmi_port_reset(struct phy *phy)
+{
+ struct tegra_xusb_lane *lane = phy_get_drvdata(phy);
+ struct tegra_xusb_padctl *padctl = lane->pad->padctl;
+
+ if (padctl->soc->ops->utmi_port_reset)
+ return padctl->soc->ops->utmi_port_reset(phy);
+
+ return -ENOTSUPP;
+}
+EXPORT_SYMBOL_GPL(tegra_phy_xusb_utmi_port
[Patch V8 4/8] dt-bindings: usb: Add NVIDIA Tegra XUSB device mode controller binding
Add device-tree binding documentation for the XUSB device mode controller
present on Tegra210 SoC. This controller supports the USB 3.0
specification.
Signed-off-by: Nagarjuna Kristam
Reviewed-by: JC Kuo
Reviewed-by: Rob Herring
Acked-by: Thierry Reding
---
.../devicetree/bindings/usb/nvidia,tegra-xudc.txt | 110 +
1 file changed, 110 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt
new file mode 100644
index 000..ce15e26
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt
@@ -0,0 +1,110 @@
+Device tree binding for NVIDIA Tegra XUSB device mode controller (XUDC)
+===
+
+The Tegra XUDC controller supports both USB 2.0 HighSpeed/FullSpeed and
+USB 3.0 SuperSpeed protocols.
+
+Required properties:
+
+- compatible: For Tegra210, must contain "nvidia,tegra210-xudc".
+- reg: Must contain the base and length of all registers used.
+- interrupts: Must contain the XUSB device interrupt.
+- clocks: Must contain an entry for all clocks used.
+ See ../clock/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+ - dev: Clock to enable core XUSB dev clock.
+ - ss: Clock to enable XUSB super speed clock.
+ - ss_src: Clock to enable XUSB super speed dev clock.
+ - hs_src: Clock to enable XUSB high speed dev clock.
+ - fs_src: Clock to enable XUSB full speed dev clock.
+- power-domains: A list of PM domain specifiers that reference each
power-domain
+ used by the XUSB device mode controller. This list must comprise of a
specifier
+ for the XUSBA and XUSBB power-domains. See ../power/power_domain.txt and
+ ../arm/tegra/nvidia,tegra20-pmc.txt for details.
+- power-domain-names: A list of names that represent each of the specifiers in
+ the 'power-domains' property. Must include 'ss' and 'dev'.
+- nvidia,xusb-padctl: phandle to the XUSB pad controller that is used to
+ configure the USB pads used by the XUDC controller.
+- phys: Must contain an entry for each entry in phy-names.
+ See ../phy/phy-bindings.txt for details.
+- phy-names: Should include an entry for each PHY used by the controller.
+ Names must be "usb2", and "usb3" if support SuperSpeed device mode.
+ - "usb3" phy, SuperSpeed (SSTX+/SSTX-/SSRX+/SSRX-) data lines.
+ - "usb2" phy, USB 2.0 (D+/D-) data lines.
+
+For Tegra210:
+- reg-names: Must include the following entries:
+ - base: XUSB device controller registers.
+ - fpci: XUSB device PCI Config registers.
+ - ipfs: XUSB device registers.
+- avddio-usb-supply: PCIe/USB3 analog logic power supply. Must supply 1.05 V.
+- hvdd-usb-supply: USB controller power supply. Must supply 3.3 V.
+
+
+Optional properties:
+
+- usb-role-switch: boolean property to indicate use of USB Role Switch driver.
+
+Sub-nodes:
+--
+- The port would be added as subnode if use "usb-role-switch" property.
+ see graph.txt.
+
+Example:
+
+ pmc: pmc@7000e400 {
+ compatible = "nvidia,tegra210-pmc";
+ reg = <0x0 0x7000e400 0x0 0x400>;
+ clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
+ clock-names = "pclk", "clk32k_in";
+
+ powergates {
+ pd_xusbss: xusba {
+ clocks = <&tegra_car TEGRA210_CLK_XUSB_SS>;
+ resets = <&tegra_car 156>;
+ #power-domain-cells = <0>;
+ };
+
+ pd_xusbdev: xusbb {
+ clocks = <&tegra_car TEGRA210_CLK_XUSB_DEV>;
+ resets = <&tegra_car 95>;
+ #power-domain-cells = <0>;
+ };
+ };
+ };
+
+ usb@700d {
+ compatible = "nvidia,tegra210-xudc";
+ reg = <0x0 0x700d 0x0 0x8000>,
+ <0x0 0x700d8000 0x0 0x1000>,
+ <0x0 0x700d9000 0x0 0x1000>;
+ reg-names = "base", "fpci", "ipfs";
+
+ interrupts = ;
+
+ clocks = <&tegra_car TEGRA210_CLK_XUSB_DEV>,
+<&tegra_car TEGRA210_CLK_XUSB_SS>,
+<&tegra_car TEGRA210_CLK_XUSB_SSP_SRC>,
+<&tegra_car TEGRA210_CLK_XUSB_HS_SRC>,
+<&tegra_car TEGRA210_CLK_XUSB_FS_SRC>;
+ clock-names = "dev", "ss", "ss_src", "hs_src", "fs_src";
+
+ power-domains = <&pd_xusbdev>, <&pd_xusbss>;
+ power-domain-names = "dev", "ss";
+
+ nvidia,xusb-padctl = <&padctl>;
+
+ phys = <µ_b>;
+ phy-names = "usb2";
+
+ avddio-usb-supply = <&
[Patch V8 1/8] phy: tegra: xusb: Add XUSB dual mode support on Tegra210
Configure the port capabilities based on usb_dr_mode settings. Based on work by JC Kuo . Signed-off-by: Nagarjuna Kristam Reviewed-by: JC Kuo Acked-by: Thierry Reding --- drivers/phy/tegra/xusb-tegra210.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/drivers/phy/tegra/xusb-tegra210.c b/drivers/phy/tegra/xusb-tegra210.c index 0c0df68..0351c4a 100644 --- a/drivers/phy/tegra/xusb-tegra210.c +++ b/drivers/phy/tegra/xusb-tegra210.c @@ -39,7 +39,10 @@ #define XUSB_PADCTL_USB2_PAD_MUX_USB2_BIAS_PAD_XUSB 0x1 #define XUSB_PADCTL_USB2_PORT_CAP 0x008 +#define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_DISABLED(x) (0x0 << ((x) * 4)) #define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_HOST(x) (0x1 << ((x) * 4)) +#define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_DEVICE(x) (0x2 << ((x) * 4)) +#define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_OTG(x) (0x3 << ((x) * 4)) #define XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_MASK(x) (0x3 << ((x) * 4)) #define XUSB_PADCTL_SS_PORT_MAP 0x014 @@ -64,6 +67,7 @@ #define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPADX_CTL1(x) (0x084 + (x) * 0x40) #define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_SHIFT 7 #define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_MASK 0x3 +#define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_VAL 0x1 #define XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_FIX18 (1 << 6) #define XUSB_PADCTL_USB2_OTG_PADX_CTL0(x) (0x088 + (x) * 0x40) @@ -957,7 +961,14 @@ static int tegra210_usb2_phy_power_on(struct phy *phy) value = padctl_readl(padctl, XUSB_PADCTL_USB2_PORT_CAP); value &= ~XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_MASK(index); - value |= XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_HOST(index); + if (port->mode == USB_DR_MODE_UNKNOWN) + value |= XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_DISABLED(index); + else if (port->mode == USB_DR_MODE_PERIPHERAL) + value |= XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_DEVICE(index); + else if (port->mode == USB_DR_MODE_HOST) + value |= XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_HOST(index); + else if (port->mode == USB_DR_MODE_OTG) + value |= XUSB_PADCTL_USB2_PORT_CAP_PORTX_CAP_OTG(index); padctl_writel(padctl, value, XUSB_PADCTL_USB2_PORT_CAP); value = padctl_readl(padctl, XUSB_PADCTL_USB2_OTG_PADX_CTL0(index)); @@ -989,7 +1000,12 @@ static int tegra210_usb2_phy_power_on(struct phy *phy) XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPADX_CTL1(index)); value &= ~(XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_MASK << XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_SHIFT); - value |= XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_FIX18; + if (port->mode == USB_DR_MODE_HOST) + value |= XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_FIX18; + else + value |= + XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_VAL << + XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPAD_CTL1_VREG_LEV_SHIFT; padctl_writel(padctl, value, XUSB_PADCTL_USB2_BATTERY_CHRG_OTGPADX_CTL1(index)); -- 2.7.4
[Patch V8 6/8] arm64: tegra: Enable xudc on Jetson TX1
Enable XUSB device mode driver for USB0 slot on Jetson TX1.
Signed-off-by: Nagarjuna Kristam
Reviewed-by: JC Kuo
---
arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 31 +-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
index a7dc319..6aba1ba 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
@@ -1362,7 +1362,7 @@
status = "okay";
lanes {
- usb2-0 {
+ micro_b: usb2-0 {
nvidia,function = "xusb";
status = "okay";
};
@@ -1483,6 +1483,21 @@
vmmc-supply = <&vdd_3v3_sd>;
};
+ usb@700d {
+ status = "okay";
+ phys = <µ_b>;
+ phy-names = "usb2";
+ avddio-usb-supply = <&vdd_3v3_sys>;
+ hvdd-usb-supply = <&vdd_1v8>;
+ usb-role-switch;
+
+ port {
+ usb_role_switch: endpoint {
+ remote-endpoint = <&usb_b_conn_ep>;
+ };
+ };
+ };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -1641,4 +1656,18 @@
linux,code = ;
};
};
+
+ usb_type_b: connector {
+ compatible = "linux,usb-conn-gpio", "gpio-usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ vbus-gpio = <&gpio TEGRA_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
+
+ port {
+ usb_b_conn_ep: endpoint {
+ remote-endpoint = <&usb_role_switch>;
+ };
+ };
+ };
+
};
--
2.7.4
[Patch V8 0/8] Tegra XUSB gadget driver support
This is the seventh version of series "Tegra XUSB gadget driver support" Patches 1-3 are phy driver changes to add support for device mode. Patches 4-7 are changes related to XUSB device mode controller driver. Patch 8 is to enable XUDC driver in defconfig Test Steps(USB 2.0): - Enable "USB Gadget precomposed configurations" in defconfig - Build, flash and boot Jetson TX1 - Connect Jetson TX1 and Ubuntu device using USB A to Micro B cable - After boot on Jetson TX1 terminal usb0 network device should be enumerated - Assign static ip to usb0 on Jetson TX1 and corresponding net device on ubuntu - Run ping test and transfer test(used scp) to check data transfer communication SS mode is verified by enabling Type A port as peripheral This patch series is dependent on [1] for functionality of hot plug triggers to xudc driver. [1] https://patchwork.kernel.org/cover/11120723/ --- v8: * Patches 1,2,3,4,5,8 - No changes * Patch 6 has update on compatible string as per change done in [1]. * Patch 7 has issue fix, where device mode didnot got enabled after resume from suspend. --- v7: * Patches 1,2,3,4,5,6,8 - No changes * Patch 7 - Comments from Balbi and Chunfun adrresed. Added COMPILE_TEST in Kconfig and updated dependencies. --- v6: * Patches 1,2,3,7,8 - No changes * Patch 4,5,6 - Comments from Rob addressed, updated usb connector driver compatibility string. --- v5: * Patches 1-3 - Commit subject updated as per inputs from Thierry * Patch 4 - Added reg-names used on Tegra210 in the bindings doc * Enabled xudc driver as module instead of part of kernel in patch 8 * Patched 5-8 - No changes --- v4: * patch 1 - no changes * corrected companion device search based on inputs from Thierry in patch 2 * removed unneeded dev variable and corrected value read in tegra210_utmi_port_reset function in patch 3 * dt binding doc and dtb files are corrected for alignments. Replaced extcon-usb-gpio with usb role switch. * Added support for USB role switch instead of extcon-usb-gpio and other minor comments as suggested by Chunfeng. * Enabled xudc driver as module instead of part of kernel in patch 8 --- V3: * Rebased patch 1 to top of tree. * Fixed bug in patch 2, where xudc interrupts dont get generated if USB host mode fails to probe. Moved fake port detection logic to generic xusb.c. fake usb port data is updated based on soc flag need_fake_usb3_port. * Added extra lines whereever necessary to make code more readable in patch 3 and 7. * dt binding doc is corrected for typos and extcon references. Also added details for clocks and removed xusb_ references to clock and power-domain names and accordingly patch 5 is updated. * removed avdd-pll-utmip-supply in patch 6, as its now part of padctl driver. * Patch 8 has no changes. --- V2: * Patches 1-3 are new patches in this series, which splits unified features patch to speprated features and removes need of port-fake entry in DT. * Patch 4 is re-arragend dt-bindings patch which incorporates previous patch comments to sort DT entries alphabetically, addresses name changes and PM domain details added. * Patch 5-6 are re-arranged DT patches with major changes - sort entries alphabetically, and adds clock names. * Patch 7 is UDC driver tegra XUSB device mode controller with major changes - remove un-used module params, lockinng for device_mode flag, moving un-needed info logs to debug level, making changes feature flag dependent rather than SOC based macros and other error handling in probe. * Patch 8 has no changes. Nagarjuna Kristam (8): phy: tegra: xusb: Add XUSB dual mode support on Tegra210 phy: tegra: xusb: Add usb3 port fake support on Tegra210 phy: tegra: xusb: Add vbus override support on Tegra210 dt-bindings: usb: Add NVIDIA Tegra XUSB device mode controller binding arm64: tegra: Add xudc node for Tegra210 arm64: tegra: Enable xudc on Jetson TX1 usb: gadget: Add UDC driver for tegra XUSB device mode controller arm64: defconfig: Enable tegra XUDC driver .../devicetree/bindings/usb/nvidia,tegra-xudc.txt | 110 + arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 31 +- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 19 + arch/arm64/configs/defconfig |1 + drivers/phy/tegra/xusb-tegra210.c | 133 +- drivers/phy/tegra/xusb.c | 87 + drivers/phy/tegra/xusb.h |4 + drivers/usb/gadget/udc/Kconfig | 12 + drivers/usb/gadget/udc/Makefile|1 + drivers/usb/gadget/udc/tegra-xudc.c| 3791 include/linux/phy/tegra/xusb.h |4 +- 11 files changed, 4189 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.txt create mode 100644 drivers/usb/gadget/udc/tegra-xudc.c -- 2.7.4
[PATCH -next] ASoC: ep93xx: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
sound/soc/cirrus/ep93xx-ac97.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/cirrus/ep93xx-ac97.c b/sound/soc/cirrus/ep93xx-ac97.c
index 84c967f..e21eaa1 100644
--- a/sound/soc/cirrus/ep93xx-ac97.c
+++ b/sound/soc/cirrus/ep93xx-ac97.c
@@ -362,7 +362,6 @@ static const struct snd_soc_component_driver
ep93xx_ac97_component = {
static int ep93xx_ac97_probe(struct platform_device *pdev)
{
struct ep93xx_ac97_info *info;
- struct resource *res;
int irq;
int ret;
@@ -370,8 +369,7 @@ static int ep93xx_ac97_probe(struct platform_device *pdev)
if (!info)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- info->regs = devm_ioremap_resource(&pdev->dev, res);
+ info->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(info->regs))
return PTR_ERR(info->regs);
--
2.7.4
Re: [PATCH] net/skbuff: silence warnings under memory pressure
On Wed 04-09-19 16:00:42, Sergey Senozhatsky wrote: > On (09/04/19 15:41), Sergey Senozhatsky wrote: > > But the thing is different in case of dump_stack() + show_mem() + > > some other output. Because now we ratelimit not a single printk() line, > > but hundreds of them. The ratelimit becomes - 10 * $$$ lines in 5 seconds > > (IOW, now we talk about thousands of lines). > > And on devices with slow serial consoles this can be somewhat close to > "no ratelimit". *Suppose* that warn_alloc() adds 700 lines each time. > Within 5 seconds we can call warn_alloc() 10 times, which will add 7000 > lines to the logbuf. If printk() can evict only 6000 lines in 5 seconds > then we have a growing number of pending logbuf messages. Yes, ratelimit is problematic when the ratelimited operation is slow. I guess that is a well known problem and we would need to rework both the api and the implementation to make it work in those cases as well. Essentially we need to make the ratelimit act as a gatekeeper to an operation section - something like a critical section except you can tolerate more code executions but not too many. So effectively start_throttle(rate, number); /* here goes your operation */ end_throttle(); one operation is not considered done until the whole section ends. Or something along those lines. In this particular case we can increase the rate limit parameters of course but I think that longterm we need a better api. -- Michal Hocko SUSE Labs
Re: [PATCH] i2c: cht-wc: drop check because i2c_unregister_device() is NULL safe
Hi,
On 03-09-19 19:52, Wolfram Sang wrote:
On Tue, Aug 20, 2019 at 05:34:40PM +0200, Wolfram Sang wrote:
No need to check the argument of i2c_unregister_device() because the
function itself does it.
Signed-off-by: Wolfram Sang
---
Hans, are you OK with this change?
Yes this is fine by me:
Acked-by: Hans de Goede
Regards,
Hans
Build tested only, buildbot is happy, too.
Please apply to your tree.
drivers/i2c/busses/i2c-cht-wc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cht-wc.c b/drivers/i2c/busses/i2c-cht-wc.c
index 66af44bfa67d..3e2608a65c06 100644
--- a/drivers/i2c/busses/i2c-cht-wc.c
+++ b/drivers/i2c/busses/i2c-cht-wc.c
@@ -363,8 +363,7 @@ static int cht_wc_i2c_adap_i2c_remove(struct
platform_device *pdev)
{
struct cht_wc_i2c_adap *adap = platform_get_drvdata(pdev);
- if (adap->client)
- i2c_unregister_device(adap->client);
+ i2c_unregister_device(adap->client);
i2c_del_adapter(&adap->adapter);
irq_domain_remove(adap->irq_domain);
--
2.20.1
Re: [PATCH v5 1/2] mm: Allow the page cache to allocate large pages
On Tue 03-09-19 21:30:30, William Kucharski wrote: > > > > On Sep 3, 2019, at 5:57 AM, Michal Hocko wrote: > > > > On Mon 02-09-19 03:23:40, William Kucharski wrote: > >> Add an 'order' argument to __page_cache_alloc() and > >> do_read_cache_page(). Ensure the allocated pages are compound pages. > > > > Why do we need to touch all the existing callers and change them to use > > order 0 when none is actually converted to a different order? This just > > seem to add a lot of code churn without a good reason. If anything I > > would simply add __page_cache_alloc_order and make __page_cache_alloc > > call it with order 0 argument. > > All the EXISTING code in patch [1/2] is changed to call it with an order > of 0, as you would expect. > > However, new code in part [2/2] of the patch calls it with an order of > HPAGE_PMD_ORDER, as it seems cleaner to have those routines operate on > a page, regardless of the order of the page desired. > > I certainly can change this as you request, but once again the question > is whether "page" should MEAN "page" regardless of the order desired, > or whether the assumption will always be "page" means base PAGESIZE. > > Either approach works, but what is the semantic we want going forward? I do not have anything against handling page as compound, if that is the question. All I was interested in whether adding a new helper to _allocate_ the comound page wouldn't be easier than touching all existing __page_cache_alloc users. -- Michal Hocko SUSE Labs
Re: [GIT PULL 2/3] ARM: samsung: mach for v5.4
On Tue, 3 Sep 2019 at 19:32, Arnd Bergmann wrote: > > On Wed, Aug 21, 2019 at 9:52 AM Krzysztof Kozlowski wrote: > > On Fri, 16 Aug 2019 at 18:30, Krzysztof Kozlowski wrote: > > > > > > > Linus Walleij (1): > > > ARM: samsung: Include GPIO driver header > > > > > > Pankaj Dubey (1): > > > ARM: exynos: Enable exynos-chipid driver > > > > This last patch should be dropped so I will rework the pull request > > and send later v2. Please ignore it for now. > > I don't see the v2 yet. Are you still planning to send it? Yes, I have two more patches so I plan incremental pull today or tomorrow. Best regards, Krzysztof
[PATCH v2] USB: dummy-hcd: fix power budget for SuperSpeed mode
The power budget for SuperSpeed mode should be 900 mA according to USB3.0 specification. If the max power consumption of SuperSpeed device is larger than 500 mA, insufficient available bus power error happens in usb_choose_configuration function when the device connects to dummy hcd. Signed-off-by: Jacky Cao --- Changes in v2: - Fix whitespace damage drivers/usb/gadget/udc/dummy_hcd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/dummy_hcd.c b/drivers/usb/gadget/udc/dummy_hcd.c index f04e91e..a373f49 100644 --- a/drivers/usb/gadget/udc/dummy_hcd.c +++ b/drivers/usb/gadget/udc/dummy_hcd.c @@ -50,6 +50,7 @@ #define DRIVER_VERSION "02 May 2005" #define POWER_BUDGET 500 /* in mA; use 8 for low-power port testing */ +#define POWER_BUDGET_3_0 900 /* in mA */ static const char driver_name[] = "dummy_hcd"; static const char driver_desc[] = "USB Host+Gadget Emulator"; @@ -2439,7 +2440,7 @@ static int dummy_start_ss(struct dummy_hcd *dum_hcd) dum_hcd->rh_state = DUMMY_RH_RUNNING; dum_hcd->stream_en_ep = 0; INIT_LIST_HEAD(&dum_hcd->urbp_list); - dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET; + dummy_hcd_to_hcd(dum_hcd)->power_budget = POWER_BUDGET_3_0; dummy_hcd_to_hcd(dum_hcd)->state = HC_STATE_RUNNING; dummy_hcd_to_hcd(dum_hcd)->uses_new_polling = 1; #ifdef CONFIG_USB_OTG -- 2.7.4
Re: [PATCH v2] mmc: tegra: Implement enable_dma() to set dma_mask
On 16/08/19 2:16 AM, Nicolin Chen wrote:
> On Thu, Aug 15, 2019 at 02:48:20PM +0300, Adrian Hunter wrote:
>> On 14/08/19 3:57 AM, Nicolin Chen wrote:
>>> [ Integrated the change and commit message made by Thierry Reding ]
>>>
>>> The SDHCI controller found in early Tegra SoCs (from Tegra20 through
>>> Tegra114) used an AHB interface to the memory controller, which allowed
>>> only 32 bits of memory to be addressed.
>>>
>>> Starting with Tegra124, this limitation was removed by making the SDHCI
>>> controllers native MCCIF clients, which means that they got increased
>>> bandwidth and better arbitration to the memory controller as well as an
>>> address range extended to 40 bits, out of which only 34 were actually
>>> used (bits 34-39 are tied to 0 in the controller).
>>>
>>> For Tegra186, all of the 40 bits can be used; For Tegra194, 39-bit can
>>> be used.
>>>
>>> So far, sdhci-tegra driver has been relying on sdhci core to configure
>>> the DMA_BIT_MASK between 32-bit or 64-bit, using one of quirks2 flags:
>>> SDHCI_QUIRK2_BROKEN_64_BIT_DMA. However, there is a common way, being
>>> mentioned in sdhci.c file, to set dma_mask via enable_dma() callback in
>>> the device driver directly.
>>>
>>> So this patch implements an enable_dma() callback in the sdhci-tegra,
>>> in order to set an accurate DMA_BIT_MASK, other than just 32/64 bits.
>>
>> Is there a reason this cannot be done at probe time?
>
> It's supposed to be done at probe() time. But sdhci_setup_host()
> does both 32-bit/64-bit dma_mask setting and dma_alloc(), so if
> the dma_mask isn't correctly set inside sdhci_setup_host(), the
> allocation would fall to a 64-bit IOVA range that hardware does
> not support -- smmu error would happen and crash the system. On
> the other hand, ->enable_dma() is called in that function right
> after 32-bit/64-bit dma_mask setting. Or is there any other way
> of adding to probe() that I am missing here?
Hmmm. Maybe we should clean that up a bit. What do about this:
From: Adrian Hunter
Date: Wed, 4 Sep 2019 11:28:51 +0300
Subject: [PATCH] mmc: sdhci: Let drivers define their DMA mask
Add host operation ->set_dma_mask() so that drivers can define their own
DMA masks.
Signed-off-by: Adrian Hunter
---
drivers/mmc/host/sdhci.c | 12
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 66c2cf89ee22..43d32ba63ff5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3756,18 +3756,14 @@ int sdhci_setup_host(struct sdhci_host *host)
host->flags &= ~SDHCI_USE_ADMA;
}
- /*
-* It is assumed that a 64-bit capable device has set a 64-bit DMA mask
-* and *must* do 64-bit DMA. A driver has the opportunity to change
-* that during the first call to ->enable_dma(). Similarly
-* SDHCI_QUIRK2_BROKEN_64_BIT_DMA must be left to the drivers to
-* implement.
-*/
if (sdhci_can_64bit_dma(host))
host->flags |= SDHCI_USE_64_BIT_DMA;
if (host->flags & (SDHCI_USE_SDMA | SDHCI_USE_ADMA)) {
- ret = sdhci_set_dma_mask(host);
+ if (host->ops->set_dma_mask)
+ ret = host->ops->set_dma_mask(host);
+ else
+ ret = sdhci_set_dma_mask(host);
if (!ret && host->ops->enable_dma)
ret = host->ops->enable_dma(host);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 81e23784475a..a9ab2deaeb45 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -623,6 +623,7 @@ struct sdhci_ops {
u32 (*irq)(struct sdhci_host *host, u32 intmask);
int (*enable_dma)(struct sdhci_host *host);
+ int (*set_dma_mask)(struct sdhci_host *host);
unsigned int(*get_max_clock)(struct sdhci_host *host);
unsigned int(*get_min_clock)(struct sdhci_host *host);
/* get_timeout_clock should return clk rate in unit of Hz */
--
2.17.1
[PATCH -next] ASoC: sirf-audio: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot Signed-off-by: YueHaibing --- sound/soc/codecs/sirf-audio-codec.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/sound/soc/codecs/sirf-audio-codec.c b/sound/soc/codecs/sirf-audio-codec.c index 9009a74..a061d78 100644 --- a/sound/soc/codecs/sirf-audio-codec.c +++ b/sound/soc/codecs/sirf-audio-codec.c @@ -459,7 +459,6 @@ static int sirf_audio_codec_driver_probe(struct platform_device *pdev) int ret; struct sirf_audio_codec *sirf_audio_codec; void __iomem *base; - struct resource *mem_res; sirf_audio_codec = devm_kzalloc(&pdev->dev, sizeof(struct sirf_audio_codec), GFP_KERNEL); @@ -468,8 +467,7 @@ static int sirf_audio_codec_driver_probe(struct platform_device *pdev) platform_set_drvdata(pdev, sirf_audio_codec); - mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - base = devm_ioremap_resource(&pdev->dev, mem_res); + base = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(base)) return PTR_ERR(base); -- 2.7.4
Re: [GIT PULL 1/3] soc: samsung: Exynos for v5.4
On Tue, 3 Sep 2019 at 19:21, Arnd Bergmann wrote: > > On Thu, Aug 22, 2019 at 8:35 PM Krzysztof Kozlowski wrote: > > On Wed, Aug 21, 2019 at 09:51:09AM +0200, Krzysztof Kozlowski wrote: > > > On Fri, 16 Aug 2019 at 18:30, Krzysztof Kozlowski wrote: > > > > > > > > The following changes since commit > > > > 5f9e832c137075045d15cd6899ab0505cfb2ca4b: > > > > > > > > Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) > > > > > > > > are available in the Git repository at: > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git > > > > tags/samsung-drivers-5.4 > > > > > > > > for you to fetch changes up to 40d8aff614f71ab3cab20785b4f213e3802d4e87: > > > > > > > > soc: samsung: chipid: Convert exynos-chipid driver to use the regmap > > > > API (2019-08-15 20:25:25 +0200) > > > > > > > > > > > > Samsung soc drivers changes for v5.4 > > > > > > > > Add Exynos Chipid driver for identification of product IDs and SoC > > > > revisions. The driver also exposes chipid regmap, later to be used by > > > > Exynos Adaptive Supply Voltage driver (adjusting voltages to different > > > > revisions of same SoC). > > > > > > It turns out that it brings troubles (code is executed on every > > > platform polluting logs because it is an initcall, not a driver) so > > > Sylwester (submitter) asked to skip the submission. > > > > > > Please ignore the pull request. > > > > I talked with Sylwester and Bartlomiej who contributed the chipid driver > > and they provided small incremental fixes. The driver is still useful > > and in the future it will be expanded towards AVS. Therefore please pull > > it or optionally wait a week and I will send incremental pull request > > with fixes. > > Pulled into arm/drivers for now. > > I have drafted a related patch recently, regarding the related > arch/arm/plat-samsung/cpu.c file. This is part of a longer series > I'm working on, see https://pastebin.com/ZqeU3Mth for the > current version of this patch. You can then also adjust the include path in arch/arm/mach-exynos/Makefile. > The observation is that mach-exynos > is almost completely independent of plat-samsung these days, and my > patch removes the last obstacle from separating the two. I have > another set of patches to do the same for mach-s5pv210 (which shares > half of its pm.c with plat-samsung, but nothing else). Great! Best regards, Krzysztof
[PATCH -next] ASoC: tegra: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot Signed-off-by: YueHaibing --- sound/soc/tegra/tegra30_ahub.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/sound/soc/tegra/tegra30_ahub.c b/sound/soc/tegra/tegra30_ahub.c index 9523812..635eacb 100644 --- a/sound/soc/tegra/tegra30_ahub.c +++ b/sound/soc/tegra/tegra30_ahub.c @@ -511,7 +511,7 @@ static int tegra30_ahub_probe(struct platform_device *pdev) const struct tegra30_ahub_soc_data *soc_data; struct reset_control *rst; int i; - struct resource *res0, *res1; + struct resource *res0; void __iomem *regs_apbif, *regs_ahub; int ret = 0; @@ -587,8 +587,7 @@ static int tegra30_ahub_probe(struct platform_device *pdev) } regcache_cache_only(ahub->regmap_apbif, true); - res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1); - regs_ahub = devm_ioremap_resource(&pdev->dev, res1); + regs_ahub = devm_platform_ioremap_resource(pdev, 1); if (IS_ERR(regs_ahub)) return PTR_ERR(regs_ahub); -- 2.7.4
Re: [virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
>>> For some reason, I am not seeing this work as I would have expected >>> but I don't have solid reasoning to share yet. It could be simply >>> because I am putting my hook at the wrong place. I will continue >>> investigating this. >>> >>> In any case, I may be over complicating things here, so please let me >>> if there is a better way to do this. >> I have already been demonstrating the "better way" I think there is to >> do this. I will push v7 of it early next week unless there is some >> other feedback. By putting the bit in the page and controlling what >> comes into and out of the lists it makes most of this quite a bit >> easier. The only limitation is you have to modify where things get >> placed in the lists so you don't create a "vapor lock" that would >> stall the feed of pages into the reporting engine. >> >>> If this overhead is not significant we can probably live with it. >> You have bigger issues you still have to overcome as I recall. Didn't >> you still need to sort out hotplu > > For memory hotplug, my impression is that it should > not be a blocker for taking the first step (in case we do decide to > go ahead with this approach). Another reason why I am considering > this as future work is that memory hot(un)plug is still under > development and requires fixing. (Specifically, issue such as zone > shrinking which will directly impact the bitmap approach is still > under discussion). Memory hotplug is way more reliable than memory unplug - however, but both are used in production. E.g. the zone shrinking you mention is something that is not "optimal", but works in most scenarios. So both features are rather in a "production/fixing" stage than a pure "development" stage. However, I do agree that memory hot(un)plug is not something high-priority for free page hinting in the first shot. If it works out of the box (Alexander's approach) - great - if not it is just one additional scenario where free page hinting might not be optimal yet (like vfio where we can't use it completely right now). After all, most virtual environment (under KVM) I am aware of don't use DIMM-base memory hot(un)plug at all. The important part is that it will not break when memory is added/removed. > >> g and a sparse map with a wide span >> in a zone? Without those resolved the bitmap approach is still a no-go >> regardless of performance. > > For sparsity, the memory wastage should not be significant as I > am tracking pages on the granularity of (MAX_ORDER - 2) and maintaining > the bitmaps on a per-zone basis (which was not the case earlier). To handle sparsity one would have to have separate bitmaps for each section. Roughly 64 bit per 128MB section. Scanning the scattered bitmap would get more expensive. Of course, one could have a hierarchical bitmap to speed up the search etc. But again, I think we should have a look how much of an issue sparse zones/nodes actually are in virtual machines (KVM). The setups I am aware of minimize sparsity (e.g., QEMU will place DIMMs consecutively in memory, only aligning to e.g, 128MB on x86 if required). Usually all memory in VMs is onlined to the NORMAL zone (except special cases of course). The only "issue" would be if you start mixing DIMMs of different nodes when hotplugging memory. The overhead for 1bit per 2MB could be almost neglectable in most setups. But I do agree that for the bitmap-based approach there might be more scenarios where you'd rather not want to use free page hinting and instead disable it. > > However, if you do consider this as a block I will think about it and try to > fix it. > In the worst case, if I don't find a solution I will add this as a known > limitation > for this approach in my cover. > >> - Alex -- Thanks, David / dhildenb
Re: Bug?: unlink cause btrfs error but other fs don't
Hi Nikolay, > There were multiple fixes from Josef recently improving btrfs enospc handling with tiny filesystems (which is generally not the targeted use case of btrfs). The code lives in https://github.com/kdave/btrfs-devel/commits/misc-next should you want to test it. Otherwise re-test after next merge windows when those patches are supposed to be merged for 5.4 > Thank for your reply, I will keep eyes on the branch. ps: this email is my simply testcase from ltp --Hongzhi On 9/4/19 4:02 PM, Hongzhi, Song wrote: Hi , *Kernel:* After v5.2-rc1, qemux86-64 make -j40 ARCH=x86_64 CROSS_COMPILE=x86-64-gcc use qemu to bootup kernel *Reproduce:* There is a test case failed on btrfs but success on other fs(ext4,ext3), see attachment. Download attachments: gcc test.c -o myout -Wall -lpthread copy myout and run.sh to your qemu same directory. on qemu: ./run.sh I found the block device size with btrfs set 512M will cause the error. 256M and 1G all success. *Error info:* "BTRFS warning (device loop0): could not allocate space for a delete; will truncate on mount" *Related patch:* I use git bisect to find the following patch introduces the issue. commit c8eaeac7b734347c3afba7008b7af62f37b9c140 Author: Josef Bacik Date: Wed Apr 10 15:56:10 2019 -0400 btrfs: reserve delalloc metadata differently ... Anyone's reply will be appreciated. --Hongzhi
Re: [PATCH] media: meson: Add NULL check after the call to kmalloc()
On 04/09/2019 10.22, Austin Kim wrote:
> If the kmalloc() return NULL, the NULL pointer dereference will occur.
> new_ts->ts = ts;
>
> Add exception check after the call to kmalloc() is made.
>
> Signed-off-by: Austin Kim
> ---
> drivers/staging/media/meson/vdec/vdec_helpers.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/staging/media/meson/vdec/vdec_helpers.c
> b/drivers/staging/media/meson/vdec/vdec_helpers.c
> index f16948b..e7e56d5 100644
> --- a/drivers/staging/media/meson/vdec/vdec_helpers.c
> +++ b/drivers/staging/media/meson/vdec/vdec_helpers.c
> @@ -206,6 +206,10 @@ void amvdec_add_ts_reorder(struct amvdec_session *sess,
> u64 ts, u32 offset)
> unsigned long flags;
>
> new_ts = kmalloc(sizeof(*new_ts), GFP_KERNEL);
> + if (!new_ts) {
> + dev_err(sess->core->dev, "Failed to kmalloc()\n");
> + return;
> + }
> new_ts->ts = ts;
> new_ts->offset = offset;
No need to printk() on error, AFAIK the mm subsystem should already make
some noise if an allocation fails.
This is not a proper fix - you need to make the function return an error
(-ENOMEM) to let the caller know allocation failed, and allow that to
propagate the error. There's only one caller, which already seems
capable of returning errors (there's an -EAGAIN), so it shouldn't be
that hard - though of course one needs to undo what has been done so far.
Also, unrelated to the kmalloc() handling: amvdec_add_ts_reorder() could
be moved to esparser.c and made static, or at the very least the
EXPORT_SYMBOL can be removed since vdec_helpers.o is linked in to the
same module as the sole user. That probably goes for all the
EXPORT_SYMBOL(amvdec_*).
Rasmus
Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption
On 9/4/19 10:19 AM, Thomas Hellström (VMware) wrote: Hi, Christian, On 9/4/19 9:33 AM, Koenig, Christian wrote: Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware): On 9/3/19 10:51 PM, Dave Hansen wrote: On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote: So the question here should really be, can we determine already at mmap time whether backing memory will be unencrypted and adjust the *real* vma->vm_page_prot under the mmap_sem? Possibly, but that requires populating the buffer with memory at mmap time rather than at first fault time. I'm not connecting the dots. vma->vm_page_prot is used to create a VMA's PTEs regardless of if they are created at mmap() or fault time. If we establish a good vma->vm_page_prot, can't we just use it forever for demand faults? With SEV I think that we could possibly establish the encryption flags at vma creation time. But thinking of it, it would actually break with SME where buffer content can be moved between encrypted system memory and unencrypted graphics card PCI memory behind user-space's back. That would imply killing all user-space encrypted PTEs and at fault time set up new ones pointing to unencrypted PCI memory.. Well my problem is where do you see encrypted system memory here? At least for AMD GPUs all memory accessed must be unencrypted and that counts for both system as well as PCI memory. We're talking SME now right? The current SME setup is that if a device's DMA mask says it's capable of addressing the encryption bit, coherent memory will be encrypted. The memory controllers will decrypt for the device on the fly. Otherwise coherent memory will be decrypted. So I don't get why we can't assume always unencrypted and keep it like that. I see two reasons. First, it would break with a real device that signals it's capable of addressing the encryption bit. Second I can imagine unaccelerated setups (something like vkms using prime feeding a VNC connection) where we actually want the TTM buffers encrypted to protect data. But at least the latter reason is way far out in the future. So for me I'm ok with that if that works for you? Hmm, BTW, Are you sure the AMD GPUs use unencrypted system memory rather than relying on the memory controllers to decrypt? In that case it seems strange that they get away with encrypted TTM PTEs, whereas vmwgfx don't... /Thomas /Thomas Regards, Christian.
[PATCH -next] USB: musb: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/usb/musb/musb_core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index bd63450af..196980b 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2431,14 +2431,12 @@ static int musb_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
int irq = platform_get_irq_byname(pdev, "mc");
- struct resource *iomem;
void __iomem*base;
if (irq <= 0)
return -ENODEV;
- iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(dev, iomem);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
2.7.4
Re: [PATCH v2] mm: emit tracepoint when RSS changes by threshold
On Tue 03-09-19 16:09:05, Joel Fernandes (Google) wrote:
> Useful to track how RSS is changing per TGID to detect spikes in RSS and
> memory hogs. Several Android teams have been using this patch in various
> kernel trees for half a year now. Many reported to me it is really
> useful so I'm posting it upstream.
>
> Initial patch developed by Tim Murray. Changes I made from original patch:
> o Prevent any additional space consumed by mm_struct.
> o Keep overhead low by checking if tracing is enabled.
> o Add some noise reduction and lower overhead by emitting only on
> threshold changes.
Does this have any pre-requisite? I do not see trace_rss_stat_enabled in
the Linus tree (nor in linux-next). Besides that why do we need batching
in the first place. Does this have a measurable overhead? How does it
differ from any other tracepoints that we have in other hotpaths (e.g.
page allocator doesn't do any checks).
Other than that this looks reasonable to me.
> Co-developed-by: Tim Murray
> Signed-off-by: Tim Murray
> Signed-off-by: Joel Fernandes (Google)
>
> ---
>
> v1->v2: Added more commit message.
>
> Cc: carmenjack...@google.com
> Cc: mayankgu...@google.com
> Cc: dan...@google.com
> Cc: rost...@goodmis.org
> Cc: minc...@kernel.org
> Cc: a...@linux-foundation.org
> Cc: kernel-t...@android.com
>
> include/linux/mm.h | 14 +++---
> include/trace/events/kmem.h | 21 +
> mm/memory.c | 20
> 3 files changed, 52 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 0334ca97c584..823aaf759bdb 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1671,19 +1671,27 @@ static inline unsigned long get_mm_counter(struct
> mm_struct *mm, int member)
> return (unsigned long)val;
> }
>
> +void mm_trace_rss_stat(int member, long count, long value);
> +
> static inline void add_mm_counter(struct mm_struct *mm, int member, long
> value)
> {
> - atomic_long_add(value, &mm->rss_stat.count[member]);
> + long count = atomic_long_add_return(value, &mm->rss_stat.count[member]);
> +
> + mm_trace_rss_stat(member, count, value);
> }
>
> static inline void inc_mm_counter(struct mm_struct *mm, int member)
> {
> - atomic_long_inc(&mm->rss_stat.count[member]);
> + long count = atomic_long_inc_return(&mm->rss_stat.count[member]);
> +
> + mm_trace_rss_stat(member, count, 1);
> }
>
> static inline void dec_mm_counter(struct mm_struct *mm, int member)
> {
> - atomic_long_dec(&mm->rss_stat.count[member]);
> + long count = atomic_long_dec_return(&mm->rss_stat.count[member]);
> +
> + mm_trace_rss_stat(member, count, -1);
> }
>
> /* Optimized variant when page is already known not to be PageAnon */
> diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
> index eb57e3037deb..8b88e04fafbf 100644
> --- a/include/trace/events/kmem.h
> +++ b/include/trace/events/kmem.h
> @@ -315,6 +315,27 @@ TRACE_EVENT(mm_page_alloc_extfrag,
> __entry->change_ownership)
> );
>
> +TRACE_EVENT(rss_stat,
> +
> + TP_PROTO(int member,
> + long count),
> +
> + TP_ARGS(member, count),
> +
> + TP_STRUCT__entry(
> + __field(int, member)
> + __field(long, size)
> + ),
> +
> + TP_fast_assign(
> + __entry->member = member;
> + __entry->size = (count << PAGE_SHIFT);
> + ),
> +
> + TP_printk("member=%d size=%ldB",
> + __entry->member,
> + __entry->size)
> + );
> #endif /* _TRACE_KMEM_H */
>
> /* This part must be outside protection */
> diff --git a/mm/memory.c b/mm/memory.c
> index e2bb51b6242e..9d81322c24a3 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -72,6 +72,8 @@
> #include
> #include
>
> +#include
> +
> #include
> #include
> #include
> @@ -140,6 +142,24 @@ static int __init init_zero_pfn(void)
> }
> core_initcall(init_zero_pfn);
>
> +/*
> + * This threshold is the boundary in the value space, that the counter has to
> + * advance before we trace it. Should be a power of 2. It is to reduce
> unwanted
> + * trace overhead. The counter is in units of number of pages.
> + */
> +#define TRACE_MM_COUNTER_THRESHOLD 128
> +
> +void mm_trace_rss_stat(int member, long count, long value)
> +{
> + long thresh_mask = ~(TRACE_MM_COUNTER_THRESHOLD - 1);
> +
> + if (!trace_rss_stat_enabled())
> + return;
> +
> + /* Threshold roll-over, trace it */
> + if ((count & thresh_mask) != ((count - value) & thresh_mask))
> + trace_rss_stat(member, count);
> +}
>
> #if defined(SPLIT_RSS_COUNTING)
>
> --
> 2.23.0.187.g17f5b7556c-goog
--
Michal Hocko
SUSE Labs
Re: [PATCH] media: meson: Add NULL check after the call to kmalloc()
On Wed, Sep 04, 2019 at 05:22:32PM +0900, Austin Kim wrote:
> If the kmalloc() return NULL, the NULL pointer dereference will occur.
> new_ts->ts = ts;
>
> Add exception check after the call to kmalloc() is made.
>
> Signed-off-by: Austin Kim
> ---
> drivers/staging/media/meson/vdec/vdec_helpers.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/staging/media/meson/vdec/vdec_helpers.c
> b/drivers/staging/media/meson/vdec/vdec_helpers.c
> index f16948b..e7e56d5 100644
> --- a/drivers/staging/media/meson/vdec/vdec_helpers.c
> +++ b/drivers/staging/media/meson/vdec/vdec_helpers.c
> @@ -206,6 +206,10 @@ void amvdec_add_ts_reorder(struct amvdec_session *sess,
> u64 ts, u32 offset)
> unsigned long flags;
>
> new_ts = kmalloc(sizeof(*new_ts), GFP_KERNEL);
> + if (!new_ts) {
> + dev_err(sess->core->dev, "Failed to kmalloc()\n");
Did you run this through checkpatch? I think it will say that this line
is not ok.
> + return;
Shouldn't you return an -ENOMEM error somehow?
thanks,
greg k-h
Re: [PATCH 1/1] soc: qcom: geni: Provide parameter error checking
On Tue, 03 Sep 2019, Bjorn Andersson wrote:
> On Tue 03 Sep 06:50 PDT 2019, Lee Jones wrote:
>
> > When booting with ACPI, the Geni Serial Engine is not set as the I2C/SPI
> > parent and thus, the wrapper (parent device) is unassigned. This causes
> > the kernel to crash with a null dereference error.
> >
>
> Now I see what you did in 8bc529b25354; i.e. stubbed all the other calls
> between the SE and wrapper.
>
> Do you think it would be possible to resolve the _DEP link to QGP[01]
> somehow?
I looked at QGP{0,1}, but did not see it represented in the current
Device Tree implementation and thus failed to identify it. Do you
know what it is? Does it have a driver in Linux already?
> For the clocks workarounds this could be resolved by us
> representing that relationship using device_link and just rely on
> pm_runtime to propagate the clock state.
That is not allowed when booting ACPI. The Clock/Regulator frameworks
are not to be used in this use-case, hence why all of the calls to
these frameworks are "stubbed out". If we wanted to properly
implement power management, we would have to create a driver/subsystem
similar to the "Windows-compatible System Power Management Controller"
(PEP). Without documentation for the PEP, this would be an impossible
task. A request for the aforementioned documentation has been put in
to Lenovo/Qualcomm. Hopefully something appears soon.
> For the DMA operation, iiuc it's the wrapper that implements the DMA
> engine involved, but I'm guessing the main reason for mapping buffers on
> the wrapper is so that it ends up being associated with the iommu
> context of the wrapper.
Judging by the code alone, the wrapper doesn't sound like it does much
at all. It seems to only have a single (version) register (at least
that is the only register that's used). The only registers it
reads/writes are those of the calling device, whether that be I2C, SPI
or UART.
Device Tree represents the wrapper's relationship with the I2C (and
SPI/UART) Serial Engine (SE) devices as parent-child ones, with the
wrapper being the parent and SE the child. Whether this is a true
representation of the hardware or just a tactic used for convenience
is not clear, but the same representation does not exist in ACPI.
In the current Linux implementation, the buffer belongs to the SE
(obtained by the child (e.g. I2C) SE by fetching the parent's
(wrapper's) device data using the standard platform helpers) but the
register-set used to control the DMA transactions belong to the SE
devices.
> Are the SMMU contexts at all represented in the ACPI world and if so do
> you know how the wrapper vs SEs are bound to contexts? Can we map on
> se->dev when wrapper is NULL (or perhaps always?)?
Yes, the SMMU devices are represented in ACPI (MMU0) and (MMU1). They
share the same register addresses as the SMMU devices located in
arch/arm64/boot/dts/qcom/sdm845.dtsi.
With this simple parameter checking patch, the SE falls back to using
FIFO mode to transmit data and continues to work flawlessly. IMHO
this should be applied in the first instance, as it fixes a real (null
dereference) bug which currently resides in the Mainline kernel.
Moving forward we can try to come up with a suitable plan to implement
DMA in the ACPI use-case - but again, this is feature adding work
which should be carried out against -next, where as this patch needs
to go in via the current -rcs ASAP.
> > Fixes: 8bc529b25354 ("soc: qcom: geni: Add support for ACPI")
> > Signed-off-by: Lee Jones
> > ---
> > Since we are already at -rc7 this patch should be processed ASAP - thank
> > you.
> >
> > drivers/soc/qcom/qcom-geni-se.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/soc/qcom/qcom-geni-se.c
> > b/drivers/soc/qcom/qcom-geni-se.c
> > index d5cf953b4337..7d622ea1274e 100644
> > --- a/drivers/soc/qcom/qcom-geni-se.c
> > +++ b/drivers/soc/qcom/qcom-geni-se.c
> > @@ -630,6 +630,9 @@ int geni_se_tx_dma_prep(struct geni_se *se, void *buf,
> > size_t len,
> > struct geni_wrapper *wrapper = se->wrapper;
> > u32 val;
> >
> > + if (!wrapper)
> > + return -EINVAL;
> > +
> > *iova = dma_map_single(wrapper->dev, buf, len, DMA_TO_DEVICE);
> > if (dma_mapping_error(wrapper->dev, *iova))
> > return -EIO;
> > @@ -663,6 +666,9 @@ int geni_se_rx_dma_prep(struct geni_se *se, void *buf,
> > size_t len,
> > struct geni_wrapper *wrapper = se->wrapper;
> > u32 val;
> >
> > + if (!wrapper)
> > + return -EINVAL;
> > +
> > *iova = dma_map_single(wrapper->dev, buf, len, DMA_FROM_DEVICE);
> > if (dma_mapping_error(wrapper->dev, *iova))
> > return -EIO;
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH -next] usb: phy: keystone: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/usb/phy/phy-keystone.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-keystone.c b/drivers/usb/phy/phy-keystone.c
index 1987126..110e6e9 100644
--- a/drivers/usb/phy/phy-keystone.c
+++ b/drivers/usb/phy/phy-keystone.c
@@ -66,15 +66,13 @@ static int keystone_usbphy_probe(struct platform_device
*pdev)
{
struct device *dev = &pdev->dev;
struct keystone_usbphy *k_phy;
- struct resource *res;
int ret;
k_phy = devm_kzalloc(dev, sizeof(*k_phy), GFP_KERNEL);
if (!k_phy)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- k_phy->phy_ctrl = devm_ioremap_resource(dev, res);
+ k_phy->phy_ctrl = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(k_phy->phy_ctrl))
return PTR_ERR(k_phy->phy_ctrl);
--
2.7.4
Re: [PATCH v4 12/12] RFC: watchdog: export core symbols in WATCHDOG_CORE namespace
On Wed, Sep 4, 2019 at 1:10 AM Guenter Roeck wrote: > > On Tue, Sep 03, 2019 at 04:06:38PM +0100, Matthias Maennich wrote: > > Modules using symbols from the WATCHDOG_CORE namespace are required to > > explicitly import the namespace. This patch was generated with the > > following steps and serves as a reference to use the symbol namespace > > feature: > > > > 1) Use EXPORT_SYMBOL_NS* macros instead of EXPORT_SYMBOL* for symbols > > in watchdog_core.c > > 2) make (see warnings during modpost about missing imports) > > 3) make nsdeps > > > > I used 'allmodconfig' for the above steps to ensure all occurrences are > > patched. > > > > Defining DEFAULT_SYMBOL_NAMESPACE in the Makefile is not trivial in this > > case as not only watchdog_core is defined in drivers/watchdog/Makefile. > > Hence this patch uses the variant of using the EXPORT_SYMBOL_NS* macros > > to export into a different namespace. > > > > An alternative to this patch would be a single definition line before > > any use of EXPORT_SYMBOL*: > > #define DEFAULT_SYMBOL_NAMESPACE WATCHDOG_CORE > > > > This patch serves as a reference on how to use the symbol namespaces. > > > > Reviewed-by: Greg Kroah-Hartman > > Signed-off-by: Matthias Maennich > > As mentioned before, I am opposed to this set of changes. I don't see > the point of restricting the use of exported symbols in WATCHDOG_CORE. > > Guenter I agree. I do not like this patch set either. Anyway, the last two patches (usb-stroage, watchdog) are useful to demonstrate that this has a bad taste. -- Best Regards Masahiro Yamada
Re: [RFC 5/5] ARM: dts: omap3-beagle: make explicitly compatible to ti,omap34xx
Hi Tony,
> Am 03.09.2019 um 15:40 schrieb Tony Lindgren :
>
> * H. Nikolaus Schaller [190902 10:56]:
>> Matching the ti-cpufreq driver needs to specify explicitly if
>> a board uses an omap34xx or omap36xx chip.
>>
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> arch/arm/boot/dts/omap3-beagle.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3-beagle.dts
>> b/arch/arm/boot/dts/omap3-beagle.dts
>> index e3df3c166902..d47213c7a4d0 100644
>> --- a/arch/arm/boot/dts/omap3-beagle.dts
>> +++ b/arch/arm/boot/dts/omap3-beagle.dts
>> @@ -8,7 +8,7 @@
>>
>> / {
>> model = "TI OMAP3 BeagleBoard";
>> -compatible = "ti,omap3-beagle", "ti,omap3";
>> +compatible = "ti,omap3-beagle", "ti,omap34xx", "ti,omap3";
>>
>> cpus {
>> cpu@0 {
>
> For a clean-up patch, we should just use the following compatibles
> in general for omap3:
>
> ti,omap3 omap3
> ti,omap34 omap34xx and omap35xx
> ti,omap36 omap36xx and dm37xx
> ti,am35 am35xx
>
> So we should just leave out the "xx" part. But we still need parse
> also the legacy binding with "xx" in drivers.
Yes, getting rid of the xx in the device trees would be nice.
But I have looked through the kernel tree and that makes more problems
than it solves...
There is code that explicitly checks for "ti,omap36xx" in drivers/clk/ti/dpll.c
Maybe that should be replaced by a check for a "ti,dpll5" property
which is only defined in omap36xx.dtsi to make the code depend
on a feature rather than SoC family string. Although such a change
may break other things or we have to keep even more legacy code around.
And there is a binding document omap.txt that does not describe
it the way you propose. IMHO that should be changed first.
Next is that omap.txt explicitly says that ti,omap3 defauls to OMAP3430.
And OMAP3430 should be specified as compatible = "ti,omap3430", "ti,omap3"
while OMAP3630 should have compatible = "ti,omap36xx", "ti,omap3".
AM3517 is compatible = "ti,am3517", "ti,omap3" which seems to ignore
the AM3505 (maybe there was never a board using it).
So this clean up is much more than what we need for moving from
opp-v1 to opp-v2 and it should therefore be addressed separately.
Therefore I'd prefer if we can keep all these problems isolated
into a separate set of patches. And because of this I have prepared
an RFC-V2 which only adds the "ti,omap3430" to those boards which
do not yet have it (in accordance to existing omap.txt).
AM3517 does not seem to have any opp table and therefore I also
exclude it at the moment.
BR and thanks,
Nikolaus
[PATCH -next] usb: phy: mxs: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/usb/phy/phy-mxs-usb.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-mxs-usb.c b/drivers/usb/phy/phy-mxs-usb.c
index 70b8c82..67b39dc 100644
--- a/drivers/usb/phy/phy-mxs-usb.c
+++ b/drivers/usb/phy/phy-mxs-usb.c
@@ -710,7 +710,6 @@ static enum usb_charger_type mxs_phy_charger_detect(struct
usb_phy *phy)
static int mxs_phy_probe(struct platform_device *pdev)
{
- struct resource *res;
void __iomem *base;
struct clk *clk;
struct mxs_phy *mxs_phy;
@@ -723,8 +722,7 @@ static int mxs_phy_probe(struct platform_device *pdev)
if (!of_id)
return -ENODEV;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_ioremap_resource(&pdev->dev, res);
+ base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
return PTR_ERR(base);
--
2.7.4
Re: [RFC PATCH 2/2] livepatch: Clear relocation targets on a module removal
On Tue 2019-09-03 15:02:34, Miroslav Benes wrote: > On Mon, 2 Sep 2019, Joe Lawrence wrote: > > > On 9/2/19 12:13 PM, Miroslav Benes wrote: > > >> I can easily foresee more problems like those in the future. Going > > >> forward we have to always keep track of which special sections are > > >> needed for which architectures. Those special sections can change over > > >> time, or can simply be overlooked for a given architecture. It's > > >> fragile. > > > > > > Indeed. It bothers me a lot. Even x86 "port" is not feature complete in > > > this regard (jump labels, alternatives,...) and who knows what lurks in > > > the corners of the other architectures we support. > > > > > > So it is in itself reason enough to do something about late module > > > patching. > > > > > > > Hi Miroslav, > > > > I was tinkering with the "blue-sky" ideas that I mentioned to Josh the other > > day. > > > I dunno if you had a chance to look at what removing that code looks > > like, but I can continue to flesh out that idea if it looks interesting: > > Unfortunately no and I don't think I'll come up with something useful > before LPC, so anything is really welcome. > > > > > https://github.com/joe-lawrence/linux/tree/blue-sky > > > > A full demo would require packaging up replacement .ko's with a livepatch, > > as > > well as "blacklisting" those deprecated .kos, etc. But that's all I had > > time > > to cook up last week before our holiday weekend here. > > Frankly, I'm not sure about this approach. I'm kind of torn. The current > solution is far from ideal, but I'm not excited about the other options > either. It seems like the choice is basically between "general but > technically complicated fragile solution with nontrivial maintenance > burden", or "something safer and maybe cleaner, but limiting for > users/distros". Of course it depends on whether the limitation is even > real and how big it is. Unfortunately we cannot quantify it much and that > is probably why our opinions (in the email thread) differ. I wonder what is necessary for a productive discussion on Plumbers: + Josh would like to see what code can get removed when late handling of modules gets removed. I think that it might be partially visible from Joe's blue-sky patches. + I would like to better understand the scope of the current problems. It is about modifying code in the livepatch that depends on position of the related code: + relocations are rather clear; we will need them anyway to access non-public (static) API from the original code. + What are the other changes? + Do we use them in livepatches? How often? + How often new problematic features appear? + Would be possible to detect potential problems, for example by comparing the code in the binary and in memory when the module is loaded the normal way? + Would be possible to reset the livepatch code in memory when the related module is unloaded and safe us half of the troubles? + It might be useful to prepare overview of the existing proposals and agree on the positives and negatives. I am afraid that some of them might depend on the customer base and use cases. Sometimes we might not have enough information. But it might be good to get on the same page where possible. Anyway, it might rule out some variants so that we could better concentrate on the acceptable ones. Or come with yet another proposal that would avoid the real blockers. Any other ideas? Would it be better to discuss this in a separate room with a whiteboard or paperboard? Best Regards, Petr
[PATCH] soc: samsung: chipid: Make exynos_chipid_early_init() static
Add missing static qualifier to the chipid initcall function.
Signed-off-by: Sylwester Nawrocki
---
drivers/soc/samsung/exynos-chipid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/samsung/exynos-chipid.c
b/drivers/soc/samsung/exynos-chipid.c
index c55a47cfe617..25562dd0b206 100644
--- a/drivers/soc/samsung/exynos-chipid.c
+++ b/drivers/soc/samsung/exynos-chipid.c
@@ -45,7 +45,7 @@ static const char * __init product_id_to_soc_id(unsigned int
product_id)
return NULL;
}
-int __init exynos_chipid_early_init(void)
+static int __init exynos_chipid_early_init(void)
{
struct soc_device_attribute *soc_dev_attr;
struct soc_device *soc_dev;
--
2.17.1
