RE: [PATCH 1/2] media: i2c: Add driver for the Analog Devices ADDI9036 ToF front-end
Hi Laurent, > > Hi Bogdan, > > On Thu, Sep 17, 2020 at 07:06:10AM +, Togorean, Bogdan wrote: > > Hi Laurent and Sakari, > > Thank you for your review, > > > Hi Bogdan, > > > > > > On Fri, Sep 11, 2020 at 01:32:39PM +, Togorean, Bogdan wrote: > > > > > On Thu, Sep 10, 2020 at 07:24:06PM +0300, Bogdan Togorean wrote: > > > > > > The ADDI9036 is a complete, 45 MHz, front-end solution for charge > > > > > > coupled device (CCD) time of flight (TOF) imaging applications. > > > > > > > > > > > > It has 2-lane MIPI CSI-2 RAW12 data output and i2c control > > > > > > interface. > > > > > > > > > > > > The programming of calibration and firmware is performed by > > > > > > userspace > > > > > > SDK through CID_USER class IOCTLs. > > > > > > > > > > I'm afraid that's not acceptable. The firmware should be loaded using > > > > > the Linux kernel firmware API. As for calibration, is it static data ? > > > > > How is it generated ? > > > > > > > > Calibration data is static data, generated at production and stored on > > > > and > EEPROM > > > > memory on camera board. The camera board consists mainly of ADDI9036 > processor > > > > + CCD image sensor + EEPROM. > > > > > > > > The firmware is a set of (address, data) tuples that are written via > > > > I2C. > > > > > > Is it a firmware in the sense of software running on the ADDI9036, or is > > > it a device configuration to be loaded in registers ? > > > > Actually what we call "firmware" is a combination of both. The binary blob > > that > gets written > > contains ToF processor instructions that end in a RAM memory internal to > ADDI9036 and > > also register configurations. > > This makes it effectively impossible to use the device unless you have a > closed-source userspace application to configure it, isn't it ? > > Firmware that runs on a device can be shipped as a binary blob, but > configuration of the device must not require closed-source software. To > be upstreamed, a driver needs to be usable either on its own (with its > userspace APIs document and usable by all applications), or in > combination with an open-source userspace stack. > The open source userspace SDK provided by Analog Devices will still be required because it computes corrections and apply them to every frame based on calibration data read from EEPROM. > > I am working on a V2 that uses firmware API and NVMEM subsystem for > EEPROM stored data. > > > > > > We want this driver to be a generic one and support all implementations > > > > of ADDI9036 ToF processor. Now the problem is that some implementations > > > > store firmware + calibration on external EEPROM and some store just > calibration > > > > data on EEPROM and firmware is loaded from a file stored in SDK. With > > > > the > help > > > > of the 2 custom controls we move the camera model detection, firmware > > > > and calibration fetching from driver to user space SDK. > > > > > > > > Also an important point is that the ToF processor has 3 operating modes > > > > (near, medium and far). At each mode change a new set of firmware + > > > > calibration data is loaded into ADDI9036 chip. If we move the firmware > loading > > > > in driver we would still need a custom enumeration control to select the > working mode. > > > > > > > > > > Signed-off-by: Bogdan Togorean > > > > > > --- > > > > > > MAINTAINERS| 10 + > > > > > > drivers/media/i2c/Kconfig | 14 + > > > > > > drivers/media/i2c/Makefile | 1 + > > > > > > drivers/media/i2c/addi9036.c | 673 > + > > > > > > include/uapi/linux/v4l2-controls.h | 6 + > > > > > > 5 files changed, 704 insertions(+) > > > > > > create mode 100644 drivers/media/i2c/addi9036.c > > > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > > > > index b5cfab015bd6..fb03ad9ca920 100644 > > > > > > --- a/MAINTAINERS > > > > > > +++ b/MAINTAINERS > > > > > > @@ -477,6 +477,16 @@ W: http://wiki.analog.com/AD7879 > > > > > > W: http://ez.analog.com/community/linux-device-drivers > > > > > > F: drivers/input/touchscreen/ad7879.c > > > > > > > > > > > > +ADDI9036 TOF FRONTEND DRIVER > > > > > > +M: Bogdan Togorean > > > > > > +L: linux-me...@vger.kernel.org > > > > > > +S: Supported > > > > > > +W: https://www.analog.com/en/products/addi9036.html > > > > > > +W: http://ez.analog.com/community/linux-device-drivers > > > > > > +T: git git://linuxtv.org/media_tree.git > > > > > > +F: > Documentation/devicetree/bindings/media/i2c/adi,addi9036.yaml > > > > > > +F: drivers/media/i2c/addi9036.c > > > > > > + > > > > > > ADDRESS SPACE LAYOUT RANDOMIZATION (ASLR) > > > > > > M: Jiri Kosina > > > > > > S: Maintained > > > > > > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig > > > > > > index c7ba76fee599..087dd307505d 100644 > > > > > > --- a/drivers/media/i2c/Kconfig > > > > > > +++ b/drivers/media/i2c/Kconfig > > > > > > @@ -725,6 +725,20 @@ config VIDEO_APTINA_PLL > > >
Re: [PATCH] dmaengine: sf-pdma: remove unused 'desc'
On 14-09-20, 11:23, Vinod Koul wrote: > 'desc' variable is now defined but not used in sf_pdma_donebh_tasklet(), > causing this warning: > > drivers/dma/sf-pdma/sf-pdma.c: In function 'sf_pdma_donebh_tasklet': > drivers/dma/sf-pdma/sf-pdma.c:287:23: warning: unused variable 'desc' > [-Wunused-variable] > > Remove this unused variable Applied, thanks -- ~Vinod
Re: [patch 09/10] sched/core: Add migrate_disable/enable()
On Thu, Sep 17 2020 at 16:24, peterz wrote:
> On Thu, Sep 17, 2020 at 11:42:11AM +0200, Thomas Gleixner wrote:
>
>> +static inline void update_nr_migratory(struct task_struct *p, long delta)
>> +{
>> +if (p->nr_cpus_allowed > 1 && p->sched_class->update_migratory)
>> +p->sched_class->update_migratory(p, delta);
>> +}
>
> Right, so as you know, I totally hate this thing :-) It adds a second
> (and radically different) version of changing affinity. I'm working on a
> version that uses the normal *set_cpus_allowed*() interface.
Tried that back and forth and ended either up in locking hell or with
race conditions of sorts, but my scheduler foo is rusty.
>> +static inline void sched_migration_ctrl(struct task_struct *prev, int cpu)
>> +{
>> +if (!prev->migration_ctrl.disable_cnt ||
>> +prev->cpus_ptr != &prev->cpus_mask)
>> +return;
>> +
>> +prev->cpus_ptr = cpumask_of(cpu);
>> +update_nr_migratory(prev, -1);
>> +prev->nr_cpus_allowed = 1;
>> +}
>
> So this thing is called from schedule(), with only rq->lock held, and
> that violates the locking rules for changing the affinity.
>
> I have a comment that explains how it's broken and why it's sort-of
> working.
Yeah :(
>> +void migrate_disable(void)
>> +{
>> +unsigned long flags;
>> +
>> +if (!current->migration_ctrl.disable_cnt) {
>> +raw_spin_lock_irqsave(¤t->pi_lock, flags);
>> +current->migration_ctrl.disable_cnt++;
>> +raw_spin_unlock_irqrestore(¤t->pi_lock, flags);
>> +} else {
>> +current->migration_ctrl.disable_cnt++;
>> +}
>> +}
>
> That pi_lock seems unfortunate, and it isn't obvious what the point of
> it is.
Indeed. That obviously lacks a big fat comment.
current->migration_ctrl.disable_cnt++ is obviously a RMW operation. So
you end up with the following:
CPU0CPU1
migrate_disable()
R = current->migration_ctrl.disable_cnt;
set_cpus_allowed_ptr()
task_rq_lock();
if
(!p->migration_ctrl.disable_cnt) {
current->migration_ctrl.disable_cnt = R + 1;
stop_one_cpu();
---> stopper_thread()
BUG_ON(task->migration_ctrl.disable_cnt);
I tried to back out from that instead of BUG(), but that ended up being
even more of a hacky trainwreck than just biting the bullet and taking
pi_lock.
>
> So, what I'm missing with all this are the design contraints for this
> trainwreck. Because the 'sane' solution was having migrate_disable()
> imply cpus_read_lock(). But that didn't fly because we can't have
> migrate_disable() / migrate_enable() schedule for raisins.
Yeah. The original code had some magic
if (preemptible())
cpus_read_lock();
else
p->atomic_migrate_disable++;
but that caused another set of horrors with asymetric code like the
below and stuff like try_lock().
> And if I'm not mistaken, the above migrate_enable() *does* require being
> able to schedule, and our favourite piece of futex:
>
> raw_spin_lock_irq(&q.pi_state->pi_mutex.wait_lock);
> spin_unlock(q.lock_ptr);
>
> is broken. Consider that spin_unlock() doing migrate_enable() with a
> pending sched_setaffinity().
Yes, we have the extra migrate_disable()/enable() pair around that.
The other way I solved that was to have a spin_[un]lock() variant which
does not have a migrate disable/enable. That works in that code because
there is no per CPUness requirement. Not pretty either...
Thanks,
tglx
Re: [PATCH v6 1/4] KEYS: trusted: Add generic trusted keys framework
On Thu, 17 Sep 2020 at 21:55, Jarkko Sakkinen
wrote:
>
> On Thu, Sep 17, 2020 at 07:21:49PM +0300, Jarkko Sakkinen wrote:
> > On Thu, Sep 17, 2020 at 07:16:35PM +0530, Sumit Garg wrote:
> > > Current trusted keys framework is tightly coupled to use TPM device as
> > > an underlying implementation which makes it difficult for implementations
> > > like Trusted Execution Environment (TEE) etc. to provide trusted keys
> > > support in case platform doesn't posses a TPM device.
> > >
> > > So this patch tries to add generic trusted keys framework where underlying
> > > implementations like TPM, TEE etc. could be easily plugged-in.
> >
> > I would rephrase this a bit:
> >
> > "Add a generic trusted keys framework where underlying implementations
> > can be easily plugged in. Create struct trusted_key_ops to achieve this,
> > which contains necessary functions of a backend."
> >
Okay, will use it instead.
> > I remember asking about this approach that what if there was just a
> > header for trusted key functions and a compile time decision, which C
> > file to include instead of ops struct. I don't remember if these was a
> > conclusion on this or not.
This approach was implemented as part of v5 and we concluded here [1]
to revert back to the dynamic approach as distro vendors won't like to
make opinionated selection at compile time which could rather be
achieved dynamically based on platform capability.
[1] https://www.spinics.net/lists/keyrings/msg08161.html
> >
> > E.g. lets say you have a device with TEE and TPM, should you be able
> > to be use both at run-time? I might play along how this works now but
> > somehow, in the commit message preferably, it should be conclude why
> > one alternative is chosen over another.
>
Okay, so how about adding a kernel module parameter which can enforce
the user's preference about which trust source to use at runtime? And
we should only check availability for that trust source if preference
is provided otherwise by default we can traverse the trust sources
list.
See following change, if this approach looks sane, I can include it in
next version:
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index edd635a..a566451 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -63,6 +63,11 @@ struct trusted_key_ops {
void (*exit)(void);
};
+struct trusted_key_source {
+ char *name;
+ struct trusted_key_ops *ops;
+};
+
extern struct key_type key_type_trusted;
#define TRUSTED_DEBUG 0
diff --git a/security/keys/trusted-keys/trusted_core.c
b/security/keys/trusted-keys/trusted_core.c
index 83a6a15..74a3d80 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -21,12 +21,16 @@
#include
#include
-static struct trusted_key_ops *available_trusted_key_ops[] = {
+static char *trusted_key_source;
+module_param_named(source, trusted_key_source, charp, 0);
+MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
+
+static struct trusted_key_source trusted_key_sources[] = {
#if defined(CONFIG_TCG_TPM)
- &tpm_trusted_key_ops,
+ { "tpm", &tpm_trusted_key_ops },
#endif
#if defined(CONFIG_TEE)
- &tee_trusted_key_ops,
+ { "tee", &tee_trusted_key_ops },
#endif
};
static struct trusted_key_ops *trusted_key_ops;
@@ -296,8 +300,13 @@ static int __init init_trusted(void)
{
int i, ret = 0;
- for (i = 0; i < sizeof(available_trusted_key_ops); i++) {
- trusted_key_ops = available_trusted_key_ops[i];
+ for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
+ if (trusted_key_source &&
+ strncmp(trusted_key_source, trusted_key_sources[i].name,
+ strlen(trusted_key_sources[i].name)))
+ continue;
+
+ trusted_key_ops = trusted_key_sources[i].ops;
ret = trusted_key_ops->init();
if (!ret)
> We must somehow seal this discussion because the other changes are
> based on this decision.
>
> I don't think tail of this patch set takes a long time spin. This
> is the main architectural decision.
Agree.
-Sumit
>
> /Jarkko
Re: [PATCH -next] dmaengine: mediatek: simplify the return expression of mtk_uart_apdma_runtime_resume()
On 15-09-20, 11:26, Liu Shixin wrote: > Simplify the return expression. > Applied, thanks -- ~Vinod
Re: [PATCH -next] dmaengine: sf-pdma: Remove set but not used variable "desc"
On 17-09-20, 15:17, Liu Shixin wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/dma/sf-pdma/sf-pdma.c: In function 'sf_pdma_donebh_tasklet':
> drivers/dma/sf-pdma/sf-pdma.c:287:23: warning: unused variable 'desc'
> [-Wunused-variable]
>
> After commit 8f6b6d060602 ("dmaengine: sf-pdma: Fix an error that calls
> callback twice"),
> variable 'desc' is never used. Remove it to avoid build warning.
This was already reported by SFR and patch posted, so picked that one
>
> Signed-off-by: Liu Shixin
> ---
> drivers/dma/sf-pdma/sf-pdma.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/dma/sf-pdma/sf-pdma.c b/drivers/dma/sf-pdma/sf-pdma.c
> index 754994087e5f..1e66c6990d81 100644
> --- a/drivers/dma/sf-pdma/sf-pdma.c
> +++ b/drivers/dma/sf-pdma/sf-pdma.c
> @@ -284,7 +284,6 @@ static void sf_pdma_free_desc(struct virt_dma_desc *vdesc)
> static void sf_pdma_donebh_tasklet(unsigned long arg)
> {
> struct sf_pdma_chan *chan = (struct sf_pdma_chan *)arg;
> - struct sf_pdma_desc *desc = chan->desc;
> unsigned long flags;
>
> spin_lock_irqsave(&chan->lock, flags);
> --
> 2.25.1
--
~Vinod
Re: [PATCH 3/3] crypto: hisilicon/hpre - fix a bug in dh algorithm
On Thu, Sep 10, 2020 at 07:25:22PM +0800, Meng Yu wrote:
>
> diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> index 0cbe99a1..2d91593 100644
> --- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> +++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
> @@ -528,6 +528,8 @@ static int hpre_dh_compute_value(struct kpp_request *req)
> ret = hpre_hw_data_init(hpre_req, req->src, req->src_len, 1, 1);
> if (unlikely(ret))
> goto clear_all;
> + } else {
> + msg->in = cpu_to_le64((u64)ctx->dh.dma_g);
Why do you need the u64 cast?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] EDAC/mc_sysfs: Add missing newlines when printing {max,dimm}_location
On Fri, Sep 18, 2020 at 10:37:28AM +0800, Xiongfeng Wang wrote: > Thansk a lot. I will send another version. Also I will change the > 'snprintf' in 'dimmdev_location_show()' to 'scnprintf' No need to send another one - I have everything locally and just amended it. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
[PATCH] scsi: 53c700: Remove set but not used variable
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/scsi/53c700.c: In function NCR_700_intr:
drivers/scsi/53c700.c:1488:27: warning: variable ‘state’ set but not used
[-Wunused-but-set-variable]
drivers/scsi/53c700.c: In function NCR_700_queuecommand_lck:
drivers/scsi/53c700.c:1742:26: warning: variable ‘direction’ set but not used
[-Wunused-but-set-variable]
these variable is never used, so remove it.
Signed-off-by: Zheng Yongjun
---
drivers/scsi/53c700.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index 84b57a8f86bf..b2c2f49f6f7d 100644
--- a/drivers/scsi/53c700.c
+++ b/drivers/scsi/53c700.c
@@ -1485,10 +1485,8 @@ NCR_700_intr(int irq, void *dev_id)
__u8 sstat0 = 0, dstat = 0;
__u32 dsp;
struct scsi_cmnd *SCp = hostdata->cmd;
- enum NCR_700_Host_State state;
handled = 1;
- state = hostdata->state;
SCp = hostdata->cmd;
if(istat & SCSI_INT_PENDING) {
@@ -1739,7 +1737,6 @@ NCR_700_queuecommand_lck(struct scsi_cmnd *SCp, void
(*done)(struct scsi_cmnd *)
struct NCR_700_Host_Parameters *hostdata =
(struct NCR_700_Host_Parameters
*)SCp->device->host->hostdata[0];
__u32 move_ins;
- enum dma_data_direction direction;
struct NCR_700_command_slot *slot;
if(hostdata->command_slot_count >= NCR_700_COMMAND_SLOTS_PER_HOST) {
@@ -1856,7 +1853,6 @@ NCR_700_queuecommand_lck(struct scsi_cmnd *SCp, void
(*done)(struct scsi_cmnd *)
}
/* now build the scatter gather list */
- direction = SCp->sc_data_direction;
if(move_ins != 0) {
int i;
int sg_count;
--
2.17.1
Re: [PATCH 2/2] serial: core: fix console port-lock regression
* Andy Shevchenko [200916 12:34]: > On Mon, Sep 14, 2020 at 11:09:16AM +0300, Tony Lindgren wrote: > > * Andy Shevchenko [200910 09:27]: > > > +Cc: Tony, let me add Tony to the discussion. > > > > > > On Thu, Sep 10, 2020 at 09:35:27AM +0200, Johan Hovold wrote: > > > > And what about power management > > > > which was the reason for wanting this on OMAP in the first place; tty > > > > core never calls shutdown() for a console port, not even when it's been > > > > detached using the new interface. > > > > > > That is interesting... Tony, do we have OMAP case working because of luck? > > > > 8250_omap won't do anything unless autosuspend_timeout is configured for > > the uart(s). If configured, then the 8250_omap will idle when console is > > detached and the PM runtime usage count held by console is decremented, and > > the configured autosuspend_timeout expires. > > > > The console is still kept open by getty, so I don't see why shutdown() would > > be called for the console port. But maybe I don't follow what you're > > concerned about, let me know if you want me to check something :) > > Is it possible to test configuration when you have kernel console enabled but > no getty is run on it (perhaps something with ssh enabled access)? > > Then kernel console should call ->shutdown on detaching, right? I gave this a quick try and Johan is right, shutdown is not called on console uart still even if detached and no getty running on that uart. I could not figure out easily where exactly this gets blocked.. So far I did try setting port->console = 0 on detach, then init it again on attach. Regards, Tony
[PATCH] net: openswitch: reuse the helper variable to improve the code readablity
In the function ovs_ct_limit_exit, there is already a helper vaibale which could be reused to improve the readability, so i fix it in this patch. Signed-off-by: Zeng Tao --- net/openvswitch/conntrack.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c index a3f1204..e86b960 100644 --- a/net/openvswitch/conntrack.c +++ b/net/openvswitch/conntrack.c @@ -1901,8 +1901,8 @@ static void ovs_ct_limit_exit(struct net *net, struct ovs_net *ovs_net) lockdep_ovsl_is_held()) kfree_rcu(ct_limit, rcu); } - kfree(ovs_net->ct_limit_info->limits); - kfree(ovs_net->ct_limit_info); + kfree(info->limits); + kfree(info); } static struct sk_buff * -- 2.8.1
[PATCH -next] rapidio: Remove set but not used variable 'rc'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/rapidio/rio_cm.c: In function rio_txcq_handler:
drivers/rapidio/rio_cm.c:673:7: warning: variable ‘rc’ set but not used
[-Wunused-but-set-variable]
rc is never used, so remove it.
Signed-off-by: Zheng Yongjun
---
drivers/rapidio/rio_cm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
index 50ec53d67a4c..545693bd86a3 100644
--- a/drivers/rapidio/rio_cm.c
+++ b/drivers/rapidio/rio_cm.c
@@ -670,12 +670,11 @@ static void rio_txcq_handler(struct cm_dev *cm, int slot)
*/
if (!list_empty(&cm->tx_reqs) && (cm->tx_cnt < RIOCM_TX_RING_SIZE)) {
struct tx_req *req, *_req;
- int rc;
list_for_each_entry_safe(req, _req, &cm->tx_reqs, node) {
list_del(&req->node);
cm->tx_buf[cm->tx_slot] = req->buffer;
- rc = rio_add_outb_message(cm->mport, req->rdev, cmbox,
+ rio_add_outb_message(cm->mport, req->rdev, cmbox,
req->buffer, req->len);
kfree(req->buffer);
kfree(req);
--
2.17.1
[PATCH -next] rapidio: Remove set but not used variable 'rc'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/rapidio/rio_cm.c: In function rio_txcq_handler:
drivers/rapidio/rio_cm.c:673:7: warning: variable ‘rc’ set but not used
[-Wunused-but-set-variable]
rc is never used, so remove it.
Signed-off-by: Zheng Yongjun
---
drivers/rapidio/rio_cm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
index 50ec53d67a4c..545693bd86a3 100644
--- a/drivers/rapidio/rio_cm.c
+++ b/drivers/rapidio/rio_cm.c
@@ -670,12 +670,11 @@ static void rio_txcq_handler(struct cm_dev *cm, int slot)
*/
if (!list_empty(&cm->tx_reqs) && (cm->tx_cnt < RIOCM_TX_RING_SIZE)) {
struct tx_req *req, *_req;
- int rc;
list_for_each_entry_safe(req, _req, &cm->tx_reqs, node) {
list_del(&req->node);
cm->tx_buf[cm->tx_slot] = req->buffer;
- rc = rio_add_outb_message(cm->mport, req->rdev, cmbox,
+ rio_add_outb_message(cm->mport, req->rdev, cmbox,
req->buffer, req->len);
kfree(req->buffer);
kfree(req);
--
2.17.1
RE: [PATCH AUTOSEL 5.4 265/330] drm/amd/powerplay: try to do a graceful shutdown on SW CTF
[AMD Official Use Only - Internal Distribution Only]
Hi @Sasha Levin @Deucher, Alexander,
The following changes need to be applied also.
Otherwise, you may see unexpected shutdown on stress gpu loading on Vega10.
drm/amd/pm: avoid false alarm due to confusing softwareshutdowntemp setting
drm/amd/pm: correct the thermal alert temperature limit settings
drm/amd/pm: correct Vega20 swctf limit setting
drm/amd/pm: correct Vega12 swctf limit setting
drm/amd/pm: correct Vega10 swctf limit setting
BR
Evan
-Original Message-
From: Sasha Levin
Sent: Friday, September 18, 2020 10:00 AM
To: linux-kernel@vger.kernel.org; sta...@vger.kernel.org
Cc: Quan, Evan ; Deucher, Alexander
; Sasha Levin ;
dri-de...@lists.freedesktop.org
Subject: [PATCH AUTOSEL 5.4 265/330] drm/amd/powerplay: try to do a graceful
shutdown on SW CTF
From: Evan Quan
[ Upstream commit 9495220577416632675959caf122e968469ffd16 ]
Normally this(SW CTF) should not happen. And by doing graceful shutdown we can
prevent further damage.
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 21 +++
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 7 +++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
index d09690fca4520..414added3d02c 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
@@ -22,6 +22,7 @@
*/
#include
+#include
#include "hwmgr.h"
#include "pp_debug.h"
@@ -593,12 +594,18 @@ int phm_irq_process(struct amdgpu_device *adev,
uint32_t src_id = entry->src_id;
if (client_id == AMDGPU_IRQ_CLIENTID_LEGACY) {
-if (src_id == VISLANDS30_IV_SRCID_CG_TSS_THERMAL_LOW_TO_HIGH)
+if (src_id == VISLANDS30_IV_SRCID_CG_TSS_THERMAL_LOW_TO_HIGH) {
pr_warn("GPU over temperature range detected on PCIe %d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
-else if (src_id == VISLANDS30_IV_SRCID_CG_TSS_THERMAL_HIGH_TO_LOW)
+/*
+ * SW CTF just occurred.
+ * Try to do a graceful shutdown to prevent further damage.
+ */
+dev_emerg(adev->dev, "System is going to shutdown due to SW CTF!\n");
+orderly_poweroff(true);
+} else if (src_id == VISLANDS30_IV_SRCID_CG_TSS_THERMAL_HIGH_TO_LOW)
pr_warn("GPU under temperature range detected on PCIe %d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
@@ -609,12 +616,18 @@ int phm_irq_process(struct amdgpu_device *adev,
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
} else if (client_id == SOC15_IH_CLIENTID_THM) {
-if (src_id == 0)
+if (src_id == 0) {
pr_warn("GPU over temperature range detected on PCIe %d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
-else
+/*
+ * SW CTF just occurred.
+ * Try to do a graceful shutdown to prevent further damage.
+ */
+dev_emerg(adev->dev, "System is going to shutdown due to SW CTF!\n");
+orderly_poweroff(true);
+} else
pr_warn("GPU under temperature range detected on PCIe %d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index c4d8c52c6b9ca..6c4405622c9bb 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "pp_debug.h"
#include "amdgpu.h"
@@ -1538,6 +1539,12 @@ static int smu_v11_0_irq_process(struct amdgpu_device
*adev,
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
+/*
+ * SW CTF just occurred.
+ * Try to do a graceful shutdown to prevent further damage.
+ */
+dev_emerg(adev->dev, "System is going to shutdown due to SW CTF!\n");
+orderly_poweroff(true);
break;
case THM_11_0__SRCID__THM_DIG_THERM_H2L:
pr_warn("GPU under temperature range detected on PCIe %d:%d.%d!\n",
--
2.25.1
[PATCH -next] rapidio: Remove set but not used variable 'rc'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/rapidio/rio_cm.c: In function rio_txcq_handler:
drivers/rapidio/rio_cm.c:673:7: warning: variable ‘rc’ set but not used
[-Wunused-but-set-variable]
rc is never used, so remove it.
Signed-off-by: Zheng Yongjun
---
drivers/rapidio/rio_cm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
index 50ec53d67a4c..545693bd86a3 100644
--- a/drivers/rapidio/rio_cm.c
+++ b/drivers/rapidio/rio_cm.c
@@ -670,12 +670,11 @@ static void rio_txcq_handler(struct cm_dev *cm, int slot)
*/
if (!list_empty(&cm->tx_reqs) && (cm->tx_cnt < RIOCM_TX_RING_SIZE)) {
struct tx_req *req, *_req;
- int rc;
list_for_each_entry_safe(req, _req, &cm->tx_reqs, node) {
list_del(&req->node);
cm->tx_buf[cm->tx_slot] = req->buffer;
- rc = rio_add_outb_message(cm->mport, req->rdev, cmbox,
+ rio_add_outb_message(cm->mport, req->rdev, cmbox,
req->buffer, req->len);
kfree(req->buffer);
kfree(req);
--
2.17.1
linux-next: build warning after merge of the v4l-dvb-fixes tree
Hi all,
After merging the v4l-dvb-fixes tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/userspace-api/media/v4l/buffer.rst:692: WARNING: The "flat-table"
directive is empty; content required.
.. flat-table::
:header-rows: 0
:stub-columns: 0
:widths: 3 1 4
Introduced by commit
129134e5415d ("media: media/v4l2: remove V4L2_FLAG_MEMORY_NON_CONSISTENT
flag")
--
Cheers,
Stephen Rothwell
pgp1tO6KPiPgP.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 2/3] Documentation: ABI: testing: mt6360: Add ADC sysfs guideline
Jonathan Cameron 於 2020年9月18日 週五 上午1:43寫道： > > On Wed, 16 Sep 2020 01:36:08 +0800 > Gene Chen wrote: > > > From: Gene Chen > > > > Add ABI documentation for mt6360 ADC sysfs interfaces. > > > > Signed-off-by: Gene Chen > Would you consider using the proposed label attribute for channels? > > https://lore.kernel.org/linux-iio/20200916132115.81795-1-cristian@analog.com/T/#u > > I'm hoping that will remove the need to have ext name used in the majority of > cases and would like to know if it would work for you? > It may not work for this particular case of course. > > Other comments inline. > because of ADC layout is fixed, I can't switch channel to specific purpose for userspace. > > --- > > Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 | 83 > > ++ > > 1 file changed, 83 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 > > b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 > > new file mode 100644 > > index 000..4b1c270 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 > > @@ -0,0 +1,83 @@ > > +What: > > /sys/bus/iio/devices/iio:deviceX/in_voltage_USBID_input > > > The mixture of case is a bit ugly. Could we do > in_voltage_usbin_input? > ACK > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 USBID ADC which connected to connector ID > > pin. > > + Reading returns voltage in uV > > + > > +What: > > /sys/bus/iio/devices/iio:deviceX/in_voltage_VBUSDIV5_input > > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 VBUS ADC with high accuracy > > + Reading returns voltage in uV > > Why would we ever read the low accuracy version? > > > + > > +What: > > /sys/bus/iio/devices/iio:deviceX/in_voltage_VBUSDIV2_input > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 VBUS ADC with low accuracy > > + Reading returns voltage in uV > > + > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage_VSYS_input > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 VSYS ADC > > + Reading returns voltage in uV > > + > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage_VBAT_input > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 VBAT ADC > > + Reading returns voltage in uV > > + > > +What:/sys/bus/iio/devices/iio:deviceX/in_current_IBUS_input > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 IBUS ADC > > + Reading returns current in uA > Given voltage and current are already clear from the channel type, > could we avoid the repetition? > > in_current_bus_input perhaps? > ACK > > + > > +What:/sys/bus/iio/devices/iio:deviceX/in_current_IBAT_input > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 IBAT ADC > > + Reading returns current in uA > > + > > +What: > > /sys/bus/iio/devices/iio:deviceX/in_voltage_CHG_VDDP_input > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 CHG_VDDP ADC > > + Reading returns voltage in uV > > + > > +What:/sys/bus/iio/devices/iio:deviceX/in_temp_TEMP_JC_input > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 IC junction temperature > > + Reading returns temperature in degree > > + > > +What: > > /sys/bus/iio/devices/iio:deviceX/in_voltage_VREF_TS_input > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 VREF_TS ADC > > + Reading returns voltage in uV > > + > > +What:/sys/bus/iio/devices/iio:deviceX/in_voltage_TS_input > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 TS ADC > > + Reading returns voltage in uV > > + > > +What:/sys/bus/iio/devices/iio:deviceX/timestamp > > +KernelVersion: 5.8.0 > > +Contact: gene_c...@richtek.com > > +Description: > > + Indicated MT6360 timestamp > > + Reading returns current timestamp in ms > > That's an odd bit of ABI. Why would we want to read the current timestamp > from > sysfs? Timestamps in IIO also tend to be in nano seconds. > > >
Re: [PATCH RFC 1/4] mm/page_alloc: convert "report" flag of __free_one_page() to a proper flag
On 18.09.20 03:53, Wei Yang wrote: > On Wed, Sep 16, 2020 at 08:34:08PM +0200, David Hildenbrand wrote: >> Let's prepare for additional flags and avoid long parameter lists of bools. >> Follow-up patches will also make use of the flags in __free_pages_ok(), >> however, I wasn't able to come up with a better name for the type - should >> be good enough for internal purposes. >> >> Cc: Andrew Morton >> Cc: Alexander Duyck >> Cc: Mel Gorman >> Cc: Michal Hocko >> Cc: Dave Hansen >> Cc: Vlastimil Babka >> Cc: Wei Yang >> Cc: Oscar Salvador >> Cc: Mike Rapoport >> Signed-off-by: David Hildenbrand >> --- >> mm/page_alloc.c | 28 >> 1 file changed, 20 insertions(+), 8 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 6b699d273d6e..91cefb8157dd 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -77,6 +77,18 @@ >> #include "shuffle.h" >> #include "page_reporting.h" >> >> +/* Free One Page flags: for internal, non-pcp variants of free_pages(). */ >> +typedef int __bitwise fop_t; >> + >> +/* No special request */ >> +#define FOP_NONE((__force fop_t)0) >> + >> +/* >> + * Skip free page reporting notification after buddy merging (will *not* >> mark > > __free_one_page() may not merge buddy when its buddy is not available. > > Would this comment be a little confusing? > I rather meant the process than if it's actually happening. "Skip free page reporting notification for the (possibly merged) page." Thanks! -- Thanks, David / dhildenb
[PATCH v7 05/17] crypto: sun8i-ss: Add more comment on some structures
This patch adds some comment on structures used by sun8i-ss.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
index da71d8059019..1a66457f4a20 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
@@ -195,6 +195,8 @@ struct sun8i_cipher_req_ctx {
* @keylen:len of the key
* @ss:pointer to the private data of driver handling
this TFM
* @fallback_tfm: pointer to the fallback TFM
+ *
+ * enginectx must be the first element
*/
struct sun8i_cipher_tfm_ctx {
struct crypto_engine_ctx enginectx;
--
2.26.2
[PATCH v7 00/17] crypto: allwinner: add xRNG and hashes
Hello The main goal of this serie is to add support for TRNG, PRNG and hashes to the sun8i-ss/sun8i-ce driver. The whole serie is tested with CRYPTO_EXTRA_TESTS enabled and loading tcrypt. The PRNG and TRNG are tested with rngtest. Both LE and BE kernel are tested. This serie was tested on: - sun50i-a64-pine64 - sun8i-a83t-bananapi-m3 - sun8i-r40-bananapi-m2-ultra - sun50i-h5-libretech-all-h3-cc - sun8i-h3-orangepi-pc Regards Change since v1: - removed _crypto_rng_cast patch Change since v2: - cleaned unused variables from sun8i-ce-prng - added some missing memzero_explicit Change since v3: - rebased on latest next - removed useless cpu_to_le32() in sun8i-ss - added 2 last patches - add handle endianness of t_common_ctl patch Change since v4: - added a style issue patch Changes since v5: - handle failure pattern of pm_runtime_get_sync - Add missing linux/dma-mapping.h Changes since v6: - fix sparse error in sun8i-ce-cipher.c Corentin Labbe (17): crypto: sun8i-ss: Add SS_START define crypto: sun8i-ss: Add support for the PRNG crypto: sun8i-ss: support hash algorithms crypto: sun8i-ss: fix a trivial typo crypto: sun8i-ss: Add more comment on some structures crypto: sun8i-ss: better debug printing crypto: sun8i-ce: handle endianness of t_common_ctl crypto: sun8i-ce: move iv data to request context crypto: sun8i-ce: split into prepare/run/unprepare crypto: sun8i-ce: handle different error registers crypto: sun8i-ce: rename has_t_dlen_in_bytes to cipher_t_dlen_in_bytes crypto: sun8i-ce: support hash algorithms crypto: sun8i-ce: Add stat_bytes debugfs crypto: sun8i-ce: Add support for the PRNG crypto: sun8i-ce: Add support for the TRNG crypto: sun8i-ce: fix comparison of integer expressions of different signedness crypto: sun8i-ss: fix comparison of integer expressions of different signedness drivers/crypto/allwinner/Kconfig | 43 ++ drivers/crypto/allwinner/sun8i-ce/Makefile| 3 + .../allwinner/sun8i-ce/sun8i-ce-cipher.c | 116 +++-- .../crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 381 ++- .../crypto/allwinner/sun8i-ce/sun8i-ce-hash.c | 413 .../crypto/allwinner/sun8i-ce/sun8i-ce-prng.c | 164 +++ .../crypto/allwinner/sun8i-ce/sun8i-ce-trng.c | 127 + drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h | 139 +- drivers/crypto/allwinner/sun8i-ss/Makefile| 2 + .../crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 205 +++- .../crypto/allwinner/sun8i-ss/sun8i-ss-hash.c | 444 ++ .../crypto/allwinner/sun8i-ss/sun8i-ss-prng.c | 173 +++ drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h | 89 +++- 13 files changed, 2240 insertions(+), 59 deletions(-) create mode 100644 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c create mode 100644 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c create mode 100644 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c create mode 100644 drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c create mode 100644 drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c -- 2.26.2
[PATCH v7 17/17] crypto: sun8i-ss: fix comparison of integer expressions of different signedness
This patch fixes the warning:
warning: comparison of integer expressions of different signedness: 'int' and
'long unsigned int' [-Wsign-compare]
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
index 739874596c72..c9cfe20b383d 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
@@ -414,7 +414,7 @@ static struct sun8i_ss_alg_template ss_algs[] = {
static int sun8i_ss_dbgfs_read(struct seq_file *seq, void *v)
{
struct sun8i_ss_dev *ss = seq->private;
- int i;
+ unsigned int i;
for (i = 0; i < MAXFLOW; i++)
seq_printf(seq, "Channel %d: nreq %lu\n", i,
ss->flows[i].stat_req);
@@ -571,7 +571,8 @@ static void sun8i_ss_pm_exit(struct sun8i_ss_dev *ss)
static int sun8i_ss_register_algs(struct sun8i_ss_dev *ss)
{
- int ss_method, err, id, i;
+ int ss_method, err, id;
+ unsigned int i;
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
ss_algs[i].ss = ss;
@@ -642,7 +643,7 @@ static int sun8i_ss_register_algs(struct sun8i_ss_dev *ss)
static void sun8i_ss_unregister_algs(struct sun8i_ss_dev *ss)
{
- int i;
+ unsigned int i;
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
if (!ss_algs[i].ss)
--
2.26.2
[PATCH] block/rnbd: send_msg_close if any error occurs after send_msg_open
From: Gioh Kim After send_msg_open is done, send_msg_close should be done if any error occurs and it is necessary to recover what has been done. Signed-off-by: Gioh Kim --- drivers/block/rnbd/rnbd-clt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/block/rnbd/rnbd-clt.c b/drivers/block/rnbd/rnbd-clt.c index cc6a4e2587ae..4a24603d5224 100644 --- a/drivers/block/rnbd/rnbd-clt.c +++ b/drivers/block/rnbd/rnbd-clt.c @@ -1520,7 +1520,7 @@ struct rnbd_clt_dev *rnbd_clt_map_device(const char *sessname, "map_device: Failed to configure device, err: %d\n", ret); mutex_unlock(&dev->lock); - goto del_dev; + goto send_close; } rnbd_clt_info(dev, @@ -1539,6 +1539,8 @@ struct rnbd_clt_dev *rnbd_clt_map_device(const char *sessname, return dev; +send_close: + send_msg_close(dev, dev->device_id, WAIT); del_dev: delete_dev(dev); put_dev: -- 2.20.1
[PATCH v7 16/17] crypto: sun8i-ce: fix comparison of integer expressions of different signedness
This patch fixes the warning:
warning: comparison of integer expressions of different signedness: 'int' and
'long unsigned int' [-Wsign-compare]
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
index 116425e3d2b9..cf320898a4b1 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
@@ -566,7 +566,7 @@ static struct sun8i_ce_alg_template ce_algs[] = {
static int sun8i_ce_dbgfs_read(struct seq_file *seq, void *v)
{
struct sun8i_ce_dev *ce = seq->private;
- int i;
+ unsigned int i;
for (i = 0; i < MAXFLOW; i++)
seq_printf(seq, "Channel %d: nreq %lu\n", i,
ce->chanlist[i].stat_req);
@@ -778,7 +778,8 @@ static int sun8i_ce_get_clks(struct sun8i_ce_dev *ce)
static int sun8i_ce_register_algs(struct sun8i_ce_dev *ce)
{
- int ce_method, err, id, i;
+ int ce_method, err, id;
+ unsigned int i;
for (i = 0; i < ARRAY_SIZE(ce_algs); i++) {
ce_algs[i].ce = ce;
@@ -858,7 +859,7 @@ static int sun8i_ce_register_algs(struct sun8i_ce_dev *ce)
static void sun8i_ce_unregister_algs(struct sun8i_ce_dev *ce)
{
- int i;
+ unsigned int i;
for (i = 0; i < ARRAY_SIZE(ce_algs); i++) {
if (!ce_algs[i].ce)
--
2.26.2
[PATCH v7 14/17] crypto: sun8i-ce: Add support for the PRNG
This patch had support for the PRNG present in the CE.
The output was tested with rngtest without any failure.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/Kconfig | 8 +
drivers/crypto/allwinner/sun8i-ce/Makefile| 1 +
.../crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 58 ++-
.../crypto/allwinner/sun8i-ce/sun8i-ce-prng.c | 164 ++
drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h | 31
5 files changed, 261 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-prng.c
diff --git a/drivers/crypto/allwinner/Kconfig b/drivers/crypto/allwinner/Kconfig
index fa34df7fbf78..bf4d2a6328dc 100644
--- a/drivers/crypto/allwinner/Kconfig
+++ b/drivers/crypto/allwinner/Kconfig
@@ -88,6 +88,14 @@ config CRYPTO_DEV_SUN8I_CE_HASH
help
Say y to enable support for hash algorithms.
+config CRYPTO_DEV_SUN8I_CE_PRNG
+ bool "Support for Allwinner Crypto Engine PRNG"
+ depends on CRYPTO_DEV_SUN8I_CE
+ select CRYPTO_RNG
+ help
+ Select this option if you want to provide kernel-side support for
+ the Pseudo-Random Number Generator found in the Crypto Engine.
+
config CRYPTO_DEV_SUN8I_SS
tristate "Support for Allwinner Security System cryptographic offloader"
select CRYPTO_SKCIPHER
diff --git a/drivers/crypto/allwinner/sun8i-ce/Makefile
b/drivers/crypto/allwinner/sun8i-ce/Makefile
index d1b1f0e86c79..c0ea81da2c7d 100644
--- a/drivers/crypto/allwinner/sun8i-ce/Makefile
+++ b/drivers/crypto/allwinner/sun8i-ce/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_CRYPTO_DEV_SUN8I_CE) += sun8i-ce.o
sun8i-ce-y += sun8i-ce-core.o sun8i-ce-cipher.o
sun8i-ce-$(CONFIG_CRYPTO_DEV_SUN8I_CE_HASH) += sun8i-ce-hash.o
+sun8i-ce-$(CONFIG_CRYPTO_DEV_SUN8I_CE_PRNG) += sun8i-ce-prng.o
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
index 3ef5b1079be3..9b7f8fdc4992 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "sun8i-ce.h"
@@ -45,6 +46,7 @@ static const struct ce_variant ce_h3_variant = {
{ "mod", 5000, 0 },
},
.esr = ESR_H3,
+ .prng = CE_ALG_PRNG,
};
static const struct ce_variant ce_h5_variant = {
@@ -60,6 +62,7 @@ static const struct ce_variant ce_h5_variant = {
{ "mod", 3, 0 },
},
.esr = ESR_H5,
+ .prng = CE_ALG_PRNG,
};
static const struct ce_variant ce_h6_variant = {
@@ -72,12 +75,14 @@ static const struct ce_variant ce_h6_variant = {
},
.cipher_t_dlen_in_bytes = true,
.hash_t_dlen_in_bits = true,
+ .prng_t_dlen_in_bytes = true,
.ce_clks = {
{ "bus", 0, 2 },
{ "mod", 3, 0 },
{ "ram", 0, 4 },
},
.esr = ESR_H6,
+ .prng = CE_ALG_PRNG_V2,
};
static const struct ce_variant ce_a64_variant = {
@@ -93,6 +98,7 @@ static const struct ce_variant ce_a64_variant = {
{ "mod", 3, 0 },
},
.esr = ESR_A64,
+ .prng = CE_ALG_PRNG,
};
static const struct ce_variant ce_r40_variant = {
@@ -108,15 +114,17 @@ static const struct ce_variant ce_r40_variant = {
{ "mod", 3, 0 },
},
.esr = ESR_R40,
+ .prng = CE_ALG_PRNG,
};
/*
* sun8i_ce_get_engine_number() get the next channel slot
* This is a simple round-robin way of getting the next channel
+ * The flow 3 is reserve for xRNG operations
*/
int sun8i_ce_get_engine_number(struct sun8i_ce_dev *ce)
{
- return atomic_inc_return(&ce->flow) % MAXFLOW;
+ return atomic_inc_return(&ce->flow) % (MAXFLOW - 1);
}
int sun8i_ce_run_task(struct sun8i_ce_dev *ce, int flow, const char *name)
@@ -527,6 +535,25 @@ static struct sun8i_ce_alg_template ce_algs[] = {
}
},
#endif
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_PRNG
+{
+ .type = CRYPTO_ALG_TYPE_RNG,
+ .alg.rng = {
+ .base = {
+ .cra_name = "stdrng",
+ .cra_driver_name= "sun8i-ce-prng",
+ .cra_priority = 300,
+ .cra_ctxsize= sizeof(struct
sun8i_ce_rng_tfm_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_init = sun8i_ce_prng_init,
+ .cra_exit = sun8i_ce_prng_exit,
+ },
+ .generate = sun8i_ce_prng_generate,
+ .seed = sun8i_ce_prng_seed,
+ .seedsize = PRNG_SEED_SIZE,
+ }
+},
+#endif
};
#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_DEBUG
@@ -554,6 +581,12 @@ static int
[PATCH v7 07/17] crypto: sun8i-ce: handle endianness of t_common_ctl
t_common_ctl is LE32 so we need to convert its value before using it.
This value is only used on H6 (ignored on other SoCs) and not handling
the endianness cause failure on xRNG/hashes operations on H6 when running BE.
Fixes: 06f751b61329 ("crypto: allwinner - Add sun8i-ce Crypto Engine")
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
index 138759dc8190..08ed1ca12baf 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
@@ -120,7 +120,10 @@ int sun8i_ce_run_task(struct sun8i_ce_dev *ce, int flow,
const char *name)
/* Be sure all data is written before enabling the task */
wmb();
- v = 1 | (ce->chanlist[flow].tl->t_common_ctl & 0x7F) << 8;
+ /* Only H6 needs to write a part of t_common_ctl along with "1", but
since it is ignored
+* on older SoCs, we have no reason to complicate things.
+*/
+ v = 1 | ((le32_to_cpu(ce->chanlist[flow].tl->t_common_ctl) & 0x7F) <<
8);
writel(v, ce->base + CE_TLR);
mutex_unlock(&ce->mlock);
--
2.26.2
[PATCH v7 11/17] crypto: sun8i-ce: rename has_t_dlen_in_bytes to cipher_t_dlen_in_bytes
Hash algorithms will need also a spetial t_dlen handling, but since the
meaning will be different, rename the current flag to specify it apply
only on ciphers algorithms.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 2 +-
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 2 +-
drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h| 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index cae307e6bcac..33707a2e55ff 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -118,7 +118,7 @@ static int sun8i_ce_cipher_prepare(struct crypto_engine
*engine, void *async_req
common |= rctx->op_dir | CE_COMM_INT;
cet->t_common_ctl = cpu_to_le32(common);
/* CTS and recent CE (H6) need length in bytes, in word otherwise */
- if (ce->variant->has_t_dlen_in_bytes)
+ if (ce->variant->cipher_t_dlen_in_bytes)
cet->t_dlen = cpu_to_le32(areq->cryptlen);
else
cet->t_dlen = cpu_to_le32(areq->cryptlen / 4);
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
index 65748dfa7a48..688976011f07 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
@@ -61,7 +61,7 @@ static const struct ce_variant ce_h6_variant = {
},
.op_mode = { CE_OP_ECB, CE_OP_CBC
},
- .has_t_dlen_in_bytes = true,
+ .cipher_t_dlen_in_bytes = true,
.ce_clks = {
{ "bus", 0, 2 },
{ "mod", 3, 0 },
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
index 6e191d1fa140..0b513771498a 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
@@ -97,7 +97,7 @@ struct ce_clock {
* @alg_cipher:list of supported ciphers. for each CE_ID_ this will
give the
* coresponding CE_ALG_XXX value
* @op_mode: list of supported block modes
- * @has_t_dlen_in_bytes: Does the request size for cipher is in
+ * @cipher_t_dlen_in_bytes:Does the request size for cipher is in
* bytes or words
* @ce_clks: list of clocks needed by this variant
* @esr: The type of error register
@@ -105,7 +105,7 @@ struct ce_clock {
struct ce_variant {
char alg_cipher[CE_ID_CIPHER_MAX];
u32 op_mode[CE_ID_OP_MAX];
- bool has_t_dlen_in_bytes;
+ bool cipher_t_dlen_in_bytes;
struct ce_clock ce_clks[CE_MAX_CLOCKS];
int esr;
};
--
2.26.2
[PATCH v7 02/17] crypto: sun8i-ss: Add support for the PRNG
This patch had support for the PRNG present in the SS.
The output was tested with rngtest without any failure.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/Kconfig | 8 +
drivers/crypto/allwinner/sun8i-ss/Makefile| 1 +
.../crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 39
.../crypto/allwinner/sun8i-ss/sun8i-ss-prng.c | 173 ++
drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h | 25 +++
5 files changed, 246 insertions(+)
create mode 100644 drivers/crypto/allwinner/sun8i-ss/sun8i-ss-prng.c
diff --git a/drivers/crypto/allwinner/Kconfig b/drivers/crypto/allwinner/Kconfig
index 96fed786ee75..b5f4f1c090ce 100644
--- a/drivers/crypto/allwinner/Kconfig
+++ b/drivers/crypto/allwinner/Kconfig
@@ -104,3 +104,11 @@ config CRYPTO_DEV_SUN8I_SS_DEBUG
Say y to enable sun8i-ss debug stats.
This will create /sys/kernel/debug/sun8i-ss/stats for displaying
the number of requests per flow and per algorithm.
+
+config CRYPTO_DEV_SUN8I_SS_PRNG
+ bool "Support for Allwinner Security System PRNG"
+ depends on CRYPTO_DEV_SUN8I_SS
+ select CRYPTO_RNG
+ help
+ Select this option if you want to provide kernel-side support for
+ the Pseudo-Random Number Generator found in the Security System.
diff --git a/drivers/crypto/allwinner/sun8i-ss/Makefile
b/drivers/crypto/allwinner/sun8i-ss/Makefile
index add7b0543fd5..49f2f912c816 100644
--- a/drivers/crypto/allwinner/sun8i-ss/Makefile
+++ b/drivers/crypto/allwinner/sun8i-ss/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_CRYPTO_DEV_SUN8I_SS) += sun8i-ss.o
sun8i-ss-y += sun8i-ss-core.o sun8i-ss-cipher.o
+sun8i-ss-$(CONFIG_CRYPTO_DEV_SUN8I_SS_PRNG) += sun8i-ss-prng.o
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
index 97012128385f..ae8321f9a1db 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "sun8i-ss.h"
@@ -264,6 +265,25 @@ static struct sun8i_ss_alg_template ss_algs[] = {
.decrypt= sun8i_ss_skdecrypt,
}
},
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_PRNG
+{
+ .type = CRYPTO_ALG_TYPE_RNG,
+ .alg.rng = {
+ .base = {
+ .cra_name = "stdrng",
+ .cra_driver_name= "sun8i-ss-prng",
+ .cra_priority = 300,
+ .cra_ctxsize = sizeof(struct sun8i_ss_rng_tfm_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_init = sun8i_ss_prng_init,
+ .cra_exit = sun8i_ss_prng_exit,
+ },
+ .generate = sun8i_ss_prng_generate,
+ .seed = sun8i_ss_prng_seed,
+ .seedsize = PRNG_SEED_SIZE,
+ }
+},
+#endif
};
#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_DEBUG
@@ -285,6 +305,12 @@ static int sun8i_ss_dbgfs_read(struct seq_file *seq, void
*v)
ss_algs[i].alg.skcipher.base.cra_name,
ss_algs[i].stat_req, ss_algs[i].stat_fb);
break;
+ case CRYPTO_ALG_TYPE_RNG:
+ seq_printf(seq, "%s %s %lu %lu\n",
+ ss_algs[i].alg.rng.base.cra_driver_name,
+ ss_algs[i].alg.rng.base.cra_name,
+ ss_algs[i].stat_req, ss_algs[i].stat_bytes);
+ break;
}
}
return 0;
@@ -448,6 +474,14 @@ static int sun8i_ss_register_algs(struct sun8i_ss_dev *ss)
return err;
}
break;
+ case CRYPTO_ALG_TYPE_RNG:
+ err = crypto_register_rng(&ss_algs[i].alg.rng);
+ if (err) {
+ dev_err(ss->dev, "Fail to register %s\n",
+ ss_algs[i].alg.rng.base.cra_name);
+ ss_algs[i].ss = NULL;
+ }
+ break;
default:
ss_algs[i].ss = NULL;
dev_err(ss->dev, "ERROR: tried to register an unknown
algo\n");
@@ -469,6 +503,11 @@ static void sun8i_ss_unregister_algs(struct sun8i_ss_dev
*ss)
ss_algs[i].alg.skcipher.base.cra_name);
crypto_unregister_skcipher(&ss_algs[i].alg.skcipher);
break;
+ case CRYPTO_ALG_TYPE_RNG:
+ dev_info(ss->dev, "Unregister %d %s\n", i,
+ss_algs[i].alg.rng.base.cra_name);
+ crypto_unregister_
[PATCH v7 15/17] crypto: sun8i-ce: Add support for the TRNG
This patch had support for the TRNG present in the CE.
Note that according to the algorithm ID, 2 version of the TRNG exists,
the first present in H3/H5/R40/A64 and the second present in H6.
This patch adds support for both, but only the second is working
reliabily according to rngtest.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/Kconfig | 8 ++
drivers/crypto/allwinner/sun8i-ce/Makefile| 1 +
.../crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 18 +++
.../crypto/allwinner/sun8i-ce/sun8i-ce-trng.c | 127 ++
drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h | 18 +++
5 files changed, 172 insertions(+)
create mode 100644 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c
diff --git a/drivers/crypto/allwinner/Kconfig b/drivers/crypto/allwinner/Kconfig
index bf4d2a6328dc..0e72543ad1f1 100644
--- a/drivers/crypto/allwinner/Kconfig
+++ b/drivers/crypto/allwinner/Kconfig
@@ -96,6 +96,14 @@ config CRYPTO_DEV_SUN8I_CE_PRNG
Select this option if you want to provide kernel-side support for
the Pseudo-Random Number Generator found in the Crypto Engine.
+config CRYPTO_DEV_SUN8I_CE_TRNG
+ bool "Support for Allwinner Crypto Engine TRNG"
+ depends on CRYPTO_DEV_SUN8I_CE
+ select HW_RANDOM
+ help
+ Select this option if you want to provide kernel-side support for
+ the True Random Number Generator found in the Crypto Engine.
+
config CRYPTO_DEV_SUN8I_SS
tristate "Support for Allwinner Security System cryptographic offloader"
select CRYPTO_SKCIPHER
diff --git a/drivers/crypto/allwinner/sun8i-ce/Makefile
b/drivers/crypto/allwinner/sun8i-ce/Makefile
index c0ea81da2c7d..0842eb2d9408 100644
--- a/drivers/crypto/allwinner/sun8i-ce/Makefile
+++ b/drivers/crypto/allwinner/sun8i-ce/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_CRYPTO_DEV_SUN8I_CE) += sun8i-ce.o
sun8i-ce-y += sun8i-ce-core.o sun8i-ce-cipher.o
sun8i-ce-$(CONFIG_CRYPTO_DEV_SUN8I_CE_HASH) += sun8i-ce-hash.o
sun8i-ce-$(CONFIG_CRYPTO_DEV_SUN8I_CE_PRNG) += sun8i-ce-prng.o
+sun8i-ce-$(CONFIG_CRYPTO_DEV_SUN8I_CE_TRNG) += sun8i-ce-trng.o
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
index 9b7f8fdc4992..116425e3d2b9 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
@@ -47,6 +47,7 @@ static const struct ce_variant ce_h3_variant = {
},
.esr = ESR_H3,
.prng = CE_ALG_PRNG,
+ .trng = CE_ID_NOTSUPP,
};
static const struct ce_variant ce_h5_variant = {
@@ -63,6 +64,7 @@ static const struct ce_variant ce_h5_variant = {
},
.esr = ESR_H5,
.prng = CE_ALG_PRNG,
+ .trng = CE_ID_NOTSUPP,
};
static const struct ce_variant ce_h6_variant = {
@@ -76,6 +78,7 @@ static const struct ce_variant ce_h6_variant = {
.cipher_t_dlen_in_bytes = true,
.hash_t_dlen_in_bits = true,
.prng_t_dlen_in_bytes = true,
+ .trng_t_dlen_in_bytes = true,
.ce_clks = {
{ "bus", 0, 2 },
{ "mod", 3, 0 },
@@ -83,6 +86,7 @@ static const struct ce_variant ce_h6_variant = {
},
.esr = ESR_H6,
.prng = CE_ALG_PRNG_V2,
+ .trng = CE_ALG_TRNG_V2,
};
static const struct ce_variant ce_a64_variant = {
@@ -99,6 +103,7 @@ static const struct ce_variant ce_a64_variant = {
},
.esr = ESR_A64,
.prng = CE_ALG_PRNG,
+ .trng = CE_ID_NOTSUPP,
};
static const struct ce_variant ce_r40_variant = {
@@ -115,6 +120,7 @@ static const struct ce_variant ce_r40_variant = {
},
.esr = ESR_R40,
.prng = CE_ALG_PRNG,
+ .trng = CE_ID_NOTSUPP,
};
/*
@@ -589,6 +595,10 @@ static int sun8i_ce_dbgfs_read(struct seq_file *seq, void
*v)
break;
}
}
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_TRNG
+ seq_printf(seq, "HWRNG %lu %lu\n",
+ ce->hwrng_stat_req, ce->hwrng_stat_bytes);
+#endif
return 0;
}
@@ -939,6 +949,10 @@ static int sun8i_ce_probe(struct platform_device *pdev)
if (err < 0)
goto error_alg;
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_TRNG
+ sun8i_ce_hwrng_register(ce);
+#endif
+
v = readl(ce->base + CE_CTR);
v >>= CE_DIE_ID_SHIFT;
v &= CE_DIE_ID_MASK;
@@ -968,6 +982,10 @@ static int sun8i_ce_remove(struct platform_device *pdev)
{
struct sun8i_ce_dev *ce = platform_get_drvdata(pdev);
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_TRNG
+ sun8i_ce_hwrng_unregister(ce);
+#endif
+
sun8i_ce_unregister_algs(ce);
#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_DEBUG
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trng.c
new file mode 100644
index ..af99730d8fd1
--- /dev/null
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-trn
[PATCH v7 06/17] crypto: sun8i-ss: better debug printing
This patch reworks the way debug info are printed.
Instead of printing raw numbers, let's add a bit of context.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
index 5cf00d03be1f..739874596c72 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
@@ -424,19 +424,19 @@ static int sun8i_ss_dbgfs_read(struct seq_file *seq, void
*v)
continue;
switch (ss_algs[i].type) {
case CRYPTO_ALG_TYPE_SKCIPHER:
- seq_printf(seq, "%s %s %lu %lu\n",
+ seq_printf(seq, "%s %s reqs=%lu fallback=%lu\n",
ss_algs[i].alg.skcipher.base.cra_driver_name,
ss_algs[i].alg.skcipher.base.cra_name,
ss_algs[i].stat_req, ss_algs[i].stat_fb);
break;
case CRYPTO_ALG_TYPE_RNG:
- seq_printf(seq, "%s %s %lu %lu\n",
+ seq_printf(seq, "%s %s reqs=%lu tsize=%lu\n",
ss_algs[i].alg.rng.base.cra_driver_name,
ss_algs[i].alg.rng.base.cra_name,
ss_algs[i].stat_req, ss_algs[i].stat_bytes);
break;
case CRYPTO_ALG_TYPE_AHASH:
- seq_printf(seq, "%s %s %lu %lu\n",
+ seq_printf(seq, "%s %s reqs=%lu fallback=%lu\n",
ss_algs[i].alg.hash.halg.base.cra_driver_name,
ss_algs[i].alg.hash.halg.base.cra_name,
ss_algs[i].stat_req, ss_algs[i].stat_fb);
--
2.26.2
[PATCH v7 03/17] crypto: sun8i-ss: support hash algorithms
The SS support multiples hash algorithms, this patch adds support for
MD5, SHA1, SHA224 and SHA256.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/Kconfig | 9 +
drivers/crypto/allwinner/sun8i-ss/Makefile| 1 +
.../crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 155 ++
.../crypto/allwinner/sun8i-ss/sun8i-ss-hash.c | 444 ++
drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h | 58 +++
5 files changed, 667 insertions(+)
create mode 100644 drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c
diff --git a/drivers/crypto/allwinner/Kconfig b/drivers/crypto/allwinner/Kconfig
index b5f4f1c090ce..b346850a91b9 100644
--- a/drivers/crypto/allwinner/Kconfig
+++ b/drivers/crypto/allwinner/Kconfig
@@ -112,3 +112,12 @@ config CRYPTO_DEV_SUN8I_SS_PRNG
help
Select this option if you want to provide kernel-side support for
the Pseudo-Random Number Generator found in the Security System.
+
+config CRYPTO_DEV_SUN8I_SS_HASH
+ bool "Enable support for hash on sun8i-ss"
+ depends on CRYPTO_DEV_SUN8I_SS
+ select MD5
+ select SHA1
+ select SHA256
+ help
+ Say y to enable support for hash algorithms.
diff --git a/drivers/crypto/allwinner/sun8i-ss/Makefile
b/drivers/crypto/allwinner/sun8i-ss/Makefile
index 49f2f912c816..aabfd893c817 100644
--- a/drivers/crypto/allwinner/sun8i-ss/Makefile
+++ b/drivers/crypto/allwinner/sun8i-ss/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_CRYPTO_DEV_SUN8I_SS) += sun8i-ss.o
sun8i-ss-y += sun8i-ss-core.o sun8i-ss-cipher.o
sun8i-ss-$(CONFIG_CRYPTO_DEV_SUN8I_SS_PRNG) += sun8i-ss-prng.o
+sun8i-ss-$(CONFIG_CRYPTO_DEV_SUN8I_SS_HASH) += sun8i-ss-hash.o
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
index ae8321f9a1db..5cf00d03be1f 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
@@ -41,6 +41,8 @@ static const struct ss_variant ss_a80_variant = {
static const struct ss_variant ss_a83t_variant = {
.alg_cipher = { SS_ALG_AES, SS_ALG_DES, SS_ALG_3DES,
},
+ .alg_hash = { SS_ALG_MD5, SS_ALG_SHA1, SS_ALG_SHA224, SS_ALG_SHA256,
+ },
.op_mode = { SS_OP_ECB, SS_OP_CBC,
},
.ss_clks = {
@@ -284,6 +286,128 @@ static struct sun8i_ss_alg_template ss_algs[] = {
}
},
#endif
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_HASH
+{ .type = CRYPTO_ALG_TYPE_AHASH,
+ .ss_algo_id = SS_ID_HASH_MD5,
+ .alg.hash = {
+ .init = sun8i_ss_hash_init,
+ .update = sun8i_ss_hash_update,
+ .final = sun8i_ss_hash_final,
+ .finup = sun8i_ss_hash_finup,
+ .digest = sun8i_ss_hash_digest,
+ .export = sun8i_ss_hash_export,
+ .import = sun8i_ss_hash_import,
+ .halg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .statesize = sizeof(struct md5_state),
+ .base = {
+ .cra_name = "md5",
+ .cra_driver_name = "md5-sun8i-ss",
+ .cra_priority = 300,
+ .cra_alignmask = 3,
+ .cra_flags = CRYPTO_ALG_TYPE_AHASH |
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = MD5_HMAC_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct
sun8i_ss_hash_tfm_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_init = sun8i_ss_hash_crainit,
+ .cra_exit = sun8i_ss_hash_craexit,
+ }
+ }
+ }
+},
+{ .type = CRYPTO_ALG_TYPE_AHASH,
+ .ss_algo_id = SS_ID_HASH_SHA1,
+ .alg.hash = {
+ .init = sun8i_ss_hash_init,
+ .update = sun8i_ss_hash_update,
+ .final = sun8i_ss_hash_final,
+ .finup = sun8i_ss_hash_finup,
+ .digest = sun8i_ss_hash_digest,
+ .export = sun8i_ss_hash_export,
+ .import = sun8i_ss_hash_import,
+ .halg = {
+ .digestsize = SHA1_DIGEST_SIZE,
+ .statesize = sizeof(struct sha1_state),
+ .base = {
+ .cra_name = "sha1",
+ .cra_driver_name = "sha1-sun8i-ss",
+ .cra_priority = 300,
+ .cra_alignmask = 3,
+ .cra_flags = CRYPTO_ALG_TYPE_AHASH |
+ CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = SHA1_BLOCK_SIZE,
+
[PATCH v7 04/17] crypto: sun8i-ss: fix a trivial typo
This fixes a trivial typo.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
index 377ea7acb54d..da71d8059019 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
@@ -100,7 +100,7 @@ struct ss_clock {
* @alg_hash: list of supported hashes. for each SS_ID_ this will give the
* corresponding SS_ALG_XXX value
* @op_mode: list of supported block modes
- * @ss_clks! list of clock needed by this variant
+ * @ss_clks: list of clock needed by this variant
*/
struct ss_variant {
char alg_cipher[SS_ID_CIPHER_MAX];
--
2.26.2
[PATCH v7 10/17] crypto: sun8i-ce: handle different error registers
Error registers are different across SoCs.
This patch handle those difference.
Signed-off-by: Corentin Labbe
---
.../crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 62 ---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h | 8 +++
2 files changed, 62 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
index 08ed1ca12baf..65748dfa7a48 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
@@ -40,7 +40,8 @@ static const struct ce_variant ce_h3_variant = {
.ce_clks = {
{ "bus", 0, 2 },
{ "mod", 5000, 0 },
- }
+ },
+ .esr = ESR_H3,
};
static const struct ce_variant ce_h5_variant = {
@@ -51,7 +52,8 @@ static const struct ce_variant ce_h5_variant = {
.ce_clks = {
{ "bus", 0, 2 },
{ "mod", 3, 0 },
- }
+ },
+ .esr = ESR_H5,
};
static const struct ce_variant ce_h6_variant = {
@@ -64,7 +66,8 @@ static const struct ce_variant ce_h6_variant = {
{ "bus", 0, 2 },
{ "mod", 3, 0 },
{ "ram", 0, 4 },
- }
+ },
+ .esr = ESR_H6,
};
static const struct ce_variant ce_a64_variant = {
@@ -75,7 +78,8 @@ static const struct ce_variant ce_a64_variant = {
.ce_clks = {
{ "bus", 0, 2 },
{ "mod", 3, 0 },
- }
+ },
+ .esr = ESR_A64,
};
static const struct ce_variant ce_r40_variant = {
@@ -86,7 +90,8 @@ static const struct ce_variant ce_r40_variant = {
.ce_clks = {
{ "bus", 0, 2 },
{ "mod", 3, 0 },
- }
+ },
+ .esr = ESR_R40,
};
/*
@@ -102,6 +107,7 @@ int sun8i_ce_run_task(struct sun8i_ce_dev *ce, int flow,
const char *name)
{
u32 v;
int err = 0;
+ struct ce_task *cet = ce->chanlist[flow].tl;
#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_DEBUG
ce->chanlist[flow].stat_req++;
@@ -131,19 +137,56 @@ int sun8i_ce_run_task(struct sun8i_ce_dev *ce, int flow,
const char *name)
msecs_to_jiffies(ce->chanlist[flow].timeout));
if (ce->chanlist[flow].status == 0) {
- dev_err(ce->dev, "DMA timeout for %s\n", name);
+ dev_err(ce->dev, "DMA timeout for %s (tm=%d) on flow %d\n",
name,
+ ce->chanlist[flow].timeout, flow);
err = -EFAULT;
}
/* No need to lock for this read, the channel is locked so
* nothing could modify the error value for this channel
*/
v = readl(ce->base + CE_ESR);
- if (v) {
+ switch (ce->variant->esr) {
+ case ESR_H3:
+ /* Sadly, the error bit is not per flow */
+ if (v) {
+ dev_err(ce->dev, "CE ERROR: %x for flow %x\n", v, flow);
+ err = -EFAULT;
+ print_hex_dump(KERN_INFO, "TASK: ", DUMP_PREFIX_NONE,
16, 4,
+ cet, sizeof(struct ce_task), false);
+ }
+ if (v & CE_ERR_ALGO_NOTSUP)
+ dev_err(ce->dev, "CE ERROR: algorithm not supported\n");
+ if (v & CE_ERR_DATALEN)
+ dev_err(ce->dev, "CE ERROR: data length error\n");
+ if (v & CE_ERR_KEYSRAM)
+ dev_err(ce->dev, "CE ERROR: keysram access error for
AES\n");
+ break;
+ case ESR_A64:
+ case ESR_H5:
+ case ESR_R40:
v >>= (flow * 4);
+ v &= 0xF;
+ if (v) {
+ dev_err(ce->dev, "CE ERROR: %x for flow %x\n", v, flow);
+ err = -EFAULT;
+ print_hex_dump(KERN_INFO, "TASK: ", DUMP_PREFIX_NONE,
16, 4,
+ cet, sizeof(struct ce_task), false);
+ }
+ if (v & CE_ERR_ALGO_NOTSUP)
+ dev_err(ce->dev, "CE ERROR: algorithm not supported\n");
+ if (v & CE_ERR_DATALEN)
+ dev_err(ce->dev, "CE ERROR: data length error\n");
+ if (v & CE_ERR_KEYSRAM)
+ dev_err(ce->dev, "CE ERROR: keysram access error for
AES\n");
+ break;
+ case ESR_H6:
+ v >>= (flow * 8);
v &= 0xFF;
if (v) {
dev_err(ce->dev, "CE ERROR: %x for flow %x\n", v, flow);
err = -EFAULT;
+ print_hex_dump(KERN_INFO, "TASK: ", DUMP_PREFIX_NONE,
16, 4,
+ cet, sizeof(struct ce_task), false);
}
[PATCH v7 12/17] crypto: sun8i-ce: support hash algorithms
The CE support multiples hash algorithms, this patch adds support for
MD5, SHA1, SHA224, SHA256, SHA384 and SHA512.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/Kconfig | 10 +
drivers/crypto/allwinner/sun8i-ce/Makefile| 1 +
.../crypto/allwinner/sun8i-ce/sun8i-ce-core.c | 229 ++
.../crypto/allwinner/sun8i-ce/sun8i-ce-hash.c | 413 ++
drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h | 58 +++
5 files changed, 711 insertions(+)
create mode 100644 drivers/crypto/allwinner/sun8i-ce/sun8i-ce-hash.c
diff --git a/drivers/crypto/allwinner/Kconfig b/drivers/crypto/allwinner/Kconfig
index b346850a91b9..fa34df7fbf78 100644
--- a/drivers/crypto/allwinner/Kconfig
+++ b/drivers/crypto/allwinner/Kconfig
@@ -78,6 +78,16 @@ config CRYPTO_DEV_SUN8I_CE_DEBUG
This will create /sys/kernel/debug/sun8i-ce/stats for displaying
the number of requests per flow and per algorithm.
+config CRYPTO_DEV_SUN8I_CE_HASH
+ bool "Enable support for hash on sun8i-ce"
+ depends on CRYPTO_DEV_SUN8I_CE
+ select MD5
+ select SHA1
+ select SHA256
+ select SHA512
+ help
+ Say y to enable support for hash algorithms.
+
config CRYPTO_DEV_SUN8I_SS
tristate "Support for Allwinner Security System cryptographic offloader"
select CRYPTO_SKCIPHER
diff --git a/drivers/crypto/allwinner/sun8i-ce/Makefile
b/drivers/crypto/allwinner/sun8i-ce/Makefile
index 08b68c3c1ca9..d1b1f0e86c79 100644
--- a/drivers/crypto/allwinner/sun8i-ce/Makefile
+++ b/drivers/crypto/allwinner/sun8i-ce/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_CRYPTO_DEV_SUN8I_CE) += sun8i-ce.o
sun8i-ce-y += sun8i-ce-core.o sun8i-ce-cipher.o
+sun8i-ce-$(CONFIG_CRYPTO_DEV_SUN8I_CE_HASH) += sun8i-ce-hash.o
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
index 688976011f07..3ef5b1079be3 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c
@@ -35,6 +35,9 @@
static const struct ce_variant ce_h3_variant = {
.alg_cipher = { CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
},
+ .alg_hash = { CE_ALG_MD5, CE_ALG_SHA1, CE_ALG_SHA224, CE_ALG_SHA256,
+ CE_ALG_SHA384, CE_ALG_SHA512
+ },
.op_mode = { CE_OP_ECB, CE_OP_CBC
},
.ce_clks = {
@@ -47,6 +50,9 @@ static const struct ce_variant ce_h3_variant = {
static const struct ce_variant ce_h5_variant = {
.alg_cipher = { CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
},
+ .alg_hash = { CE_ALG_MD5, CE_ALG_SHA1, CE_ALG_SHA224, CE_ALG_SHA256,
+ CE_ID_NOTSUPP, CE_ID_NOTSUPP
+ },
.op_mode = { CE_OP_ECB, CE_OP_CBC
},
.ce_clks = {
@@ -59,9 +65,13 @@ static const struct ce_variant ce_h5_variant = {
static const struct ce_variant ce_h6_variant = {
.alg_cipher = { CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
},
+ .alg_hash = { CE_ALG_MD5, CE_ALG_SHA1, CE_ALG_SHA224, CE_ALG_SHA256,
+ CE_ALG_SHA384, CE_ALG_SHA512
+ },
.op_mode = { CE_OP_ECB, CE_OP_CBC
},
.cipher_t_dlen_in_bytes = true,
+ .hash_t_dlen_in_bits = true,
.ce_clks = {
{ "bus", 0, 2 },
{ "mod", 3, 0 },
@@ -73,6 +83,9 @@ static const struct ce_variant ce_h6_variant = {
static const struct ce_variant ce_a64_variant = {
.alg_cipher = { CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
},
+ .alg_hash = { CE_ALG_MD5, CE_ALG_SHA1, CE_ALG_SHA224, CE_ALG_SHA256,
+ CE_ID_NOTSUPP, CE_ID_NOTSUPP
+ },
.op_mode = { CE_OP_ECB, CE_OP_CBC
},
.ce_clks = {
@@ -85,6 +98,9 @@ static const struct ce_variant ce_a64_variant = {
static const struct ce_variant ce_r40_variant = {
.alg_cipher = { CE_ALG_AES, CE_ALG_DES, CE_ALG_3DES,
},
+ .alg_hash = { CE_ALG_MD5, CE_ALG_SHA1, CE_ALG_SHA224, CE_ALG_SHA256,
+ CE_ID_NOTSUPP, CE_ID_NOTSUPP
+ },
.op_mode = { CE_OP_ECB, CE_OP_CBC
},
.ce_clks = {
@@ -329,6 +345,188 @@ static struct sun8i_ce_alg_template ce_algs[] = {
.decrypt= sun8i_ce_skdecrypt,
}
},
+#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_HASH
+{ .type = CRYPTO_ALG_TYPE_AHASH,
+ .ce_algo_id = CE_ID_HASH_MD5,
+ .alg.hash = {
+ .init = sun8i_ce_hash_init,
+ .update = sun8i_ce_hash_update,
+ .final = sun8i_ce_hash_final,
+ .finup = sun8i_ce_hash_finup,
+ .digest = sun8i_ce_hash_digest,
+ .export = sun8i_ce_hash_export,
+ .import = sun8i_ce_hash_import,
+ .halg = {
+ .digestsize = MD5_DIGEST_SIZE,
+ .statesize = sizeof(struct md5_state),
+ .base = {
+ .cra_name = "md5",
+
[PATCH v7 01/17] crypto: sun8i-ss: Add SS_START define
Instead of using an hardcoded value, let's use a defined value for
SS_START.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c | 2 +-
drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
index 9a23515783a6..97012128385f 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c
@@ -61,7 +61,7 @@ int sun8i_ss_run_task(struct sun8i_ss_dev *ss, struct
sun8i_cipher_req_ctx *rctx
const char *name)
{
int flow = rctx->flow;
- u32 v = 1;
+ u32 v = SS_START;
int i;
#ifdef CONFIG_CRYPTO_DEV_SUN8I_SS_DEBUG
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
index 0405767f1f7e..f3ffaea3a59f 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h
@@ -13,6 +13,8 @@
#include
#include
+#define SS_START 1
+
#define SS_ENCRYPTION 0
#define SS_DECRYPTION BIT(6)
--
2.26.2
[PATCH v7 13/17] crypto: sun8i-ce: Add stat_bytes debugfs
This patch adds a new stat_bytes counter in the sun8i-ce debugfs.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
index 9311c114947d..c80006853d10 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
@@ -280,6 +280,7 @@ struct sun8i_ce_hash_reqctx {
* @alg: one of sub struct must be used
* @stat_req: number of request done on this template
* @stat_fb: number of request which has fallbacked
+ * @stat_bytes:total data size done by this template
*/
struct sun8i_ce_alg_template {
u32 type;
@@ -293,6 +294,7 @@ struct sun8i_ce_alg_template {
#ifdef CONFIG_CRYPTO_DEV_SUN8I_CE_DEBUG
unsigned long stat_req;
unsigned long stat_fb;
+ unsigned long stat_bytes;
#endif
};
--
2.26.2
[PATCH v7 09/17] crypto: sun8i-ce: split into prepare/run/unprepare
This patch split the do_one_request into three.
Prepare will handle all DMA mapping and initialisation of the task
structure.
Unprepare will clean all DMA mapping.
And the do_one_request will be limited to just executing the task.
Signed-off-by: Corentin Labbe
---
.../allwinner/sun8i-ce/sun8i-ce-cipher.c | 91 +++
drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h | 8 ++
2 files changed, 79 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index f699b135de74..cae307e6bcac 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -75,8 +75,9 @@ static int sun8i_ce_cipher_fallback(struct skcipher_request
*areq)
return err;
}
-static int sun8i_ce_cipher(struct skcipher_request *areq)
+static int sun8i_ce_cipher_prepare(struct crypto_engine *engine, void
*async_req)
{
+ struct skcipher_request *areq = container_of(async_req, struct
skcipher_request, base);
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(areq);
struct sun8i_cipher_tfm_ctx *op = crypto_skcipher_ctx(tfm);
struct sun8i_ce_dev *ce = op->ce;
@@ -87,7 +88,6 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
struct ce_task *cet;
struct scatterlist *sg;
unsigned int todo, len, offset, ivsize;
- dma_addr_t addr_iv = 0, addr_key = 0;
u32 common, sym;
int flow, i;
int nr_sgs = 0;
@@ -140,13 +140,13 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
cet->t_sym_ctl = cpu_to_le32(sym);
cet->t_asym_ctl = 0;
- addr_key = dma_map_single(ce->dev, op->key, op->keylen, DMA_TO_DEVICE);
- cet->t_key = cpu_to_le32(addr_key);
- if (dma_mapping_error(ce->dev, addr_key)) {
+ rctx->addr_key = dma_map_single(ce->dev, op->key, op->keylen,
DMA_TO_DEVICE);
+ if (dma_mapping_error(ce->dev, rctx->addr_key)) {
dev_err(ce->dev, "Cannot DMA MAP KEY\n");
err = -EFAULT;
goto theend;
}
+ cet->t_key = cpu_to_le32(rctx->addr_key);
ivsize = crypto_skcipher_ivsize(tfm);
if (areq->iv && crypto_skcipher_ivsize(tfm) > 0) {
@@ -167,14 +167,14 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
offset, ivsize, 0);
}
memcpy(rctx->bounce_iv, areq->iv, ivsize);
- addr_iv = dma_map_single(ce->dev, rctx->bounce_iv, rctx->ivlen,
-DMA_TO_DEVICE);
- cet->t_iv = cpu_to_le32(addr_iv);
- if (dma_mapping_error(ce->dev, addr_iv)) {
+ rctx->addr_iv = dma_map_single(ce->dev, rctx->bounce_iv,
rctx->ivlen,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(ce->dev, rctx->addr_iv)) {
dev_err(ce->dev, "Cannot DMA MAP IV\n");
err = -ENOMEM;
goto theend_iv;
}
+ cet->t_iv = cpu_to_le32(rctx->addr_iv);
}
if (areq->src == areq->dst) {
@@ -234,7 +234,9 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
}
chan->timeout = areq->cryptlen;
- err = sun8i_ce_run_task(ce, flow, crypto_tfm_alg_name(areq->base.tfm));
+ rctx->nr_sgs = nr_sgs;
+ rctx->nr_sgd = nr_sgd;
+ return 0;
theend_sgs:
if (areq->src == areq->dst) {
@@ -247,9 +249,8 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
theend_iv:
if (areq->iv && ivsize > 0) {
- if (addr_iv)
- dma_unmap_single(ce->dev, addr_iv, rctx->ivlen,
-DMA_TO_DEVICE);
+ if (rctx->addr_iv)
+ dma_unmap_single(ce->dev, rctx->addr_iv, rctx->ivlen,
DMA_TO_DEVICE);
offset = areq->cryptlen - ivsize;
if (rctx->op_dir & CE_DECRYPTION) {
memcpy(areq->iv, rctx->backup_iv, ivsize);
@@ -262,19 +263,69 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
}
theend_key:
- dma_unmap_single(ce->dev, addr_key, op->keylen, DMA_TO_DEVICE);
+ dma_unmap_single(ce->dev, rctx->addr_key, op->keylen, DMA_TO_DEVICE);
theend:
return err;
}
-static int sun8i_ce_handle_cipher_request(struct crypto_engine *engine, void
*areq)
+static int sun8i_ce_cipher_run(struct crypto_engine *engine, void *areq)
{
- int err;
struct skcipher_request *breq = container_of(areq, struct
skcipher_request, base);
+ struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(breq);
+ struct sun8i_cipher_tfm_ctx *op = crypto_skcipher_ctx(tfm);
+ struct sun8i_ce_dev *ce = op->ce;
+ struct sun8i_cipher_req_ctx *rctx = skcipher_requ
[PATCH v7 08/17] crypto: sun8i-ce: move iv data to request context
Instead of storing IV data in the channel context, store them in the
request context.
Storing them in the channel structure was conceptualy wrong since they
are per request related.
Signed-off-by: Corentin Labbe
---
.../allwinner/sun8i-ce/sun8i-ce-cipher.c | 27 +--
drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h | 10 ---
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
index f996dc3d7dcc..f699b135de74 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c
@@ -88,7 +88,6 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
struct scatterlist *sg;
unsigned int todo, len, offset, ivsize;
dma_addr_t addr_iv = 0, addr_key = 0;
- void *backup_iv = NULL;
u32 common, sym;
int flow, i;
int nr_sgs = 0;
@@ -151,24 +150,24 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
ivsize = crypto_skcipher_ivsize(tfm);
if (areq->iv && crypto_skcipher_ivsize(tfm) > 0) {
- chan->ivlen = ivsize;
- chan->bounce_iv = kzalloc(ivsize, GFP_KERNEL | GFP_DMA);
- if (!chan->bounce_iv) {
+ rctx->ivlen = ivsize;
+ rctx->bounce_iv = kzalloc(ivsize, GFP_KERNEL | GFP_DMA);
+ if (!rctx->bounce_iv) {
err = -ENOMEM;
goto theend_key;
}
if (rctx->op_dir & CE_DECRYPTION) {
- backup_iv = kzalloc(ivsize, GFP_KERNEL);
- if (!backup_iv) {
+ rctx->backup_iv = kzalloc(ivsize, GFP_KERNEL);
+ if (!rctx->backup_iv) {
err = -ENOMEM;
goto theend_key;
}
offset = areq->cryptlen - ivsize;
- scatterwalk_map_and_copy(backup_iv, areq->src, offset,
-ivsize, 0);
+ scatterwalk_map_and_copy(rctx->backup_iv, areq->src,
+offset, ivsize, 0);
}
- memcpy(chan->bounce_iv, areq->iv, ivsize);
- addr_iv = dma_map_single(ce->dev, chan->bounce_iv, chan->ivlen,
+ memcpy(rctx->bounce_iv, areq->iv, ivsize);
+ addr_iv = dma_map_single(ce->dev, rctx->bounce_iv, rctx->ivlen,
DMA_TO_DEVICE);
cet->t_iv = cpu_to_le32(addr_iv);
if (dma_mapping_error(ce->dev, addr_iv)) {
@@ -249,17 +248,17 @@ static int sun8i_ce_cipher(struct skcipher_request *areq)
theend_iv:
if (areq->iv && ivsize > 0) {
if (addr_iv)
- dma_unmap_single(ce->dev, addr_iv, chan->ivlen,
+ dma_unmap_single(ce->dev, addr_iv, rctx->ivlen,
DMA_TO_DEVICE);
offset = areq->cryptlen - ivsize;
if (rctx->op_dir & CE_DECRYPTION) {
- memcpy(areq->iv, backup_iv, ivsize);
- kfree_sensitive(backup_iv);
+ memcpy(areq->iv, rctx->backup_iv, ivsize);
+ kfree_sensitive(rctx->backup_iv);
} else {
scatterwalk_map_and_copy(areq->iv, areq->dst, offset,
ivsize, 0);
}
- kfree(chan->bounce_iv);
+ kfree(rctx->bounce_iv);
}
theend_key:
diff --git a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
index 963645fe4adb..fc4800e8 100644
--- a/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
+++ b/drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h
@@ -129,8 +129,6 @@ struct ce_task {
/*
* struct sun8i_ce_flow - Information used by each flow
* @engine:ptr to the crypto_engine for this flow
- * @bounce_iv: buffer which contain the IV
- * @ivlen: size of bounce_iv
* @complete: completion for the current task on this flow
* @status:set to 1 by interrupt if task is done
* @t_phy: Physical address of task
@@ -139,8 +137,6 @@ struct ce_task {
*/
struct sun8i_ce_flow {
struct crypto_engine *engine;
- void *bounce_iv;
- unsigned int ivlen;
struct completion complete;
int status;
dma_addr_t t_phy;
@@ -183,11 +179,17 @@ struct sun8i_ce_dev {
* struct sun8i_cipher_req_ctx - context for a skcipher request
* @op_dir:direction (encrypt vs decrypt) for this request
* @flow: the flow to use for this request
+ * @backup_iv: buffer which contain the next IV to store
+ * @bounce_iv: buffer which contain the IV
+ * @i
Re: [PATCH -next] dmaengine: iop-adma: Fix pointer cast warnings
On 18-08-20, 19:51, YueHaibing wrote: > drivers/dma/iop-adma.c: In function ‘iop_adma_alloc_chan_resources’: > drivers/dma/iop-adma.c:447:13: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] >hw_desc = (char *) iop_chan->device->dma_desc_pool; > ^ > drivers/dma/iop-adma.c:449:4: warning: cast from pointer to integer of > different size [-Wpointer-to-int-cast] > (dma_addr_t) &hw_desc[idx * IOP_ADMA_SLOT_SIZE]; > ^ > drivers/dma/iop-adma.c: In function ‘iop_adma_probe’: > drivers/dma/iop-adma.c:1301:3: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] >(void *) adev->dma_desc_pool); > > Use dma_addr_t for dma_desc_pool, and %pad to print dma_addr_t. Applied, thanks -- ~Vinod
Re: [PATCH v12 3/9] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel[_low]()
Hi,
On 09/07/20 at 09:47pm, Chen Zhou wrote:
> To make the functions reserve_crashkernel[_low]() as generic,
> replace some hard-coded numbers with macro CRASH_ADDR_LOW_MAX.
>
> Signed-off-by: Chen Zhou
> ---
> arch/x86/kernel/setup.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d7fd90c52dae..71a6a6e7ca5b 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -430,7 +430,7 @@ static int __init reserve_crashkernel_low(void)
> unsigned long total_low_mem;
> int ret;
>
> - total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
> + total_low_mem = memblock_mem_size(CRASH_ADDR_LOW_MAX >> PAGE_SHIFT);
Just note that the replacement has been done in another patch from Mike
Rapoport, partially. He seems to have done reserve_crashkernel_low()
part, there's one left in reserve_crashkernel(), you might want to check
that.
Mike's patch which is from a patchset has been merged into Andrew's next
tree.
commit 6e50f7672ffa362e9bd4bc0c0d2524ed872828c5
Author: Mike Rapoport
Date: Wed Aug 26 15:22:32 2020 +1000
x86/setup: simplify reserve_crashkernel()
>
> /* crashkernel=Y,low */
> ret = parse_crashkernel_low(boot_command_line, total_low_mem,
> &low_size, &base);
> @@ -451,7 +451,7 @@ static int __init reserve_crashkernel_low(void)
> return 0;
> }
>
> - low_base = memblock_find_in_range(CRASH_ALIGN, 1ULL << 32, low_size,
> CRASH_ALIGN);
> + low_base = memblock_find_in_range(CRASH_ALIGN, CRASH_ADDR_LOW_MAX,
> low_size, CRASH_ALIGN);
> if (!low_base) {
> pr_err("Cannot reserve %ldMB crashkernel low memory, please try
> smaller size.\n",
> (unsigned long)(low_size >> 20));
> @@ -504,8 +504,9 @@ static void __init reserve_crashkernel(void)
> if (!crash_base) {
> /*
>* Set CRASH_ADDR_LOW_MAX upper bound for crash memory,
> - * crashkernel=x,high reserves memory over 4G, also allocates
> - * 256M extra low memory for DMA buffers and swiotlb.
> + * crashkernel=x,high reserves memory over CRASH_ADDR_LOW_MAX,
> + * also allocates 256M extra low memory for DMA buffers
> + * and swiotlb.
>* But the extra memory is not required for all machines.
>* So try low memory first and fall back to high memory
>* unless "crashkernel=size[KMG],high" is specified.
> @@ -539,7 +540,7 @@ static void __init reserve_crashkernel(void)
> return;
> }
>
> - if (crash_base >= (1ULL << 32) && reserve_crashkernel_low()) {
> + if (crash_base >= CRASH_ADDR_LOW_MAX && reserve_crashkernel_low()) {
> memblock_free(crash_base, crash_size);
> return;
> }
> --
> 2.20.1
>
RE: [PATCH v10 1/3] dt-bindings: drm/bridge: Document Cadence MHDP8546 bridge bindings
Hi Tomi, > -Original Message- > From: Tomi Valkeinen > Sent: Wednesday, September 16, 2020 5:48 PM > To: Swapnil Kashinath Jakhade ; airl...@linux.ie; > dan...@ffwll.ch; laurent.pinch...@ideasonboard.com; robh...@kernel.org; > a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se; > jernej.skra...@siol.net; dri-de...@lists.freedesktop.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: Milind Parab ; Yuti Suresh Amonkar > ; jsa...@ti.com; nsek...@ti.com; > prane...@ti.com; nikhil...@ti.com > Subject: Re: [PATCH v10 1/3] dt-bindings: drm/bridge: Document Cadence > MHDP8546 bridge bindings > > EXTERNAL MAIL > > > Hi Swapnil, Yuti, > > On 14/09/2020 15:48, Swapnil Jakhade wrote: > > From: Yuti Amonkar > > > > Document the bindings used for the Cadence MHDP8546 DPI/DP bridge in > > yaml format. > > > > Signed-off-by: Yuti Amonkar > > Signed-off-by: Swapnil Jakhade > > Reviewed-by: Rob Herring > > Reviewed-by: Laurent Pinchart > > --- > > .../display/bridge/cdns,mhdp8546.yaml | 154 ++ > > 1 file changed, 154 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > I was testing this on J7 EVM, and looking at the dts files and DT bindings. To > get rid of the warnings from dtbs_check, I made the following changes. > > I think the interrupt one is clear. The driver needs the interrupt, but it was > not defined in the yaml file. > > For phy-names, we had that in the out-of-tree dts file, so I added it here. > The > driver just looks for the PHY via index, but I guess we should require it. > > The power-domain is not needed by the driver, but if I'm not mistaken, has > to be defined here. > > > diff --git > a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > index a21a4bfe15cf..c5f5781c1ed6 100644 > --- > a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml > +++ > b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yam > +++ l > @@ -46,6 +46,16 @@ properties: > description: >phandle to the DisplayPort PHY. > > + phy-names: > +items: > + - const: dpphy > + > + power-domains: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + >ports: > type: object > description: > @@ -114,6 +124,8 @@ required: >- reg >- reg-names >- phys > + - phy-names > + - interrupts >- ports > Okay. We will update the bindings as per above suggestions. Thanks for your inputs. Thanks & regards, Swapnil > additionalProperties: false > > Tomi > > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH RFC 2/4] mm/page_alloc: place pages to tail in __putback_isolated_page()
On 18.09.20 04:07, Wei Yang wrote: > On Wed, Sep 16, 2020 at 08:34:09PM +0200, David Hildenbrand wrote: >> __putback_isolated_page() already documents that pages will be placed to >> the tail of the freelist - this is, however, not the case for >> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be >> the case for all existing users. >> >> This change affects two users: >> - free page reporting >> - page isolation, when undoing the isolation. >> >> This behavior is desireable for pages that haven't really been touched >> lately, so exactly the two users that don't actually read/write page >> content, but rather move untouched pages. >> >> The new behavior is especially desirable for memory onlining, where we >> allow allocation of newly onlined pages via undo_isolate_page_range() >> in online_pages(). Right now, we always place them to the head of the > > The code looks good, while I don't fully understand the log here. > > undo_isolate_page_range() is used in __offline_pages and alloc_contig_range. I > don't connect them with online_pages(). Do I miss something? Yeah, please look at -mm / -next instead. See https://lkml.kernel.org/r/20200819175957.28465-11-da...@redhat.com -- Thanks, David / dhildenb
Re: [PATCH v2 00/10] crypto: hisilicon/zip - misc clean up
On Mon, Sep 07, 2020 at 04:21:52PM +0800, Yang Shen wrote: > This patchset make some clean up: > patch 1:remove useless parameters > patch 4:replace 'sprintf' with 'scnprintf' > patch 7:fix static check warning > and the rest patch fix some coding style > > v2: > - remove the return check of 'scnprintf' in PATCH 4 > > Shukun Tan (1): > crypto: hisilicon/zip - modify debugfs interface parameters > > Yang Shen (9): > crypto: hisilicon/zip - remove some useless parameters > crypto: hisilicon/zip - unify naming style for functions and macros > crypto: hisilicon/zip - replace 'sprintf' with 'scnprintf' > crypto: hisilicon/zip - use a enum parameter instead of some macros > crypto: hisilicon/zip - add print for error branch > crypto: hisilicon/zip - fix static check warning > crypto: hisilicon/zip - move some private macros from 'zip.h' to > 'zip_crypto.c' > crypto: hisilicon/zip - supplement some comments > crypto: hisilicon/zip - fix some coding styles > > drivers/crypto/hisilicon/zip/zip.h| 15 > drivers/crypto/hisilicon/zip/zip_crypto.c | 112 ++ > drivers/crypto/hisilicon/zip/zip_main.c | 126 > ++ > 3 files changed, 135 insertions(+), 118 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH RFC 2/4] mm/page_alloc: place pages to tail in __putback_isolated_page()
On 18.09.20 04:16, Wei Yang wrote: > On Wed, Sep 16, 2020 at 08:34:09PM +0200, David Hildenbrand wrote: >> __putback_isolated_page() already documents that pages will be placed to >> the tail of the freelist - this is, however, not the case for >> "order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be >> the case for all existing users. >> >> This change affects two users: >> - free page reporting >> - page isolation, when undoing the isolation. >> >> This behavior is desireable for pages that haven't really been touched >> lately, so exactly the two users that don't actually read/write page >> content, but rather move untouched pages. >> >> The new behavior is especially desirable for memory onlining, where we >> allow allocation of newly onlined pages via undo_isolate_page_range() >> in online_pages(). Right now, we always place them to the head of the >> free list, resulting in undesireable behavior: Assume we add >> individual memory chunks via add_memory() and online them right away to >> the NORMAL zone. We create a dependency chain of unmovable allocations >> e.g., via the memmap. The memmap of the next chunk will be placed onto >> previous chunks - if the last block cannot get offlined+removed, all >> dependent ones cannot get offlined+removed. While this can already be >> observed with individual DIMMs, it's more of an issue for virtio-mem >> (and I suspect also ppc DLPAR). >> >> Note: If we observe a degradation due to the changed page isolation >> behavior (which I doubt), we can always make this configurable by the >> instance triggering undo of isolation (e.g., alloc_contig_range(), >> memory onlining, memory offlining). >> >> Cc: Andrew Morton >> Cc: Alexander Duyck >> Cc: Mel Gorman >> Cc: Michal Hocko >> Cc: Dave Hansen >> Cc: Vlastimil Babka >> Cc: Wei Yang >> Cc: Oscar Salvador >> Cc: Mike Rapoport >> Cc: Scott Cheloha >> Cc: Michael Ellerman >> Signed-off-by: David Hildenbrand >> --- >> mm/page_alloc.c | 10 +- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 91cefb8157dd..bba9a0f60c70 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -89,6 +89,12 @@ typedef int __bitwise fop_t; >> */ >> #define FOP_SKIP_REPORT_NOTIFY ((__force fop_t)BIT(0)) >> >> +/* >> + * Place the freed page to the tail of the freelist after buddy merging. >> Will >> + * get ignored with page shuffling enabled. >> + */ >> +#define FOP_TO_TAIL ((__force fop_t)BIT(1)) >> + >> /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */ >> static DEFINE_MUTEX(pcp_batch_high_lock); >> #define MIN_PERCPU_PAGELIST_FRACTION (8) >> @@ -1040,6 +1046,8 @@ static inline void __free_one_page(struct page *page, >> unsigned long pfn, >> >> if (is_shuffle_order(order)) >> to_tail = shuffle_pick_tail(); >> +else if (fop_flags & FOP_TO_TAIL) >> +to_tail = true; > > Take another look into this part. Maybe we can move this check at top? > > For online_page case, currently we have following call flow: > > online_page > online_pages_range > shuffle_zone > > This means we would always shuffle the newly added pages. Maybe we don't need > to do the shuffle when adding them to the free_list? Yeah we don't, but it doesn't really buy us too much as the call paths I am touching are used by other mechanisms as well that need it (especially undoing page isolation). -- Thanks, David / dhildenb
Re: [PATCH v2 1/4] crypto: caam - Fix kerneldoc
On Thu, Sep 10, 2020 at 09:29:16PM +0200, Krzysztof Kozlowski wrote: > Fix kerneldoc warnings like: > > drivers/crypto/caam/caamalg_qi2.c:73: warning: cannot understand function > prototype: 'struct caam_ctx' > drivers/crypto/caam/caamalg_qi2.c:2962: warning: cannot understand function > prototype: 'struct caam_hash_ctx' > drivers/crypto/caam/ctrl.c:449: warning: Function parameter or member > 'ctrl' not described in 'caam_get_era' > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. Fix more warnings > --- > drivers/crypto/caam/caamalg_desc.c | 1 + > drivers/crypto/caam/caamalg_qi2.c | 4 ++-- > drivers/crypto/caam/ctrl.c | 4 +++- > drivers/crypto/caam/jr.c | 10 +- > 4 files changed, 11 insertions(+), 8 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH RFC 3/4] mm/page_alloc: always move pages to the tail of the freelist in unset_migratetype_isolate()
On 18.09.20 04:29, Wei Yang wrote: > On Wed, Sep 16, 2020 at 08:34:10PM +0200, David Hildenbrand wrote: >> Page isolation doesn't actually touch the pages, it simply isolates >> pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist. >> >> We already place pages to the tail of the freelists when undoing >> isolation via __putback_isolated_page(), let's do it in any case >> (e.g., if order == pageblock_order) and document the behavior. >> >> This change results in all pages getting onlined via online_pages() to >> be placed to the tail of the freelist. > > I am sorry to not follow again. unset_migratetype_isolate() is used in > __offline_pages if my understanding is correct. How does it contribute on > online_pages? See -next / -mm, that should make it clearer. -- Thanks, David / dhildenb
Re: [PATCH 4/7] crypto: sun4i-ss: handle BigEndian for cipher
On Thu, Sep 17, 2020 at 06:35:55PM +, Corentin Labbe wrote:
> Ciphers produce invalid results on BE.
> Key and IV need to be written in LE.
> Furthermore, the non-optimized function is too complicated to convert,
> let's simply fallback on BE for the moment.
>
> Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System
> crypto accelerator")
> Cc:
> Signed-off-by: Corentin Labbe
> ---
> .../crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 17 +++--
> 1 file changed, 11 insertions(+), 6 deletions(-)
Does the BE failure get caught by the selftest?
If so please just leave it enabled so that it can be fixed properly.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH RFC 0/4] mm: place pages to the freelist tail when onling and undoing isolation
On 18.09.20 04:30, Wei Yang wrote: > On Wed, Sep 16, 2020 at 09:31:21PM +0200, David Hildenbrand wrote: >> >> >>> Am 16.09.2020 um 20:50 schrieb osalva...@suse.de: >>> >>> On 2020-09-16 20:34, David Hildenbrand wrote: When adding separate memory blocks via add_memory*() and onlining them immediately, the metadata (especially the memmap) of the next block will be placed onto one of the just added+onlined block. This creates a chain of unmovable allocations: If the last memory block cannot get offlined+removed() so will all dependant ones. We directly have unmovable allocations all over the place. This can be observed quite easily using virtio-mem, however, it can also be observed when using DIMMs. The freshly onlined pages will usually be placed to the head of the freelists, meaning they will be allocated next, turning the just-added memory usually immediately un-removable. The fresh pages are cold, prefering to allocate others (that might be hot) also feels to be the natural thing to do. It also applies to the hyper-v balloon xen-balloon, and ppc64 dlpar: when adding separate, successive memory blocks, each memory block will have unmovable allocations on them - for example gigantic pages will fail to allocate. While the ZONE_NORMAL doesn't provide any guarantees that memory can get offlined+removed again (any kind of fragmentation with unmovable allocations is possible), there are many scenarios (hotplugging a lot of memory, running workload, hotunplug some memory/as much as possible) where we can offline+remove quite a lot with this patchset. >>> >>> Hi David, >>> >> >> Hi Oscar. >> >>> I did not read through the patchset yet, so sorry if the question is >>> nonsense, but is this not trying to fix the same issue the vmemmap patches >>> did? [1] >> >> Not nonesense at all. It only helps to some degree, though. It solves the >> dependencies due to the memmap. However, it‘s not completely ideal, >> especially for single memory blocks. >> >> With single memory blocks (virtio-mem, xen-balloon, hv balloon, ppc dlpar) >> you still have unmovable (vmemmap chunks) all over the physical address >> space. Consider the gigantic page example after hotplug. You directly >> fragmented all hotplugged memory. >> >> Of course, there might be (less extreme) dependencies due page tables for >> the identity mapping, extended struct pages and similar. >> >> Having that said, there are other benefits when preferring other memory over >> just hotplugged memory. Think about adding+onlining memory during boot >> (dimms under QEMU, virtio-mem), once the system is up you will have most >> (all) of that memory completely untouched. >> >> So while vmemmap on hotplugged memory would tackle some part of the issue, >> there are cases where this approach is better, and there are even benefits >> when combining both. > > While everything changes with shuffle. > Right. Shuffling would naturally try to break the dependencies. Shuffling is quite rare though, it has to be enabled explicitly on the cmdline and might not be of too much help in virtualized environments. -- Thanks, David / dhildenb
Re: [PATCH 01/13] mm: use add_page_to_lru_list()
On Thu 17-09-20 21:00:39, Yu Zhao wrote:
> This patch replaces the only open-coded lru list addition with
> add_page_to_lru_list().
>
> Before this patch, we have:
> update_lru_size()
> list_move()
>
> After this patch, we have:
> list_del()
> add_page_to_lru_list()
> update_lru_size()
> list_add()
>
> The only side effect is that page->lru is temporarily poisoned
> after a page is deleted from its old list, which shouldn't be a
> problem.
"because the lru lock is held" right?
Please always be explicit about your reasoning. "It shouldn't be a
problem" without further justification is just pointless for anybody
reading the code later on.
> Signed-off-by: Yu Zhao
> ---
> mm/vmscan.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 9727dd8e2581..503fc5e1fe32 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1850,8 +1850,8 @@ static unsigned noinline_for_stack
> move_pages_to_lru(struct lruvec *lruvec,
> while (!list_empty(list)) {
> page = lru_to_page(list);
> VM_BUG_ON_PAGE(PageLRU(page), page);
> + list_del(&page->lru);
> if (unlikely(!page_evictable(page))) {
> - list_del(&page->lru);
> spin_unlock_irq(&pgdat->lru_lock);
> putback_lru_page(page);
> spin_lock_irq(&pgdat->lru_lock);
> @@ -1862,9 +1862,7 @@ static unsigned noinline_for_stack
> move_pages_to_lru(struct lruvec *lruvec,
> SetPageLRU(page);
> lru = page_lru(page);
>
> - nr_pages = thp_nr_pages(page);
> - update_lru_size(lruvec, lru, page_zonenum(page), nr_pages);
> - list_move(&page->lru, &lruvec->lists[lru]);
> + add_page_to_lru_list(page, lruvec, lru);
>
> if (put_page_testzero(page)) {
> __ClearPageLRU(page);
> @@ -1878,6 +1876,7 @@ static unsigned noinline_for_stack
> move_pages_to_lru(struct lruvec *lruvec,
> } else
> list_add(&page->lru, &pages_to_free);
> } else {
> + nr_pages = thp_nr_pages(page);
> nr_moved += nr_pages;
> if (PageActive(page))
> workingset_age_nonresident(lruvec, nr_pages);
> --
> 2.28.0.681.g6f77f65b4e-goog
--
Michal Hocko
SUSE Labs
Re: [PATCH v2] software_node: Add support for fwnode_graph*() family of functions
On Fri, Sep 18, 2020 at 07:49:31AM +0100, Dan Scally wrote:
> Good morning
>
> On 18/09/2020 07:22, Sakari Ailus wrote:
> > Hi Dan,
> >
> > On Wed, Sep 16, 2020 at 02:22:10PM +0100, Dan Scally wrote:
> >> Hi Sakari - thanks for the comments
> >>
> >> On 16/09/2020 10:17, Sakari Ailus wrote:
> >>> Moi Daniel and Heikki,
> >>>
> >>> On Wed, Sep 16, 2020 at 12:28:27AM +0100, Daniel Scally wrote:
> From: Heikki Krogerus
>
> This implements the remaining .graph_* callbacks in the
> fwnode operations vector for the software nodes. That makes
> the fwnode_graph*() functions available in the drivers also
> when software nodes are used.
>
> The implementation tries to mimic the "OF graph" as much as
> possible, but there is no support for the "reg" device
> property. The ports will need to have the index in their
> name which starts with "port" (for example "port0", "port1",
> ...) and endpoints will use the index of the software node
> that is given to them during creation. The port nodes can
> also be grouped under a specially named "ports" subnode,
> just like in DT, if necessary.
>
> The remote-endpoints are reference properties under the
> endpoint nodes that are named "remote-endpoint".
>
> Signed-off-by: Heikki Krogerus
> Co-developed-by: Daniel Scally
> Signed-off-by: Daniel Scally
> ---
> changes in v2:
> - added software_node_device_is_available
> - altered software_node_get_next_child to get references
> - altered software_node_get_next_endpoint to release references
> to ports and avoid passing invalid combinations of swnodes to
> software_node_get_next_child
> - altered swnode_graph_find_next_port to release port rather than
> old
>
> drivers/base/swnode.c | 129 +-
> 1 file changed, 127 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> index 010828fc785b..d69034b807e3 100644
> --- a/drivers/base/swnode.c
> +++ b/drivers/base/swnode.c
> @@ -363,6 +363,11 @@ static void software_node_put(struct fwnode_handle
> *fwnode)
> kobject_put(&swnode->kobj);
> }
>
> +static bool software_node_device_is_available(const struct
> fwnode_handle *fwnode)
> +{
> +return is_software_node(fwnode);
> >>> This basically tells whether the device is there. Are there software node
> >>> based devices, i.e. do you need this?
> >>>
> >>> If you do really need this, then I guess this could just return true for
> >>> now as if you somehow get here, the node is a software node anyway.
> >> I do think its better to include it; I'm targeting using this with
> >> ipu3-cio2; the cio2_parse_firmware() call there doesn't pass
> >> FWNODE_GRAPH_DEVICE_DISABLED to fwnode_graph_get_endpoint_by_id() so
> > I wonder if this has something to do with replacing the device's fwnode
> > in the cio2-bridge patch.
> >
> > It's the device that needs to be enabled, and it's not a software node.
> >
> I think it is because of that yes, but I don't see a way around it at
> the moment - unless there's a way to attach the software_node port and
> endpoints that cio2-bridge creates to the device's existing firmware
> instead.
I thought this was how it was meant to be used?
The secondary field is there for this purpose. But it may be not all fwnode
interface functions operate on fwnode->secondary?
--
Regards,
Sakari Ailus
Re: [PATCH 02/13] mm: use page_off_lru()
On Thu 17-09-20 21:00:40, Yu Zhao wrote:
> This patch replaces the only open-coded __ClearPageActive() with
> page_off_lru(). There is no open-coded __ClearPageUnevictable()s.
>
> Before this patch, we have:
> __ClearPageActive()
> add_page_to_lru_list()
>
> After this patch, we have:
> page_off_lru()
> if PageUnevictable()
> __ClearPageUnevictable()
> else if PageActive()
> __ClearPageActive()
> add_page_to_lru_list()
>
> Checking PageUnevictable() shouldn't be a problem because these two
> flags are mutually exclusive. Leaking either will trigger bad_page().
I am sorry but the changelog is really hard to grasp. What are you
trying to achieve, why and why it is safe. This should be a general
outline for any patch. I have already commented on the previous patch
and asked you for the explanation why removing __ClearPageActive from
this path is desirable and safe. I have specifically asked to clarify
the compound page situation as that is using its oen destructor in the
freeing path and that might result in page_off_lru to be not called.
> Signed-off-by: Yu Zhao
> ---
> mm/vmscan.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 503fc5e1fe32..f257d2f61574 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1845,7 +1845,6 @@ static unsigned noinline_for_stack
> move_pages_to_lru(struct lruvec *lruvec,
> int nr_pages, nr_moved = 0;
> LIST_HEAD(pages_to_free);
> struct page *page;
> - enum lru_list lru;
>
> while (!list_empty(list)) {
> page = lru_to_page(list);
> @@ -1860,14 +1859,11 @@ static unsigned noinline_for_stack
> move_pages_to_lru(struct lruvec *lruvec,
> lruvec = mem_cgroup_page_lruvec(page, pgdat);
>
> SetPageLRU(page);
> - lru = page_lru(page);
> -
> add_page_to_lru_list(page, lruvec, lru);
>
> if (put_page_testzero(page)) {
> __ClearPageLRU(page);
> - __ClearPageActive(page);
> - del_page_from_lru_list(page, lruvec, lru);
> + del_page_from_lru_list(page, lruvec,
> page_off_lru(page));
>
> if (unlikely(PageCompound(page))) {
> spin_unlock_irq(&pgdat->lru_lock);
> --
> 2.28.0.681.g6f77f65b4e-goog
--
Michal Hocko
SUSE Labs
Re: [PATCH v2] dmaengine: ti: k3-udma-glue: fix channel enable functions
On 16-09-20, 15:09, Grygorii Strashko wrote: > Now the K3 UDMA glue layer enable functions perform RMW operation on UDMA > RX/TX RT_CTL registers to set EN bit and enable channel, which is > incorrect, because only EN bit has to be set in those registers to enable > channel (all other bits should be cleared 0). > More over, this causes issues when bootloader leaves UDMA channel RX/TX > RT_CTL registers in incorrect state - TDOWN bit set, for example. As > result, UDMA channel will just perform teardown right after it's enabled. > > Hence, fix it by writing correct values (EN=1) directly in UDMA channel > RX/TX RT_CTL registers in k3_udma_glue_enable_tx/rx_chn() functions. Applied, thanks -- ~Vinod
Re: [PATCH 03/13] mm: move __ClearPageLRU() into page_off_lru()
On Thu 17-09-20 21:00:41, Yu Zhao wrote:
> Now we have a total of three places that free lru pages when their
> references become zero (after we drop the reference from isolation).
>
> Before this patch, they all do:
> __ClearPageLRU()
> page_off_lru()
> del_page_from_lru_list()
>
> After this patch, they become:
> page_off_lru()
> __ClearPageLRU()
> del_page_from_lru_list()
>
> This change should have no side effects.
Again, why this is desirable?
> Signed-off-by: Yu Zhao
> ---
> include/linux/mm_inline.h | 1 +
> mm/swap.c | 2 --
> mm/vmscan.c | 1 -
> 3 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
> index 8fc71e9d7bb0..be9418425e41 100644
> --- a/include/linux/mm_inline.h
> +++ b/include/linux/mm_inline.h
> @@ -92,6 +92,7 @@ static __always_inline enum lru_list page_off_lru(struct
> page *page)
> {
> enum lru_list lru;
>
> + __ClearPageLRU(page);
> if (PageUnevictable(page)) {
> __ClearPageUnevictable(page);
> lru = LRU_UNEVICTABLE;
> diff --git a/mm/swap.c b/mm/swap.c
> index 40bf20a75278..8362083f00c9 100644
> --- a/mm/swap.c
> +++ b/mm/swap.c
> @@ -86,7 +86,6 @@ static void __page_cache_release(struct page *page)
> spin_lock_irqsave(&pgdat->lru_lock, flags);
> lruvec = mem_cgroup_page_lruvec(page, pgdat);
> VM_BUG_ON_PAGE(!PageLRU(page), page);
> - __ClearPageLRU(page);
> del_page_from_lru_list(page, lruvec, page_off_lru(page));
> spin_unlock_irqrestore(&pgdat->lru_lock, flags);
> }
> @@ -895,7 +894,6 @@ void release_pages(struct page **pages, int nr)
>
> lruvec = mem_cgroup_page_lruvec(page, locked_pgdat);
> VM_BUG_ON_PAGE(!PageLRU(page), page);
> - __ClearPageLRU(page);
> del_page_from_lru_list(page, lruvec,
> page_off_lru(page));
> }
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index f257d2f61574..f9a186a96410 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1862,7 +1862,6 @@ static unsigned noinline_for_stack
> move_pages_to_lru(struct lruvec *lruvec,
> add_page_to_lru_list(page, lruvec, lru);
>
> if (put_page_testzero(page)) {
> - __ClearPageLRU(page);
> del_page_from_lru_list(page, lruvec,
> page_off_lru(page));
>
> if (unlikely(PageCompound(page))) {
> --
> 2.28.0.681.g6f77f65b4e-goog
--
Michal Hocko
SUSE Labs
[PATCH v4] ASoC: tlv320adcx140: Add support for configuring GPIO pin
From: Camel Guo
Add support to configure the GPIO pin to the specific configuration.
The GPIO pin can be configured as GPO, IRQ, SDOUT2, PDMCLK, MICBASE_EN,
GPI, MCLK, SDIN, PDMDIN1, PDMDIN2, PDMDIN3 or PDMDIN4 and the output
drive can be configured with various configuration.
Signed-off-by: Camel Guo
Acked-by: Dan Murphy
---
v4:
- Rebase and fix merge conflict
- Add Acked-by from Dan
v3:
- Add ADCX140_NUM_GPIO_CFGS avoiding using magic number
- Remove unneeded check on ret in adcx140_configure_gpio
sound/soc/codecs/tlv320adcx140.c | 40
sound/soc/codecs/tlv320adcx140.h | 5
2 files changed, 45 insertions(+)
diff --git a/sound/soc/codecs/tlv320adcx140.c b/sound/soc/codecs/tlv320adcx140.c
index 28dbd7d5e149..53a80246aee1 100644
--- a/sound/soc/codecs/tlv320adcx140.c
+++ b/sound/soc/codecs/tlv320adcx140.c
@@ -861,6 +861,42 @@ static int adcx140_configure_gpo(struct adcx140_priv
*adcx140)
}
+static int adcx140_configure_gpio(struct adcx140_priv *adcx140)
+{
+ int gpio_count = 0;
+ u32 gpio_outputs[ADCX140_NUM_GPIO_CFGS];
+ u32 gpio_output_val = 0;
+ int ret;
+
+ gpio_count = device_property_count_u32(adcx140->dev,
+ "ti,gpio-config");
+ if (gpio_count == 0)
+ return 0;
+
+ if (gpio_count != ADCX140_NUM_GPIO_CFGS)
+ return -EINVAL;
+
+ ret = device_property_read_u32_array(adcx140->dev, "ti,gpio-config",
+ gpio_outputs, gpio_count);
+ if (ret)
+ return ret;
+
+ if (gpio_outputs[0] > ADCX140_GPIO_CFG_MAX) {
+ dev_err(adcx140->dev, "GPIO config out of range\n");
+ return -EINVAL;
+ }
+
+ if (gpio_outputs[1] > ADCX140_GPIO_DRV_MAX) {
+ dev_err(adcx140->dev, "GPIO drive out of range\n");
+ return -EINVAL;
+ }
+
+ gpio_output_val = gpio_outputs[0] << ADCX140_GPIO_SHIFT
+ | gpio_outputs[1];
+
+ return regmap_write(adcx140->regmap, ADCX140_GPIO_CFG0,
gpio_output_val);
+}
+
static int adcx140_codec_probe(struct snd_soc_component *component)
{
struct adcx140_priv *adcx140 = snd_soc_component_get_drvdata(component);
@@ -958,6 +994,10 @@ static int adcx140_codec_probe(struct snd_soc_component
*component)
return ret;
}
+ ret = adcx140_configure_gpio(adcx140);
+ if (ret)
+ return ret;
+
ret = adcx140_configure_gpo(adcx140);
if (ret)
goto out;
diff --git a/sound/soc/codecs/tlv320adcx140.h b/sound/soc/codecs/tlv320adcx140.h
index 107bd7927d9c..d7d4e3a88b5c 100644
--- a/sound/soc/codecs/tlv320adcx140.h
+++ b/sound/soc/codecs/tlv320adcx140.h
@@ -148,4 +148,9 @@
#define ADCX140_TX_FILLBIT(0)
+#define ADCX140_NUM_GPIO_CFGS 2
+#define ADCX140_GPIO_SHIFT 4
+#define ADCX140_GPIO_CFG_MAX 15
+#define ADCX140_GPIO_DRV_MAX 5
+
#endif /* _TLV320ADCX140_ */
--
2.20.1
[media] st-hva: potential null pointer dereference in hva_hw_its_irq_thread()
If ctx_id >= HVA_MAX_INSTANCES in hva_hw_its_irq_thread(), it dereferences ctx that is initialized to NULL. I can not provide the patch since I do not know the logic of the driver and I have not a capability to test it. Found by Linux Driver Verification project (linuxtesting.org). -- Best regards, Evgeny Novikov
Re: [PATCH 2/9] ARM: traps: use get_kernel_nofault instead of set_fs()
On Thu, Sep 17, 2020 at 07:29:37PM +0200, Arnd Bergmann wrote:
> On Tue, Sep 8, 2020 at 8:15 AM Christoph Hellwig wrote:
> >
> > > +static void dump_mem(const char *, const char *, unsigned long, unsigned
> > > long, bool kernel_mode);
> >
> > This adds a pointlessly long line.
>
> Fixed.
>
> > And looking at the code I don't see why the argument is even needed.
> >
> > dump_mem() currently does an unconditional set_fs(KERNEL_DS), so it
> > should always use get_kernel_nofault.
>
> I had looked at
>
> if (!user_mode(regs) || in_interrupt()) {
> dump_mem(KERN_EMERG, "Stack: ", regs->ARM_sp,
> THREAD_SIZE + (unsigned
> long)task_stack_page(tsk), kernel_mode);
>
> which told me that there should be at least some code path ending up in
> __die() that has in_interrupt() set but comes from user mode.
>
> In this case, the memory to print would be a user pointer and cannot be
> accessed by get_kernel_nofault() (but could be accessed with
> "set_fs(KERNEL_DS); __get_user()").
>
> I looked through the history now and the only code path I could
> find that would arrive here this way is from bad_mode(), indicating
> that there is probably a hardware bug or the contents of *regs are
> corrupted.
Yes, that's correct. It isn't something entirely theoretical, although
we never see it now, it used to happen in the distant past due to saved
regs corruption. If bad_mode() ever gets called, all bets are off and
we're irrecoverably crashing.
Note that in that case, while user_mode(regs) may return true or false,
regs->ARM_sp and regs->ARM_lr are always the SVC mode stack and return
address after regs has been stacked, and not the expected values for
the parent context (which we have most likely long since destroyed.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
[tip: x86/pasid] drm, iommu: Change type of pasid to u32
The following commit has been merged into the x86/pasid branch of tip: Commit-ID: c7b6bac9c72c5fcbd6e9e12545bd3022c7f21860 Gitweb: https://git.kernel.org/tip/c7b6bac9c72c5fcbd6e9e12545bd3022c7f21860 Author:Fenghua Yu AuthorDate:Tue, 15 Sep 2020 09:30:05 -07:00 Committer: Borislav Petkov CommitterDate: Thu, 17 Sep 2020 19:21:16 +02:00 drm, iommu: Change type of pasid to u32 PASID is defined as a few different types in iommu including "int", "u32", and "unsigned int". To be consistent and to match with uapi definitions, define PASID and its variations (e.g. max PASID) as "u32". "u32" is also shorter and a little more explicit than "unsigned int". No PASID type change in uapi although it defines PASID as __u64 in some places. Suggested-by: Thomas Gleixner Signed-off-by: Fenghua Yu Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Reviewed-by: Lu Baolu Acked-by: Felix Kuehling Acked-by: Joerg Roedel Link: https://lkml.kernel.org/r/1600187413-163670-2-git-send-email-fenghua...@intel.com --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.h | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 8 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h| 8 +-- drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_dbgmgr.h | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 7 +-- drivers/gpu/drm/amd/amdkfd/kfd_events.c | 8 +-- drivers/gpu/drm/amd/amdkfd/kfd_events.h | 4 +- drivers/gpu/drm/amd/amdkfd/kfd_iommu.c| 6 +- drivers/gpu/drm/amd/amdkfd/kfd_pasid.c| 4 +- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 20 +++--- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 +- drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 2 +- drivers/iommu/amd/amd_iommu.h | 10 +-- drivers/iommu/amd/iommu.c | 31 +- drivers/iommu/amd/iommu_v2.c | 20 +++--- drivers/iommu/intel/dmar.c| 7 +- drivers/iommu/intel/iommu.c | 4 +- drivers/iommu/intel/pasid.c | 31 -- drivers/iommu/intel/pasid.h | 24 drivers/iommu/intel/svm.c | 12 ++-- drivers/iommu/iommu.c | 2 +- drivers/misc/uacce/uacce.c| 2 +- include/linux/amd-iommu.h | 8 +-- include/linux/intel-iommu.h | 12 ++-- include/linux/intel-svm.h | 2 +- include/linux/iommu.h | 10 +-- include/linux/uacce.h | 2 +- 38 files changed, 141 insertions(+), 141 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h index ffe149a..dfef5a7 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h @@ -207,11 +207,11 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev *dst, struct kgd_dev *s }) /* GPUVM API */ -int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, unsigned int pasid, +int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, u32 pasid, void **vm, void **process_info, struct dma_fence **ef); int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd, - struct file *filp, unsigned int pasid, + struct file *filp, u32 pasid, void **vm, void **process_info, struct dma_fence **ef); void amdgpu_amdkfd_gpuvm_destroy_cb(struct amdgpu_device *adev, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c index bf927f4..ee531c3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c @@ -105,7 +105,7 @@ static void kgd_program_sh_mem_settings(struct kgd_dev *kgd, uint32_t vmid, unlock_srbm(kgd);
[tip: x86/pasid] x86/mmu: Allocate/free a PASID
The following commit has been merged into the x86/pasid branch of tip:
Commit-ID: 20f0afd1fb3d7d44f4a3db5a4b6e904410862140
Gitweb:
https://git.kernel.org/tip/20f0afd1fb3d7d44f4a3db5a4b6e904410862140
Author:Fenghua Yu
AuthorDate:Tue, 15 Sep 2020 09:30:13 -07:00
Committer: Borislav Petkov
CommitterDate: Thu, 17 Sep 2020 20:22:15 +02:00
x86/mmu: Allocate/free a PASID
A PASID is allocated for an "mm" the first time any thread binds to an
SVA-capable device and is freed from the "mm" when the SVA is unbound
by the last thread. It's possible for the "mm" to have different PASID
values in different binding/unbinding SVA cycles.
The mm's PASID (non-zero for valid PASID or 0 for invalid PASID) is
propagated to a per-thread PASID MSR for all threads within the mm
through IPI, context switch, or inherited. This is done to ensure that a
running thread has the right PASID in the MSR matching the mm's PASID.
[ bp: s/SVM/SVA/g; massage. ]
Suggested-by: Andy Lutomirski
Signed-off-by: Fenghua Yu
Signed-off-by: Borislav Petkov
Reviewed-by: Tony Luck
Link:
https://lkml.kernel.org/r/1600187413-163670-10-git-send-email-fenghua...@intel.com
---
arch/x86/include/asm/fpu/api.h | 12 ++-
arch/x86/include/asm/fpu/internal.h | 7 +++-
arch/x86/kernel/fpu/xstate.c| 57 -
drivers/iommu/intel/svm.c | 28 +-
4 files changed, 103 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h
index b774c52..dcd9503 100644
--- a/arch/x86/include/asm/fpu/api.h
+++ b/arch/x86/include/asm/fpu/api.h
@@ -62,4 +62,16 @@ extern void switch_fpu_return(void);
*/
extern int cpu_has_xfeatures(u64 xfeatures_mask, const char **feature_name);
+/*
+ * Tasks that are not using SVA have mm->pasid set to zero to note that they
+ * will not have the valid bit set in MSR_IA32_PASID while they are running.
+ */
+#define PASID_DISABLED 0
+
+#ifdef CONFIG_IOMMU_SUPPORT
+/* Update current's PASID MSR/state by mm's PASID. */
+void update_pasid(void);
+#else
+static inline void update_pasid(void) { }
+#endif
#endif /* _ASM_X86_FPU_API_H */
diff --git a/arch/x86/include/asm/fpu/internal.h
b/arch/x86/include/asm/fpu/internal.h
index 0a460f2..341d00e 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -583,6 +583,13 @@ static inline void switch_fpu_finish(struct fpu *new_fpu)
pkru_val = pk->pkru;
}
__write_pkru(pkru_val);
+
+ /*
+* Expensive PASID MSR write will be avoided in update_pasid() because
+* TIF_NEED_FPU_LOAD was set. And the PASID state won't be updated
+* unless it's different from mm->pasid to reduce overhead.
+*/
+ update_pasid();
}
/*
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 67f1a03..5d80474 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -1402,3 +1402,60 @@ int proc_pid_arch_status(struct seq_file *m, struct
pid_namespace *ns,
return 0;
}
#endif /* CONFIG_PROC_PID_ARCH_STATUS */
+
+#ifdef CONFIG_IOMMU_SUPPORT
+void update_pasid(void)
+{
+ u64 pasid_state;
+ u32 pasid;
+
+ if (!cpu_feature_enabled(X86_FEATURE_ENQCMD))
+ return;
+
+ if (!current->mm)
+ return;
+
+ pasid = READ_ONCE(current->mm->pasid);
+ /* Set the valid bit in the PASID MSR/state only for valid pasid. */
+ pasid_state = pasid == PASID_DISABLED ?
+ pasid : pasid | MSR_IA32_PASID_VALID;
+
+ /*
+* No need to hold fregs_lock() since the task's fpstate won't
+* be changed by others (e.g. ptrace) while the task is being
+* switched to or is in IPI.
+*/
+ if (!test_thread_flag(TIF_NEED_FPU_LOAD)) {
+ /* The MSR is active and can be directly updated. */
+ wrmsrl(MSR_IA32_PASID, pasid_state);
+ } else {
+ struct fpu *fpu = ¤t->thread.fpu;
+ struct ia32_pasid_state *ppasid_state;
+ struct xregs_state *xsave;
+
+ /*
+* The CPU's xstate registers are not currently active. Just
+* update the PASID state in the memory buffer here. The
+* PASID MSR will be loaded when returning to user mode.
+*/
+ xsave = &fpu->state.xsave;
+ xsave->header.xfeatures |= XFEATURE_MASK_PASID;
+ ppasid_state = get_xsave_addr(xsave, XFEATURE_PASID);
+ /*
+* Since XFEATURE_MASK_PASID is set in xfeatures, ppasid_state
+* won't be NULL and no need to check its value.
+*
+* Only update the task's PASID state when it's different
+* from the mm's pasid.
+*/
+ if (ppasid_state->pasid != pasid_state) {
+
[tip: x86/pasid] x86/cpufeatures: Mark ENQCMD as disabled when configured out
The following commit has been merged into the x86/pasid branch of tip: Commit-ID: 1478b99a76534b6c244cfe24fa616280a9441118 Gitweb: https://git.kernel.org/tip/1478b99a76534b6c244cfe24fa616280a9441118 Author:Fenghua Yu AuthorDate:Tue, 15 Sep 2020 09:30:12 -07:00 Committer: Borislav Petkov CommitterDate: Thu, 17 Sep 2020 20:22:15 +02:00 x86/cpufeatures: Mark ENQCMD as disabled when configured out Currently, the ENQCMD feature depends on CONFIG_IOMMU_SUPPORT. Add X86_FEATURE_ENQCMD to the disabled features mask so that it gets disabled when the IOMMU config option above is not enabled. Signed-off-by: Fenghua Yu Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Link: https://lkml.kernel.org/r/1600187413-163670-9-git-send-email-fenghua...@intel.com --- arch/x86/include/asm/disabled-features.h | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/disabled-features.h b/arch/x86/include/asm/disabled-features.h index 4ea8584..5861d34 100644 --- a/arch/x86/include/asm/disabled-features.h +++ b/arch/x86/include/asm/disabled-features.h @@ -56,6 +56,12 @@ # define DISABLE_PTI (1 << (X86_FEATURE_PTI & 31)) #endif +#ifdef CONFIG_IOMMU_SUPPORT +# define DISABLE_ENQCMD0 +#else +# define DISABLE_ENQCMD (1 << (X86_FEATURE_ENQCMD & 31)) +#endif + /* * Make sure to add features to the correct mask */ @@ -75,7 +81,8 @@ #define DISABLED_MASK130 #define DISABLED_MASK140 #define DISABLED_MASK150 -#define DISABLED_MASK16 (DISABLE_PKU|DISABLE_OSPKE|DISABLE_LA57|DISABLE_UMIP) +#define DISABLED_MASK16 (DISABLE_PKU|DISABLE_OSPKE|DISABLE_LA57|DISABLE_UMIP| \ +DISABLE_ENQCMD) #define DISABLED_MASK170 #define DISABLED_MASK180 #define DISABLED_MASK_CHECK BUILD_BUG_ON_ZERO(NCAPINTS != 19)
[tip: x86/pasid] Documentation/x86: Add documentation for SVA (Shared Virtual Addressing)
The following commit has been merged into the x86/pasid branch of tip: Commit-ID: 4e7b11567d946ebe14a3d10b697b078971a9da89 Gitweb: https://git.kernel.org/tip/4e7b11567d946ebe14a3d10b697b078971a9da89 Author:Ashok Raj AuthorDate:Tue, 15 Sep 2020 09:30:07 -07:00 Committer: Borislav Petkov CommitterDate: Thu, 17 Sep 2020 19:29:42 +02:00 Documentation/x86: Add documentation for SVA (Shared Virtual Addressing) ENQCMD and Data Streaming Accelerator (DSA) and all of their associated features are a complicated stack with lots of interconnected pieces. This documentation provides a big picture overview for all of the features. Signed-off-by: Ashok Raj Co-developed-by: Fenghua Yu Signed-off-by: Fenghua Yu Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Link: https://lkml.kernel.org/r/1600187413-163670-4-git-send-email-fenghua...@intel.com --- Documentation/x86/index.rst | 1 +- Documentation/x86/sva.rst | 257 +++- 2 files changed, 258 insertions(+) create mode 100644 Documentation/x86/sva.rst diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 265d9e9..e5d5ff0 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -30,3 +30,4 @@ x86-specific Documentation usb-legacy-support i386/index x86_64/index + sva diff --git a/Documentation/x86/sva.rst b/Documentation/x86/sva.rst new file mode 100644 index 000..076efd5 --- /dev/null +++ b/Documentation/x86/sva.rst @@ -0,0 +1,257 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Shared Virtual Addressing (SVA) with ENQCMD +=== + +Background +== + +Shared Virtual Addressing (SVA) allows the processor and device to use the +same virtual addresses avoiding the need for software to translate virtual +addresses to physical addresses. SVA is what PCIe calls Shared Virtual +Memory (SVM). + +In addition to the convenience of using application virtual addresses +by the device, it also doesn't require pinning pages for DMA. +PCIe Address Translation Services (ATS) along with Page Request Interface +(PRI) allow devices to function much the same way as the CPU handling +application page-faults. For more information please refer to the PCIe +specification Chapter 10: ATS Specification. + +Use of SVA requires IOMMU support in the platform. IOMMU is also +required to support the PCIe features ATS and PRI. ATS allows devices +to cache translations for virtual addresses. The IOMMU driver uses the +mmu_notifier() support to keep the device TLB cache and the CPU cache in +sync. When an ATS lookup fails for a virtual address, the device should +use the PRI in order to request the virtual address to be paged into the +CPU page tables. The device must use ATS again in order the fetch the +translation before use. + +Shared Hardware Workqueues +== + +Unlike Single Root I/O Virtualization (SR-IOV), Scalable IOV (SIOV) permits +the use of Shared Work Queues (SWQ) by both applications and Virtual +Machines (VM's). This allows better hardware utilization vs. hard +partitioning resources that could result in under utilization. In order to +allow the hardware to distinguish the context for which work is being +executed in the hardware by SWQ interface, SIOV uses Process Address Space +ID (PASID), which is a 20-bit number defined by the PCIe SIG. + +PASID value is encoded in all transactions from the device. This allows the +IOMMU to track I/O on a per-PASID granularity in addition to using the PCIe +Resource Identifier (RID) which is the Bus/Device/Function. + + +ENQCMD +== + +ENQCMD is a new instruction on Intel platforms that atomically submits a +work descriptor to a device. The descriptor includes the operation to be +performed, virtual addresses of all parameters, virtual address of a completion +record, and the PASID (process address space ID) of the current process. + +ENQCMD works with non-posted semantics and carries a status back if the +command was accepted by hardware. This allows the submitter to know if the +submission needs to be retried or other device specific mechanisms to +implement fairness or ensure forward progress should be provided. + +ENQCMD is the glue that ensures applications can directly submit commands +to the hardware and also permits hardware to be aware of application context +to perform I/O operations via use of PASID. + +Process Address Space Tagging += + +A new thread-scoped MSR (IA32_PASID) provides the connection between +user processes and the rest of the hardware. When an application first +accesses an SVA-capable device, this MSR is initialized with a newly +allocated PASID. The driver for the device calls an IOMMU-specific API +that sets up the routing for DMA and page-requests. + +For example, the Intel Data Streaming Accelerator (DSA) uses +iommu_sva_bind_device(), which will
[tip: x86/pasid] mm: Add a pasid member to struct mm_struct
The following commit has been merged into the x86/pasid branch of tip:
Commit-ID: 52ad9bc64c74167466e70e0df4b99ee5ccef0078
Gitweb:
https://git.kernel.org/tip/52ad9bc64c74167466e70e0df4b99ee5ccef0078
Author:Fenghua Yu
AuthorDate:Tue, 15 Sep 2020 09:30:11 -07:00
Committer: Borislav Petkov
CommitterDate: Thu, 17 Sep 2020 20:22:15 +02:00
mm: Add a pasid member to struct mm_struct
A PASID is shared by all threads in a process. So the logical place to
keep track of it is in the mm_struct. Both ARM and x86 would use this
PASID.
[ bp: Massage commit message. ]
Suggested-by: Christoph Hellwig
Signed-off-by: Fenghua Yu
Signed-off-by: Borislav Petkov
Reviewed-by: Tony Luck
Link:
https://lkml.kernel.org/r/1600187413-163670-8-git-send-email-fenghua...@intel.com
---
include/linux/mm_types.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 496c3ff..1ff0615 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -542,6 +542,10 @@ struct mm_struct {
atomic_long_t hugetlb_usage;
#endif
struct work_struct async_put_work;
+
+#ifdef CONFIG_IOMMU_SUPPORT
+ u32 pasid;
+#endif
} __randomize_layout;
/*
[tip: x86/pasid] x86/fpu/xstate: Add supervisor PASID state for ENQCMD
The following commit has been merged into the x86/pasid branch of tip:
Commit-ID: b454feb9abc1a9ee876fb84bfea0fc8d726f5bc4
Gitweb:
https://git.kernel.org/tip/b454feb9abc1a9ee876fb84bfea0fc8d726f5bc4
Author:Yu-cheng Yu
AuthorDate:Tue, 15 Sep 2020 09:30:09 -07:00
Committer: Borislav Petkov
CommitterDate: Thu, 17 Sep 2020 20:22:10 +02:00
x86/fpu/xstate: Add supervisor PASID state for ENQCMD
The ENQCMD instruction reads a PASID from the IA32_PASID MSR. The
MSR is stored in the task's supervisor XSAVE* PASID state and is
context-switched by XSAVES/XRSTORS.
[ bp: Add (in-)definite articles and massage. ]
Signed-off-by: Yu-cheng Yu
Co-developed-by: Fenghua Yu
Signed-off-by: Fenghua Yu
Signed-off-by: Borislav Petkov
Reviewed-by: Tony Luck
Link:
https://lkml.kernel.org/r/1600187413-163670-6-git-send-email-fenghua...@intel.com
---
arch/x86/include/asm/fpu/types.h | 11 ++-
arch/x86/include/asm/fpu/xstate.h | 2 +-
arch/x86/kernel/fpu/xstate.c | 6 +-
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index c87364e..f5a38a5 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -114,7 +114,7 @@ enum xfeature {
XFEATURE_Hi16_ZMM,
XFEATURE_PT_UNIMPLEMENTED_SO_FAR,
XFEATURE_PKRU,
- XFEATURE_RSRVD_COMP_10,
+ XFEATURE_PASID,
XFEATURE_RSRVD_COMP_11,
XFEATURE_RSRVD_COMP_12,
XFEATURE_RSRVD_COMP_13,
@@ -134,6 +134,7 @@ enum xfeature {
#define XFEATURE_MASK_Hi16_ZMM (1 << XFEATURE_Hi16_ZMM)
#define XFEATURE_MASK_PT (1 << XFEATURE_PT_UNIMPLEMENTED_SO_FAR)
#define XFEATURE_MASK_PKRU (1 << XFEATURE_PKRU)
+#define XFEATURE_MASK_PASID(1 << XFEATURE_PASID)
#define XFEATURE_MASK_LBR (1 << XFEATURE_LBR)
#define XFEATURE_MASK_FPSSE(XFEATURE_MASK_FP | XFEATURE_MASK_SSE)
@@ -256,6 +257,14 @@ struct arch_lbr_state {
struct lbr_entryentries[];
} __packed;
+/*
+ * State component 10 is supervisor state used for context-switching the
+ * PASID state.
+ */
+struct ia32_pasid_state {
+ u64 pasid;
+} __packed;
+
struct xstate_header {
u64 xfeatures;
u64 xcomp_bv;
diff --git a/arch/x86/include/asm/fpu/xstate.h
b/arch/x86/include/asm/fpu/xstate.h
index 14ab815..47a9223 100644
--- a/arch/x86/include/asm/fpu/xstate.h
+++ b/arch/x86/include/asm/fpu/xstate.h
@@ -35,7 +35,7 @@
XFEATURE_MASK_BNDCSR)
/* All currently supported supervisor features */
-#define XFEATURE_MASK_SUPERVISOR_SUPPORTED (0)
+#define XFEATURE_MASK_SUPERVISOR_SUPPORTED (XFEATURE_MASK_PASID)
/*
* A supervisor state component may not always contain valuable information,
diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 038e19c..67f1a03 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -37,6 +37,7 @@ static const char *xfeature_names[] =
"AVX-512 ZMM_Hi256" ,
"Processor Trace (unused)" ,
"Protection Keys User registers",
+ "PASID state",
"unknown xstate feature",
};
@@ -51,6 +52,7 @@ static short xsave_cpuid_features[] __initdata = {
X86_FEATURE_AVX512F,
X86_FEATURE_INTEL_PT,
X86_FEATURE_PKU,
+ X86_FEATURE_ENQCMD,
};
/*
@@ -318,6 +320,7 @@ static void __init print_xstate_features(void)
print_xstate_feature(XFEATURE_MASK_ZMM_Hi256);
print_xstate_feature(XFEATURE_MASK_Hi16_ZMM);
print_xstate_feature(XFEATURE_MASK_PKRU);
+ print_xstate_feature(XFEATURE_MASK_PASID);
}
/*
@@ -592,6 +595,7 @@ static void check_xstate_against_struct(int nr)
XCHECK_SZ(sz, nr, XFEATURE_ZMM_Hi256, struct avx_512_zmm_uppers_state);
XCHECK_SZ(sz, nr, XFEATURE_Hi16_ZMM, struct avx_512_hi16_state);
XCHECK_SZ(sz, nr, XFEATURE_PKRU, struct pkru_state);
+ XCHECK_SZ(sz, nr, XFEATURE_PASID, struct ia32_pasid_state);
/*
* Make *SURE* to add any feature numbers in below if
@@ -601,7 +605,7 @@ static void check_xstate_against_struct(int nr)
if ((nr < XFEATURE_YMM) ||
(nr >= XFEATURE_MAX) ||
(nr == XFEATURE_PT_UNIMPLEMENTED_SO_FAR) ||
- ((nr >= XFEATURE_RSRVD_COMP_10) && (nr <= XFEATURE_LBR))) {
+ ((nr >= XFEATURE_RSRVD_COMP_11) && (nr <= XFEATURE_LBR))) {
WARN_ONCE(1, "no structure for xstate: %d\n", nr);
XSTATE_WARN_ON(1);
}
[tip: x86/pasid] x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions
The following commit has been merged into the x86/pasid branch of tip:
Commit-ID: ff4f82816dff28ffaaff96d1409bb3811d345514
Gitweb:
https://git.kernel.org/tip/ff4f82816dff28ffaaff96d1409bb3811d345514
Author:Fenghua Yu
AuthorDate:Tue, 15 Sep 2020 09:30:08 -07:00
Committer: Borislav Petkov
CommitterDate: Thu, 17 Sep 2020 20:03:54 +02:00
x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions
Work submission instruction comes in two flavors. ENQCMD can be called
both in ring 3 and ring 0 and always uses the contents of a PASID MSR
when shipping the command to the device. ENQCMDS allows a kernel driver
to submit commands on behalf of a user process. The driver supplies the
PASID value in ENQCMDS. There isn't any usage of ENQCMD in the kernel as
of now.
The CPU feature flag is shown as "enqcmd" in /proc/cpuinfo.
Signed-off-by: Fenghua Yu
Signed-off-by: Borislav Petkov
Reviewed-by: Tony Luck
Link:
https://lkml.kernel.org/r/1600187413-163670-5-git-send-email-fenghua...@intel.com
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/cpuid-deps.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 2901d5d..fea10d0 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -353,6 +353,7 @@
#define X86_FEATURE_CLDEMOTE (16*32+25) /* CLDEMOTE instruction */
#define X86_FEATURE_MOVDIRI(16*32+27) /* MOVDIRI instruction */
#define X86_FEATURE_MOVDIR64B (16*32+28) /* MOVDIR64B instruction */
+#define X86_FEATURE_ENQCMD (16*32+29) /* ENQCMD and ENQCMDS
instructions */
/* AMD-defined CPU features, CPUID level 0x8007 (EBX), word 17 */
#define X86_FEATURE_OVERFLOW_RECOV (17*32+ 0) /* MCA overflow recovery
support */
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 3cbe24c..3a02707 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -69,6 +69,7 @@ static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_CQM_MBM_TOTAL,X86_FEATURE_CQM_LLC },
{ X86_FEATURE_CQM_MBM_LOCAL,X86_FEATURE_CQM_LLC },
{ X86_FEATURE_AVX512_BF16, X86_FEATURE_AVX512VL },
+ { X86_FEATURE_ENQCMD, X86_FEATURE_XSAVES},
{}
};
[tip: x86/pasid] iommu/vt-d: Change flags type to unsigned int in binding mm
The following commit has been merged into the x86/pasid branch of tip:
Commit-ID: 2a5054c6e7b16906984ac36a7363ca46b8d99ade
Gitweb:
https://git.kernel.org/tip/2a5054c6e7b16906984ac36a7363ca46b8d99ade
Author:Fenghua Yu
AuthorDate:Tue, 15 Sep 2020 09:30:06 -07:00
Committer: Borislav Petkov
CommitterDate: Thu, 17 Sep 2020 19:21:30 +02:00
iommu/vt-d: Change flags type to unsigned int in binding mm
"flags" passed to intel_svm_bind_mm() is a bit mask and should be
defined as "unsigned int" instead of "int".
Change its type to "unsigned int".
Suggested-by: Thomas Gleixner
Signed-off-by: Fenghua Yu
Signed-off-by: Borislav Petkov
Reviewed-by: Tony Luck
Reviewed-by: Lu Baolu
Acked-by: Joerg Roedel
Link:
https://lkml.kernel.org/r/1600187413-163670-3-git-send-email-fenghua...@intel.com
---
drivers/iommu/intel/svm.c | 7 ---
include/linux/intel-iommu.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index e78a74a..fc90a07 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -446,7 +446,8 @@ out:
/* Caller must hold pasid_mutex, mm reference */
static int
-intel_svm_bind_mm(struct device *dev, int flags, struct svm_dev_ops *ops,
+intel_svm_bind_mm(struct device *dev, unsigned int flags,
+ struct svm_dev_ops *ops,
struct mm_struct *mm, struct intel_svm_dev **sd)
{
struct intel_iommu *iommu = device_to_iommu(dev, NULL, NULL);
@@ -1033,7 +1034,7 @@ intel_svm_bind(struct device *dev, struct mm_struct *mm,
void *drvdata)
{
struct iommu_sva *sva = ERR_PTR(-EINVAL);
struct intel_svm_dev *sdev = NULL;
- int flags = 0;
+ unsigned int flags = 0;
int ret;
/*
@@ -1042,7 +1043,7 @@ intel_svm_bind(struct device *dev, struct mm_struct *mm,
void *drvdata)
* and intel_svm etc.
*/
if (drvdata)
- flags = *(int *)drvdata;
+ flags = *(unsigned int *)drvdata;
mutex_lock(&pasid_mutex);
ret = intel_svm_bind_mm(dev, flags, NULL, mm, &sdev);
if (ret)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 7322073..9c3e833 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -765,7 +765,7 @@ struct intel_svm {
struct mm_struct *mm;
struct intel_iommu *iommu;
- int flags;
+ unsigned int flags;
u32 pasid;
int gpasid; /* In case that guest PASID is different from host PASID */
struct list_head devs;
回复：[PATCH] riscv: fix pfn_to_virt err in do_page_fault().
Hi Christoph, > On Thu, Sep 17, 2020 at 03:25:49PM +0800, liush wrote: > > The argument to pfn_to_virt() should be pfn not the value of CSR_SATP. > > > > Signed-off-by: liush > > --- > > arch/riscv/mm/fault.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c > > index 716d64e..9b4e088 100644 > > --- a/arch/riscv/mm/fault.c > > +++ b/arch/riscv/mm/fault.c > > @@ -212,7 +212,7 @@ asmlinkage void do_page_fault(struct pt_regs *regs) > > * of a task switch. > > */ > >index = pgd_index(addr); > > - pgd = (pgd_t *)pfn_to_virt(csr_read(CSR_SATP)) + index; > > + pgd = (pgd_t *)pfn_to_virt(csr_read(CSR_SATP) & SATP_PPN) + index; > This adds a crazy long line. One nice way to clean this up would be to > add a local pfn variable, as it would also make the code more readable. Thanks, i'll modify it in next revision
[tip: x86/pasid] x86/msr-index: Define an IA32_PASID MSR
The following commit has been merged into the x86/pasid branch of tip: Commit-ID: f0f2f9feb4ee6f28729e5388da3c03ce1dac077a Gitweb: https://git.kernel.org/tip/f0f2f9feb4ee6f28729e5388da3c03ce1dac077a Author:Fenghua Yu AuthorDate:Tue, 15 Sep 2020 09:30:10 -07:00 Committer: Borislav Petkov CommitterDate: Thu, 17 Sep 2020 20:22:15 +02:00 x86/msr-index: Define an IA32_PASID MSR The IA32_PASID MSR (0xd93) contains the Process Address Space Identifier (PASID), a 20-bit value. Bit 31 must be set to indicate the value programmed in the MSR is valid. Hardware uses the PASID to identify a process address space and direct responses to the right address space. Signed-off-by: Fenghua Yu Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Link: https://lkml.kernel.org/r/1600187413-163670-7-git-send-email-fenghua...@intel.com --- arch/x86/include/asm/msr-index.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h index 2859ee4..aaddc6a 100644 --- a/arch/x86/include/asm/msr-index.h +++ b/arch/x86/include/asm/msr-index.h @@ -257,6 +257,9 @@ #define MSR_IA32_LASTINTFROMIP 0x01dd #define MSR_IA32_LASTINTTOIP 0x01de +#define MSR_IA32_PASID 0x0d93 +#define MSR_IA32_PASID_VALID BIT_ULL(31) + /* DEBUGCTLMSR bits (others vary by model): */ #define DEBUGCTLMSR_LBR(1UL << 0) /* last branch recording */ #define DEBUGCTLMSR_BTF_SHIFT 1
Re: [PATCH 00/13] mm: clean up some lru related pieces
On Thu 17-09-20 21:00:38, Yu Zhao wrote: > Hi Andrew, > > I see you have taken this: > mm: use add_page_to_lru_list()/page_lru()/page_off_lru() > Do you mind dropping it? > > Michal asked to do a bit of additional work. So I thought I probably > should create a series to do more cleanups I've been meaning to. > > This series contains the change in the patch above and goes a few > more steps farther. It's intended to improve readability and should > not have any performance impacts. There are minor behavior changes in > terms of debugging and error reporting, which I have all highlighted > in the individual patches. All patches were properly tested on 5.8 > running Chrome OS, with various debug options turned on. > > Michal, > > Do you mind taking a looking at the entire series? I have stopped at patch 3 as all patches until then are really missing any justification. What is the point for all this to be done? The code is far from trivial and just shifting around sounds like a risk. You are removing ~50 LOC which is always nice but I am not sure the resulting code is better maintainble or easier to read and understand. Just consider __ClearPageLRU moving to page_off_lru patch. What is the additional value of having the flag moved and burry it into a function to have even more side effects? I found the way how __ClearPageLRU is nicely close to removing it from LRU easier to follow. This is likely subjective and other might think differently but as it is not clear what is your actual goal here it is hard to judge pros and cons. -- Michal Hocko SUSE Labs
Re: [PATCH v2] software_node: Add support for fwnode_graph*() family of functions
On 18/09/2020 08:34, Sakari Ailus wrote:
> On Fri, Sep 18, 2020 at 07:49:31AM +0100, Dan Scally wrote:
>> Good morning
>>
>> On 18/09/2020 07:22, Sakari Ailus wrote:
>>> Hi Dan,
>>>
>>> On Wed, Sep 16, 2020 at 02:22:10PM +0100, Dan Scally wrote:
Hi Sakari - thanks for the comments
On 16/09/2020 10:17, Sakari Ailus wrote:
> Moi Daniel and Heikki,
>
> On Wed, Sep 16, 2020 at 12:28:27AM +0100, Daniel Scally wrote:
>> From: Heikki Krogerus
>>
>> This implements the remaining .graph_* callbacks in the
>> fwnode operations vector for the software nodes. That makes
>> the fwnode_graph*() functions available in the drivers also
>> when software nodes are used.
>>
>> The implementation tries to mimic the "OF graph" as much as
>> possible, but there is no support for the "reg" device
>> property. The ports will need to have the index in their
>> name which starts with "port" (for example "port0", "port1",
>> ...) and endpoints will use the index of the software node
>> that is given to them during creation. The port nodes can
>> also be grouped under a specially named "ports" subnode,
>> just like in DT, if necessary.
>>
>> The remote-endpoints are reference properties under the
>> endpoint nodes that are named "remote-endpoint".
>>
>> Signed-off-by: Heikki Krogerus
>> Co-developed-by: Daniel Scally
>> Signed-off-by: Daniel Scally
>> ---
>> changes in v2:
>> - added software_node_device_is_available
>> - altered software_node_get_next_child to get references
>> - altered software_node_get_next_endpoint to release references
>> to ports and avoid passing invalid combinations of swnodes to
>> software_node_get_next_child
>> - altered swnode_graph_find_next_port to release port rather than
>> old
>>
>> drivers/base/swnode.c | 129 +-
>> 1 file changed, 127 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
>> index 010828fc785b..d69034b807e3 100644
>> --- a/drivers/base/swnode.c
>> +++ b/drivers/base/swnode.c
>> @@ -363,6 +363,11 @@ static void software_node_put(struct fwnode_handle
>> *fwnode)
>> kobject_put(&swnode->kobj);
>> }
>>
>> +static bool software_node_device_is_available(const struct
>> fwnode_handle *fwnode)
>> +{
>> +return is_software_node(fwnode);
> This basically tells whether the device is there. Are there software node
> based devices, i.e. do you need this?
>
> If you do really need this, then I guess this could just return true for
> now as if you somehow get here, the node is a software node anyway.
I do think its better to include it; I'm targeting using this with
ipu3-cio2; the cio2_parse_firmware() call there doesn't pass
FWNODE_GRAPH_DEVICE_DISABLED to fwnode_graph_get_endpoint_by_id() so
>>> I wonder if this has something to do with replacing the device's fwnode
>>> in the cio2-bridge patch.
>>>
>>> It's the device that needs to be enabled, and it's not a software node.
>>>
>> I think it is because of that yes, but I don't see a way around it at
>> the moment - unless there's a way to attach the software_node port and
>> endpoints that cio2-bridge creates to the device's existing firmware
>> instead.
> I thought this was how it was meant to be used?
>
> The secondary field is there for this purpose. But it may be not all fwnode
> interface functions operate on fwnode->secondary?
Let me test it; it might just require some changes to
software_node_graph_get_port_parent() to check if the parent fwnode is a
secondary, and if it is to return the primary instead.
Re: [PATCH -next] rapidio: Remove set but not used variable 'rc'
On Fri, Sep 18, 2020 at 03:18:44PM +0800, Zheng Yongjun wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/rapidio/rio_cm.c: In function rio_txcq_handler:
> drivers/rapidio/rio_cm.c:673:7: warning: variable ‘rc’ set but not used
> [-Wunused-but-set-variable]
>
> rc is never used, so remove it.
>
> Signed-off-by: Zheng Yongjun
> ---
> drivers/rapidio/rio_cm.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
> index 50ec53d67a4c..545693bd86a3 100644
> --- a/drivers/rapidio/rio_cm.c
> +++ b/drivers/rapidio/rio_cm.c
> @@ -670,12 +670,11 @@ static void rio_txcq_handler(struct cm_dev *cm, int
> slot)
>*/
> if (!list_empty(&cm->tx_reqs) && (cm->tx_cnt < RIOCM_TX_RING_SIZE)) {
> struct tx_req *req, *_req;
> - int rc;
>
> list_for_each_entry_safe(req, _req, &cm->tx_reqs, node) {
> list_del(&req->node);
> cm->tx_buf[cm->tx_slot] = req->buffer;
> - rc = rio_add_outb_message(cm->mport, req->rdev, cmbox,
> + rio_add_outb_message(cm->mport, req->rdev, cmbox,
> req->buffer, req->len);
That's not the only place in this file where this call is made, and the
return value is ignored.
It should be fixed up to properly check that return value, not ignore
it. Can you do that instead for the places this is called?
thanks,
greg k-h
Re: [PATCH AUTOSEL 5.4 265/330] drm/amd/powerplay: try to do a graceful shutdown on SW CTF
On Fri, Sep 18, 2020 at 07:17:10AM +, Quan, Evan wrote: > [AMD Official Use Only - Internal Distribution Only] That didn't work :)
[PATCH] vt: fix some doc warnings in vt.c
Fix following warnings caused by mismatch bewteen function parameters and comments. drivers/tty/vt/vt.c:3994: warning: Function parameter or member 'vc' not described in 'con_debug_enter' drivers/tty/vt/vt.c:3994: warning: Excess function parameter 'sw' description in 'con_debug_enter' drivers/tty/vt/vt.c:4051: warning: Excess function parameter 'sw' description in 'con_debug_leave' Signed-off-by: Xiaofei Tan --- drivers/tty/vt/vt.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c index 19cd4a4..1e9a6b6 100644 --- a/drivers/tty/vt/vt.c +++ b/drivers/tty/vt/vt.c @@ -1180,7 +1180,6 @@ static inline int resize_screen(struct vc_data *vc, int width, int height, /** * vc_do_resize- resizing method for the tty * @tty: tty being resized - * @real_tty: real tty (different to tty if a pty/tty pair) * @vc: virtual console private data * @cols: columns * @lines: lines @@ -3980,7 +3979,7 @@ EXPORT_SYMBOL(con_is_visible); /** * con_debug_enter - prepare the console for the kernel debugger - * @sw: console driver + * @vc: virtual console * * Called when the console is taken over by the kernel debugger, this * function needs to save the current console state, then put the console @@ -4038,7 +4037,6 @@ EXPORT_SYMBOL_GPL(con_debug_enter); /** * con_debug_leave - restore console state - * @sw: console driver * * Restore the console state to what it was before the kernel debugger * was invoked. -- 2.8.1
Re: linux-next: manual merge of the staging tree with the crypto tree
On Fri, Sep 18, 2020 at 03:41:34PM +1000, Herbert Xu wrote:
> On Fri, Sep 18, 2020 at 03:21:27PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the staging tree got a conflict in:
> >
> > drivers/staging/rtl8192e/Kconfig
> >
> > between commit:
> >
> > 054694a46d64 ("staging/rtl8192e: switch to RC4 library interface")
> >
> > from the crypto tree and commits:
> >
> > 243d040a6e4a ("staging: rtl8192e: fix kconfig dependency warning for
> > RTLLIB_CRYPTO_TKIP")
> > 02c4260713d6 ("staging: rtl8192e: fix kconfig dependency warning for
> > RTLLIB_CRYPTO_WEP")
> >
> > from the staging tree.
>
> Those two commits should just be dropped.
Ok, I'll go revert these.
>
> > diff --cc drivers/staging/rtl8192e/Kconfig
> > index 4c440bdaaf6e,31e076cc6f16..
> > --- a/drivers/staging/rtl8192e/Kconfig
> > +++ b/drivers/staging/rtl8192e/Kconfig
> > @@@ -25,7 -26,8 +26,8 @@@ config RTLLIB_CRYPTO_CCM
> > config RTLLIB_CRYPTO_TKIP
> > tristate "Support for rtllib TKIP crypto"
> > depends on RTLLIB
> > + select CRYPTO
> > - select CRYPTO_ARC4
> > + select CRYPTO_LIB_ARC4
>
> As the driver has been converted over to the lib arc4 API, it
> does not need to select CRYPTO at all.
Is it converted in your tree? If so, have a branch/tag I can pull in to
prevent merge issues in the future?
thanks,
greg k-h
Re: linux-next: manual merge of the staging tree with the crypto tree
On Fri, Sep 18, 2020 at 09:49:11AM +0200, Greg KH wrote: > > Ok, I'll go revert these. Thanks! > > As the driver has been converted over to the lib arc4 API, it > > does not need to select CRYPTO at all. > > Is it converted in your tree? If so, have a branch/tag I can pull in to > prevent merge issues in the future? It's in the cryptodev tree, but unfortunately it's not in a topic branch so you'd be pulling all other crypto changes along with it. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 5/8] x86/mce: Avoid tail copy when machine check terminated a copy from user
On Thu, Sep 17, 2020 at 02:57:51PM -0700, Luck, Tony wrote: > On Thu, Sep 17, 2020 at 07:04:06PM +0200, Borislav Petkov wrote: > > So actually, I'm thinking: > > > > .LMCE_during_user_access: > > mov $-ENODEV, %eax > > ASM_CLAC > > ret > > > > I have no clue which error code we should put there but it should be an > > error code which tells you not to retry and to back off immediately. > > That does look a lot easier to understand *at this point* in the code. > > But the existing iterator code is not expecting an error code. Just a > count of bytes not copied. > > So doing this would mean some surgery on the maze of giant #defines that > is lib/iov_iter.c Ok, since the user task is guaranteed to get the SIGBUS, let's just resort to documenting this properly for now and we can consider more involved surgery later, if really needed. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] vt: fix some doc warnings in vt.c
On 18. 09. 20, 9:47, Xiaofei Tan wrote: > Fix following warnings caused by mismatch bewteen function parameters > and comments. > drivers/tty/vt/vt.c:3994: warning: Function parameter or member 'vc' not > described in 'con_debug_enter' > drivers/tty/vt/vt.c:3994: warning: Excess function parameter 'sw' description > in 'con_debug_enter' > drivers/tty/vt/vt.c:4051: warning: Excess function parameter 'sw' description > in 'con_debug_leave' It looks like I fixed those in https://lore.kernel.org/r/20200818085655.12071-6-jsl...@suse.cz too. Could you rebase on the top of tty-next? thanks, -- js suse labs
Re: [PATCHv3 1/1] ext4: Optimize file overwrites
On Fri, Sep 18, 2020 at 7:09 AM Ritesh Harjani wrote:
>
> In case if the file already has underlying blocks/extents allocated
> then we don't need to start a journal txn and can directly return
> the underlying mapping. Currently ext4_iomap_begin() is used by
> both DAX & DIO path. We can check if the write request is an
> overwrite & then directly return the mapping information.
>
> This could give a significant perf boost for multi-threaded writes
> specially random overwrites.
> On PPC64 VM with simulated pmem(DAX) device, ~10x perf improvement
> could be seen in random writes (overwrite). Also bcoz this optimizes
> away the spinlock contention during jbd2 slab cache allocation
> (jbd2_journal_handle). On x86 VM, ~2x perf improvement was observed.
>
> Reported-by: Dan Williams
> Suggested-by: Jan Kara
> Signed-off-by: Ritesh Harjani
I have applied your patch on top of recent Linus Git and boot-tested on x86-64.
Here I have LTP installed.
If you have a LTP filesystem test-/use-case you know for testing,
please let me know.
Yes, I have seen the FIO config in the cover-letter.
Maybe you have a different FIO config - 16G AFAIK is too big here.
Feel free to add...
Tested-by: Sedat Dilek # Compile and boot on
x86-64 Debian/unstable
Thanks.
- Sedat -
> ---
> fs/ext4/inode.c | 18 +++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 10dd470876b3..6eae17758ece 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3437,14 +3437,26 @@ static int ext4_iomap_begin(struct inode *inode,
> loff_t offset, loff_t length,
> map.m_len = min_t(loff_t, (offset + length - 1) >> blkbits,
> EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;
>
> - if (flags & IOMAP_WRITE)
> + if (flags & IOMAP_WRITE) {
> + /*
> +* We check here if the blocks are already allocated, then we
> +* don't need to start a journal txn and we can directly
> return
> +* the mapping information. This could boost performance
> +* especially in multi-threaded overwrite requests.
> +*/
> + if (offset + length <= i_size_read(inode)) {
> + ret = ext4_map_blocks(NULL, inode, &map, 0);
> + if (ret > 0 && (map.m_flags & EXT4_MAP_MAPPED))
> + goto out;
> + }
> ret = ext4_iomap_alloc(inode, &map, flags);
> - else
> + } else {
> ret = ext4_map_blocks(NULL, inode, &map, 0);
> + }
>
> if (ret < 0)
> return ret;
> -
> +out:
> ext4_set_iomap(inode, iomap, &map, offset, length);
>
> return 0;
> --
> 2.26.2
>
Re: [PATCH 1/2] usb: serial: option: Fix the lackage for Quectel EG95 LTE modem support
On Tue, Sep 01, 2020 at 01:00:21PM +0800, William Sung wrote:
> * Add reset-resume callback for resetting USB devices after MCU exits
> from suspend/sleep mode.
Please split this in it's own patch and argue for why it's needed.
> * Because Quectel EG95 uses USB interface 4 as a USB network device, so
> return from option_startup() to prevent being used as a USB serial
> device.
>
> Fixes: da6902e5b6db ("USB: serial: option: add Quectel EG95 LTE modem"
>
> Signed-off-by: William Sung
> ---
> drivers/usb/serial/option.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 89b3192af326..9de8aec47e5e 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -2069,6 +2069,7 @@ static struct usb_serial_driver option_1port_device = {
> #ifdef CONFIG_PM
> .suspend = usb_wwan_suspend,
> .resume= usb_wwan_resume,
> + .reset_resume = usb_wwan_resume,
> #endif
> };
>
> @@ -2104,6 +2105,11 @@ static int option_probe(struct usb_serial *serial,
> if (device_flags & NUMEP2 && iface_desc->bNumEndpoints != 2)
> return -ENODEV;
>
> + /* Quectel EC25 & EC21 & EG91 & EG95 ... interface 4 can be used as USB
> network device */
> + if (serial->dev->descriptor.idVendor == cpu_to_le16(0x2c7c) &&
> + serial->interface->cur_altsetting->desc.bInterfaceNumber >= 4)
> + return -ENODEV;
And please use the normal mechanisms for blacklisting interfaces (e.g.
the RSVD() macro).
> +
> /* Store the device flags so we can use them during attach. */
> usb_set_serial_data(serial, (void *)device_flags);
Also make sure your patches have distinct and descriptive summaries
(Subject lines).
Johan
Re: [RFC PATCH] Add bridge driver to connect sensors to CIO2 device via software nodes on ACPI platforms
Hi Andy, On Thu, Sep 17, 2020 at 03:45:14PM +0300, Andy Shevchenko wrote: > On Thu, Sep 17, 2020 at 11:52:28AM +0100, Dan Scally wrote: > > On 17/09/2020 11:33, Sakari Ailus wrote: > > > a module and not enlarge everyone's kernel, and the initialisation would > > > at > > > the same time take place before the rest of what the CIO2 driver does in > > > probe. > > I thought of that as well, but wasn't sure which was preferable. I can > > compress it into the CIO2 driver though sure. > > Sakari, I tend to agree with Dan and have the board file separated from the > driver and even framework. And it'll be linked to the kernel binary then I suppose? I don't have a strong opinion either way, just thought that this will affect anyone using x86 machines, whether or not they have IPU3. I guess it could be compiled in if the ipu3-cio2 driver is enabled? -- Sakari Ailus
Re: linux-next: build warning after merge of the v4l-dvb-fixes tree
On (20/09/18 17:21), Stephen Rothwell wrote: > Hi all, > > After merging the v4l-dvb-fixes tree, today's linux-next build (htmldocs) > produced this warning: > > Documentation/userspace-api/media/v4l/buffer.rst:692: WARNING: The > "flat-table" directive is empty; content required. > > .. flat-table:: > :header-rows: 0 > :stub-columns: 0 > :widths: 3 1 4 Thanks. I think there is a patch for this already. Will hit linux-next soon. -ss
[PATCH] nvme: use correct upper limit for tag in nvme_handle_cqe()
We met a crash issue when hot-insert a nvme device, blk_mq_tag_to_rq()
returned null(req=null), then crash happened in nvme_end_request():
req = blk_mq_tag_to_rq();
struct nvme_request *rq = nvme_req(req); //rq = req + 1
rq->result = result; <==crash here!!!
[ 1124.256246] nvme nvme5: pci function :e1:00.0
[ 1124.256323] nvme :e1:00.0: enabling device ( -> 0002)
[ 1125.720859] nvme nvme5: 96/0/0 default/read/poll queues
[ 1125.732483] nvme5n1: p1 p2 p3
[ 1125.788049] BUG: unable to handle kernel NULL pointer dereference at
0130
[ 1125.788054] PGD 0 P4D 0
[ 1125.788057] Oops: 0002 [#1] SMP NOPTI
[ 1125.788059] CPU: 50 PID: 0 Comm: swapper/50 Kdump: loaded Tainted: G
--- -t - 4.18.0-147.el8.x86_64 #1
[ 1125.788065] RIP: 0010:nvme_irq+0xe8/0x240 [nvme]
[ 1125.788068] RSP: 0018:916b8ec83ed0 EFLAGS: 00010813
[ 1125.788069] RAX: RBX: 918ae9211b00 RCX:
[ 1125.788070] RDX: 400b RSI: RDI:
[ 1125.788071] RBP: 918ae887 R08: 0004 R09:
918ae887
[ 1125.788072] R10: R11: R12:
[ 1125.788073] R13: 0001 R14: R15:
0001
[ 1125.788075] FS: () GS:916b8ec8()
knlGS:
[ 1125.788075] CS: 0010 DS: ES: CR0: 80050033
[ 1125.788076] CR2: 0130 CR3: 001768f0 CR4:
00340ee0
[ 1125.788077] Call Trace:
[ 1125.788080]
[ 1125.788085] __handle_irq_event_percpu+0x40/0x180
[ 1125.788087] handle_irq_event_percpu+0x30/0x80
[ 1125.788089] handle_irq_event+0x36/0x53
[ 1125.788090] handle_edge_irq+0x82/0x190
[ 1125.788094] handle_irq+0xbf/0x100
[ 1125.788098] do_IRQ+0x49/0xd0
[ 1125.788100] common_interrupt+0xf/0xf
The analysis of the possible cause of above crash as below.
According to our test, in nvme_pci_enable(), 'dev->q_depth' is set to 1024,
in nvme_create_io_queues()->nvme_alloc_queue(), 'nvmeq->q_depth' is set to
'dev->q_depth'. In nvme_dev_add(), 'dev->tagset.queue_depth' is set to 1023:
dev->tagset.queue_depth = min_t(unsigned int, dev->q_depth,
BLK_MQ_MAX_DEPTH) - 1;
//why -1?? first involved by commit
a4aea562
In nvme_alloc_queue(), 'nvmeq->q_depth' is set to dev->q_depth'.
So we got below values for mutiple depth:
dev->q_depth= 1024
dev->tagset.queue_depth = 1023
nvmeq->q_depth = 1024
In blk_mq_alloc_rqs(), it allocated 1023(dev->tagset.queue_depth) rqs for
one hw queue. In nvme_alloc_queue(), it allocated 1024(nvmeq->q_depth)
cqes for nvmeq->cqes[]. When process cqe in nvme_handle_cqe(), it get it by:
struct nvme_completion *cqe = &nvmeq->cqes[idx];
We also added below prints in nvme_handle_cqe() and blk_mq_tag_to_rq():
static inline void nvme_handle_cqe(struct nvme_queue *nvmeq, u16 idx)
{
volatile struct nvme_completion *cqe = &nvmeq->cqes[idx];
struct request *req;
//debug print
dev_warn(nvmeq->dev->ctrl.device,
"command_id %d completed on queue %d, nvmeq q_depth %d,
nvme tagset q_depth %d\n",
cqe->command_id, le16_to_cpu(cqe->sq_id),
nvmeq->q_depth, nvmeq->dev->tagset.queue_depth);
if (unlikely(cqe->command_id >= nvmeq->q_depth)) {
dev_warn(nvmeq->dev->ctrl.device,
"invalid id %d completed on queue %d\n",
cqe->command_id, le16_to_cpu(cqe->sq_id));
return;
}
... ...
req = blk_mq_tag_to_rq(nvme_queue_tagset(nvmeq),
cqe->command_id);
... ...
}
struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags, unsigned int
tag)
{
//debug print
printk("tag, nr_tags:%d %d\n", tag, tags->nr_tags);
if (tag < tags->nr_tags) {
prefetch(tags->rqs[tag]);
return tags->rqs[tag];
}
return NULL;
}
According to the output, we know the max tag number(nr_tags) is 1023, but
nvmeq->q_depth is 1024 and nvmeq->cqes[] has 1024 cqes. So if command_id(tag)
is 1023, the judgement "if (unlikely(cqe->command_id >= nvmeq->q_depth))"
in nvme_handle_cqe() is useless, we will get a null pointer, which is returned
by blk_mq_tag_to_rq():
[ 16.649973] nvme nvme0: command_id 968 completed on queue 13, nvmeq
q_depth 1024, nvme tagset q_depth 1023
[ 16.649974] tag, nr_tags:968 1023
Thi
Re: [PATCH v2 01/13] dt-bindings: gpio: add common schema for GPIO controllers
On Thu, 17 Sep 2020 at 22:10, Laurent Pinchart wrote: > > Hi Krzysztof, > > Thank you for the patch. > > On Thu, Sep 17, 2020 at 06:52:49PM +0200, Krzysztof Kozlowski wrote: > > Convert parts of gpio.txt bindings into common dtschema file for GPIO > > controllers. > > How about deleting the part that has been converted from gpio.txt ? I did not move everything from the gpio.txt and it is really nicely explained there. I think to leave it as it works as a overview/guide better than YAML. > > > The schema enforces proper naming of GPIO controller nodes and GPIO > > hogs. > > > > The schema should be included by specific GPIO controllers bindings. > > Instead of including it manually, could we use a conditional select: to > apply the schema automatically when a gpio-controller property is > present ? You mean the same way as generic schema for GPIO controllers work? This could be done but the point is to enforce the GPIO controller bindings in GPIO controllers, so also in cases when someone forgets to add "gpio-controller" property. Although, if given GPIO controller schema requires "gpio-controller" then indeed select would work... Best regards, Krzysztof
Re: [PATCH v2] usb: serial: option: Fix the lackage for Quectel EG95 LTE modem support
On Wed, Sep 02, 2020 at 07:03:01PM +0800, William Sung wrote:
> * Add reset-resume callback for resetting USB devices after MCU exits
> from suspend/sleep mode.
Looks like both your patches try to do this. Again, one logical change
per patch, please.
> * Add zero packet support
>
> Fixes: da6902e5b6db ("USB: serial: option: add Quectel EG95 LTE modem"
>
> Signed-off-by: William Sung
> ---
>
> v2: * Add ZLP support
> * Remove redundant code for reserving interface number 4
>
> drivers/usb/serial/option.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 89b3192af326..ba4dc67dab2f 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -1099,7 +1099,7 @@ static const struct usb_device_id option_ids[] = {
> { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EC25),
> .driver_info = RSVD(4) },
> { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EG95),
> - .driver_info = RSVD(4) },
> + .driver_info = RSVD(4) | ZLP },
> { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
> .driver_info = RSVD(4) },
> { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID,
> QUECTEL_PRODUCT_EP06, 0xff, 0xff, 0xff),
> @@ -2069,6 +2069,7 @@ static struct usb_serial_driver option_1port_device = {
> #ifdef CONFIG_PM
> .suspend = usb_wwan_suspend,
> .resume= usb_wwan_resume,
> + .reset_resume = usb_wwan_resume,
> #endif
> };
Johan
Re: [PATCH 3/3 v4] KVM: SVM: Don't flush cache if hardware enforces cache coherency across encryption domains
On Thu, Sep 17, 2020 at 09:20:38PM +, Krish Sadhukhan wrote:
> In some hardware implementations, coherency between the encrypted and
> unencrypted mappings of the same physical page in a VM is enforced. In such a
> system, it is not required for software to flush the VM's page from all CPU
> caches in the system prior to changing the value of the C-bit for the page.
>
> Signed-off-by: Krish Sadhukhan
> ---
> arch/x86/kvm/svm/sev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 7bf7bf734979..3c9a45efdd4d 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -384,7 +384,8 @@ static void sev_clflush_pages(struct page *pages[],
> unsigned long npages)
> uint8_t *page_virtual;
> unsigned long i;
>
> - if (npages == 0 || pages == NULL)
> + if (this_cpu_has(X86_FEATURE_SME_COHERENT) || npages == 0 ||
> + pages == NULL)
> return;
>
> for (i = 0; i < npages; i++) {
> --
Took the first two, Paolo lemme know if I should route this one through
tip too.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH v6 08/12] mm,hwpoison: Rework soft offline for in-use pages
On 2020-08-06 20:49, nao.horigu...@gmail.com wrote:
From: Oscar Salvador
This patch changes the way we set and handle in-use poisoned pages.
Until now, poisoned pages were released to the buddy allocator,
trusting
that the checks that take place prior to hand the page would act as a
safe net and would skip that page.
This has proved to be wrong, as we got some pfn walkers out there, like
compaction, that all they care is the page to be PageBuddy and be in a
freelist.
Although this might not be the only user, having poisoned pages
in the buddy allocator seems a bad idea as we should only have
free pages that are ready and meant to be used as such.
Before explaining the taken approach, let us break down the kind
of pages we can soft offline.
- Anonymous THP (after the split, they end up being 4K pages)
- Hugetlb
- Order-0 pages (that can be either migrated or invalited)
* Normal pages (order-0 and anon-THP)
- If they are clean and unmapped page cache pages, we invalidate
then by means of invalidate_inode_page().
- If they are mapped/dirty, we do the isolate-and-migrate dance.
Either way, do not call put_page directly from those paths.
Instead, we keep the page and send it to page_set_poison to perform
the
right handling.
page_set_poison sets the HWPoison flag and does the last put_page.
This call to put_page is mainly to be able to call
__page_cache_release,
since this function is not exported.
Down the chain, we placed a check for HWPoison page in
free_pages_prepare, that just skips any poisoned page, so those pages
do not end up in any pcplist/freelist.
After that, we set the refcount on the page to 1 and we increment
the poisoned pages counter.
We could do as we do for free pages:
1) wait until the page hits buddy's freelists
2) take it off
3) flag it
The problem is that we could race with an allocation, so by the time
we
want to take the page off the buddy, the page is already allocated,
so we
cannot soft-offline it.
This is not fatal of course, but if it is better if we can close the
race
as does not require a lot of code.
* Hugetlb pages
- We isolate-and-migrate them
After the migration has been successful, we call
dissolve_free_huge_page,
and we set HWPoison on the page if we succeed.
Hugetlb has a slightly different handling though.
While for non-hugetlb pages we cared about closing the race with an
allocation, doing so for hugetlb pages requires quite some additional
code (we would need to hook in free_huge_page and some other places).
So I decided to not make the code overly complicated and just fail
normally if the page we allocated in the meantime.
Because of the way we handle now in-use pages, we no longer need the
put-as-isolation-migratetype dance, that was guarding for poisoned
pages
to end up in pcplists.
Signed-off-by: Oscar Salvador
Signed-off-by: Naoya Horiguchi
Hi Andrew,
I just found out yesterday that the patchset Naoya sent has diverged
from mine in some aspects that lead to some bugs [1].
This was due to a misunderstanding so no blame here.
So, patch#8 and patch#9 need a little tweak [2].
I was wondering what do you prefer?
1) I paste the chunks that need to be changed in the offending patches
(this and patch#9)
2) I just send them as standalone patches and you applied them on top
I am asking this because although patches had hit -next, we might still
have time to change them.
If not, do not worry, I will send them as standalone.
[1] https://patchwork.kernel.org/comment/23622881/
[2] https://patchwork.kernel.org/comment/23622985/
I will go ahead and paste the chunks here, in case you lean towards
option#1:
Patch#8:
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index f68cb5e3b320..4ffaaa5c2603 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -67,11 +67,6 @@ atomic_long_t num_poisoned_pages __read_mostly =
ATOMIC_LONG_INIT(0);
static bool page_handle_poison(struct page *page, bool
hugepage_or_freepage, bool release)
{
- if (release) {
- put_page(page);
- drain_all_pages(page_zone(page));
- }
-
if (hugepage_or_freepage) {
/*
* Doing this check for free pages is also fine since
dissolve_free_huge_page
@@ -89,6 +84,12 @@ static bool page_handle_poison(struct page *page,
bool hugepage_or_freepage, boo
}
SetPageHWPoison(page);
+
+ if (release) {
+put_page(page);
+drain_all_pages(page_zone(page));
+}
+
page_ref_inc(page);
num_poisoned_pages_inc();
return true;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0d9f9bd0e06c..8a6ab05f074c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1173,6 +1173,16 @@ static __always_inline bool
free_pages_prepare(struct page *page,
trace_mm_page_free(page, order);
+ if (unlikely(PageHWPoison(page)) && !order) {
+
Re: [PATCH v2] software_node: Add support for fwnode_graph*() family of functions
On Fri, Sep 18, 2020 at 08:46:52AM +0100, Dan Scally wrote:
> On 18/09/2020 08:34, Sakari Ailus wrote:
> > On Fri, Sep 18, 2020 at 07:49:31AM +0100, Dan Scally wrote:
> >> Good morning
> >>
> >> On 18/09/2020 07:22, Sakari Ailus wrote:
> >>> Hi Dan,
> >>>
> >>> On Wed, Sep 16, 2020 at 02:22:10PM +0100, Dan Scally wrote:
> Hi Sakari - thanks for the comments
>
> On 16/09/2020 10:17, Sakari Ailus wrote:
> > Moi Daniel and Heikki,
> >
> > On Wed, Sep 16, 2020 at 12:28:27AM +0100, Daniel Scally wrote:
> >> From: Heikki Krogerus
> >>
> >> This implements the remaining .graph_* callbacks in the
> >> fwnode operations vector for the software nodes. That makes
> >> the fwnode_graph*() functions available in the drivers also
> >> when software nodes are used.
> >>
> >> The implementation tries to mimic the "OF graph" as much as
> >> possible, but there is no support for the "reg" device
> >> property. The ports will need to have the index in their
> >> name which starts with "port" (for example "port0", "port1",
> >> ...) and endpoints will use the index of the software node
> >> that is given to them during creation. The port nodes can
> >> also be grouped under a specially named "ports" subnode,
> >> just like in DT, if necessary.
> >>
> >> The remote-endpoints are reference properties under the
> >> endpoint nodes that are named "remote-endpoint".
> >>
> >> Signed-off-by: Heikki Krogerus
> >> Co-developed-by: Daniel Scally
> >> Signed-off-by: Daniel Scally
> >> ---
> >> changes in v2:
> >>- added software_node_device_is_available
> >>- altered software_node_get_next_child to get references
> >>- altered software_node_get_next_endpoint to release references
> >>to ports and avoid passing invalid combinations of swnodes to
> >>software_node_get_next_child
> >>- altered swnode_graph_find_next_port to release port rather
> >> than
> >>old
> >>
> >> drivers/base/swnode.c | 129 +-
> >> 1 file changed, 127 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> >> index 010828fc785b..d69034b807e3 100644
> >> --- a/drivers/base/swnode.c
> >> +++ b/drivers/base/swnode.c
> >> @@ -363,6 +363,11 @@ static void software_node_put(struct
> >> fwnode_handle *fwnode)
> >>kobject_put(&swnode->kobj);
> >> }
> >>
> >> +static bool software_node_device_is_available(const struct
> >> fwnode_handle *fwnode)
> >> +{
> >> + return is_software_node(fwnode);
> > This basically tells whether the device is there. Are there software
> > node
> > based devices, i.e. do you need this?
> >
> > If you do really need this, then I guess this could just return true for
> > now as if you somehow get here, the node is a software node anyway.
> I do think its better to include it; I'm targeting using this with
> ipu3-cio2; the cio2_parse_firmware() call there doesn't pass
> FWNODE_GRAPH_DEVICE_DISABLED to fwnode_graph_get_endpoint_by_id() so
> >>> I wonder if this has something to do with replacing the device's fwnode
> >>> in the cio2-bridge patch.
> >>>
> >>> It's the device that needs to be enabled, and it's not a software node.
> >>>
> >> I think it is because of that yes, but I don't see a way around it at
> >> the moment - unless there's a way to attach the software_node port and
> >> endpoints that cio2-bridge creates to the device's existing firmware
> >> instead.
> > I thought this was how it was meant to be used?
> >
> > The secondary field is there for this purpose. But it may be not all fwnode
> > interface functions operate on fwnode->secondary?
> Let me test it; it might just require some changes to
> software_node_graph_get_port_parent() to check if the parent fwnode is a
> secondary, and if it is to return the primary instead.
Ah, indeed. I forgot this part. I wonder if it'd cause issues to return the
primary if you've got the secondary swnode.
Heikki, any idea?
Code elsewhere (e.g. V4L2 fwnode framework + drivers) assume a device is
identified by a single fwnode, not two --- currently the swnode graph
function returning port parent returns the secondary so there's no match
with the primary fwnode.
--
Sakari Ailus
[tip: x86/cpu] x86/cpu: Add hardware-enforced cache coherency as a CPUID feature
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: f1f325183519ba25370765607e2732d6edf53de1
Gitweb:
https://git.kernel.org/tip/f1f325183519ba25370765607e2732d6edf53de1
Author:Krish Sadhukhan
AuthorDate:Thu, 17 Sep 2020 21:20:36
Committer: Borislav Petkov
CommitterDate: Fri, 18 Sep 2020 09:46:06 +02:00
x86/cpu: Add hardware-enforced cache coherency as a CPUID feature
In some hardware implementations, coherency between the encrypted and
unencrypted mappings of the same physical page is enforced. In such a system,
it is not required for software to flush the page from all CPU caches in the
system prior to changing the value of the C-bit for a page. This hardware-
enforced cache coherency is indicated by EAX[10] in CPUID leaf 0x801f.
Suggested-by: Tom Lendacky
Signed-off-by: Krish Sadhukhan
Signed-off-by: Borislav Petkov
Link: https://lkml.kernel.org/r/20200917212038.5090-2-krish.sadhuk...@oracle.com
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/kernel/cpu/scattered.c| 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index 83fc9d3..ba6e8f4 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -288,6 +288,7 @@
#define X86_FEATURE_FENCE_SWAPGS_USER (11*32+ 4) /* "" LFENCE in user entry
SWAPGS path */
#define X86_FEATURE_FENCE_SWAPGS_KERNEL(11*32+ 5) /* "" LFENCE in
kernel entry SWAPGS path */
#define X86_FEATURE_SPLIT_LOCK_DETECT (11*32+ 6) /* #AC for split lock */
+#define X86_FEATURE_SME_COHERENT (11*32+ 7) /* "" AMD hardware-enforced
cache coherency */
/* Intel-defined CPU features, CPUID level 0x0007:1 (EAX), word 12 */
#define X86_FEATURE_AVX512_BF16(12*32+ 5) /* AVX512 BFLOAT16
instructions */
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 62b137c..3221b71 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -41,6 +41,7 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_MBA, CPUID_EBX, 6, 0x8008, 0 },
{ X86_FEATURE_SME, CPUID_EAX, 0, 0x801f, 0 },
{ X86_FEATURE_SEV, CPUID_EAX, 1, 0x801f, 0 },
+ { X86_FEATURE_SME_COHERENT, CPUID_EAX, 10, 0x801f, 0 },
{ 0, 0, 0, 0, 0 }
};
[tip: x86/cpu] x86/mm/pat: Don't flush cache if hardware enforces cache coherency across encryption domnains
The following commit has been merged into the x86/cpu branch of tip: Commit-ID: 789521fca70ec8cb98f7257b880405e46f8a47a1 Gitweb: https://git.kernel.org/tip/789521fca70ec8cb98f7257b880405e46f8a47a1 Author:Krish Sadhukhan AuthorDate:Thu, 17 Sep 2020 21:20:37 Committer: Borislav Petkov CommitterDate: Fri, 18 Sep 2020 09:48:22 +02:00 x86/mm/pat: Don't flush cache if hardware enforces cache coherency across encryption domnains In some hardware implementations, coherency between the encrypted and unencrypted mappings of the same physical page is enforced. In such a system, it is not required for software to flush the page from all CPU caches in the system prior to changing the value of the C-bit for the page. So check that bit before flushing the cache. [ bp: Massage commit message. ] Suggested-by: Tom Lendacky Signed-off-by: Krish Sadhukhan Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200917212038.5090-3-krish.sadhuk...@oracle.com --- arch/x86/mm/pat/set_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c index d1b2a88..40baa90 100644 --- a/arch/x86/mm/pat/set_memory.c +++ b/arch/x86/mm/pat/set_memory.c @@ -1999,7 +1999,7 @@ static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc) /* * Before changing the encryption attribute, we need to flush caches. */ - cpa_flush(&cpa, 1); + cpa_flush(&cpa, !this_cpu_has(X86_FEATURE_SME_COHERENT)); ret = __change_page_attr_set_clr(&cpa, 1);
[PATCH v2 0/2] perf probe: Support debuginfod client
Hi,
Here is the 2nd version of a series to enable debuginfod support on
perf probe command. This allows users to access debuginfo binary
from remote device.
In this version I fixed a build error when libdebuginfod is not
installed ([2/2]).
Since the perf-probe heavily depends on the debuginfo, debuginfod
gives us many benefits on the perf probe command on remote
machine, especially for the embedded devices.
Here is an example (copied from [2/2])
1. at first you need to start debuginfod on the host machine.
-F option scans local debuginfo binary. (You don't need to pass
the source tree, but you must keep the source tree untouched)
(host) $ cd PATH/TO/KBUILD/DIR/
(host) $ debuginfod -F .
...
2. In the remote machine, you need to set DEBUGINFOD_URLS.
debuginfod uses 8002 tcp port.
(remote) # export DEBUGINFOD_URLS="http://$HOST_IP:8002/";
3. Then you can use the perf probe (it can refer the source code)
(remote) # perf probe -L vfs_read
0 ssize_t vfs_read(struct file *file, char __user *buf, size_t count,
loff_t *pos)
{
2 ssize_t ret;
if (!(file->f_mode & FMODE_READ))
return -EBADF;
6 if (!(file->f_mode & FMODE_CAN_READ))
return -EINVAL;
8 if (unlikely(!access_ok(buf, count)))
return -EFAULT;
11 ret = rw_verify_area(READ, file, pos, count);
12 if (ret)
return ret;
if (count > MAX_RW_COUNT)
...
(remote) # perf probe -a "vfs_read count"
Added new event:
probe:vfs_read (on vfs_read with count)
(remote) # perf probe -l
probe:vfs_read (on vfs_read@ksrc/linux/fs/read_write.c with count)
Thank you,
---
Masami Hiramatsu (2):
perf probe: Fix to adjust symbol address with correct reloc_sym address
perf probe: Fall back to debuginfod query if debuginfo and source not
found
tools/perf/util/probe-event.c | 66 ++--
tools/perf/util/probe-finder.c | 61 ++---
tools/perf/util/probe-finder.h |7 +++-
3 files changed, 123 insertions(+), 11 deletions(-)
--
Masami Hiramatsu (Linaro)
[PATCH v2 1/2] perf probe: Fix to adjust symbol address with correct reloc_sym address
Perf probe uses ref_reloc_sym to adjust symbol offset address
from debuginfo address or ref_reloc_sym based address, but
that is misused the reloc_sym->addr and reloc_sym->unrelocated_addr.
If map is not relocated (map->reloc == 0), we can use reloc_sym->addr
as unrelocated address instead of reloc_sym->unrelocated_addr.
This usually may not happen. If we have a non-stripped elf
binary, we will use it for map and debuginfo, if not, we use only
kallsyms without debuginfo. Thus, the map is always relocated (elf
and dwarf binary) or not relocated (kallsyms).
However, if we will allow the combination of debuginfo and kallsyms
based map (like using debuginfod), we have to check the map->reloc
and choose the collect address of reloc_sym.
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/probe-event.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 99d36ac77c08..17831f186ab5 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -129,9 +129,10 @@ static int kernel_get_symbol_address_by_name(const char
*name, u64 *addr,
struct map *map;
/* ref_reloc_sym is just a label. Need a special fix*/
- reloc_sym = kernel_get_ref_reloc_sym(NULL);
+ reloc_sym = kernel_get_ref_reloc_sym(&map);
if (reloc_sym && strcmp(name, reloc_sym->name) == 0)
- *addr = (reloc) ? reloc_sym->addr : reloc_sym->unrelocated_addr;
+ *addr = (!map->reloc || reloc) ? reloc_sym->addr :
+ reloc_sym->unrelocated_addr;
else {
sym = machine__find_kernel_symbol_by_name(host_machine, name,
&map);
if (!sym)
@@ -795,7 +796,8 @@ post_process_kernel_probe_trace_events(struct
probe_trace_event *tevs,
free(tevs[i].point.symbol);
tevs[i].point.symbol = tmp;
tevs[i].point.offset = tevs[i].point.address -
- reloc_sym->unrelocated_addr;
+ (map->reloc ? reloc_sym->unrelocated_addr :
+ reloc_sym->addr);
}
return skipped;
}
[PATCH v2 2/2] perf probe: Fall back to debuginfod query if debuginfo and source not found
Since the perf-probe heavily depends on the debuginfo, debuginfod
gives us many benefits on the perf probe command on remote machine.
Especially, this will be helpful for the embedded devices which will
not have enough storage, or boot with a cross-build kernel whose
source code is in the host machine.
This will work as similar to the commit c7a14fdcb3fa ("perf build-ids:
Fall back to debuginfod query if debuginfo not found")
Tested with:
(host) $ cd PATH/TO/KBUILD/DIR/
(host) $ debuginfod -F .
...
(remote) # perf probe -L vfs_read
Failed to find the path for the kernel: No such file or directory
Error: Failed to show lines.
(remote) # export DEBUGINFOD_URLS="http://$HOST_IP:8002/";
(remote) # perf probe -L vfs_read
0 ssize_t vfs_read(struct file *file, char __user *buf, size_t count,
loff_t *pos)
{
2 ssize_t ret;
if (!(file->f_mode & FMODE_READ))
return -EBADF;
6 if (!(file->f_mode & FMODE_CAN_READ))
return -EINVAL;
8 if (unlikely(!access_ok(buf, count)))
return -EFAULT;
11 ret = rw_verify_area(READ, file, pos, count);
12 if (ret)
return ret;
if (count > MAX_RW_COUNT)
...
(remote) # perf probe -a "vfs_read count"
Added new event:
probe:vfs_read (on vfs_read with count)
(remote) # perf probe -l
probe:vfs_read (on vfs_read@ksrc/linux/fs/read_write.c with count)
Signed-off-by: Masami Hiramatsu
---
Changes in v2:
- Fix build error when libdebuginfod is not detected.
---
tools/perf/util/probe-event.c | 58 +-
tools/perf/util/probe-finder.c | 61 +---
tools/perf/util/probe-finder.h |7 +++--
3 files changed, 118 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 17831f186ab5..3a1b58a92673 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -43,6 +43,10 @@
#include
#include
+#ifdef HAVE_DEBUGINFOD_SUPPORT
+#include
+#endif
+
#define PERFPROBE_GROUP "probe"
bool probe_event_dry_run; /* Dry run flag */
@@ -338,6 +342,8 @@ static int kernel_get_module_dso(const char *module, struct
dso **pdso)
map = machine__kernel_map(host_machine);
dso = map->dso;
+ if (!dso->has_build_id)
+ dso__read_running_kernel_build_id(dso, host_machine);
vmlinux_name = symbol_conf.vmlinux_name;
dso->load_errno = 0;
@@ -453,6 +459,49 @@ static int get_alternative_line_range(struct debuginfo
*dinfo,
return ret;
}
+#ifdef HAVE_DEBUGINFOD_SUPPORT
+static struct debuginfo *open_from_debuginfod(struct dso *dso, struct nsinfo
*nsi,
+ bool silent)
+{
+ debuginfod_client *c = debuginfod_begin();
+ char sbuild_id[SBUILD_ID_SIZE + 1];
+ struct debuginfo *ret = NULL;
+ struct nscookie nsc;
+ char *path;
+ int fd;
+
+ if (!c)
+ return NULL;
+
+ build_id__sprintf(dso->build_id, BUILD_ID_SIZE, sbuild_id);
+ fd = debuginfod_find_debuginfo(c, (const unsigned char *)sbuild_id,
+ 0, &path);
+ if (fd >= 0)
+ close(fd);
+ debuginfod_end(c);
+ if (fd < 0) {
+ if (!silent)
+ pr_debug("Failed to find debuginfo in debuginfod.\n");
+ return NULL;
+ }
+ if (!silent)
+ pr_debug("Load debuginfo from debuginfod (%s)\n", path);
+
+ nsinfo__mountns_enter(nsi, &nsc);
+ ret = debuginfo__new((const char *)path);
+ nsinfo__mountns_exit(&nsc);
+ return ret;
+}
+#else
+static inline
+struct debuginfo *open_from_debuginfod(struct dso *dso __maybe_unused,
+ struct nsinfo *nsi __maybe_unused,
+ bool silent __maybe_unused)
+{
+ return NULL;
+}
+#endif
+
/* Open new debuginfo of given module */
static struct debuginfo *open_debuginfo(const char *module, struct nsinfo *nsi,
bool silent)
@@ -472,6 +521,10 @@ static struct debuginfo *open_debuginfo(const char
*module, struct nsinfo *nsi,
strcpy(reason, "(unknown)");
} else
dso__strerror_load(dso, reason, STRERR_BUFSIZE);
+ if (dso)
+ ret = open_from_debuginfod(dso, nsi, silent);
+ if (ret)
+ return ret;
if (!silent) {
if (module)
pr_err("Module %s is not loaded, please
specify its full path name.
Re: [PATCH v2 05/37] kasan: rename KASAN_SHADOW_* to KASAN_GRANULE_*
On Tue, Sep 15, 2020 at 11:16 PM Andrey Konovalov wrote:
>
> This is a preparatory commit for the upcoming addition of a new hardware
> tag-based (MTE-based) KASAN mode.
>
> The new mode won't be using shadow memory, but will still use the concept
> of memory granules.
KASAN documentation doesn't seem to explain this concept anywhere (I
also checked the "kasan: add documentation for hardware tag-based
mode" patch), looks like it's only mentioned in MTE documentation.
Could you please elaborate on what we consider a granule in each of KASAN modes?
> Rename KASAN_SHADOW_SCALE_SIZE to KASAN_GRANULE_SIZE,
> and KASAN_SHADOW_MASK to KASAN_GRANULE_MASK.
>
> Also use MASK when used as a mask, otherwise use SIZE.
>
> No functional changes.
>
> Signed-off-by: Andrey Konovalov
> Signed-off-by: Vincenzo Frascino
> ---
> Change-Id: Iac733e2248aa9d29f6fc425d8946ba07cca73ecf
> ---
> Documentation/dev-tools/kasan.rst | 2 +-
> lib/test_kasan.c | 2 +-
> mm/kasan/common.c | 39 ---
> mm/kasan/generic.c| 14 +--
> mm/kasan/generic_report.c | 8 +++
> mm/kasan/init.c | 8 +++
> mm/kasan/kasan.h | 4 ++--
> mm/kasan/report.c | 10
> mm/kasan/tags_report.c| 2 +-
> 9 files changed, 45 insertions(+), 44 deletions(-)
>
> diff --git a/Documentation/dev-tools/kasan.rst
> b/Documentation/dev-tools/kasan.rst
> index 38fd5681fade..a3030fc6afe5 100644
> --- a/Documentation/dev-tools/kasan.rst
> +++ b/Documentation/dev-tools/kasan.rst
> @@ -264,7 +264,7 @@ Most mappings in vmalloc space are small, requiring less
> than a full
> page of shadow space. Allocating a full shadow page per mapping would
> therefore be wasteful. Furthermore, to ensure that different mappings
> use different shadow pages, mappings would have to be aligned to
> -``KASAN_SHADOW_SCALE_SIZE * PAGE_SIZE``.
> +``KASAN_GRANULE_SIZE * PAGE_SIZE``.
>
> Instead, we share backing space across multiple mappings. We allocate
> a backing page when a mapping in vmalloc space uses a particular page
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index 53e953bb1d1d..ddd0b80f24a1 100644
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -25,7 +25,7 @@
>
> #include "../mm/kasan/kasan.h"
>
> -#define OOB_TAG_OFF (IS_ENABLED(CONFIG_KASAN_GENERIC) ? 0 :
> KASAN_SHADOW_SCALE_SIZE)
> +#define OOB_TAG_OFF (IS_ENABLED(CONFIG_KASAN_GENERIC) ? 0 :
> KASAN_GRANULE_SIZE)
>
> /*
> * We assign some test results to these globals to make sure the tests
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 65933b27df81..c9daf2c33651 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -111,7 +111,7 @@ void *memcpy(void *dest, const void *src, size_t len)
>
> /*
> * Poisons the shadow memory for 'size' bytes starting from 'addr'.
> - * Memory addresses should be aligned to KASAN_SHADOW_SCALE_SIZE.
> + * Memory addresses should be aligned to KASAN_GRANULE_SIZE.
> */
> void kasan_poison_memory(const void *address, size_t size, u8 value)
> {
> @@ -143,13 +143,13 @@ void kasan_unpoison_memory(const void *address, size_t
> size)
>
> kasan_poison_memory(address, size, tag);
>
> - if (size & KASAN_SHADOW_MASK) {
> + if (size & KASAN_GRANULE_MASK) {
> u8 *shadow = (u8 *)kasan_mem_to_shadow(address + size);
>
> if (IS_ENABLED(CONFIG_KASAN_SW_TAGS))
> *shadow = tag;
> else
> - *shadow = size & KASAN_SHADOW_MASK;
> + *shadow = size & KASAN_GRANULE_MASK;
> }
> }
>
> @@ -301,7 +301,7 @@ void kasan_unpoison_object_data(struct kmem_cache *cache,
> void *object)
> void kasan_poison_object_data(struct kmem_cache *cache, void *object)
> {
> kasan_poison_memory(object,
> - round_up(cache->object_size, KASAN_SHADOW_SCALE_SIZE),
> + round_up(cache->object_size, KASAN_GRANULE_SIZE),
> KASAN_KMALLOC_REDZONE);
> }
>
> @@ -373,7 +373,7 @@ static inline bool shadow_invalid(u8 tag, s8 shadow_byte)
> {
> if (IS_ENABLED(CONFIG_KASAN_GENERIC))
> return shadow_byte < 0 ||
> - shadow_byte >= KASAN_SHADOW_SCALE_SIZE;
> + shadow_byte >= KASAN_GRANULE_SIZE;
>
> /* else CONFIG_KASAN_SW_TAGS: */
> if ((u8)shadow_byte == KASAN_TAG_INVALID)
> @@ -412,7 +412,7 @@ static bool __kasan_slab_free(struct kmem_cache *cache,
> void *object,
> return true;
> }
>
> - rounded_up_size = round_up(cache->object_size,
> KASAN_SHADOW_SCALE_SIZE);
> + rounded_up_size = round_up(cache->object_size, KASAN_GRANULE_SIZE);
> kasan_poison_memory(object, rounded_up_size, KASAN_KMALLOC_FREE);
>
> if ((IS_ENABLED(CONFIG_KASAN_GENERIC) && !quarantine) ||
> @@ -445,9 +445,9 @
Re: [PATCH v4 3/3] iio: adc: mt6360: Add ADC driver for MT6360
Jonathan Cameron 於 2020年9月18日 週五 上午1:53寫道：
>
> On Wed, 16 Sep 2020 01:36:09 +0800
> Gene Chen wrote:
>
> > From: Gene Chen
> >
> > Add MT6360 ADC driver include Charger Current, Voltage, and
> > Temperature.
> >
> > Signed-off-by: Gene Chen
> Comments inline.
>
> > ---
> > drivers/iio/adc/Kconfig | 11 ++
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/mt6360-adc.c | 357
> > +++
> > 3 files changed, 369 insertions(+)
> > create mode 100644 drivers/iio/adc/mt6360-adc.c
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 66d9cc0..8d36b66 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -703,6 +703,17 @@ config MCP3911
> > This driver can also be built as a module. If so, the module will be
> > called mcp3911.
> >
> > +config MEDIATEK_MT6360_ADC
> > + tristate "Mediatek MT6360 ADC driver"
> > + depends on MFD_MT6360
> > + select IIO_BUFFER
> > + select IIO_TRIGGERED_BUFFER
> > + help
> > + Say Y here to enable MT6360 ADC support.
> > + Integrated for System Monitoring includes
> > + is used in smartphones and tablets and supports a 11 channel
> > + general purpose ADC.
> > +
> > config MEDIATEK_MT6577_AUXADC
> > tristate "MediaTek AUXADC driver"
> > depends on ARCH_MEDIATEK || COMPILE_TEST
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 90f94ad..5fca90a 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -65,6 +65,7 @@ obj-$(CONFIG_MAX9611) += max9611.o
> > obj-$(CONFIG_MCP320X) += mcp320x.o
> > obj-$(CONFIG_MCP3422) += mcp3422.o
> > obj-$(CONFIG_MCP3911) += mcp3911.o
> > +obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o
> > obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> > obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> > obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> > diff --git a/drivers/iio/adc/mt6360-adc.c b/drivers/iio/adc/mt6360-adc.c
> > new file mode 100644
> > index 000..b256d0a
> > --- /dev/null
> > +++ b/drivers/iio/adc/mt6360-adc.c
> > @@ -0,0 +1,357 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define MT6360_REG_PMUCHGCTRL3 0x313
> > +#define MT6360_REG_PMUADCCFG 0x356
> > +#define MT6360_REG_PMUADCIDLET 0x358
> > +#define MT6360_REG_PMUADCRPT10x35A
> > +
> > +/* PMUCHGCTRL3 0x313 */
> > +#define MT6360_AICR_MASK GENMASK(7, 2)
> > +#define MT6360_AICR_SHFT 2
> > +#define MT6360_AICR_400MA0x6
> > +/* PMUADCCFG 0x356 */
> > +#define MT6360_ADCEN_MASK0x8000
> > +/* PMUADCRPT1 0x35A */
> > +#define MT6360_PREFERCH_MASK GENMASK(7, 4)
> > +#define MT6360_PREFERCH_SHFT 4
> > +#define MT6360_RPTCH_MASKGENMASK(3, 0)
> > +#define MT6360_NO_PREFER 15
> > +
> > +/* Time in ms */
> > +#define ADC_WAIT_TIME_MS 25
> > +
> > +enum {
> > + MT6360_CHAN_USBID = 0,
> > + MT6360_CHAN_VBUSDIV5,
> > + MT6360_CHAN_VBUSDIV2,
> > + MT6360_CHAN_VSYS,
> > + MT6360_CHAN_VBAT,
> > + MT6360_CHAN_IBUS,
> > + MT6360_CHAN_IBAT,
> > + MT6360_CHAN_CHG_VDDP,
> > + MT6360_CHAN_TEMP_JC,
> > + MT6360_CHAN_VREF_TS,
> > + MT6360_CHAN_TS,
> > + MT6360_CHAN_MAX
> > +};
> > +
> > +struct mt6360_adc_data {
> > + struct device *dev;
> > + struct regmap *regmap;
> > + struct mutex adc_lock;
>
> Please add a comment to document what the scope of the lock is.
>
ACK
> > + ktime_t last_off_timestamps[MT6360_CHAN_MAX];
> > +};
> > +
> > +static int mt6360_adc_read_channel(struct mt6360_adc_data *mad, int
> > channel, int *val)
> > +{
> > + __be16 adc_enable;
> > + u8 rpt[3];
> > + ktime_t start_t, predict_end_t;
> > + unsigned int pre_wait_time;
> > + int ret;
> > +
> > + mutex_lock(&mad->adc_lock);
> > +
> > + /* Select the preferred ADC channel */
> > + ret = regmap_update_bits(mad->regmap, MT6360_REG_PMUADCRPT1,
> > MT6360_PREFERCH_MASK,
> > + channel << MT6360_PREFERCH_SHFT);
> > + if (ret)
> > + goto out_adc_lock;
> > +
> > + adc_enable = cpu_to_be16(MT6360_ADCEN_MASK | BIT(channel));
> > + ret = regmap_raw_write(mad->regmap, MT6360_REG_PMUADCCFG, (void
> > *)&adc_enable,
>
> Shouldn't be any need to cast a pointer explicitly to void *
>
ACK
> > +sizeof(__be16));
>
> sizeof(adc_enable) preferred.
>
ACK
> > + if (ret)
> > + goto out_adc_lock;
> > +
> > + start_t = ktime_get();
> > + predict_end_t = ktime_add_ms(mad->last_off_timestamps[channel], 2 *
> > ADC_WAIT_TIME_MS);
> > +
> > + if (ktime_after(start_t, predict_end_t))
> > + pre_wait_time = ADC_WAIT_TIME_MS;
> > + else
> > +
Re: linux-next: build warning after merge of the v4l-dvb-fixes tree
Hi Sergey, On Fri, 18 Sep 2020 16:52:30 +0900 Sergey Senozhatsky wrote: > > On (20/09/18 17:21), Stephen Rothwell wrote: > > After merging the v4l-dvb-fixes tree, today's linux-next build (htmldocs) > > produced this warning: > > > > Documentation/userspace-api/media/v4l/buffer.rst:692: WARNING: The > > "flat-table" directive is empty; content required. > > > > .. flat-table:: > > :header-rows: 0 > > :stub-columns: 0 > > :widths: 3 1 4 > > Thanks. I think there is a patch for this already. > Will hit linux-next soon. Excellent, thanks. -- Cheers, Stephen Rothwell pgpJesNpfPEGk.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the staging tree with the crypto tree
On Fri, Sep 18, 2020 at 05:50:36PM +1000, Herbert Xu wrote: > On Fri, Sep 18, 2020 at 09:49:11AM +0200, Greg KH wrote: > > > > Ok, I'll go revert these. > > Thanks! > > > > As the driver has been converted over to the lib arc4 API, it > > > does not need to select CRYPTO at all. > > > > Is it converted in your tree? If so, have a branch/tag I can pull in to > > prevent merge issues in the future? > > It's in the cryptodev tree, but unfortunately it's not in a > topic branch so you'd be pulling all other crypto changes along > with it. Ok, no worries, I'll just revert the above commits and all should be good. thanks, greg k-h
[PATCH -next] ARM: zx: Use devm_platform_ioremap_resource()
Make use of devm_platform_ioremap_resource() provided by driver
core platform instead of duplicated analogue. dev_err() is
removed because it has been done in devm_ioremap_resource().
Signed-off-by: Wang ShaoBo
---
arch/arm/mach-zx/zx296702-pm-domain.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-zx/zx296702-pm-domain.c
b/arch/arm/mach-zx/zx296702-pm-domain.c
index 7a08bf9dd792..8ddc94530d5d 100644
--- a/arch/arm/mach-zx/zx296702-pm-domain.c
+++ b/arch/arm/mach-zx/zx296702-pm-domain.c
@@ -152,7 +152,6 @@ static struct generic_pm_domain *zx296702_pm_domains[] = {
static int zx296702_pd_probe(struct platform_device *pdev)
{
struct genpd_onecell_data *genpd_data;
- struct resource *res;
int i;
genpd_data = devm_kzalloc(&pdev->dev, sizeof(*genpd_data), GFP_KERNEL);
@@ -162,17 +161,9 @@ static int zx296702_pd_probe(struct platform_device *pdev)
genpd_data->domains = zx296702_pm_domains;
genpd_data->num_domains = ARRAY_SIZE(zx296702_pm_domains);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "no memory resource defined\n");
- return -ENODEV;
- }
-
- pcubase = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(pcubase)) {
- dev_err(&pdev->dev, "ioremap fail.\n");
+ pcubase = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(pcubase))
return -EIO;
- }
for (i = 0; i < ARRAY_SIZE(zx296702_pm_domains); ++i)
pm_genpd_init(zx296702_pm_domains[i], NULL, false);
--
2.17.1
Re: [RFC PATCH] Add bridge driver to connect sensors to CIO2 device via software nodes on ACPI platforms
I ran Smatch over the code and it spotted an off by one.
On Wed, Sep 16, 2020 at 10:36:18PM +0100, Daniel Scally wrote:
> +#define MAX_CONNECTED_DEVICES4
> +#define SWNODE_SENSOR_HID0
> +#define SWNODE_SENSOR_PORT 1
> +#define SWNODE_SENSOR_ENDPOINT 2
> +#define SWNODE_CIO2_PORT 3
> +#define SWNODE_CIO2_ENDPOINT 4
> +#define SWNODE_NULL_TERMINATOR 5
^^
> +struct sensor {
> + struct device *dev;
> + struct software_node swnodes[5];
^^
This needs to be 6 instead of 5 to prevent memory corruption.
> + struct property_entry sensor_props[6];
> + struct property_entry cio2_props[3];
> + struct fwnode_handle *fwnode;
> +};
> + nodes[SWNODE_NULL_TERMINATOR] = SOFTWARE_NODE_NULL;
Here.
regards,
dan carpenter
Re: [PATCH 4/7] crypto: sun4i-ss: handle BigEndian for cipher
On Fri, Sep 18, 2020 at 05:31:28PM +1000, Herbert Xu wrote:
> On Thu, Sep 17, 2020 at 06:35:55PM +, Corentin Labbe wrote:
> > Ciphers produce invalid results on BE.
> > Key and IV need to be written in LE.
> > Furthermore, the non-optimized function is too complicated to convert,
> > let's simply fallback on BE for the moment.
> >
> > Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System
> > crypto accelerator")
> > Cc:
> > Signed-off-by: Corentin Labbe
> > ---
> > .../crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 17 +++--
> > 1 file changed, 11 insertions(+), 6 deletions(-)
>
> Does the BE failure get caught by the selftest?
>
Yes, selftest found it.
> If so please just leave it enabled so that it can be fixed properly.
Not sure to leave it enabled is a good idea.
A least, leaving it failing probably will not annoy any user (according to my
readings of #linux-sunxi, nobody use BE).
But I think only me will see it and since I already have this on my TODO list,
I dont see any interest to leave it failing.
Furthermore, having a clean BE boot will permit to enable BE boots for thoses
SoCs on kernelCI.
Regards
[PATCH] docs: admin-guide: update kdump documentation due to change of crash URL
Since crash utility has moved to github, the original URL is no longer available. Let's update it accordingly. Suggested-by: Dave Young Signed-off-by: Lianbo Jiang --- Documentation/admin-guide/kdump/kdump.rst | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index 2da65fef2a1c..75a9dd98e76e 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -509,9 +509,12 @@ ELF32-format headers using the --elf32-core-headers kernel option on the dump kernel. You can also use the Crash utility to analyze dump files in Kdump -format. Crash is available on Dave Anderson's site at the following URL: +format. Crash is available at the following URL: - http://people.redhat.com/~anderson/ + https://github.com/crash-utility/crash + +Crash document can be found at: + https://crash-utility.github.io/ Trigger Kdump on WARN() === -- 2.17.1
Re: [PATCH] ARM: dts: picoxcell: drop unused reg-io-width from DW APB GPIO controller
On Thu, Sep 17, 2020 at 06:49:09PM +0200, Krzysztof Kozlowski wrote: > The Synopsys DesignWare APB GPIO controller driver does not parse > reg-io-width and dtschema does not allow it so drop it to fix dtschema > warnings like: > > arch/arm/boot/dts/picoxcell-pc7302-pc3x2.dt.yaml: gpio@2: > 'reg-io-width' does not match any of the regexes: > '^gpio-(port|controller)@[0-9a-f]+$', 'pinctrl-[0-9]+' > > Signed-off-by: Krzysztof Kozlowski Acked-by: Jamie Iles Thanks!
Re: [PATCH] drm: fsl-dcu: enable PIXCLK on LS1021A
On Fri, 2020-08-21 at 15:41 +0200, Stefan Agner wrote:
> Hi Matthias,
>
> On 2020-08-20 12:58, Matthias Schiffer wrote:
> > The PIXCLK needs to be enabled in SCFG before accessing the DCU on LS1021A,
> > or the access will hang.
>
> Hm, this seems a rather ad-hoc access to SCFG from the DCU. We do
> support a pixel clock in the device tree bindings of fsl-dcu, so ideally
> we should enable the pixel clock through the clock framework.
>
> On the other hand, I guess that would mean adding a clock driver to flip
> a single bit, which seems a bit excessive too.
>
> I'd like a second opinion on that. Adding clk framework maintainers.
>
> --
> Stefan
How do we proceed with this patch?
Kind regards,
Matthias
>
> >
> > Signed-off-by: Matthias Schiffer
> > ---
> > drivers/gpu/drm/fsl-dcu/Kconfig | 1 +
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 25 +++
> > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 3 +++
> > 3 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig
> > b/drivers/gpu/drm/fsl-dcu/Kconfig
> > index d7dd8ba90e3a..9e5a35e7c00c 100644
> > --- a/drivers/gpu/drm/fsl-dcu/Kconfig
> > +++ b/drivers/gpu/drm/fsl-dcu/Kconfig
> > @@ -8,6 +8,7 @@ config DRM_FSL_DCU
> > select DRM_PANEL
> > select REGMAP_MMIO
> > select VIDEOMODE_HELPERS
> > + select MFD_SYSCON if SOC_LS1021A
> > help
> > Choose this option if you have an Freescale DCU chipset.
> > If M is selected the module will be called fsl-dcu-drm.
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > index abbc1ddbf27f..8a7556655581 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> > @@ -51,6 +51,23 @@ static const struct regmap_config fsl_dcu_regmap_config
> > = {
> > .volatile_reg = fsl_dcu_drm_is_volatile_reg,
> > };
> >
> > +static int fsl_dcu_scfg_config_ls1021a(struct device_node *np)
> > +{
> > + struct regmap *scfg;
> > +
> > + scfg = syscon_regmap_lookup_by_compatible("fsl,ls1021a-scfg");
> > + if (IS_ERR(scfg))
> > + return PTR_ERR(scfg);
> > +
> > + /*
> > +* For simplicity, enable the PIXCLK unconditionally. It might
> > +* be possible to disable the clock in PM or on unload as a future
> > +* improvement.
> > +*/
> > + return regmap_update_bits(scfg, SCFG_PIXCLKCR, SCFG_PIXCLKCR_PXCEN,
> > + SCFG_PIXCLKCR_PXCEN);
> > +}
> > +
> > static void fsl_dcu_irq_uninstall(struct drm_device *dev)
> > {
> > struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
> > @@ -70,6 +87,14 @@ static int fsl_dcu_load(struct drm_device *dev,
> > unsigned long flags)
> > return ret;
> > }
> >
> > + if (of_device_is_compatible(fsl_dev->np, "fsl,ls1021a-dcu")) {
> > + ret = fsl_dcu_scfg_config_ls1021a(fsl_dev->np);
> > + if (ret < 0) {
> > + dev_err(dev->dev, "failed to enable pixclk\n");
> > + goto done;
> > + }
> > + }
> > +
> > ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
> > if (ret < 0) {
> > dev_err(dev->dev, "failed to initialize vblank\n");
> > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > index e2049a0e8a92..566396013c04 100644
> > --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> > @@ -160,6 +160,9 @@
> > #define FSL_DCU_ARGB 12
> > #define FSL_DCU_YUV422 14
> >
> > +#define SCFG_PIXCLKCR 0x28
> > +#define SCFG_PIXCLKCR_PXCENBIT(31)
> > +
> > #define VF610_LAYER_REG_NUM9
> > #define LS1021A_LAYER_REG_NUM 10
Re: [PATCH v4 1/3] iio: core: Add optional symbolic label to a device channel
On Wed, 16 Sep 2020 16:21:15 +0300
Cristian Pop wrote:
> If a label is defined in the device tree for this channel add that
> to the channel specific attributes. This is useful for userspace to
> be able to identify an individual channel.
>
> Signed-off-by: Cristian Pop
Hi Cristian.
I (and lore.kernel.org) only received patch 1 so guess docs and example were
in patches 2 and 3? Something odd is perhaps going on with Analog's email
vs vger as there was only a partial set of Nuno's series last night as well
so I couldn't pick it up with b4.
This patch looks good to me. Thanks for your hard work on this.
Given timing it may slip into the next cycle.
Jonathan
> ---
> Change in V4:
> - Check for callback before generating file system for label
> - Add documentation in: Documentation/ABI/testing/sysfs-bus-iio
> - Add example of usage for channel label attribute
> drivers/iio/industrialio-core.c | 41 +
> include/linux/iio/iio.h | 6 +
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 1527f01a44f1..49868e080840 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -643,6 +643,21 @@ ssize_t iio_format_value(char *buf, unsigned int type,
> int size, int *vals)
> }
> EXPORT_SYMBOL_GPL(iio_format_value);
>
> +static ssize_t iio_read_channel_label(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> + struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> +
> + if (indio_dev->info->read_label)
> + return indio_dev->info->read_label(indio_dev,
> + this_attr->c,
> + buf);
> + else
> + return -EINVAL;
> +}
> +
> static ssize_t iio_read_channel_info(struct device *dev,
>struct device_attribute *attr,
>char *buf)
> @@ -,6 +1126,25 @@ int __iio_add_chan_devattr(const char *postfix,
> return ret;
> }
>
> +static int iio_device_add_channel_label(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan)
> +{
> + int ret;
> +
> + ret = __iio_add_chan_devattr("label",
> + chan,
> + &iio_read_channel_label,
> + NULL,
> + 0,
> + IIO_SEPARATE,
> + &indio_dev->dev,
> + &indio_dev->channel_attr_list);
> + if (ret < 0)
> + return ret;
> +
> + return 1;
> +}
> +
> static int iio_device_add_info_mask_type(struct iio_dev *indio_dev,
>struct iio_chan_spec const *chan,
>enum iio_shared_by shared_by,
> @@ -1241,6 +1275,13 @@ static int iio_device_add_channel_sysfs(struct iio_dev
> *indio_dev,
> return ret;
> attrcount += ret;
>
> + if (indio_dev->info->read_label) {
> + ret = iio_device_add_channel_label(indio_dev, chan);
> + if (ret < 0)
> + return ret;
> + attrcount += ret;
> + }
> +
> if (chan->ext_info) {
> unsigned int i = 0;
> for (ext_info = chan->ext_info; ext_info->name; ext_info++) {
> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
> index a1be82e74c93..58b151f5321d 100644
> --- a/include/linux/iio/iio.h
> +++ b/include/linux/iio/iio.h
> @@ -362,6 +362,8 @@ struct iio_trigger; /* forward declaration */
> * and max. For lists, all possible values are enumerated.
> * @write_raw: function to write a value to the device.
> * Parameters are the same as for read_raw.
> + * @read_label: function to request label name for a specified
> label,
> + * for better channel identification.
> * @write_raw_get_fmt: callback function to query the expected
> * format/precision. If not set by the driver, write_raw
> * returns IIO_VAL_INT_PLUS_MICRO.
> @@ -420,6 +422,10 @@ struct iio_info {
>int val2,
>long mask);
>
> + int (*read_label)(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + char *label);
> +
> int (*write_raw_get_fmt)(struct iio_dev *indio_dev,
>struct iio_chan_spec const *chan,
>long mask);
