* [dpdk-dev] [PATCH] crypto/nitrox: fix coverity defects
From: Nagadheeraj Rottela @ 2020-02-20 11:04 UTC (permalink / raw)
To: akhil.goyal; +Cc: dev, jsrikanth, Nagadheeraj Rottela
Address the defects reported by coverity: Unintended sign extension
and Out-of-bounds access.
Coverity issue: 349899, 349905, 349911, 349921, 349923, 349926
Fixes: 32e4930d5a3b ("crypto/nitrox: add hardware queue management")
Fixes: 9fdef0cc2385 ("crypto/nitrox: create symmetric cryptodev")
Signed-off-by: Nagadheeraj Rottela <rnagadheeraj@marvell.com>
---
drivers/crypto/nitrox/nitrox_csr.h | 18 +++++++++---------
drivers/crypto/nitrox/nitrox_sym.c | 3 ++-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/nitrox/nitrox_csr.h b/drivers/crypto/nitrox/nitrox_csr.h
index 8cd92e38b..b4c969b26 100644
--- a/drivers/crypto/nitrox/nitrox_csr.h
+++ b/drivers/crypto/nitrox/nitrox_csr.h
@@ -12,15 +12,15 @@
#define NITROX_CSR_ADDR(bar_addr, offset) (bar_addr + (offset))
/* NPS packet registers */
-#define NPS_PKT_IN_INSTR_CTLX(_i) (0x10060 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INSTR_BADDRX(_i) (0x10068 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INSTR_RSIZEX(_i) (0x10070 + ((_i) * 0x40000))
-#define NPS_PKT_IN_DONE_CNTSX(_i) (0x10080 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INSTR_BAOFF_DBELLX(_i) (0x10078 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INT_LEVELSX(_i) (0x10088 + ((_i) * 0x40000))
-#define NPS_PKT_SLC_CTLX(_i) (0x10000 + ((_i) * 0x40000))
-#define NPS_PKT_SLC_CNTSX(_i) (0x10008 + ((_i) * 0x40000))
-#define NPS_PKT_SLC_INT_LEVELSX(_i) (0x10010 + ((_i) * 0x40000))
+#define NPS_PKT_IN_INSTR_CTLX(_i) (0x10060UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INSTR_BADDRX(_i) (0x10068UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INSTR_RSIZEX(_i) (0x10070UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_DONE_CNTSX(_i) (0x10080UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INSTR_BAOFF_DBELLX(_i) (0x10078UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INT_LEVELSX(_i) (0x10088UL + ((_i) * 0x40000UL))
+#define NPS_PKT_SLC_CTLX(_i) (0x10000UL + ((_i) * 0x40000UL))
+#define NPS_PKT_SLC_CNTSX(_i) (0x10008UL + ((_i) * 0x40000UL))
+#define NPS_PKT_SLC_INT_LEVELSX(_i) (0x10010UL + ((_i) * 0x40000UL))
/* AQM Virtual Function Registers */
#define AQMQ_QSZX(_i) (0x20008 + ((_i)*0x40000))
diff --git a/drivers/crypto/nitrox/nitrox_sym.c b/drivers/crypto/nitrox/nitrox_sym.c
index 56410c44d..d1b32fec9 100644
--- a/drivers/crypto/nitrox/nitrox_sym.c
+++ b/drivers/crypto/nitrox/nitrox_sym.c
@@ -683,7 +683,8 @@ nitrox_sym_pmd_create(struct nitrox_device *ndev)
struct rte_cryptodev *cdev;
rte_pci_device_name(&ndev->pdev->addr, name, sizeof(name));
- snprintf(name + strlen(name), RTE_CRYPTODEV_NAME_MAX_LEN, "_n5sym");
+ snprintf(name + strlen(name), RTE_CRYPTODEV_NAME_MAX_LEN - strlen(name),
+ "_n5sym");
ndev->rte_sym_dev.driver = &nitrox_rte_sym_drv;
ndev->rte_sym_dev.numa_node = ndev->pdev->device.numa_node;
ndev->rte_sym_dev.devargs = NULL;
--
2.13.6
^ permalink raw reply related
* Re: [PATCH v6 2/4] tty: rename tty_kopen() and add new function tty_kopen_shared()
From: Uwe Kleine-König @ 2020-02-20 11:04 UTC (permalink / raw)
To: Johan Hovold
Cc: kernel, linux-serial, Greg Kroah-Hartman, linux-kernel,
Dan Murphy, Pavel Machek, Jiri Slaby, linux-leds,
Jacek Anaszewski
In-Reply-To: <20200219171759.GE32540@localhost>
On Wed, Feb 19, 2020 at 06:17:59PM +0100, Johan Hovold wrote:
> On Wed, Feb 19, 2020 at 05:37:58PM +0100, Uwe Kleine-König wrote:
> > On Wed, Feb 19, 2020 at 02:21:13PM +0100, Johan Hovold wrote:
> > > On Thu, Feb 13, 2020 at 10:15:58AM +0100, Uwe Kleine-König wrote:
> > > > From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > >
> > > > Introduce a new function tty_kopen_shared() that yields a struct
> > > > tty_struct. The semantic difference to tty_kopen() is that the tty is
> > > > expected to be used already. So rename tty_kopen() to
> > > > tty_kopen_exclusive() for clearness, adapt the single user and put the
> > > > common code in a new static helper function.
> > > >
> > > > tty_kopen_shared is to be used to implement an LED trigger for tty
> > > > devices in one of the next patches.
> > > >
> > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > > > ---
> > >
> > > > -/**
> > > > - * tty_kopen - open a tty device for kernel
> > > > - * @device: dev_t of device to open
> > > > - *
> > > > - * Opens tty exclusively for kernel. Performs the driver lookup,
> > > > - * makes sure it's not already opened and performs the first-time
> > > > - * tty initialization.
> > > > - *
> > > > - * Returns the locked initialized &tty_struct
> > > > - *
> > > > - * Claims the global tty_mutex to serialize:
> > > > - * - concurrent first-time tty initialization
> > > > - * - concurrent tty driver removal w/ lookup
> > > > - * - concurrent tty removal from driver table
> > > > - */
> > > > -struct tty_struct *tty_kopen(dev_t device)
> > > > +static struct tty_struct *tty_kopen(dev_t device, int shared)
> > > > {
> > > > struct tty_struct *tty;
> > > > struct tty_driver *driver;
> > > > @@ -1905,7 +1890,7 @@ struct tty_struct *tty_kopen(dev_t device)
> > > >
> > > > /* check whether we're reopening an existing tty */
> > > > tty = tty_driver_lookup_tty(driver, NULL, index);
> > > > - if (IS_ERR(tty))
> > > > + if (IS_ERR(tty) || shared)
> > >
> > > So here you skip initialisation and return NULL if the tty isn't already
> > > in use (e.g. is open) when shared is set.
> >
> > Which is good, right? If I remember my tests correctly this even works
> > if the tty isn't opened but just "exists".
>
> No, this means that your trigger will never be installed unless the port
> is already open, yet the sysfs interface still returns success (see
> patch 4/4 dev_store()).
Ah I think I see. tty_driver_lookup_tty() might return NULL which for
the trigger driver indicates that tty_kopen_shared should be retried,
right?
> Note that the struct tty doesn't exist until the port is opened; it's
> allocated in tty_init_dev() that you skip above when "shared" is set.
That needs fixing. I will try to resolve the dialog with Andy before
addressing that in the next iteration.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 01/19] vfs: syscall: Add fsinfo() to query filesystem information [ver #16]
From: David Howells @ 2020-02-20 11:03 UTC (permalink / raw)
To: Jann Horn
Cc: dhowells, Al Viro, raven, Miklos Szeredi, Christian Brauner,
Linux API, linux-fsdevel, kernel list
In-Reply-To: <CAG48ez0o3iHjQJNvh8V2Ao77g0CqfqGsv6caMCOFDy7w-VdtkQ@mail.gmail.com>
Jann Horn <jannh@google.com> wrote:
> > +int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> ...
> Please add a check here to ensure that "ret" actually fits into the
> buffer (and use WARN_ON() if you think the check should never fire).
> Otherwise I think this is too fragile.
How about:
int fsinfo_string(const char *s, struct fsinfo_context *ctx)
{
unsigned int len;
char *p = ctx->buffer;
int ret = 0;
if (s) {
len = strlen(s);
if (len > ctx->buf_size - 1)
len = ctx->buf_size;
if (!ctx->want_size_only) {
memcpy(p, s, len);
p[len] = 0;
}
ret = len;
}
return ret;
}
I've also added a check to eliminate the copy if userspace didn't actually
supply a buffer.
> > + ret = vfs_statfs(path, &buf);
> > + if (ret < 0 && ret != -ENOSYS)
> > + return ret;
> ...
> > + memcpy(&p->f_fsid, &buf.f_fsid, sizeof(p->f_fsid));
>
> What's going on here? If vfs_statfs() returns -ENOSYS, we just use the
> (AFAICS uninitialized) buf.f_fsid anyway in the memcpy() below and
> return it to userspace?
Good point. I've made the access to the buffer contingent on ret==0. If I
don't set it, it will just be left pre-cleared.
> > + return sizeof(*attr);
>
> I think you meant sizeof(*info).
Yes. I've renamed the buffer point to "p" in all cases so that it's more
obvious.
> > + return ctx->usage;
>
> It is kind of weird that you have to return the ctx->usage everywhere
> even though the caller already has ctx...
At this point, it's only used and returned by fsinfo_attributes() and really
is only for the use of the attribute getter function.
I could, I suppose, return the amount of data in ctx->usage and then preset it
for VSTRUCT-type objects. Unfortunately, I can't make the getter return void
since it might have to return an error.
> > + ctx->buffer = kvmalloc(ctx->buf_size, GFP_KERNEL);
>
> ctx->buffer is _almost_ always pre-zeroed (see vfs_do_fsinfo() below),
> except if we have FSINFO_TYPE_OPAQUE or FSINFO_TYPE_LIST with a size
> bigger than what the attribute's ->size field said? Is that
> intentional?
Fixed.
> > +struct fsinfo_attribute {
> > + unsigned int attr_id; /* The ID of the attribute */
> > + enum fsinfo_value_type type:8; /* The type of the attribute's value(s) */
> > + unsigned int flags:8;
> > + unsigned int size:16; /* - Value size (FSINFO_STRUCT) */
> > + unsigned int element_size:16; /* - Element size (FSINFO_LIST) */
> > + int (*get)(struct path *path, struct fsinfo_context *params);
> > +};
>
> Why the bitfields? It doesn't look like that's going to help you much,
> you'll just end up with 6 bytes of holes on x86-64:
Expanding them to non-bitfields will require an extra 10 bytes, making the
struct 8 bytes bigger with 4 bytes of padding. I can do that if you'd rather.
David
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 2/4] ci: fix Travis config warnings
From: Thomas Monjalon @ 2020-02-20 11:03 UTC (permalink / raw)
To: David Marchand; +Cc: aconole, dev, Michael Santana
In-Reply-To: <20200219194131.29417-3-david.marchand@redhat.com>
19/02/2020 20:41, David Marchand:
> Reading https://config.travis-ci.com/ and using
> https://config.travis-ci.com/explore to check changes, we can cleanup
> some warnings reported by the config validation options in Travis.
For documentation purpose, would be good to describe issues in the commit log.
^ permalink raw reply
* Re: [PATCH v3 16/17] s390x: protvirt: Handle SIGP store status correctly
From: Cornelia Huck @ 2020-02-20 11:02 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200214151636.8764-17-frankja@linux.ibm.com>
On Fri, 14 Feb 2020 10:16:35 -0500
Janosch Frank <frankja@linux.ibm.com> wrote:
> Status storing is not done by QEMU anymore, but is handled by SIE.
>
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> ---
> target/s390x/helper.c | 4 ++++
> target/s390x/sigp.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
> index a3a49164e4..3800c4b395 100644
> --- a/target/s390x/helper.c
> +++ b/target/s390x/helper.c
> @@ -246,6 +246,10 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool store_arch)
> hwaddr len = sizeof(*sa);
> int i;
>
> + if (cpu->env.pv) {
> + return 0;
> + }
> +
> sa = cpu_physical_memory_map(addr, &len, 1);
> if (!sa) {
> return -EFAULT;
> diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
> index c604f17710..da0cfb97de 100644
> --- a/target/s390x/sigp.c
> +++ b/target/s390x/sigp.c
> @@ -497,6 +497,7 @@ void do_stop_interrupt(CPUS390XState *env)
> if (s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu) == 0) {
> qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN);
> }
> + /* Storing will occur on next SIE entry for fmt 4 */
What's fmt 4?
> if (cpu->env.sigp_order == SIGP_STOP_STORE_STATUS) {
> s390_store_status(cpu, S390_STORE_STATUS_DEF_ADDR, true);
> }
^ permalink raw reply
* [linux-next:master 2654/3478] drivers/clk//tegra/clk-tegra124.c:865:31: error: 'TEGRA124_CLK_OSC' undeclared here (not in a function); did you mean 'TEGRA124_CLK_CEC'?
From: kbuild test robot @ 2020-02-20 11:02 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 19114 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: f4aba10148cd290bbbf4d0efae0e9789a13c2778
commit: 78b5672e023c6a42ab4a59fb962fb31adb609e6b [2654/3478] clk: tegra: Add Tegra OSC to clock lookup
config: arm64-allyesconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.5.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 78b5672e023c6a42ab4a59fb962fb31adb609e6b
# save the attached .config to linux build tree
GCC_VERSION=7.5.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
Note: the linux-next/master HEAD f4aba10148cd290bbbf4d0efae0e9789a13c2778 builds fine.
It may have been fixed somewhere.
All errors (new ones prefixed by >>):
>> drivers/clk//tegra/clk-tegra124.c:865:31: error: 'TEGRA124_CLK_OSC' undeclared here (not in a function); did you mean 'TEGRA124_CLK_CEC'?
[tegra_clk_osc] = { .dt_id = TEGRA124_CLK_OSC, .present = true },
^~~~~~~~~~~~~~~~
TEGRA124_CLK_CEC
drivers/clk//tegra/clk-tegra124.c:866:36: error: 'TEGRA124_CLK_OSC_DIV2' undeclared here (not in a function); did you mean 'TEGRA124_CLK_OSC'?
[tegra_clk_osc_div2] = { .dt_id = TEGRA124_CLK_OSC_DIV2, .present = true },
^~~~~~~~~~~~~~~~~~~~~
TEGRA124_CLK_OSC
drivers/clk//tegra/clk-tegra124.c:867:36: error: 'TEGRA124_CLK_OSC_DIV4' undeclared here (not in a function); did you mean 'TEGRA124_CLK_OSC_DIV2'?
[tegra_clk_osc_div4] = { .dt_id = TEGRA124_CLK_OSC_DIV4, .present = true },
^~~~~~~~~~~~~~~~~~~~~
TEGRA124_CLK_OSC_DIV2
--
>> drivers/clk//tegra/clk-tegra210.c:2376:31: error: 'TEGRA210_CLK_OSC' undeclared here (not in a function); did you mean 'TEGRA210_CLK_EMC'?
[tegra_clk_osc] = { .dt_id = TEGRA210_CLK_OSC, .present = true },
^~~~~~~~~~~~~~~~
TEGRA210_CLK_EMC
drivers/clk//tegra/clk-tegra210.c:2377:36: error: 'TEGRA210_CLK_OSC_DIV2' undeclared here (not in a function); did you mean 'TEGRA210_CLK_OSC'?
[tegra_clk_osc_div2] = { .dt_id = TEGRA210_CLK_OSC_DIV2, .present = true },
^~~~~~~~~~~~~~~~~~~~~
TEGRA210_CLK_OSC
drivers/clk//tegra/clk-tegra210.c:2378:36: error: 'TEGRA210_CLK_OSC_DIV4' undeclared here (not in a function); did you mean 'TEGRA210_CLK_OSC_DIV2'?
[tegra_clk_osc_div4] = { .dt_id = TEGRA210_CLK_OSC_DIV4, .present = true },
^~~~~~~~~~~~~~~~~~~~~
TEGRA210_CLK_OSC_DIV2
vim +865 drivers/clk//tegra/clk-tegra124.c
746
747 static struct tegra_clk tegra124_clks[tegra_clk_max] __initdata = {
748 [tegra_clk_ispb] = { .dt_id = TEGRA124_CLK_ISPB, .present = true },
749 [tegra_clk_rtc] = { .dt_id = TEGRA124_CLK_RTC, .present = true },
750 [tegra_clk_timer] = { .dt_id = TEGRA124_CLK_TIMER, .present = true },
751 [tegra_clk_uarta] = { .dt_id = TEGRA124_CLK_UARTA, .present = true },
752 [tegra_clk_sdmmc2_8] = { .dt_id = TEGRA124_CLK_SDMMC2, .present = true },
753 [tegra_clk_i2s1] = { .dt_id = TEGRA124_CLK_I2S1, .present = true },
754 [tegra_clk_i2c1] = { .dt_id = TEGRA124_CLK_I2C1, .present = true },
755 [tegra_clk_sdmmc1_8] = { .dt_id = TEGRA124_CLK_SDMMC1, .present = true },
756 [tegra_clk_sdmmc4_8] = { .dt_id = TEGRA124_CLK_SDMMC4, .present = true },
757 [tegra_clk_pwm] = { .dt_id = TEGRA124_CLK_PWM, .present = true },
758 [tegra_clk_i2s2] = { .dt_id = TEGRA124_CLK_I2S2, .present = true },
759 [tegra_clk_usbd] = { .dt_id = TEGRA124_CLK_USBD, .present = true },
760 [tegra_clk_isp_8] = { .dt_id = TEGRA124_CLK_ISP, .present = true },
761 [tegra_clk_disp2] = { .dt_id = TEGRA124_CLK_DISP2, .present = true },
762 [tegra_clk_disp1] = { .dt_id = TEGRA124_CLK_DISP1, .present = true },
763 [tegra_clk_host1x_8] = { .dt_id = TEGRA124_CLK_HOST1X, .present = true },
764 [tegra_clk_vcp] = { .dt_id = TEGRA124_CLK_VCP, .present = true },
765 [tegra_clk_i2s0] = { .dt_id = TEGRA124_CLK_I2S0, .present = true },
766 [tegra_clk_apbdma] = { .dt_id = TEGRA124_CLK_APBDMA, .present = true },
767 [tegra_clk_kbc] = { .dt_id = TEGRA124_CLK_KBC, .present = true },
768 [tegra_clk_kfuse] = { .dt_id = TEGRA124_CLK_KFUSE, .present = true },
769 [tegra_clk_sbc1] = { .dt_id = TEGRA124_CLK_SBC1, .present = true },
770 [tegra_clk_nor] = { .dt_id = TEGRA124_CLK_NOR, .present = true },
771 [tegra_clk_sbc2] = { .dt_id = TEGRA124_CLK_SBC2, .present = true },
772 [tegra_clk_sbc3] = { .dt_id = TEGRA124_CLK_SBC3, .present = true },
773 [tegra_clk_i2c5] = { .dt_id = TEGRA124_CLK_I2C5, .present = true },
774 [tegra_clk_mipi] = { .dt_id = TEGRA124_CLK_MIPI, .present = true },
775 [tegra_clk_hdmi] = { .dt_id = TEGRA124_CLK_HDMI, .present = true },
776 [tegra_clk_csi] = { .dt_id = TEGRA124_CLK_CSI, .present = true },
777 [tegra_clk_i2c2] = { .dt_id = TEGRA124_CLK_I2C2, .present = true },
778 [tegra_clk_uartc] = { .dt_id = TEGRA124_CLK_UARTC, .present = true },
779 [tegra_clk_mipi_cal] = { .dt_id = TEGRA124_CLK_MIPI_CAL, .present = true },
780 [tegra_clk_usb2] = { .dt_id = TEGRA124_CLK_USB2, .present = true },
781 [tegra_clk_usb3] = { .dt_id = TEGRA124_CLK_USB3, .present = true },
782 [tegra_clk_vde_8] = { .dt_id = TEGRA124_CLK_VDE, .present = true },
783 [tegra_clk_bsea] = { .dt_id = TEGRA124_CLK_BSEA, .present = true },
784 [tegra_clk_bsev] = { .dt_id = TEGRA124_CLK_BSEV, .present = true },
785 [tegra_clk_uartd] = { .dt_id = TEGRA124_CLK_UARTD, .present = true },
786 [tegra_clk_i2c3] = { .dt_id = TEGRA124_CLK_I2C3, .present = true },
787 [tegra_clk_sbc4] = { .dt_id = TEGRA124_CLK_SBC4, .present = true },
788 [tegra_clk_sdmmc3_8] = { .dt_id = TEGRA124_CLK_SDMMC3, .present = true },
789 [tegra_clk_pcie] = { .dt_id = TEGRA124_CLK_PCIE, .present = true },
790 [tegra_clk_owr] = { .dt_id = TEGRA124_CLK_OWR, .present = true },
791 [tegra_clk_afi] = { .dt_id = TEGRA124_CLK_AFI, .present = true },
792 [tegra_clk_csite] = { .dt_id = TEGRA124_CLK_CSITE, .present = true },
793 [tegra_clk_la] = { .dt_id = TEGRA124_CLK_LA, .present = true },
794 [tegra_clk_trace] = { .dt_id = TEGRA124_CLK_TRACE, .present = true },
795 [tegra_clk_soc_therm] = { .dt_id = TEGRA124_CLK_SOC_THERM, .present = true },
796 [tegra_clk_dtv] = { .dt_id = TEGRA124_CLK_DTV, .present = true },
797 [tegra_clk_i2cslow] = { .dt_id = TEGRA124_CLK_I2CSLOW, .present = true },
798 [tegra_clk_tsec] = { .dt_id = TEGRA124_CLK_TSEC, .present = true },
799 [tegra_clk_xusb_host] = { .dt_id = TEGRA124_CLK_XUSB_HOST, .present = true },
800 [tegra_clk_msenc] = { .dt_id = TEGRA124_CLK_MSENC, .present = true },
801 [tegra_clk_csus] = { .dt_id = TEGRA124_CLK_CSUS, .present = true },
802 [tegra_clk_mselect] = { .dt_id = TEGRA124_CLK_MSELECT, .present = true },
803 [tegra_clk_tsensor] = { .dt_id = TEGRA124_CLK_TSENSOR, .present = true },
804 [tegra_clk_i2s3] = { .dt_id = TEGRA124_CLK_I2S3, .present = true },
805 [tegra_clk_i2s4] = { .dt_id = TEGRA124_CLK_I2S4, .present = true },
806 [tegra_clk_i2c4] = { .dt_id = TEGRA124_CLK_I2C4, .present = true },
807 [tegra_clk_sbc5] = { .dt_id = TEGRA124_CLK_SBC5, .present = true },
808 [tegra_clk_sbc6] = { .dt_id = TEGRA124_CLK_SBC6, .present = true },
809 [tegra_clk_d_audio] = { .dt_id = TEGRA124_CLK_D_AUDIO, .present = true },
810 [tegra_clk_apbif] = { .dt_id = TEGRA124_CLK_APBIF, .present = true },
811 [tegra_clk_dam0] = { .dt_id = TEGRA124_CLK_DAM0, .present = true },
812 [tegra_clk_dam1] = { .dt_id = TEGRA124_CLK_DAM1, .present = true },
813 [tegra_clk_dam2] = { .dt_id = TEGRA124_CLK_DAM2, .present = true },
814 [tegra_clk_hda2codec_2x] = { .dt_id = TEGRA124_CLK_HDA2CODEC_2X, .present = true },
815 [tegra_clk_audio0_2x] = { .dt_id = TEGRA124_CLK_AUDIO0_2X, .present = true },
816 [tegra_clk_audio1_2x] = { .dt_id = TEGRA124_CLK_AUDIO1_2X, .present = true },
817 [tegra_clk_audio2_2x] = { .dt_id = TEGRA124_CLK_AUDIO2_2X, .present = true },
818 [tegra_clk_audio3_2x] = { .dt_id = TEGRA124_CLK_AUDIO3_2X, .present = true },
819 [tegra_clk_audio4_2x] = { .dt_id = TEGRA124_CLK_AUDIO4_2X, .present = true },
820 [tegra_clk_spdif_2x] = { .dt_id = TEGRA124_CLK_SPDIF_2X, .present = true },
821 [tegra_clk_actmon] = { .dt_id = TEGRA124_CLK_ACTMON, .present = true },
822 [tegra_clk_extern1] = { .dt_id = TEGRA124_CLK_EXTERN1, .present = true },
823 [tegra_clk_extern2] = { .dt_id = TEGRA124_CLK_EXTERN2, .present = true },
824 [tegra_clk_extern3] = { .dt_id = TEGRA124_CLK_EXTERN3, .present = true },
825 [tegra_clk_sata_oob] = { .dt_id = TEGRA124_CLK_SATA_OOB, .present = true },
826 [tegra_clk_sata] = { .dt_id = TEGRA124_CLK_SATA, .present = true },
827 [tegra_clk_hda] = { .dt_id = TEGRA124_CLK_HDA, .present = true },
828 [tegra_clk_se] = { .dt_id = TEGRA124_CLK_SE, .present = true },
829 [tegra_clk_hda2hdmi] = { .dt_id = TEGRA124_CLK_HDA2HDMI, .present = true },
830 [tegra_clk_sata_cold] = { .dt_id = TEGRA124_CLK_SATA_COLD, .present = true },
831 [tegra_clk_cilab] = { .dt_id = TEGRA124_CLK_CILAB, .present = true },
832 [tegra_clk_cilcd] = { .dt_id = TEGRA124_CLK_CILCD, .present = true },
833 [tegra_clk_cile] = { .dt_id = TEGRA124_CLK_CILE, .present = true },
834 [tegra_clk_dsialp] = { .dt_id = TEGRA124_CLK_DSIALP, .present = true },
835 [tegra_clk_dsiblp] = { .dt_id = TEGRA124_CLK_DSIBLP, .present = true },
836 [tegra_clk_entropy] = { .dt_id = TEGRA124_CLK_ENTROPY, .present = true },
837 [tegra_clk_dds] = { .dt_id = TEGRA124_CLK_DDS, .present = true },
838 [tegra_clk_dp2] = { .dt_id = TEGRA124_CLK_DP2, .present = true },
839 [tegra_clk_amx] = { .dt_id = TEGRA124_CLK_AMX, .present = true },
840 [tegra_clk_adx] = { .dt_id = TEGRA124_CLK_ADX, .present = true },
841 [tegra_clk_xusb_ss] = { .dt_id = TEGRA124_CLK_XUSB_SS, .present = true },
842 [tegra_clk_i2c6] = { .dt_id = TEGRA124_CLK_I2C6, .present = true },
843 [tegra_clk_vim2_clk] = { .dt_id = TEGRA124_CLK_VIM2_CLK, .present = true },
844 [tegra_clk_hdmi_audio] = { .dt_id = TEGRA124_CLK_HDMI_AUDIO, .present = true },
845 [tegra_clk_clk72Mhz] = { .dt_id = TEGRA124_CLK_CLK72MHZ, .present = true },
846 [tegra_clk_vic03] = { .dt_id = TEGRA124_CLK_VIC03, .present = true },
847 [tegra_clk_adx1] = { .dt_id = TEGRA124_CLK_ADX1, .present = true },
848 [tegra_clk_dpaux] = { .dt_id = TEGRA124_CLK_DPAUX, .present = true },
849 [tegra_clk_sor0] = { .dt_id = TEGRA124_CLK_SOR0, .present = true },
850 [tegra_clk_sor0_out] = { .dt_id = TEGRA124_CLK_SOR0_OUT, .present = true },
851 [tegra_clk_gpu] = { .dt_id = TEGRA124_CLK_GPU, .present = true },
852 [tegra_clk_amx1] = { .dt_id = TEGRA124_CLK_AMX1, .present = true },
853 [tegra_clk_uartb] = { .dt_id = TEGRA124_CLK_UARTB, .present = true },
854 [tegra_clk_vfir] = { .dt_id = TEGRA124_CLK_VFIR, .present = true },
855 [tegra_clk_spdif_in] = { .dt_id = TEGRA124_CLK_SPDIF_IN, .present = true },
856 [tegra_clk_spdif_out] = { .dt_id = TEGRA124_CLK_SPDIF_OUT, .present = true },
857 [tegra_clk_vi_9] = { .dt_id = TEGRA124_CLK_VI, .present = true },
858 [tegra_clk_vi_sensor_8] = { .dt_id = TEGRA124_CLK_VI_SENSOR, .present = true },
859 [tegra_clk_fuse] = { .dt_id = TEGRA124_CLK_FUSE, .present = true },
860 [tegra_clk_fuse_burn] = { .dt_id = TEGRA124_CLK_FUSE_BURN, .present = true },
861 [tegra_clk_clk_32k] = { .dt_id = TEGRA124_CLK_CLK_32K, .present = true },
862 [tegra_clk_clk_m] = { .dt_id = TEGRA124_CLK_CLK_M, .present = true },
863 [tegra_clk_clk_m_div2] = { .dt_id = TEGRA124_CLK_CLK_M_DIV2, .present = true },
864 [tegra_clk_clk_m_div4] = { .dt_id = TEGRA124_CLK_CLK_M_DIV4, .present = true },
> 865 [tegra_clk_osc] = { .dt_id = TEGRA124_CLK_OSC, .present = true },
866 [tegra_clk_osc_div2] = { .dt_id = TEGRA124_CLK_OSC_DIV2, .present = true },
867 [tegra_clk_osc_div4] = { .dt_id = TEGRA124_CLK_OSC_DIV4, .present = true },
868 [tegra_clk_pll_ref] = { .dt_id = TEGRA124_CLK_PLL_REF, .present = true },
869 [tegra_clk_pll_c] = { .dt_id = TEGRA124_CLK_PLL_C, .present = true },
870 [tegra_clk_pll_c_out1] = { .dt_id = TEGRA124_CLK_PLL_C_OUT1, .present = true },
871 [tegra_clk_pll_c2] = { .dt_id = TEGRA124_CLK_PLL_C2, .present = true },
872 [tegra_clk_pll_c3] = { .dt_id = TEGRA124_CLK_PLL_C3, .present = true },
873 [tegra_clk_pll_m] = { .dt_id = TEGRA124_CLK_PLL_M, .present = true },
874 [tegra_clk_pll_m_out1] = { .dt_id = TEGRA124_CLK_PLL_M_OUT1, .present = true },
875 [tegra_clk_pll_p] = { .dt_id = TEGRA124_CLK_PLL_P, .present = true },
876 [tegra_clk_pll_p_out1] = { .dt_id = TEGRA124_CLK_PLL_P_OUT1, .present = true },
877 [tegra_clk_pll_p_out2] = { .dt_id = TEGRA124_CLK_PLL_P_OUT2, .present = true },
878 [tegra_clk_pll_p_out3] = { .dt_id = TEGRA124_CLK_PLL_P_OUT3, .present = true },
879 [tegra_clk_pll_p_out4] = { .dt_id = TEGRA124_CLK_PLL_P_OUT4, .present = true },
880 [tegra_clk_pll_a] = { .dt_id = TEGRA124_CLK_PLL_A, .present = true },
881 [tegra_clk_pll_a_out0] = { .dt_id = TEGRA124_CLK_PLL_A_OUT0, .present = true },
882 [tegra_clk_pll_d] = { .dt_id = TEGRA124_CLK_PLL_D, .present = true },
883 [tegra_clk_pll_d_out0] = { .dt_id = TEGRA124_CLK_PLL_D_OUT0, .present = true },
884 [tegra_clk_pll_d2] = { .dt_id = TEGRA124_CLK_PLL_D2, .present = true },
885 [tegra_clk_pll_d2_out0] = { .dt_id = TEGRA124_CLK_PLL_D2_OUT0, .present = true },
886 [tegra_clk_pll_u] = { .dt_id = TEGRA124_CLK_PLL_U, .present = true },
887 [tegra_clk_pll_u_480m] = { .dt_id = TEGRA124_CLK_PLL_U_480M, .present = true },
888 [tegra_clk_pll_u_60m] = { .dt_id = TEGRA124_CLK_PLL_U_60M, .present = true },
889 [tegra_clk_pll_u_48m] = { .dt_id = TEGRA124_CLK_PLL_U_48M, .present = true },
890 [tegra_clk_pll_u_12m] = { .dt_id = TEGRA124_CLK_PLL_U_12M, .present = true },
891 [tegra_clk_pll_x] = { .dt_id = TEGRA124_CLK_PLL_X, .present = true },
892 [tegra_clk_pll_x_out0] = { .dt_id = TEGRA124_CLK_PLL_X_OUT0, .present = true },
893 [tegra_clk_pll_re_vco] = { .dt_id = TEGRA124_CLK_PLL_RE_VCO, .present = true },
894 [tegra_clk_pll_re_out] = { .dt_id = TEGRA124_CLK_PLL_RE_OUT, .present = true },
895 [tegra_clk_spdif_in_sync] = { .dt_id = TEGRA124_CLK_SPDIF_IN_SYNC, .present = true },
896 [tegra_clk_i2s0_sync] = { .dt_id = TEGRA124_CLK_I2S0_SYNC, .present = true },
897 [tegra_clk_i2s1_sync] = { .dt_id = TEGRA124_CLK_I2S1_SYNC, .present = true },
898 [tegra_clk_i2s2_sync] = { .dt_id = TEGRA124_CLK_I2S2_SYNC, .present = true },
899 [tegra_clk_i2s3_sync] = { .dt_id = TEGRA124_CLK_I2S3_SYNC, .present = true },
900 [tegra_clk_i2s4_sync] = { .dt_id = TEGRA124_CLK_I2S4_SYNC, .present = true },
901 [tegra_clk_vimclk_sync] = { .dt_id = TEGRA124_CLK_VIMCLK_SYNC, .present = true },
902 [tegra_clk_audio0] = { .dt_id = TEGRA124_CLK_AUDIO0, .present = true },
903 [tegra_clk_audio1] = { .dt_id = TEGRA124_CLK_AUDIO1, .present = true },
904 [tegra_clk_audio2] = { .dt_id = TEGRA124_CLK_AUDIO2, .present = true },
905 [tegra_clk_audio3] = { .dt_id = TEGRA124_CLK_AUDIO3, .present = true },
906 [tegra_clk_audio4] = { .dt_id = TEGRA124_CLK_AUDIO4, .present = true },
907 [tegra_clk_spdif] = { .dt_id = TEGRA124_CLK_SPDIF, .present = true },
908 [tegra_clk_clk_out_1] = { .dt_id = TEGRA124_CLK_CLK_OUT_1, .present = true },
909 [tegra_clk_clk_out_2] = { .dt_id = TEGRA124_CLK_CLK_OUT_2, .present = true },
910 [tegra_clk_clk_out_3] = { .dt_id = TEGRA124_CLK_CLK_OUT_3, .present = true },
911 [tegra_clk_blink] = { .dt_id = TEGRA124_CLK_BLINK, .present = true },
912 [tegra_clk_xusb_host_src] = { .dt_id = TEGRA124_CLK_XUSB_HOST_SRC, .present = true },
913 [tegra_clk_xusb_falcon_src] = { .dt_id = TEGRA124_CLK_XUSB_FALCON_SRC, .present = true },
914 [tegra_clk_xusb_fs_src] = { .dt_id = TEGRA124_CLK_XUSB_FS_SRC, .present = true },
915 [tegra_clk_xusb_ss_src] = { .dt_id = TEGRA124_CLK_XUSB_SS_SRC, .present = true },
916 [tegra_clk_xusb_ss_div2] = { .dt_id = TEGRA124_CLK_XUSB_SS_DIV2, .present = true },
917 [tegra_clk_xusb_dev_src] = { .dt_id = TEGRA124_CLK_XUSB_DEV_SRC, .present = true },
918 [tegra_clk_xusb_dev] = { .dt_id = TEGRA124_CLK_XUSB_DEV, .present = true },
919 [tegra_clk_xusb_hs_src] = { .dt_id = TEGRA124_CLK_XUSB_HS_SRC, .present = true },
920 [tegra_clk_sclk] = { .dt_id = TEGRA124_CLK_SCLK, .present = true },
921 [tegra_clk_hclk] = { .dt_id = TEGRA124_CLK_HCLK, .present = true },
922 [tegra_clk_pclk] = { .dt_id = TEGRA124_CLK_PCLK, .present = true },
923 [tegra_clk_cclk_g] = { .dt_id = TEGRA124_CLK_CCLK_G, .present = true },
924 [tegra_clk_cclk_lp] = { .dt_id = TEGRA124_CLK_CCLK_LP, .present = true },
925 [tegra_clk_dfll_ref] = { .dt_id = TEGRA124_CLK_DFLL_REF, .present = true },
926 [tegra_clk_dfll_soc] = { .dt_id = TEGRA124_CLK_DFLL_SOC, .present = true },
927 [tegra_clk_vi_sensor2] = { .dt_id = TEGRA124_CLK_VI_SENSOR2, .present = true },
928 [tegra_clk_pll_p_out5] = { .dt_id = TEGRA124_CLK_PLL_P_OUT5, .present = true },
929 [tegra_clk_pll_c4] = { .dt_id = TEGRA124_CLK_PLL_C4, .present = true },
930 [tegra_clk_pll_dp] = { .dt_id = TEGRA124_CLK_PLL_DP, .present = true },
931 [tegra_clk_audio0_mux] = { .dt_id = TEGRA124_CLK_AUDIO0_MUX, .present = true },
932 [tegra_clk_audio1_mux] = { .dt_id = TEGRA124_CLK_AUDIO1_MUX, .present = true },
933 [tegra_clk_audio2_mux] = { .dt_id = TEGRA124_CLK_AUDIO2_MUX, .present = true },
934 [tegra_clk_audio3_mux] = { .dt_id = TEGRA124_CLK_AUDIO3_MUX, .present = true },
935 [tegra_clk_audio4_mux] = { .dt_id = TEGRA124_CLK_AUDIO4_MUX, .present = true },
936 [tegra_clk_spdif_mux] = { .dt_id = TEGRA124_CLK_SPDIF_MUX, .present = true },
937 [tegra_clk_clk_out_1_mux] = { .dt_id = TEGRA124_CLK_CLK_OUT_1_MUX, .present = true },
938 [tegra_clk_clk_out_2_mux] = { .dt_id = TEGRA124_CLK_CLK_OUT_2_MUX, .present = true },
939 [tegra_clk_clk_out_3_mux] = { .dt_id = TEGRA124_CLK_CLK_OUT_3_MUX, .present = true },
940 [tegra_clk_cec] = { .dt_id = TEGRA124_CLK_CEC, .present = true },
941 };
942
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 70466 bytes --]
^ permalink raw reply
* Re: [PATCH v3 13/17] s390x: protvirt: Move diag 308 data over SIDAD
From: Cornelia Huck @ 2020-02-20 11:00 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200214151636.8764-14-frankja@linux.ibm.com>
On Fri, 14 Feb 2020 10:16:32 -0500
Janosch Frank <frankja@linux.ibm.com> wrote:
> For protected guests the IPIB is written/read to/from the satellite
> block, so we need to make those accesses virtual to make them go
> through KVM mem ops.
Confused. What does 'make those accesses virtual' mean?
>
> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> ---
> target/s390x/diag.c | 32 +++++++++++++++++++++++++-------
> 1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
> index 6aaeef6029..59ae122e82 100644
> --- a/target/s390x/diag.c
> +++ b/target/s390x/diag.c
> @@ -88,6 +88,7 @@ static int diag308_parm_check(CPUS390XState *env, uint64_t r1, uint64_t addr,
> void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
> {
> CPUState *cs = env_cpu(env);
> + S390CPU *cpu = S390_CPU(cs);
> uint64_t addr = env->regs[r1];
> uint64_t subcode = env->regs[r3];
> IplParameterBlock *iplb;
> @@ -118,14 +119,24 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
> if (diag308_parm_check(env, r1, addr, ra, false)) {
> return;
> }
> +
Whitespace.
> iplb = g_new0(IplParameterBlock, 1);
> - cpu_physical_memory_read(addr, iplb, sizeof(iplb->len));
> + if (!env->pv) {
> + cpu_physical_memory_read(addr, iplb, sizeof(iplb->len));
> + } else {
> + s390_cpu_pv_mem_read(cpu, 0, iplb, sizeof(iplb->len));
> + }
> +
> if (!iplb_valid_len(iplb)) {
> env->regs[r1 + 1] = DIAG_308_RC_INVALID;
> goto out;
> }
>
> - cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
> + if (!env->pv) {
> + cpu_physical_memory_read(addr, iplb, be32_to_cpu(iplb->len));
> + } else {
> + s390_cpu_pv_mem_read(cpu, 0, iplb, be32_to_cpu(iplb->len));
> + }
>
> if (!iplb_valid_ccw(iplb) && !iplb_valid_fcp(iplb) &&
> !(iplb_valid_pv(iplb) && s390_ipl_pv_check_components(iplb) >= 0)) {
> @@ -137,23 +148,30 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t ra)
> env->regs[r1 + 1] = DIAG_308_RC_OK;
> out:
> g_free(iplb);
> - return;
> + break;
> case DIAG308_STORE:
> case DIAG308_PV_STORE:
> if (diag308_parm_check(env, r1, addr, ra, true)) {
> return;
> }
> +
Whitespace.
> if (subcode == DIAG308_PV_STORE) {
> iplb = s390_ipl_get_iplb_secure();
> } else {
> iplb = s390_ipl_get_iplb();
> }
> - if (iplb) {
> - cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
> - env->regs[r1 + 1] = DIAG_308_RC_OK;
> - } else {
> + if (!iplb) {
> env->regs[r1 + 1] = DIAG_308_RC_NO_CONF;
> + return;
> }
> +
> + if (!env->pv) {
> + cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
> + } else {
> + s390_cpu_pv_mem_write(cpu, 0, iplb, be32_to_cpu(iplb->len));
> + }
> +
> + env->regs[r1 + 1] = DIAG_308_RC_OK;
> break;
> case DIAG308_PV_START:
> iplb = s390_ipl_get_iplb_secure();
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marc Zyngier @ 2020-02-20 11:01 UTC (permalink / raw)
To: Stefan Agner
Cc: Vladimir Murzin, Russell King, kvm, Arnd Bergmann,
Suzuki K Poulose, Quentin Perret, Christoffer Dall, James Morse,
Julien Thierry, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <69845f739bbd91e73cd82e7c4683ab5a@agner.ch>
On 2020-02-19 13:53, Stefan Agner wrote:
> On 2020-02-10 15:13, Marc Zyngier wrote:
>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>> life so far. It mostly works if you're prepared to deal with its
>> limitations, it has been a good prototype for the arm64 version,
>> but it suffers a few problems:
>>
>> - It is incomplete (no debug support, no PMU)
>> - It hasn't followed any of the architectural evolutions
>> - It has zero users (I don't count myself here)
>> - It is more and more getting in the way of new arm64 developments
>>
>> So here it is: unless someone screams and shows that they rely on
>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>> form the tree. One of the reasons that makes me confident nobody is
>> using it is that I never receive *any* bug report. Yes, it is perfect.
>
> Not entirely true:
> https://lore.kernel.org/m/e2f7196ca6c70c55463a45b490f6731a@agner.ch
And I thank you for that. This bug was actually hitting both arm and
arm64, and triggered by a bogus DT (that KVM should have handled in a
nicer way). What I was trying to say is that nobody reports bugs that
are specific to 32bit KVM/arm.
> But, after that was fixed, it actually was perfect :-D
> https://blog.printk.io/2016/09/kvm-with-kvmtool-on-armv7/
Hey, neat! not sure how useful, but neat nonetheless... ;-)
> That said, I never used it in a real-world application, so from my side
> removing it is fine.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marc Zyngier @ 2020-02-20 11:01 UTC (permalink / raw)
To: Stefan Agner
Cc: Russell King, kvm, Arnd Bergmann, Paolo Bonzini, Will Deacon,
kvmarm, linux-arm-kernel
In-Reply-To: <69845f739bbd91e73cd82e7c4683ab5a@agner.ch>
On 2020-02-19 13:53, Stefan Agner wrote:
> On 2020-02-10 15:13, Marc Zyngier wrote:
>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>> life so far. It mostly works if you're prepared to deal with its
>> limitations, it has been a good prototype for the arm64 version,
>> but it suffers a few problems:
>>
>> - It is incomplete (no debug support, no PMU)
>> - It hasn't followed any of the architectural evolutions
>> - It has zero users (I don't count myself here)
>> - It is more and more getting in the way of new arm64 developments
>>
>> So here it is: unless someone screams and shows that they rely on
>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>> form the tree. One of the reasons that makes me confident nobody is
>> using it is that I never receive *any* bug report. Yes, it is perfect.
>
> Not entirely true:
> https://lore.kernel.org/m/e2f7196ca6c70c55463a45b490f6731a@agner.ch
And I thank you for that. This bug was actually hitting both arm and
arm64, and triggered by a bogus DT (that KVM should have handled in a
nicer way). What I was trying to say is that nobody reports bugs that
are specific to 32bit KVM/arm.
> But, after that was fixed, it actually was perfect :-D
> https://blog.printk.io/2016/09/kvm-with-kvmtool-on-armv7/
Hey, neat! not sure how useful, but neat nonetheless... ;-)
> That said, I never used it in a real-world application, so from my side
> removing it is fine.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marc Zyngier @ 2020-02-20 11:01 UTC (permalink / raw)
To: Stefan Agner
Cc: linux-arm-kernel, kvmarm, kvm, Vladimir Murzin, Russell King,
Arnd Bergmann, Suzuki K Poulose, Quentin Perret, Christoffer Dall,
James Morse, Paolo Bonzini, Will Deacon, Julien Thierry
In-Reply-To: <69845f739bbd91e73cd82e7c4683ab5a@agner.ch>
On 2020-02-19 13:53, Stefan Agner wrote:
> On 2020-02-10 15:13, Marc Zyngier wrote:
>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>> life so far. It mostly works if you're prepared to deal with its
>> limitations, it has been a good prototype for the arm64 version,
>> but it suffers a few problems:
>>
>> - It is incomplete (no debug support, no PMU)
>> - It hasn't followed any of the architectural evolutions
>> - It has zero users (I don't count myself here)
>> - It is more and more getting in the way of new arm64 developments
>>
>> So here it is: unless someone screams and shows that they rely on
>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>> form the tree. One of the reasons that makes me confident nobody is
>> using it is that I never receive *any* bug report. Yes, it is perfect.
>
> Not entirely true:
> https://lore.kernel.org/m/e2f7196ca6c70c55463a45b490f6731a@agner.ch
And I thank you for that. This bug was actually hitting both arm and
arm64, and triggered by a bogus DT (that KVM should have handled in a
nicer way). What I was trying to say is that nobody reports bugs that
are specific to 32bit KVM/arm.
> But, after that was fixed, it actually was perfect :-D
> https://blog.printk.io/2016/09/kvm-with-kvmtool-on-armv7/
Hey, neat! not sure how useful, but neat nonetheless... ;-)
> That said, I never used it in a real-world application, so from my side
> removing it is fine.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH] PM / hibernate: fix typo "reserverd_size" -> "reserved_size"
From: Rafael J. Wysocki @ 2020-02-20 11:01 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Rafael J . Wysocki, Pavel Machek, Linux PM,
Linux Kernel Mailing List
In-Reply-To: <20200214140621.19796-1-alexandre.belloni@bootlin.com>
On Fri, Feb 14, 2020 at 3:06 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> Fix a mistake in a variable name in a comment.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> kernel/power/snapshot.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index ddade80ad276..d82b7b88d616 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -1681,7 +1681,7 @@ static unsigned long minimum_image_size(unsigned long saveable)
> * hibernation for allocations made while saving the image and for device
> * drivers, in case they need to allocate memory from their hibernation
> * callbacks (these two numbers are given by PAGES_FOR_IO (which is a rough
> - * estimate) and reserverd_size divided by PAGE_SIZE (which is tunable through
> + * estimate) and reserved_size divided by PAGE_SIZE (which is tunable through
> * /sys/power/reserved_size, respectively). To make this happen, we compute the
> * total number of available page frames and allocate at least
> *
> --
Applied as 5.6 material, thanks!
^ permalink raw reply
* Re: [Intel-gfx] [PATCH] drm/i915: remove the other slab_dependencies
From: Chris Wilson @ 2020-02-20 11:00 UTC (permalink / raw)
To: Matthew Auld, intel-gfx
In-Reply-To: <20200220105707.344522-1-matthew.auld@intel.com>
Quoting Matthew Auld (2020-02-20 10:57:07)
> The real one can be found in i915_scheduler.c.
>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
You're not a fan of redundancy, I see :)
Oops,
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [Xen-devel] [linux-4.4 test] 147279: regressions - FAIL
From: osstest service owner @ 2020-02-20 11:00 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147279 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 139698
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 139698
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-amd 14 xen-boot/l1 fail in 147111 pass in 147279
test-armhf-armhf-xl-credit1 7 xen-boot fail in 147111 pass in 147279
test-amd64-i386-xl-xsm 23 leak-check/check fail in 147111 pass in 147279
test-armhf-armhf-libvirt 19 leak-check/check fail in 147111 pass in 147279
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 147111
test-amd64-i386-libvirt-xsm 18 guest-start/debian.repeat fail pass in 147186
test-armhf-armhf-libvirt-raw 11 guest-start fail pass in 147186
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 147111 REGR. vs. 139698
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 147111 never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 147111 never pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-amd64-xl-pvhv2-amd 12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
version targeted for testing:
linux 76e5c6fd6d163f1aa63969cc982e79be1fee87a7
baseline version:
linux dc16a7e5f36d65b25a1b66ade14356773ed52875
Last test of basis 139698 2019-08-04 07:48:30 Z 200 days
Failing since 139773 2019-08-06 16:40:26 Z 197 days 110 attempts
Testing same since 147111 2020-02-16 03:37:56 Z 4 days 3 attempts
------------------------------------------------------------
1097 people touched revisions under test,
not listing them all
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 fail
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-amd64-examine pass
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvhv2-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 55417 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [MODERATED] Re: [PATCH 1/2] more sampling fun 1
From: Andrew Cooper @ 2020-02-20 11:00 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220101340.GB30404@zn.tnic>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On 20/02/2020 10:13, speck for Borislav Petkov wrote:
> On Thu, Feb 20, 2020 at 10:10:03AM +0000, speck for Andrew Cooper wrote:
>> Because it is under embargo until May 12th.
> Maybe 2/2 is - which I don't have in my mbox - but by staring only at
> 1/2 there's nothing to embargo there AFAICT.
>
Right, but a lone patch (coming pre-reviewed even!) adding stepping
support into the speculative model checking is going to be about as
subtle as the KPTI work was :)
~Andrew
^ permalink raw reply
* [meta-oe][sumo][PATCH] strongswan: avoid charon crash
From: Saloni Jain @ 2020-02-20 10:58 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org, Khem Raj
Cc: Nisha Parrakat, Rahul Taya, Aditya Tayade, Anuj Chougule
[-- Attachment #1: Type: text/plain, Size: 6611 bytes --]
From: Anuj Chougule <Anuj.Chougule@kpit.com>
This is a possible fix to charon that crashed early due to invalid
memory access.
Important frames from Backtraces :
8 0x00007f607246e160 in memcpy (__len=1704, __src=<optimized out>, __dest=<optimized out>)
at /usr/include/bits/string_fortified.h:34
No locals.
9 memcpy_noop (n=1704, src=<optimized out>, dst=<optimized out>)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/utils/utils/memory.h:47
n = 1704
src = <optimized out>
dst = <optimized out>
10 chunk_create_clone (ptr=<optimized out>, chunk=...)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/utils/chunk.c:48
clone = <optimized out>
11 0x00007f606ebae810 in load_from_blob (blob=..., type=type@entry=CRED_PRIVATE_KEY, subtype=subtype@entry=1,
subject=subject@entry=0x0, flags=flags@entry=X509_NONE)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:399
x = <optimized out>
cred = 0x0
---Type <return> to continue, or q <return> to quit---
pgp = false
12 0x00007f606ebaf0e4 in load_from_file (flags=X509_NONE, subject=0x0, subtype=1, type=CRED_PRIVATE_KEY,
file=0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem")
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:452
cred = <optimized out>
chunk = 0x7f6054005430
13 pem_load (type=CRED_PRIVATE_KEY, subtype=1, args=<optimized out>)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:498
file = 0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem"
pem = <optimized out>
subject = 0x0
flags = 0
Problem lies in frame 12 & 11.
(gdb) f 12
12 0x00007f606ebaf0e4 in load_from_file (flags=X509_NONE, subject=0x0, subtype=1, type=CRED_PRIVATE_KEY,
file=0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem")
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:452
452 in /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c
(gdb) info locals
cred = <optimized out>
chunk = 0x7f6054005430
(gdb) print *chunk
$21 = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 1704}
(gdb) f 11
11 0x00007f606ebae810 in load_from_blob (blob=..., type=type@entry=CRED_PRIVATE_KEY, subtype=subtype@entry=1, subject=subject@entry=0x0,
flags=flags@entry=X509_NONE) at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:399
399 in /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c
(gdb) info args
blob = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 140052215328768}
type = CRED_PRIVATE_KEY
subtype = 1
subject = 0x0
flags = X509_NONE
(gdb) print blob
$22 = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 140052215328768}
Source code snippet :
static void *load_from_file(char *file, credential_type_t type, int subtype,
identification_t *subject, x509_flag_t flags)
{
void *cred;
chunk_t *chunk;
chunk = chunk_map(file, FALSE);
if (!chunk)
{
DBG1(DBG_LIB, " opening '%s' failed: %s", file, strerror(errno));
return NULL;
}
cred = load_from_blob(*chunk, type, subtype, subject, flags);
chunk_unmap(chunk);
return cred;
}
Local variable chunk is an uninitialised pointer in load_from_file()
(frame 12 above) which is expected to get initialised through
chunk_map() & then passed to load_from_blob() as a parameter.
But somehow, the chunk pointer has not got initialised &
got passed as it is to load_from_blob() in frame 11 above.
As this contains a garbage address, when method load_from_blob()
tried cloning the memory regions through chunk_clone() ->
chunk_create_clone() -> memcpy() -> memcpy_noop(), it crashed with
SIGBUS (frames 10, 9, 8).
It could also be that chunk_map() has a bug which does not memmap()
the full or correct areas.
Upstream-Status: Pending
Tested By: Anuj Chougule <Anuj.Chougule@kpit.com>
Signed-off-by: Anuj Chougule <Anuj.Chougule@kpit.com>
Signed-off-by: Saloni Jain <Saloni.Jain@kpit.com>
---
.../strongswan/files/fix-charon-crash.patch | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 recipes-support/strongswan/files/fix-charon-crash.patch
diff --git a/recipes-support/strongswan/files/fix-charon-crash.patch b/recipes-support/strongswan/files/fix-charon-crash.patch
new file mode 100644
index 0000000..95e71a2
--- /dev/null
+++ b/recipes-support/strongswan/files/fix-charon-crash.patch
@@ -0,0 +1,23 @@
+strongswan: avoid charon crash
+
+Variable chunk is an uninitialised pointer,which
+is expected to get initialised through method chunk_map()
+& then passed to load_from_blob() as a parameter.
+But somehow, if the chunk pointer did not get initialised & gets
+passed as it is to load_from_blob(), it may lead crash as this
+contains a garbage address.
+
+Signed-off-by: Anuj Chougule <Anuj.Chougule@kpit.com>
+Upstream-Status: Pending
+
+--- a/src/libstrongswan/plugins/pem/pem_builder.c
++++ b/src/libstrongswan/plugins/pem/pem_builder.c
+@@ -441,7 +441,7 @@ static void *load_from_file(char *file, credential_type_t type, int subtype,
+ identification_t *subject, x509_flag_t flags)
+ {
+ void *cred;
+- chunk_t *chunk;
++ chunk_t *chunk = NULL;
+
+ chunk = chunk_map(file, FALSE);
+ if (!chunk)
--
2.7.4
This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.
[-- Attachment #2: Type: text/html, Size: 10472 bytes --]
^ permalink raw reply related
* Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()
From: Uwe Kleine-König @ 2020-02-20 10:57 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sascha Hauer, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
Linux Kernel Mailing List, Jacek Anaszewski, Pavel Machek,
Jiri Slaby, Linux LED Subsystem, Dan Murphy
In-Reply-To: <CAHp75VcxXWputX1y90t8f-c0a3dw2CHU6=ebQ+o6e8Z1GymiDw@mail.gmail.com>
Hello Andy,
On Thu, Feb 20, 2020 at 12:22:36PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 20, 2020 at 9:49 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Wed, Feb 19, 2020 at 09:50:54PM +0200, Andy Shevchenko wrote:
> > > On Thu, Feb 13, 2020 at 11:27 AM Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> > > >
> > > > This function is in the same spirit as the other kstrto* functions and
> > > > uses the same calling convention. It expects the input string to be in
> > > > the format %u:%u and implements stricter parsing than sscanf as it
> > > > returns an error on trailing data (other than the usual \n).
>
> ...
>
> > > On top of that, why kstrtodev_t is so important? How many users are
> > > already in the kernel to get an advantage out of it?
> >
> > Does it need to be important? It matches the other kstrto* functions and
> > so it seemed more natural to me to put it near the other functions. I'm
> > not aware of other potential users and surprised you seem to suggest
> > this as a requirement.
>
> Yes it does. The kstrtox() are quite generic, what you are proposing
> is rather one particular case with blurry understanding how many users
> will be out of it.
In my understanding one user is a hard requirement.
> If you had told "look, we have 1234 users which may benefit out of
> it", I would have given no comment against.
Sure, having >1000 potential users would be a good argument pro this
function. But having only one isn't a good contra IMHO.
> > > What to do with all other possible variants ("%d:%d", "%dx%d" and its
> > > %u variant, etc)?
> >
> > I don't see how %d:%d is relevant, major and minor cannot be negative
> > can they? I never saw 'x' as separator between major and minor. I
> > considered shortly parsing %u, but given that (I think) this is an
> > internal representation only I chose to not make it more visible than it
> > already is.
>
> See above, if we are going to make it generic, perhaps better to cover
> more possible users, right?
> Otherwise your change provokes pile of (replaced)
> kstrto_resolution() /* %ux:%u */
> kstrto_range() /* %d:%d */
> kstrto_you_name_it()
Given there are respective types that this can be stored to, I don't
object more functions of this type and don't see a good reason to not
add such a function. And in my eyes I prefer to have such a function in
a visible place (i.e. where all the other kstrto* functions are) to
prevent code duplication.
Also I don't understand yet, what you want me to do. Assume I'd be
willing to use simple_strtoul, I'd still want to have a function that
gives me a dev_t from a given string. Should I put this directly in my
led-trigger driver?
> > > Why simple_strto*() can't be used?
> >
> > I didn't really consider it, but looking in more detail I don't like it
> > much. Without having tried it I think simple_strtoull accepts
> > "1000000000000000000000000000000000000000000" returning some arbitrary
> > value without an error indication.
>
> So what? User has a lot of possibilities to shoot into the foot.
> Since you interpret this as device major:minor, not founding a device
> will be first level of error, next one when your code will try to do
> something out of it. It shouldn't be a problem of kstrtox generic
> helpers.
I fail to follow your argument here. In my eyes if the user writes a
valid major:minor it should work, and if they write an invalid one this
should result in an error and not a usage of a device that just happens
to have the major:minor that simple_strtoull happens to return for the
two components.
> > And given that I was asked for strict
> > parsing (i.e. not accepting 2:4:something) I'd say using simple_strto*
> > is a step backwards. Also simple_strtoul() has "This function is obsolete.
> > Please use kstrtoul instead." in its docstring which seems to apply to
> > the other simple_strto*() functions, too.
>
> I specifically fixed a doc string to approve its use in the precisely
> cases you have here.
Can you please be a bit more constructive here and point to the change
you talk about? I didn't find a commit in next.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v2 2/2] phy: intel: Add driver support for Combophy
From: Andy Shevchenko @ 2020-02-20 10:57 UTC (permalink / raw)
To: Dilip Kota
Cc: linux-kernel, devicetree, kishon, robh, cheol.yong.kim,
chuanhua.lei, qi-ming.wu, yixin.zhu
In-Reply-To: <3c73c805-55a6-dcc0-4cd4-dd452f1d002d@linux.intel.com>
On Thu, Feb 20, 2020 at 05:58:41PM +0800, Dilip Kota wrote:
> On 2/19/2020 6:14 PM, Andy Shevchenko wrote:
> > On Wed, Feb 19, 2020 at 11:31:30AM +0800, Dilip Kota wrote:
...
> > return regmap_update_bits(..., mask, val);
> >
> > ?
> Still it is taking more than 80 characters with mask, need to be in 2 lines
>
> return regmap_update_bits(...,
> mask, val);
It's up to maintainer, I was talking about use of temporary variable for mask.
> > > +static int intel_cbphy_pcie_refclk_cfg(struct intel_cbphy_iphy *iphy, bool set)
> > > +{
> > > + struct intel_combo_phy *cbphy = iphy->parent;
> > > + const u32 pad_dis_cfg_off = 0x174;
> > > + u32 val, bitn;
> > > +
> > > + bitn = cbphy->id * 2 + iphy->id;
> > > +
> > > + /* Register: 0 is enable, 1 is disable */
> > > + val = set ? 0 : BIT(bitn);
> > > +
> > > + return regmap_update_bits(cbphy->syscfg, pad_dis_cfg_off, BIT(bitn),
> > > + val);
> > Ditto.
> Here it can with go in single line with mask,
Here I meant all changes from previous function, yes, temporary variable mask
in particular.
> > > +}
...
> > > + case PHY_PCIE_MODE:
> > > + cb_mode = (aggr == PHY_DL_MODE) ?
> > > + PCIE_DL_MODE : PCIE0_PCIE1_MODE;
> > I think one line is okay here.
> its taking 82 characters.
Up to maintainer, but I consider the two lines approach is worse to read.
> > > + break;
...
> > > + ret = intel_cbphy_iphy_cfg(iphy,
> > > + intel_cbphy_pcie_en_pad_refclk);
> > One line is fine here.
> It is taking 81 characters, so kept in 2 lines.
Ditto.
> > > + if (ret)
> > > + return ret;
...
> > > + ret = intel_cbphy_iphy_cfg(iphy,
> > > + intel_cbphy_pcie_dis_pad_refclk);
> > Ditto.
> 82 characters here.
Ditto.
> > > + if (ret)
> > > + return ret;
...
> > > + ret = fwnode_property_get_reference_args(dev_fwnode(dev),
> > > + "intel,syscfg", NULL, 1, 0,
> > > + &ref);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + fwnode_handle_put(ref.fwnode);
> > Why here?
>
> Instructed to do:
>
> " Caller is responsible to call fwnode_handle_put() on the returned
> args->fwnode pointer"
Right...
> > > + cbphy->id = ref.args[0];
> > > + cbphy->syscfg = device_node_to_regmap(ref.fwnode->dev->of_node);
...and here you called unreferenced one. Is it okay?
If it's still being referenced, that is fine, but otherwise it may gone already.
> > > + ret = fwnode_property_get_reference_args(dev_fwnode(dev), "intel,hsio",
> > > + NULL, 1, 0, &ref);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + fwnode_handle_put(ref.fwnode);
> > > + cbphy->bid = ref.args[0];
> > > + cbphy->hsiocfg = device_node_to_regmap(ref.fwnode->dev->of_node);
> > Ditto.
> >
> > > + if (!device_property_read_u32(dev, "intel,phy-mode", &prop)) {
> > Hmm... Why to mix device_property_*() vs. fwnode_property_*() ?
> device_property_* are wrapper functions to fwnode_property_*().
> Calling the fwnode_property_*() ending up doing the same work of
> device_property_*().
>
> If the best practice is to maintain symmetry, will call fwnode_property_*().
The best practice to keep consistency as much as possible.
If you call two similar APIs in one scope, it's not okay.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] docs: power: Drop reference to interface.rst
From: Rafael J. Wysocki @ 2020-02-20 10:57 UTC (permalink / raw)
To: Jonathan Neuschäfer
Cc: open list:DOCUMENTATION, Rafael J. Wysocki, Len Brown,
Pavel Machek, Linux PM, Linux Kernel Mailing List
In-Reply-To: <20200218145819.17314-1-j.neuschaefer@gmx.net>
On Tue, Feb 18, 2020 at 3:59 PM Jonathan Neuschäfer
<j.neuschaefer@gmx.net> wrote:
>
> It has been merged into sleep-states.rst.
>
> Fixes: c21502efdaed ("Documentation: admin-guide: PM: Update sleep states documentation")
> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> ---
> Documentation/power/index.rst | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/power/index.rst b/Documentation/power/index.rst
> index 002e42745263..ced8a8007434 100644
> --- a/Documentation/power/index.rst
> +++ b/Documentation/power/index.rst
> @@ -13,7 +13,6 @@ Power Management
> drivers-testing
> energy-model
> freezing-of-tasks
> - interface
> opp
> pci
> pm_qos_interface
> --
Applied as a fix for 5.6, thanks!
^ permalink raw reply
* [Intel-gfx] [PATCH] drm/i915: remove the other slab_dependencies
From: Matthew Auld @ 2020-02-20 10:57 UTC (permalink / raw)
To: intel-gfx
The real one can be found in i915_scheduler.c.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_request.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 6daf18dbb3d4..dbd882fe22ef 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -51,7 +51,6 @@ struct execute_cb {
static struct i915_global_request {
struct i915_global base;
struct kmem_cache *slab_requests;
- struct kmem_cache *slab_dependencies;
struct kmem_cache *slab_execute_cbs;
} global;
@@ -1614,14 +1613,12 @@ long i915_request_wait(struct i915_request *rq,
static void i915_global_request_shrink(void)
{
- kmem_cache_shrink(global.slab_dependencies);
kmem_cache_shrink(global.slab_execute_cbs);
kmem_cache_shrink(global.slab_requests);
}
static void i915_global_request_exit(void)
{
- kmem_cache_destroy(global.slab_dependencies);
kmem_cache_destroy(global.slab_execute_cbs);
kmem_cache_destroy(global.slab_requests);
}
@@ -1651,16 +1648,9 @@ int __init i915_global_request_init(void)
if (!global.slab_execute_cbs)
goto err_requests;
- global.slab_dependencies = KMEM_CACHE(i915_dependency,
- SLAB_HWCACHE_ALIGN |
- SLAB_RECLAIM_ACCOUNT);
- if (!global.slab_dependencies)
- goto err_execute_cbs;
-
i915_global_register(&global.base);
return 0;
-err_execute_cbs:
kmem_cache_destroy(global.slab_execute_cbs);
err_requests:
kmem_cache_destroy(global.slab_requests);
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH v2 1/2] docs: Convert qemu-cpu-models.texi to rST
From: Peter Maydell @ 2020-02-20 10:56 UTC (permalink / raw)
To: Kashyap Chamarthy
Cc: Markus Armbruster, Daniel P. Berrange, QEMU Developers,
Eduardo Habkost
In-Reply-To: <20200220102308.GE24572@paraplu>
On Thu, 20 Feb 2020 at 10:23, Kashyap Chamarthy <kchamart@redhat.com> wrote:
>
> On Wed, Feb 19, 2020 at 05:57:16PM +0000, Peter Maydell wrote:
> > On Wed, 19 Feb 2020 at 16:40, Kashyap Chamarthy <kchamart@redhat.com> wrote:
> > > Peter, how are you able to generate those *.7 `nroff` man pages? When I
> > > do 'make sphinxbuild' from my build dir ($HOME/buld/qemu), I only see:
> >
> > Just run 'make'.
>
> I did that, but I was missing the "--enable-docs" with my `configure`
> invocation (which I didn't post in full on the list, but only on IRC
> yesterday). Thanks, Markus, for spotting that.
Yeah, if you don't have the necessary tools then we'll
silently not build the docs (per configure's usual default
of "probe and enable only if possible").
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH v5] tools/perf/metricgroup: Fix printing event names of metric group with multiple events incase of overlapping events
From: Jiri Olsa @ 2020-02-20 10:56 UTC (permalink / raw)
To: Kajol Jain
Cc: acme, linux-kernel, linux-perf-users, Jiri Olsa,
Alexander Shishkin, Andi Kleen, Kan Liang, Peter Zijlstra,
Jin Yao, Madhavan Srinivasan, Anju T Sudhakar, Ravi Bangoria
In-Reply-To: <20200220050104.14094-1-kjain@linux.ibm.com>
On Thu, Feb 20, 2020 at 10:31:04AM +0530, Kajol Jain wrote:
SNIP
> + i++;
> + if (i == idnum)
> + break;
> }
> }
> }
> @@ -144,7 +142,10 @@ static struct evsel *find_evsel_group(struct evlist *perf_evlist,
> !strcmp(ev->name, metric_events[i]->name)) {
> ev->metric_leader = metric_events[i];
> }
> + j++;
> }
> + ev = metric_events[i];
> + evlist_used[ev->idx] = true;
> }
>
> return metric_events[0];
> @@ -160,6 +161,14 @@ static int metricgroup__setup_events(struct list_head *groups,
> int ret = 0;
> struct egroup *eg;
> struct evsel *evsel;
> + bool *evlist_used;
> +
> + evlist_used = (bool *)calloc(perf_evlist->core.nr_entries,
> + sizeof(bool));
no need for the (bool *) cast
other than that
Acked-by: Jiri Olsa <jolsa@redhat.com>
thanks,
jirka
^ permalink raw reply
* Re: [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh
From: Emil Velikov @ 2020-02-20 10:56 UTC (permalink / raw)
To: Ville Syrjala
Cc: Kyungmin Park, Seung-Woo Kim, Intel Graphics Development,
ML dri-devel, Joonyoung Shim
In-Reply-To: <20200219203544.31013-3-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
>
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh
From: Emil Velikov @ 2020-02-20 10:56 UTC (permalink / raw)
To: Ville Syrjala
Cc: Kyungmin Park, Seung-Woo Kim, Intel Graphics Development,
ML dri-devel, Joonyoung Shim
In-Reply-To: <20200219203544.31013-3-ville.syrjala@linux.intel.com>
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
<ville.syrjala@linux.intel.com> wrote:
>
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
>
> Cc: Inki Dae <inki.dae@samsung.com>
> Cc: Joonyoung Shim <jy0922.shim@samsung.com>
> Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
-Emil
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH -next] Documentation/power: fix pm_qos_interface.rst format warning
From: Rafael J. Wysocki @ 2020-02-20 10:55 UTC (permalink / raw)
To: Randy Dunlap
Cc: Linux PM list, linux-doc@vger.kernel.org, Jonathan Corbet,
Rafael J. Wysocki
In-Reply-To: <561e2780-111a-1939-43fb-ae32d7abce8d@infradead.org>
On Mon, Feb 17, 2020 at 5:54 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix Sphinx warnings by indenting the bullet list (and making it
> unnumbered).
>
> Documentation/power/pm_qos_interface.rst:12: WARNING: Unexpected indentation.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: linux-pm@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org
> ---
> Documentation/power/pm_qos_interface.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20200217.orig/Documentation/power/pm_qos_interface.rst
> +++ linux-next-20200217/Documentation/power/pm_qos_interface.rst
> @@ -7,8 +7,8 @@ performance expectations by drivers, sub
> one of the parameters.
>
> Two different PM QoS frameworks are available:
> -1. CPU latency QoS.
> -2. The per-device PM QoS framework provides the API to manage the
> + * CPU latency QoS.
> + * The per-device PM QoS framework provides the API to manage the
> per-device latency constraints and PM QoS flags.
>
> The latency unit used in the PM QoS framework is the microsecond (usec).
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/2] tty: serial: samsung_tty: remove SERIAL_SAMSUNG_DEBUG
From: Krzysztof Kozlowski @ 2020-02-20 10:55 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Donghoon Yu, linux-samsung-soc, linux-kernel, Shinbeom Choi,
Hyunki Koo, Kukjin Kim, linux-arm-kernel, linux-serial,
Jiri Slaby, HYUN-KI KOO
In-Reply-To: <20200220102628.3371996-2-gregkh@linuxfoundation.org>
On Thu, Feb 20, 2020 at 11:26:28AM +0100, Greg Kroah-Hartman wrote:
> Since a05025d0ce72 ("tty: serial: samsung_tty: use standard debugging
> macros") this configuration option is not used at all, so remove it from
> the Kconfig file.
>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Donghoon Yu <hoony.yu@samsung.com>
> Cc: Hyunki Koo <kkoos00@naver.com>
> Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
> Cc: Shinbeom Choi <sbeom.choi@samsung.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Jiri Slaby <jslaby@suse.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-serial@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/tty/serial/Kconfig | 9 ---------
> 1 file changed, 9 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.