Re: [PATCH 03/15] mm/hmm: HMM should have a callback before MM is destroyed v3
On 03/21/2018 06:28 PM, jgli...@redhat.com wrote:
> From: Ralph Campbell
>
> The hmm_mirror_register() function registers a callback for when
> the CPU pagetable is modified. Normally, the device driver will
> call hmm_mirror_unregister() when the process using the device is
> finished. However, if the process exits uncleanly, the struct_mm
> can be destroyed with no warning to the device driver.
>
> Changed since v1:
> - dropped VM_BUG_ON()
> - cc stable
> Changed since v2:
> - drop stable
> - Split list removale and call to driver release callback. This
> allow the release callback to wait on any pending fault handler
> without deadlock.
>
> Signed-off-by: Ralph Campbell
> Signed-off-by: Jérôme Glisse
> Cc: Evgeny Baskakov
> Cc: Mark Hairgrove
> Cc: John Hubbard
> ---
> include/linux/hmm.h | 10 ++
> mm/hmm.c| 29 -
> 2 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/hmm.h b/include/linux/hmm.h
> index 36dd21fe5caf..fa7b51f65905 100644
> --- a/include/linux/hmm.h
> +++ b/include/linux/hmm.h
> @@ -218,6 +218,16 @@ enum hmm_update_type {
> * @update: callback to update range on a device
> */
> struct hmm_mirror_ops {
> + /* release() - release hmm_mirror
> + *
> + * @mirror: pointer to struct hmm_mirror
> + *
> + * This is called when the mm_struct is being released.
> + * The callback should make sure no references to the mirror occur
> + * after the callback returns.
> + */
> + void (*release)(struct hmm_mirror *mirror);
> +
> /* sync_cpu_device_pagetables() - synchronize page tables
>*
>* @mirror: pointer to struct hmm_mirror
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 320545b98ff5..34c16297f65e 100644
> --- a/mm/hmm.c
> +++ b/mm/hmm.c
> @@ -160,6 +160,32 @@ static void hmm_invalidate_range(struct hmm *hmm,
> up_read(&hmm->mirrors_sem);
> }
>
> +static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm)
> +{
> + struct hmm_mirror *mirror;
> + struct hmm *hmm = mm->hmm;
> +
> + down_write(&hmm->mirrors_sem);
> + mirror = list_first_entry_or_null(&hmm->mirrors, struct hmm_mirror,
> + list);
> + while (mirror) {
> + list_del_init(&mirror->list);
> + if (mirror->ops->release) {
> + /*
> + * Drop mirrors_sem so callback can wait on any pending
> + * work that might itself trigger mmu_notifier callback
> + * and thus would deadlock with us.
> + */
> + up_write(&hmm->mirrors_sem);
> + mirror->ops->release(mirror);
> + down_write(&hmm->mirrors_sem);
> + }
> + mirror = list_first_entry_or_null(&hmm->mirrors, struct
> hmm_mirror,
> + list);
> + }
> + up_write(&hmm->mirrors_sem);
> +}
> +
Hi Jerome,
This looks good (and the list handling is way better than my horrible
copy-the-list idea)!
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
> static void hmm_invalidate_range_start(struct mmu_notifier *mn,
> struct mm_struct *mm,
> unsigned long start,
> @@ -185,6 +211,7 @@ static void hmm_invalidate_range_end(struct mmu_notifier
> *mn,
> }
>
> static const struct mmu_notifier_ops hmm_mmu_notifier_ops = {
> + .release= hmm_release,
> .invalidate_range_start = hmm_invalidate_range_start,
> .invalidate_range_end = hmm_invalidate_range_end,
> };
> @@ -230,7 +257,7 @@ void hmm_mirror_unregister(struct hmm_mirror *mirror)
> struct hmm *hmm = mirror->hmm;
>
> down_write(&hmm->mirrors_sem);
> - list_del(&mirror->list);
> + list_del_init(&mirror->list);
> up_write(&hmm->mirrors_sem);
> }
> EXPORT_SYMBOL(hmm_mirror_unregister);
>
linux-next: manual merge of the nvdimm tree with the xfs tree
Hi Dan,
Today's linux-next merge of the nvdimm tree got a conflict in:
fs/xfs/xfs_inode.h
between commit:
f5c54717bf2b ("xfs: remove xfs_zero_range")
from the xfs tree and commit:
6ea4108852e9 ("xfs: prepare xfs_break_layouts() for another layout type")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/xfs/xfs_inode.h
index 132d8aa2afc4,6951d57aae71..
--- a/fs/xfs/xfs_inode.h
+++ b/fs/xfs/xfs_inode.h
@@@ -443,6 -457,12 +457,8 @@@ enum xfs_prealloc_flags
int xfs_update_prealloc_flags(struct xfs_inode *ip,
enum xfs_prealloc_flags flags);
-int xfs_zero_eof(struct xfs_inode *ip, xfs_off_t offset,
- xfs_fsize_t isize, bool *did_zeroing);
-int xfs_zero_range(struct xfs_inode *ip, xfs_off_t pos, xfs_off_t count,
- bool *did_zero);
+ int xfs_break_layouts(struct inode *inode, uint *iolock,
+ enum layout_break_reason reason);
/* from xfs_iops.c */
extern void xfs_setup_inode(struct xfs_inode *ip);
pgpay6iO1ZjYO.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/5 v4] add compression algorithm zBeWalgo
Hi Philippe,
> Actually to be consistent if you want to use GPL-2-0 (and not "or
> later") you should use:
>
> 1. at the top, for a c. file:
> // SPDX-License-Identifier: GPL-2.0
>
> or for a .h file:
> /* SPDX-License-Identifier: GPL-2.0 */
>
> The doc explains it all. Including the comment style (a topic that has
> been discussed also on list quite bit: Linus had the final word there)
>
> 2. and in your MODULE_LICENSE macro:
>
> MODULE_LICENSE("GPL v2");
>
> because a MODULE_LICENSE("GPL"); would mean GPL-2.0+ (e.g. or any
> later version) and this would not match your top level license tag.
Thanks, I have done this correctly in my files, but accidentally written it
wrong in my mail.
Cordinally
Benjamin Warnke
Re: [PATCH 03/10] drm/sun4i: Don't pretend to handle ARGB8888 with the frontend
On Wed, Mar 21, 2018 at 11:28 PM, Paul Kocialkowski
wrote:
> It turns out that the frontend is not capable of preserving the alpha
> component (that is always set to 0xff), so only support XRGB
> instead.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/sun4i/sun4i_backend.c | 4
> drivers/gpu/drm/sun4i/sun4i_frontend.c | 3 +--
> drivers/gpu/drm/sun4i/sun4i_layer.c| 4 ++--
> 3 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c
> b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index b98dafda52f8..274a1db6fa8e 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -440,6 +440,10 @@ static bool sun4i_backend_plane_uses_frontend(struct
> drm_plane_state *state)
> if (IS_ERR(backend->frontend))
> return false;
>
> + /*
> +* TODO: Don't use the frontend for x2/x4 scaling and allow RGB
> formats
> +* with an alpha component then.
This and the commit log are kind of conflicting. Is it just the scalar
that doesn't
work with an alpha component, or the whole frontend?
Thanks
ChenYu
> +*/
> return sun4i_backend_plane_uses_scaler(state);
> }
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> index ddf6cfa6dd23..3ea925584891 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
> @@ -107,7 +107,7 @@ EXPORT_SYMBOL(sun4i_frontend_update_buffer);
> static int sun4i_frontend_drm_format_to_input_fmt(uint32_t fmt, u32 *val)
> {
> switch (fmt) {
> - case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_XRGB:
> *val = 5;
> return 0;
>
> @@ -120,7 +120,6 @@ static int
> sun4i_frontend_drm_format_to_output_fmt(uint32_t fmt, u32 *val)
> {
> switch (fmt) {
> case DRM_FORMAT_XRGB:
> - case DRM_FORMAT_ARGB:
> *val = 2;
> return 0;
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
> b/drivers/gpu/drm/sun4i/sun4i_layer.c
> index eb93df445a10..15238211a61a 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
> @@ -100,9 +100,9 @@ static void sun4i_backend_layer_atomic_update(struct
> drm_plane *plane,
> sun4i_frontend_update_coord(frontend, plane);
> sun4i_frontend_update_buffer(frontend, plane);
> sun4i_frontend_update_formats(frontend, plane,
> - DRM_FORMAT_ARGB);
> + DRM_FORMAT_XRGB);
> sun4i_backend_update_layer_frontend(backend, layer->id, plane,
> - DRM_FORMAT_ARGB);
> + DRM_FORMAT_XRGB);
> sun4i_frontend_enable(frontend);
> } else {
> sun4i_backend_update_layer_formats(backend, layer->id, plane);
> --
> 2.16.2
>
Re: [PATCH v4 4/6] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs
Hi Sinan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6 next-20180321]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/ib-Eliminate-duplicate-barriers-on-weakly-ordered-archs/20180321-091659
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
In file included from drivers/infiniband/hw/cxgb4/iw_cxgb4.h:73:0,
from drivers/infiniband/hw/cxgb4/device.c:40:
drivers/infiniband/hw/cxgb4/t4.h: In function 'pio_copy':
>> drivers/infiniband/hw/cxgb4/t4.h:460:3: error: implicit declaration of
>> function 'writeq_relaxed'; did you mean 'writel_relaxed'?
>> [-Werror=implicit-function-declaration]
writeq_relaxed(*src, dst);
^~
writel_relaxed
cc1: some warnings being treated as errors
vim +460 drivers/infiniband/hw/cxgb4/t4.h
450
451 /* This function copies 64 byte coalesced work request to memory
452 * mapped BAR2 space. For coalesced WRs, the SGE fetches data
453 * from the FIFO instead of from Host.
454 */
455 static inline void pio_copy(u64 __iomem *dst, u64 *src)
456 {
457 int count = 8;
458
459 while (count) {
> 460 writeq_relaxed(*src, dst);
461 src++;
462 dst++;
463 count--;
464 }
465 }
466
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
linux-next: manual merge of the drm tree with Linus' tree
Hi all, Today's linux-next merge of the drm tree got conflicts in several amdgpu files because there are a set of (mostly identical) patches that appear Linus' tree and the drm tree. In each case I just used the version fo the file from the drm tree. You should do a test merge between your tree and Linus' tree and see what you want to do about the resolution (either do the back merge (I think with v4.16-rc6), or provide Linus with branch that has the merge done). Its a bit of a mess :-( -- Cheers, Stephen Rothwell pgplUIjH36xU1.pgp Description: OpenPGP digital signature
linux-next: build failure after merge of the scsi-mkp tree
Hi Martin,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/qla2xxx/qla_gs.c: In function 'qla24xx_async_gnnft_done':
drivers/scsi/qla2xxx/qla_gs.c:3974:7: error: 'fc4type' undeclared (first use in
this function); did you mean 'fc4type_t'?
if ((fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
^~~
fc4type_t
drivers/scsi/qla2xxx/qla_gs.c:3974:7: note: each undeclared identifier is
reported only once for each function it appears in
drivers/scsi/qla2xxx/qla_gs.c:3975:3: error: too few arguments to function
'qla24xx_async_gpnft'
qla24xx_async_gpnft(vha, FC4_TYPE_NVME);
^~~
In file included from drivers/scsi/qla2xxx/qla_def.h:4633:0,
from drivers/scsi/qla2xxx/qla_gs.c:7:
drivers/scsi/qla2xxx/qla_gbl.h:661:5: note: declared here
int qla24xx_async_gpnft(scsi_qla_host_t *, u8, srb_t *);
^~~
Caused by commit
33b28357dd00 ("scsi: qla2xxx: Fix Async GPN_FT for FCP and FC-NVMe scan")
interacting with commit
2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery")
from Linus' tree.
I have added the following merge fix patch for today. Unfortunately it
produces this warning, so a better merge resolution is needed ...
drivers/scsi/qla2xxx/qla_gs.c: In function 'qla24xx_async_gnnft_done':
drivers/scsi/qla2xxx/qla_gs.c:3974:9: warning: 'rp' may be used uninitialized
in this function [-Wmaybe-uninitialized]
if ((rp->fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
~~^
From: Stephen Rothwell
Date: Thu, 22 Mar 2018 17:09:38 +1100
Subject: [PATCH] scsi: qla2xxx: merge fix in qla_gs.c
Signed-off-by: Stephen Rothwell
---
drivers/scsi/qla2xxx/qla_gs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c
index f84807e850c3..d33f4619332e 100644
--- a/drivers/scsi/qla2xxx/qla_gs.c
+++ b/drivers/scsi/qla2xxx/qla_gs.c
@@ -3971,8 +3971,8 @@ void qla24xx_async_gnnft_done(scsi_qla_host_t *vha, srb_t
*sp)
vha->scan.scan_flags &= ~SF_SCANNING;
spin_unlock_irqrestore(&vha->work_lock, flags);
- if ((fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
- qla24xx_async_gpnft(vha, FC4_TYPE_NVME);
+ if ((rp->fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
+ qla24xx_async_gpnft(vha, FC4_TYPE_NVME, NULL);
}
static void qla2x00_find_free_fcp_nvme_slot(struct scsi_qla_host *vha,
--
2.16.1
--
Cheers,
Stephen Rothwell
pgp3Wir5_Nys7.pgp
Description: OpenPGP digital signature
RE: [RFT][PATCH v7 5/8] cpuidle: Return nohz hint from cpuidle_select()
On 2018.03.21 15:15 Rafael J. Wysocki wrote: > On Wed, Mar 21, 2018 at 6:59 PM, Thomas Ilsche wrote: >> On 2018-03-21 15:36, Rafael J. Wysocki wrote: >>> >>> >>> So please disregard this one entirely and take the v7.2 replacement >>> instead of it:https://patchwork.kernel.org/patch/10299429/ >>> >>> The current versions (including the above) is in the git branch at >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ >>> idle-loop-v7.2 >> >> With v7.2 (tested on SKL-SP from git) I see similar behavior in idle >> as with v5: several cores which just keep the sched tick enabled. >> Worse yet, some go only in C1 (not even C1E!?) despite sleeping the >> full sched tick. >> The resulting power consumption is ~105 W instead of ~ 70 W. >> >> https://wwwpub.zih.tu-dresden.de/~tilsche/powernightmares/v7_2_skl_sp_idle.png >> >> I have briefly ran v7 and I believe it was also affected. > > Then it looks like menu_select() stubbornly thinks that the idle > duration will be within the tick boundary on those cores. > > That may be because the bumping up of the correction factor in > menu_reflect() is too conservative or it may be necessary to do > something radical to measured_us in menu_update() in case of a tick > wakeup combined with a large next_timer_us value. > > For starters, please see if the attached patch (on top of the > idle-loop-v7.2 git branch) changes this behavior in any way. O.K. I am seeing some weirdness. On my system with both V7.2 and V7.2 plus this patch, I observe A spike in Idle State 1 residency every 34+ minutes. And slightly higher average idle power than before. (I might not have done V7 idle tests long enough). It can be seen in the frequency sweep I did earlier today, with V7.2: http://fast.smythies.com/rjw_freq_sweep_72_combined.png Despite the note on the graph that says it might be real, I don't think it is (I forgot to delete the note). With V7.2+ sometimes the event occurs at 17 minute intervals. Here is a idle graph (for reference: we have seen idle package power pretty steady at ~3.7 watts before). http://fast.smythies.com/rjw_v72p_idle.png ... Doug
Re: [PATCH v4 16/24] fpga: dfl: add fpga manager platform driver for FME
On Wed, Mar 21, 2018 at 09:55:52AM -0700, Moritz Fischer wrote:
> On Wed, Mar 21, 2018 at 10:50:01AM +0800, Wu Hao wrote:
> > On Tue, Mar 20, 2018 at 03:32:34PM -0500, Alan Tull wrote:
> > > On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote:
> > >
> > > Hi Hao,
> > >
> > > Elsewhere we discussed moving #defines used only in this driver either
> > > to this .c file or to a similarly named .h file. A couple minor
> > > things below.
> >
> > Hi Alan,
> >
> > Yes, I will move those #defines into a similarly named .h file.
> >
> > >
> > > > This patch adds fpga manager driver for FPGA Management Engine (FME). It
> > > > implements fpga_manager_ops for FPGA Partial Reconfiguration function.
> > > >
> > > > Signed-off-by: Tim Whisonant
> > > > Signed-off-by: Enno Luebbers
> > > > Signed-off-by: Shiva Rao
> > > > Signed-off-by: Christopher Rauer
> > > > Signed-off-by: Kang Luwei
> > > > Signed-off-by: Xiao Guangrong
> > > > Signed-off-by: Wu Hao
> > > > ---
> > > > v3: rename driver to dfl-fpga-fme-mgr
> > > > implemented status callback for fpga manager
> > > > rebased due to fpga api changes
> > > > v4: rename to dfl-fme-mgr, and fix SPDX license issue
> > > > add pr_credit comments and improve dev_err message
> > > > remove interface_id sysfs interface
> > > > include dfl-fme-pr.h instead of dfl.h
> > > > ---
> > > > drivers/fpga/Kconfig | 6 +
> > > > drivers/fpga/Makefile | 1 +
> > > > drivers/fpga/dfl-fme-mgr.c | 290
> > > > +
> > > > 3 files changed, 297 insertions(+)
> > > > create mode 100644 drivers/fpga/dfl-fme-mgr.c
> > > >
> > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > > index 103d5e2..89f76e8 100644
> > > > --- a/drivers/fpga/Kconfig
> > > > +++ b/drivers/fpga/Kconfig
> > > > @@ -150,6 +150,12 @@ config FPGA_DFL_FME
> > > > FPGA platform level management features. There shall be 1 FME
> > > > per DFL based FPGA device.
> > > >
> > > > +config FPGA_DFL_FME_MGR
> > > > + tristate "FPGA DFL FME Manager Driver"
> > > > + depends on FPGA_DFL_FME
> > > > + help
> > > > + Say Y to enable FPGA Manager driver for FPGA Management
> > > > Engine.
> > > > +
> > > > config FPGA_DFL_PCI
> > > > tristate "FPGA Device Feature List (DFL) PCIe Device Driver"
> > > > depends on PCI && FPGA_DFL
> > > > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > > > index 3c44fc9..f82814a 100644
> > > > --- a/drivers/fpga/Makefile
> > > > +++ b/drivers/fpga/Makefile
> > > > @@ -31,6 +31,7 @@ obj-$(CONFIG_OF_FPGA_REGION) +=
> > > > of-fpga-region.o
> > > > # FPGA Device Feature List Support
> > > > obj-$(CONFIG_FPGA_DFL) += dfl.o
> > > > obj-$(CONFIG_FPGA_DFL_FME) += dfl-fme.o
> > > > +obj-$(CONFIG_FPGA_DFL_FME_MGR) += dfl-fme-mgr.o
> > > >
> > > > dfl-fme-objs := dfl-fme-main.o dfl-fme-pr.o
> > > >
> > > > diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
> > > > new file mode 100644
> > > > index 000..2f92c29
> > > > --- /dev/null
> > > > +++ b/drivers/fpga/dfl-fme-mgr.c
> > > > @@ -0,0 +1,290 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * FPGA Manager Driver for FPGA Management Engine (FME)
> > > > + *
> > > > + * Copyright (C) 2017 Intel Corporation, Inc.
> > > > + *
> > > > + * Authors:
> > > > + * Kang Luwei
> > > > + * Xiao Guangrong
> > > > + * Wu Hao
> > > > + * Joseph Grecco
> > > > + * Enno Luebbers
> > > > + * Tim Whisonant
> > > > + * Ananda Ravuri
> > > > + * Christopher Rauer
> > > > + * Henry Mitchel
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +#include "dfl-fme-pr.h"
> > > > +
> > > > +#define PR_WAIT_TIMEOUT 800
> > > > +#define PR_HOST_STATUS_IDLE0
> > > > +
> > > > +struct fme_mgr_priv {
> > > > + void __iomem *ioaddr;
> > > > + u64 pr_error;
> > > > +};
> > > > +
> > > > +static u64 pr_error_to_mgr_status(u64 err)
> > > > +{
> > > > + u64 status = 0;
> > > > +
> > > > + if (err & FME_PR_ERR_OPERATION_ERR)
> > > > + status |= FPGA_MGR_STATUS_OPERATION_ERR;
> > > > + if (err & FME_PR_ERR_CRC_ERR)
> > > > + status |= FPGA_MGR_STATUS_CRC_ERR;
> > > > + if (err & FME_PR_ERR_INCOMPATIBLE_BS)
> > > > + status |= FPGA_MGR_STATUS_INCOMPATIBLE_IMAGE_ERR;
> > > > + if (err & FME_PR_ERR_PROTOCOL_ERR)
> > > > + status |= FPGA_MGR_STATUS_IP_PROTOCOL_ERR;
> > > > + if (err & FME_PR_ERR_FIFO_OVERFLOW)
> > > > + status |= FPGA_MGR_STATUS_FIFO_OVERFLOW_ERR;
> > > > +
> > > > + return status;
> > > > +}
> > > > +
> > > > +static u64 fme_mgr_pr_error_handle(void __iomem *fme_pr)
> > > > +{
> > > > + u64 pr_status, pr_error;
> > > > +
> > > > + pr_status = readq(fme_pr + FME_PR_STS);
> > > > + if
Re: [linux-sunxi] Re: [PATCH 2/7] dt-bindings: add binding for the Allwinner A64 DE2 bus
于 2018年3月22日 GMT+08:00 上午1:13:42, "Jernej Škrabec" 写到: >Hi all, > >Dne sreda, 21. marec 2018 ob 03:18:13 CET je Icenowy Zheng napisal(a): >> 于 2018年3月21日 GMT+08:00 上午2:46:46, Maxime Ripard > >写到: >> >On Sat, Mar 17, 2018 at 01:53:49AM +0800, Icenowy Zheng wrote: >> >> All the sub-blocks of Allwinner A64 DE2 needs the SRAM C on A64 >SoC >> > >> >to >> > >> >> be claimed, otherwise the whole DE2 space is inaccessible. >> >> >> >> Add a device tree binding of the DE2 part as a sub-bus. >> > >> >Where did you get the info that it was a bus? >> >> There's no direct evidence, just some guess. >> >> The DE2 is a whole part that is just allocated a memory >> space at the user manual, and the SRAM controls the >> access to all modules in the DE2. >> >> So it might be a bus. >> >> Implement it as a bus is a clear representation on A64. > >Since there is already syscon for same mmio region, we migh as well use >it >when loading ccu-sun8i-de2 driver on A64. > >Other options, like SRAM driver or bus driver, might better represent >HW, but I think the device tree should properly represent the HW, it's a basic requirment. >then we would have two DT nodes covering same mmio region, which I >think is >not really acceptable. It's acceptable, and DE2 is not the only user of SRAM controller so far. VE will also need a SRAM region to be claimed. > >Any suggestions? > >BTW, H6 has same design in this regard. > >Best regards, >Jernej
Re: [PATCH] arm64: avoid race condition issue in dump_backtrace
On Thu, Mar 22, 2018 at 11:06:00AM +0800, Ji Zhang wrote:
> When we dump the backtrace of some specific task, there is a potential race
> condition due to the task may be running on other cores if SMP enabled.
> That is because for current implementation, if the task is not the current
> task, we will get the registers used for unwind from cpu_context saved in
> thread_info, which is the snapshot before context switch, but if the task
> is running on other cores, the registers and the content of stack are
> changed.
> This may cause that we get the wrong backtrace or incomplete backtrace or
> even crash the kernel.
When do we call dump_backtrace() on a running task that is not current?
AFAICT, we don't do that in the arm64-specific callers of dump_backtrace(), and
this would have to be some caller of show_stack() in generic code.
We pin the task's stack via try_get_task_stack(), so this cannot be unmapped
while we walk it. In unwind_frame() we check that the frame record falls
entirely within the task's stack. So AFAICT, we cannot crash the kernel here,
though the backtrace may be misleading (and we could potentially get stuck in
an infinite loop).
> To avoid this case, do not dump the backtrace of the tasks which are
> running on other cores.
> This patch cannot solve the issue completely but can shrink the window of
> race condition.
> @@ -113,6 +113,9 @@ void dump_backtrace(struct pt_regs *regs, struct
> task_struct *tsk)
> if (tsk == current) {
> frame.fp = (unsigned long)__builtin_frame_address(0);
> frame.pc = (unsigned long)dump_backtrace;
> + else if (tsk->state == TASK_RUNNING) {
> + pr_notice("Do not dump other running tasks\n");
> + return;
As you note, if we can race with the task being scheduled, this doesn't help.
Can we rule this out at a higher level?
Thanks,
Mark.
linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi Martin,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/qla2xxx/qla_os.c
between commit:
2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery")
from Linus' tree and commit:
33b28357dd00 ("scsi: qla2xxx: Fix Async GPN_FT for FCP and FC-NVMe scan")
from the scsi-mkp tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpAoQJDoZnav.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the sound-asoc tree
On Thursday 22 March 2018 07:08 AM, Mark Brown wrote: On Wed, Mar 21, 2018 at 11:15:16AM +0530, Mukunda,Vijendar wrote: There is a patch dependency . Below patch not merged yet. We submitted for upstream review. [PATCH V2] ASoC: dwc: I2S Controller instance param added You need to mention dependencies between patches when publishing and I don't seem to have a copy of that patch, according to the list archives Alex asked you to make some chnages to it. Changes suggested by Alex already implemented and posted . Current patch (https://patchwork.kernel.org/patch/10298281/ ) is dependent on below patch. https://patchwork.kernel.org/patch/10296597/ We will publish patch dependencies while sending patches.
[RESEND PATCH] mfd: sprd: Add one syscon cell to access PMIC global registers
There are some global registers in Spreadtrum sc27xx PMICs, which will
be accessed by other drivers. So this patch adds one syscon cell to
help to access the PMIC's global registers.
Signed-off-by: Baolin Wang
---
drivers/mfd/sprd-sc27xx-spi.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c
index 56a4782..3460ef0 100644
--- a/drivers/mfd/sprd-sc27xx-spi.c
+++ b/drivers/mfd/sprd-sc27xx-spi.c
@@ -111,6 +111,9 @@ struct sprd_pmic_data {
}, {
.name = "sc27xx-poweroff",
.of_compatible = "sprd,sc27xx-poweroff",
+ }, {
+ .name = "sc27xx-syscon",
+ .of_compatible = "sprd,sc27xx-syscon",
},
};
--
1.7.9.5
RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver
Hi Miquel, Thanks for reviewing the patch series. Please see my comments below. > -Original Message- > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com] > Sent: Tuesday, March 20, 2018 2:38 AM > To: nagasureshkumarre...@gmail.com > Cc: boris.brezil...@bootlin.com; rich...@nod.at; dw...@infradead.org; > computersforpe...@gmail.com; marek.va...@gmail.com; > cyrille.pitc...@wedev4u.fr; linux-...@lists.infradead.org; linux- > ker...@vger.kernel.org; Michal Simek ; Punnaiah > Choudary Kalluri ; Naga Sureshkumar Relli > > Subject: Re: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add > documentation for controller and driver > > Hi naga, > > On Wed, 14 Mar 2018 16:18:14 +0530, > wrote: > > > From: Naga Sureshkumar Relli > > > > Added notes about the controller and driver > > > > Signed-off-by: Naga Sureshkumar Relli > > --- > > Changes in v8 > > - None > > Changes in v7: > > - None > > Changes in v6: > > - None > > Changes in v5: > > - Fixed the review comments > > Changes in v4: > > - None > > --- > > Documentation/mtd/nand/pl353-nand.txt | 92 > > +++ > > 1 file changed, 92 insertions(+) > > create mode 100644 Documentation/mtd/nand/pl353-nand.txt > > > > diff --git a/Documentation/mtd/nand/pl353-nand.txt > > b/Documentation/mtd/nand/pl353-nand.txt > > new file mode 100644 > > index 000..ac6fbd5 > > --- /dev/null > > +++ b/Documentation/mtd/nand/pl353-nand.txt > > @@ -0,0 +1,92 @@ > > +This documents provides some notes about the ARM pl353 smc controller > > +used in Zynq SOC and confined to NAND specific details. > > + > > +Overview of the controller > > +== > > + The SMC (PL353) supports two memory interfaces: > > + Interface 0 type SRAM. > > + Interface 1 type NAND. > > + This configuration supports the following configurable options: > > + . 32-bit or 64-bit AXI data width > > + . 8-bit, 16-bit, or 32-bit memory data width for interface 0 > > + . 8-bit, or 16-bit memory data width for interface 1 > > + . 1-4 chip selects on each interface > > + . SLC ECC block for interface 1 > > + > > +For more information, refer the below link for TRM > > +http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/ > > +DDI0380G_smc_pl350_series_r2p1_trm.pdf > > I think it is better to do not break the links? I will correct it in next patch. > > > + > > +NAND memory accesses > > + > > + . Two phase NAND accesses > > + . NAND command phase transfers > > + . NAND data phase transfers > > + > > +Two phase NAND accesses > > + The SMC defines two phases of commands when transferring data to or > > +from NAND flash. > > + > > +Command phase > > + Commands and optional address information are written to the NAND > flash. > > +The command and address can be associated with either a data phase > > +operation to write to or read from the array, or a status/ID register > > transfer. > > + > > +Data phase > > + Data is either written to or read from the NAND flash. This data can > > +be either data transferred to or from the array, or status/ID register > information. > > + > > +NAND AXI address setup > > + AXI address Command phase Data phase > > + [31:24] Chip address Chip address > > + [23]NoOfAddCycles_2Reserved > > + [22]NoOfAddCycles_1Reserved > > + [21]NoOfAddCycles_0ClearCS > > + [20]End command valid End command valid > > + [19]0 1 > > + [18:11] End commandEnd command > > + [10:3] Start command [10] ECC Last > > + [9:3] Reserved > > + [2:0] Reserved Reserved > > + > > +ECC > > +=== > > +It operates on a number of 512 byte blocks of NAND memory and can > > +be programmed to store the ECC codes after the data in memory. For > > +writes, the ECC is written to the spare area of the page. For reads, > > +the result of a block ECC check are made available to the device driver. > > + > > +- > > +--- > > +| n * 512 blocks | extra | ecc| | > > +| | block | codes | | > > +- > > +--- > > + > > +The ECC calculation uses a simple Hamming code, using 1-bit > > +correction 2-bit detection. It starts when a valid read or write > > +command with a 512 byte aligned address is detected on the memory > interface. > > + > > +Driver details > > +== > > + The NAND driver has dependency with the pl353_smc memory > controller > > +driver for intializing the nand timing parameters, bus width, ECC > > +modes, > > ^NAND > > > +control and status information. > > + > > +Since the controller expects that the c
Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online
Hi, Kumar On Thu, 2018-03-22 at 11:30 +0800, Viresh Kumar wrote: > On 21-03-18, 18:21, Shunyong Yang wrote: > > > > When multiple cpus are related in one cpufreq policy, the first > > online cpu > > will be chosen by default to handle cpufreq operations. In a CPPC > > case, > > let's take two related cpus, cpu0 and cpu1 as an example. > > > > After system start, cpu0 is the first online cpu. Cpufreq policy > > will be > > allocated and init() in cpufreq_driver will be called to initialize > > cpu0's > > perf capabilities and policy parameters. > Not exactly. The init() is called to initialize stuff for all the > CPUs that > should be part of policy->related_cpus after init() has returned. So > you should > initialize perf capabilities for all of them. In page 533 of ACPI 6.2 specificaiton, it says, "Starting with ACPI Specification 6.2, all _CPC registers can be in PCC, System Memory, System IO, or Functional Fixed Hardware address spaces. OSPM support for this more flexible register space scheme is indicated by the “Flexible Address Space for CPPC Registers” _OSC bit." As _CPC register maybe in System Memory, System IO, or Functional Fixed Hardware address spaces. I am not sure all architecture implementing CPPC can return correct value before CPU come into online. That's the reason I add the extra init() call. BTW, I've tested on QDF2400 platform and it return correct value when cpu1 is offline. Do you know whether firmware can guarantee correct perf capabilities regardless of CPU online/offline? > > > > > When cpu1 is online, current code > > will not call init() in cpufreq_driver as policy has been allocated > > and > > activated by cpu0. So, cpu1's perf capabilities are not initialized > > (all 0s). > > > > When cpu0 is offline, policy->cpu will be shifted to cpu1. As > > cpu1's perf > > capabilities are 0s, speed change will not take effect when setting > > speed. > > > > This patch adds calling init() of cpufreq_driver when policy > > inactive cpu > > comes to online. > No CPU should be inactive here, its just that you haven't initialized > it > properly. > I mean the policy is handled(active) by the first online cpu's (cpu0) perf capabilities. Not handled (inactive) by the one's just come into online (cpu1). Sorry for this. Thanks. Shunyong. > And we are not going to call init() multiple times for a group of > CPUs. That's > not what the purpose of init() is. >
[PATCH] Documentation: Mention why %p prints ptrval
When debugging recent kernels, people will see '(ptrval)' but there isn't much information as to what that means. Briefly describe why it's there. Signed-off-by: Joel Stanley --- Documentation/core-api/printk-formats.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/core-api/printk-formats.rst b/Documentation/core-api/printk-formats.rst index 934559b3c130..eb30efdd2e78 100644 --- a/Documentation/core-api/printk-formats.rst +++ b/Documentation/core-api/printk-formats.rst @@ -60,8 +60,8 @@ Plain Pointers Pointers printed without a specifier extension (i.e unadorned %p) are hashed to prevent leaking information about the kernel memory layout. This has the added benefit of providing a unique identifier. On 64-bit machines -the first 32 bits are zeroed. If you *really* want the address see %px -below. +the first 32 bits are zeroed. The kernel will print ``(ptrval)`` until it +gathers enough entropy. If you *really* want the address see %px below. Symbols/Function Pointers - -- 2.15.1
Re: [PATCH v10] mmc: Export host capabilities to debugfs.
On Friday 16 March 2018 01:27 PM, Ulf Hansson wrote: > On 16 March 2018 at 05:20, Harish Jenny K N wrote: >> >> On Thursday 15 March 2018 05:59 PM, Ulf Hansson wrote: >>> On 15 March 2018 at 11:26, Andy Shevchenko >>> wrote: On Thu, 2018-03-15 at 11:12 +0100, Ulf Hansson wrote: > On 13 March 2018 at 06:10, Harish Jenny K N > wrote: >> > Honestly, I don't like this, but maybe other people do, then I am fine > with this approach. > > If were to decide, I would just rather print the caps field in a > hexadecimal bit form and leave the translation to the user. A compromise would be to print both: 0x\n Description of each enabled field, one per line Another format would be: Bit XX: Description of a field >>> If we were to print the description, there is no point in printing the >>> bits in hex. Or is it? >> Yes. I also do not see the use of printing hex value if we are printing the >> description. >> >>> As I said, if you and other folkz thinks this is valuable, then I am >>> fine as well. Just saying, it's not my preferred option. >>> >>> >> >> I just want to inform that the idea of printing the description came after >> discussion in https://www.spinics.net/lists/linux-mmc/msg48246.html, where >> it was decided adding utility in mmc-utils was not going to work ( reason: >> We may very well be changing the bit offsets for the caps and caps2 in the >> mmc kernel header, keeping a copy of them is not a good idea. It's just a >> matter of *when* it will break). > I recall. However, I didn't realize all these strings were going to be > needed. :-) > >> On Thu, 2018-03-15 at 11:12 +0100, Ulf Hansson wrote: >>> If were to decide, I would just rather print the caps field in a >>> hexadecimal bit form and leave the translation to the user. >> I think translation becomes difficult for the above reason and hence I would >> prefer printing the description. > Okay. > >> Note: Printing values in Hex was the original idea and it is also available >> in https://www.spinics.net/lists/linux-mmc/msg48213.html just in case if it >> is required. > Yeah, so maybe I should apply that one, then we can take it from there!? Fine with both the approach. Please consider this. Thanks, Harish Jenny K N
Re: [PATCH v1 1/1] dmaengine: stm32-dmamux: fix a potential buffer overflow
On Tue, Mar 13, 2018 at 05:55:35PM +0100, Pierre-Yves MORDRET wrote: > The bitfield dma_inuse is allocated of size dma_requests bits, thus a > valid bit address is from 0 to (dma_requests - 1). > When find_first_zero_bit() fails, it returns dma_requests as invalid > address. > Using such address for the following set_bit() is incorrect and, if > dma_requests is a multiple of BITS_PER_LONG, it will cause a buffer > overflow. > Currently this driver is only used in DT stm32h743.dtsi where a safe value > dma_requests=16 is not triggering the buffer overflow. > > Fixed by checking the return value of find_first_zero_bit() _before_ > using it. Applied, thanks -- ~Vinod
Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed
On 3/21/18 10:12 PM, Srivatsa S. Bhat wrote: > On 3/21/18 7:02 PM, Steve French wrote: >> Found a patch which solves the dependency issue. In my testing (on >> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this >> appears to fix the problem, but I will let Srivatsa confirm that it >> also fixes it for him. The two attached patches for 4.9 should work. >> > > Indeed, those two patches fix the problem for me on 4.9. Thanks a lot > Steve, Pavel and Aurelien for all your efforts in fixing this! > > I was also interested in getting this fixed on 4.4, so I modified the > patches to apply on 4.4.88 and verified that they fix the mount I meant to say 4.4.122 there (the latest stable 4.4 version at the moment). Regards, Srivatsa VMware Photon OS
Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed
On 3/21/18 7:02 PM, Steve French wrote:
> Found a patch which solves the dependency issue. In my testing (on
> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this
> appears to fix the problem, but I will let Srivatsa confirm that it
> also fixes it for him. The two attached patches for 4.9 should work.
>
Indeed, those two patches fix the problem for me on 4.9. Thanks a lot
Steve, Pavel and Aurelien for all your efforts in fixing this!
I was also interested in getting this fixed on 4.4, so I modified the
patches to apply on 4.4.88 and verified that they fix the mount
failure. I have attached my patches for 4.4 with this mail.
Steve, Pavel, could you kindly double-check the second patch for 4.4,
especially around the keygen_exit error path?
Thank you very much!
Regards,
Srivatsa
VMware Photon OS
From a01a7dfb60e2d5421a487a7b81fd8a1bf72d96d4 Mon Sep 17 00:00:00 2001
From: Steve French
Date: Sun, 11 Mar 2018 20:00:27 -0700
Subject: [PATCH 1/2] SMB3: Validate negotiate request must always be signed
commit 4587eee04e2ac7ac3ac9fa2bc164fb6e548f99cd upstream.
According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned
See kernel bugzilla bug 197311
[ Fixed up for kernel version 4.4 ]
CC: Stable
Acked-by: Ronnie Sahlberg
Signed-off-by: Steve French
Signed-off-by: Srivatsa S. Bhat
---
fs/cifs/smb2pdu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 84614a5..6dae5b8 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1558,6 +1558,9 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon
*tcon, u64 persistent_fid,
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;
+ /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */
+ if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+ req->hdr.Flags |= SMB2_FLAGS_SIGNED;
rc = SendReceive2(xid, ses, iov, num_iovecs, &resp_buftype, 0);
rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
--
2.7.4
From d0178d8f096b29a88914787274bdc8ee8334ab07 Mon Sep 17 00:00:00 2001
From: Pavel Shilovsky
Date: Mon, 7 Nov 2016 18:20:50 -0800
Subject: [PATCH 2/2] CIFS: Enable encryption during session setup phase
commit cabfb3680f78981d26c078a26e5c748531257ebb upstream.
In order to allow encryption on SMB connection we need to exchange
a session key and generate encryption and decryption keys.
[ Fixed up for kernel version 4.4 ]
Signed-off-by: Pavel Shilovsky
Signed-off-by: Srivatsa S. Bhat
---
fs/cifs/sess.c| 22 ++
fs/cifs/smb2pdu.c | 8 +---
2 files changed, 11 insertions(+), 19 deletions(-)
diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index e88ffe1..a035d1a 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -344,13 +344,12 @@ void build_ntlmssp_negotiate_blob(unsigned char *pbuffer,
/* BB is NTLMV2 session security format easier to use here? */
flags = NTLMSSP_NEGOTIATE_56 | NTLMSSP_REQUEST_TARGET |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
- ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
sec_blob->NegotiateFlags = cpu_to_le32(flags);
@@ -407,13 +406,12 @@ int build_ntlmssp_auth_blob(unsigned char **pbuffer,
flags = NTLMSSP_NEGOTIATE_56 |
NTLMSSP_REQUEST_TARGET | NTLMSSP_NEGOTIATE_TARGET_INFO |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
- ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
tmp = *pbuffer + sizeof(AUTHENTICATE_MESSAGE);
sec_blob->NegotiateFlags = cpu_to_le32(flags);
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 6dae5b8..33b1bc2 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -832,10 +832,8 @@ ssetup_exit:
if (!rc) {
mutex_l
Re: [RFC PATCH 4/6] sched/fair: Introduce an energy estimation helper function
On Wednesday 21 Mar 2018 at 15:54:58 (+), Patrick Bellasi wrote: > On 21-Mar 14:26, Quentin Perret wrote: > > On Wednesday 21 Mar 2018 at 12:39:21 (+), Patrick Bellasi wrote: > > > On 20-Mar 09:43, Dietmar Eggemann wrote: > > > > From: Quentin Perret [...] > > So actually, what I can do is add something like > > > > fdom_tot_util += util; > > > > to this loop and compute > > > > energy = cs->power * fdom_tot_util / cs->cap; > > > > only once, instead of having the second loop to compute the energy. We don't > > have to scale the util for each and every CPU since they share the same > > cap state. That would save some divisions and ensure the consistency > > between the selection of the cap state and the associated energy > > computation. What do you think ? > > Right, would say that under the hypothesis the we are in the same > frequency domain (and we are because of fdom->span), that's basically > doing: > >sum_i(P_x * U_i / C_x) => P_x / C_x * sum_i(U_i) > > Where (C_x, P_x) are the EM reported capacity and power for the > expected frequency domain OPP. > Yes that's exactly that. I'll do the change in v2. > > Or maybe you were talking about consistency between several consecutive > > calls to compute_energy() ? > > Nope, the above +1 > [...] > > I agree that it would be nice to document somewhere that > > compute_energy() is unsafe to call without sched_energy_present. > > I can simply add a proper doc comment to this function actually. > > Would that work ? > > Right, it's just that _maybe_ an explicit BUG_ON is improving the > documentation by making more explicit the error on testing ? > > Thus, I would probably add both... but Peter will tell you for sure ;) > Right, but I'm still not sure if the BUG_ON is the right thing to do. I mean, if we really want to make this check, then we could also try to recover into a working state ... If we enter compute_energy() without having an energy model, and if we detect it on time, we could bail out and disable sched_energy_present ASAP with an error message for example. That would let us know if EAS is broken without making the system unusable. Anyways, if there is a general agreement, or if the maintainers think that the BUG_ON is the right thing to do here, I'm happy to change that in future versions :)
Re: [PATCH RFC] xfs, memcg: Call xfs_fs_nr_cached_objects() only in case of global reclaim
On Wed, Mar 21, 2018 at 07:15:14PM +0300, Kirill Tkhai wrote: > On 20.03.2018 17:34, Dave Chinner wrote: > > On Tue, Mar 20, 2018 at 04:15:16PM +0300, Kirill Tkhai wrote: > >> On 20.03.2018 03:18, Dave Chinner wrote: > >>> On Mon, Mar 19, 2018 at 02:06:01PM +0300, Kirill Tkhai wrote: > On 17.03.2018 00:39, Dave Chinner wrote: > >>> Actually, it is fair, because: > >>> > >>> /* proportion the scan between the caches */ > >>> dentries = mult_frac(sc->nr_to_scan, dentries, total_objects); > >>> inodes = mult_frac(sc->nr_to_scan, inodes, total_objects); > >>> fs_objects = mult_frac(sc->nr_to_scan, fs_objects, total_objects); > >>> > >>> This means that if the number of objects in the memcg aware VFS > >>> caches are tiny compared to the global XFS inode cache, then they > >>> only get a tiny amount of the total scanning done by the shrinker. > >> > >> This is just wrong. If you have two memcgs, the first is charged > >> by xfs dentries and inodes, while the second is not charged by xfs > >> dentries and inodes, the second will response for xfs shrink as well > >> as the first. > > > > That makes no sense to me. Shrinkers are per-sb, so they only > > shrink per-filesystem dentries and inodes. If your memcgs are on > > different filesystems, then they'll behave according to the size of > > that filesystem's caches, not the cache of some other filesystem. > > But this break the isolation purpose of memcg. When someone places > different services in different pairs of memcg and cpu cgroup, he > wants do not do foreign work. Too bad. Filesystems *break memcg isolation all the time*. Think about it. The filesystem journal is owned by the filesystem, not the memcg that is writing a transaction to it. If one memcg does lots of metadata modifications, it can use all the journal space and starve iitself and all other memcgs of journal space while the filesystem does writeback to clear it out. Another example: if one memcg is manipulating free space in a particular allocation group, other memcgs that need to manipulate space in those allocation groups will block and be prevented from operating until the other memcg finishes it's work. Another example: inode IO in XFS are done in clusters of 32. read or write any inode in the cluster, and we read/write all the other inodes in that cluster, too. Hence if we need to read an inode and the cluster is busy because the filesystem journal needed flushing or another inode in the cluster is being unlinked (e.g. by a process in a different memcg), then the read in the first memcg will block until whatever is being done on the buffer is complete. IOWs, even at the physical on-disk inode level we violate memcg resource isolation principles. I can go on, but I think you get the picture: Filesystems are full of global structures whose access arbitration mechanisms fundamentally break the concept of operational memcg isolation. With that in mind, we really don't care that the shrinker does global work and violate memcg isolation principles because we violately them everywhere. IOWs, if we try to enforce memcg isolation in the shrinker, then we can't guarantee forwards progress in memory reclaim because we end up with multi-dimensional memcg dependencies at the physical layers of the filesystem structure I don't expect people who know nothing about XFS or filesystems to understand the complexity of the interactions we are dealing with here. Everything is a compromise when it comes to the memory reclaim code as tehre are so many corner cases we have to handle. In this situation, perfect is the enemy of good Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] arm64: avoid race condition issue in dump_backtrace
Hi Ji Zhang,
On Thu, Mar 22, 2018 at 11:06:00AM +0800, Ji Zhang wrote:
> When we dump the backtrace of some specific task, there is a potential race
> condition due to the task may be running on other cores if SMP enabled.
> That is because for current implementation, if the task is not the current
> task, we will get the registers used for unwind from cpu_context saved in
> thread_info, which is the snapshot before context switch, but if the task
> is running on other cores, the registers and the content of stack are
> changed.
> This may cause that we get the wrong backtrace or incomplete backtrace or
> even crash the kernel.
> To avoid this case, do not dump the backtrace of the tasks which are
> running on other cores.
> This patch cannot solve the issue completely but can shrink the window of
> race condition.
>
> Signed-off-by: Ji Zhang
> ---
> arch/arm64/kernel/traps.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index eb2d151..95749364 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -113,6 +113,9 @@ void dump_backtrace(struct pt_regs *regs, struct
> task_struct *tsk)
> if (tsk == current) {
> frame.fp = (unsigned long)__builtin_frame_address(0);
> frame.pc = (unsigned long)dump_backtrace;
> + else if (tsk->state == TASK_RUNNING) {
Missing closing brace. Does this build?
> + pr_notice("Do not dump other running tasks\n");
> + return;
> } else {
> /*
>* task blocked in __switch_to
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
[PATCH] vfio iommu type1: improve memory pinning process for raw PFN mapping
When using vfio to pass through a PCIe device (e.g. a GPU card) that
has a huge BAR (e.g. 16GB), a lot of cycles are wasted on memory
pinning because PFNs of PCI BAR are not backed by struct page, and
the corresponding VMA has flag VM_PFNMAP.
With this change, when pinning a region which is a raw PFN mapping,
it can skip unnecessary user memory pinning process, and thus, can
significantly improve VM's boot up time when passing through devices
via VFIO. In my test on a Xeon E5 2.6GHz, the time mapping a 16GB
BAR was reduced from about 0.4s to 1.5us.
Signed-off-by: Jason Cai (Xiang Feng)
---
drivers/vfio/vfio_iommu_type1.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 45657e2b1ff7..0658f35318b8 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -397,7 +397,6 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma,
unsigned long vaddr,
{
unsigned long pfn = 0;
long ret, pinned = 0, lock_acct = 0;
- bool rsvd;
dma_addr_t iova = vaddr - dma->vaddr + dma->iova;
/* This code path is only user initiated */
@@ -408,14 +407,22 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma,
unsigned long vaddr,
if (ret)
return ret;
+ if (is_invalid_reserved_pfn(*pfn_base)) {
+ struct vm_area_struct *vma;
+ down_read(¤t->mm->mmap_sem);
+ vma = find_vma_intersection(current->mm, vaddr, vaddr + 1);
+ pinned = min(npage, (long)vma_pages(vma));
+ up_read(¤t->mm->mmap_sem);
+ return pinned;
+ }
+
pinned++;
- rsvd = is_invalid_reserved_pfn(*pfn_base);
/*
* Reserved pages aren't counted against the user, externally pinned
* pages are already counted against the user.
*/
- if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+ if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap && current->mm->locked_vm + 1 > limit) {
put_pfn(*pfn_base, dma->prot);
pr_warn("%s: RLIMIT_MEMLOCK (%ld) exceeded\n", __func__,
@@ -435,13 +442,12 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma,
unsigned long vaddr,
if (ret)
break;
- if (pfn != *pfn_base + pinned ||
- rsvd != is_invalid_reserved_pfn(pfn)) {
+ if (pfn != *pfn_base + pinned) {
put_pfn(pfn, dma->prot);
break;
}
- if (!rsvd && !vfio_find_vpfn(dma, iova)) {
+ if (!vfio_find_vpfn(dma, iova)) {
if (!lock_cap &&
current->mm->locked_vm + lock_acct + 1 > limit) {
put_pfn(pfn, dma->prot);
@@ -459,10 +465,8 @@ static long vfio_pin_pages_remote(struct vfio_dma *dma,
unsigned long vaddr,
unpin_out:
if (ret) {
- if (!rsvd) {
- for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
- put_pfn(pfn, dma->prot);
- }
+ for (pfn = *pfn_base ; pinned ; pfn++, pinned--)
+ put_pfn(pfn, dma->prot);
return ret;
}
--
2.13.6
[PATCH] nfit: skip region registration for incomplete control regions
Per the ACPI specification the only functional purpose for a DIMM
Control Region to be mapped into the system physical address space, from
an OSPM perspective, is to support block-apertures. However, there are
some BIOSen that publish DIMM Control Region SPA entries for pre-boot
environment consumption. Undo the kernel policy of generating disabled
'ndblk' regions when this configuration is detected.
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index 39ad06143e78..4530d89044db 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -2578,7 +2578,7 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc
*acpi_desc,
struct acpi_nfit_system_address *spa = nfit_spa->spa;
struct nd_blk_region_desc *ndbr_desc;
struct nfit_mem *nfit_mem;
- int blk_valid = 0, rc;
+ int rc;
if (!nvdimm) {
dev_err(acpi_desc->dev, "spa%d dimm: %#x not found\n",
@@ -2598,15 +2598,14 @@ static int acpi_nfit_init_mapping(struct acpi_nfit_desc
*acpi_desc,
if (!nfit_mem || !nfit_mem->bdw) {
dev_dbg(acpi_desc->dev, "spa%d %s missing bdw\n",
spa->range_index, nvdimm_name(nvdimm));
- } else {
- mapping->size = nfit_mem->bdw->capacity;
- mapping->start = nfit_mem->bdw->start_address;
- ndr_desc->num_lanes = nfit_mem->bdw->windows;
- blk_valid = 1;
+ break;
}
+ mapping->size = nfit_mem->bdw->capacity;
+ mapping->start = nfit_mem->bdw->start_address;
+ ndr_desc->num_lanes = nfit_mem->bdw->windows;
ndr_desc->mapping = mapping;
- ndr_desc->num_mappings = blk_valid;
+ ndr_desc->num_mappings = 1;
ndbr_desc = to_blk_region_desc(ndr_desc);
ndbr_desc->enable = acpi_nfit_blk_region_enable;
ndbr_desc->do_io = acpi_desc->blk_do_io;
Re: [PATCH v4 23/24] fpga: dfl: afu: add user afu sub feature support
On Wed, Mar 21, 2018 at 06:50:54PM -0500, Alan Tull wrote:
> On Tue, Mar 20, 2018 at 2:10 AM, Wu Hao wrote:
>
> >> > +static int afu_mmap(struct file *filp, struct vm_area_struct *vma)
> >> > +{
> >> > + struct fpga_afu_region region;
> >> > + struct platform_device *pdev = filp->private_data;
> >> > + struct feature_platform_data *pdata =
> >> > dev_get_platdata(&pdev->dev);
> >> > + u64 size = vma->vm_end - vma->vm_start;
> >> > + u64 offset;
> >> > + int ret;
> >> > +
> >> > + if (!(vma->vm_flags & VM_SHARED))
> >> > + return -EINVAL;
> >> > +
> >> > + offset = vma->vm_pgoff << PAGE_SHIFT;
> >> > + ret = afu_get_region_by_offset(pdata, offset, size, ®ion);
>
> Most of the functions here are afu_region_*, but there's also
> afu_get_region_by_*. Better if afu_region_get_by_* to be consistent.
Agree, will fix it in the next version, thanks a lot for the comments.
Hao
Re: [PATCH v4 04/24] fpga: add device feature list support
On Wed, Mar 21, 2018 at 06:54:58PM -0500, Alan Tull wrote:
> On Tue, Feb 13, 2018 at 3:24 AM, Wu Hao wrote:
>
> Hi Hao,
>
> > +static int
> > +build_info_create_dev(struct build_feature_devs_info *binfo,
> > + enum fpga_id_type type, const char *name,
> > + void __iomem *ioaddr)
> > +{
> > + struct platform_device *fdev;
> > + int ret;
> > +
> > + /* we will create a new device, commit current device first */
> > + ret = build_info_commit_dev(binfo);
> > + if (ret)
> > + return ret;
> > +
> > + /*
> > +* we use -ENODEV as the initialization indicator which indicates
> > +* whether the id need to be reclaimed
> > +*/
> > + fdev = platform_device_alloc(name, -ENODEV);
> > + if (!fdev)
> > + return -ENOMEM;
> > +
> > + binfo->feature_dev = fdev;
> > + binfo->feature_num = 0;
> > + binfo->ioaddr = ioaddr;
> > + INIT_LIST_HEAD(&binfo->sub_features);
> > +
> > + fdev->id = alloc_fpga_id(type, &fdev->dev);
> > + if (fdev->id < 0)
> > + return fdev->id;
>
> Do we need platform_device_put if returning here?
Hi Alan,
Actually if any error returned by this build_info_create_dev, it will cause
parse_feature_list returns error code and finally build_info_free is invoked.
In build_info_free function, it will do platform_device_put there, so we don't
have to add code to do put here. : )
Thanks
Hao
>
> Alan
>
> > +
> > + fdev->dev.parent = &binfo->cdev->region.dev;
> > +
> > + return 0;
> > +}
> > +
Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses
On Thu, 2018-03-22 at 13:37 +0900, y.k.oh wrote: > > On 03/14/2018 10:58 PM, Greg KH wrote: > > On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote: > > > Cleanup checkpatch error: > > > ERROR: Macros with complex values should be enclosed in parentheses > > > > > > Signed-off-by: YOUNGKEUN OH > > > --- > > > drivers/tty/serial/samsung.c | 16 > > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > > > diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c > > > index 3f2f8c1..da9bddb1 100644 > > > --- a/drivers/tty/serial/samsung.c > > > +++ b/drivers/tty/serial/samsung.c > > > @@ -1455,7 +1455,7 @@ static int __init s3c24xx_serial_console_init(void) > > > } > > > console_initcall(s3c24xx_serial_console_init); > > > > > > -#define S3C24XX_SERIAL_CONSOLE &s3c24xx_serial_console > > > +#define S3C24XX_SERIAL_CONSOLE (&s3c24xx_serial_console) > > > > That's not a complex macro! > > > > Please use checkpatch as a hint, not the "truth". > > > > thanks, > > > > greg k-h > > > > Dear Greg. > > Yes! Of course that's not a pretty complex macro. However, I think it is > important to make a small effort to modify the minimum standard, > Checkpatch ERROR, to ensure consistency in the Linux code. > Starting with this Checkpatch error of samsung.c, I would like to start > my efforts on contribution from a small point. Please review it again. > If there are any points that require modification, such as comment, > then I'll modify it. It might be better to remove the #defines and use an #ifdef in the one place S2C24XX_SERIAL_CONSOLE is referenced instead.
Re: [PATCH 0/7] HID core and multitouch fixups
On Tue, Mar 20, 2018 at 12:04:44PM +0100, Benjamin Tissoires wrote: > Hi, > > Patches 1 and 2 are related to the Razer Blade Stealth that has some dead zone > near the edges of the touchpad. > Patches 3 was previously sent and reviewed by Dmitry and he suggested patch 4 > at the time. > Patches 5..7 are cleanups I realized while trying to merge hid-multitouch > into hid-core, so that other drivers could reuse the hid-mt logic (but it's > not that easy I must confess). Series: Acked-by: Peter Hutterer Cheers, Peter > > Cheers, > Benjamin > > Benjamin Tissoires (7): > HID: multitouch: export a quirk for the button handling of touchpads > HID: multitouch: remove dead zones of Razer Blade Stealth > HID: use BIT macro instead of plain integers for flags > HID: use BIT() macro for quirks too > HID: core: remove the need for HID_QUIRK_NO_EMPTY_INPUT > HID: multitouch: do not set HID_QUIRK_NO_INIT_REPORTS > HID: core: reset the quirks before calling probe again > > drivers/hid/hid-asus.c | 3 +- > drivers/hid/hid-core.c | 2 ++ > drivers/hid/hid-input.c | 10 +++ > drivers/hid/hid-multitouch.c | 61 - > drivers/hid/hid-uclogic.c| 1 - > include/linux/hid.h | 65 > ++-- > 6 files changed, 65 insertions(+), 77 deletions(-) > > -- > 2.14.3 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: [PATCH] serial: samsung: macros with complex values should be enclosed in parentheses
On 03/14/2018 10:58 PM, Greg KH wrote: > On Wed, Mar 14, 2018 at 11:17:05AM +0900, YOUNGKEUN OH wrote: >> Cleanup checkpatch error: >> ERROR: Macros with complex values should be enclosed in parentheses >> >> Signed-off-by: YOUNGKEUN OH >> --- >> drivers/tty/serial/samsung.c | 16 >> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c >> index 3f2f8c1..da9bddb1 100644 >> --- a/drivers/tty/serial/samsung.c >> +++ b/drivers/tty/serial/samsung.c >> @@ -1455,7 +1455,7 @@ static int __init s3c24xx_serial_console_init(void) >> } >> console_initcall(s3c24xx_serial_console_init); >> >> -#define S3C24XX_SERIAL_CONSOLE &s3c24xx_serial_console >> +#define S3C24XX_SERIAL_CONSOLE (&s3c24xx_serial_console) > > That's not a complex macro! > > Please use checkpatch as a hint, not the "truth". > > thanks, > > greg k-h > Dear Greg. Yes! Of course that's not a pretty complex macro. However, I think it is important to make a small effort to modify the minimum standard, Checkpatch ERROR, to ensure consistency in the Linux code. Starting with this Checkpatch error of samsung.c, I would like to start my efforts on contribution from a small point. Please review it again. If there are any points that require modification, such as comment, then I'll modify it. Thank you. Best regards, Youngkeun Oh
Re: [RESEND PATCH] crypto: Add zstd support
On (03/21/18 15:49), Nick Terrell wrote: > depends on CONFIG_CRYPTO_ZSTD, which isn't defined until this patch is in Yikes! How come I missed that... :) > [0] > lkml.kernel.org/r/9c9416b2dff19f05fb4c35879aaa83d11ff72c92.1521626182.git.geliangt...@gmail.com Signed-off-by: Nick Terrell ? -ss
Re: [PATCH 1/1] lz4: Implement lz4 with dynamic offset length.
CC: Vaneet Narang.
On (03/21/18 10:10), Maninder Singh wrote:
> diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c
> index cc7b6d4..185c358 100644
> --- a/lib/lz4/lz4_compress.c
> +++ b/lib/lz4/lz4_compress.c
> @@ -183,7 +183,8 @@ static FORCE_INLINE int LZ4_compress_generic(
> const tableType_t tableType,
> const dict_directive dict,
> const dictIssue_directive dictIssue,
> -const U32 acceleration)
> +const U32 acceleration,
> +const Dynamic_Offset dynOffset)
> {
> const BYTE *ip = (const BYTE *) source;
> const BYTE *base;
> @@ -199,6 +200,7 @@ static FORCE_INLINE int LZ4_compress_generic(
>
> BYTE *op = (BYTE *) dest;
> BYTE * const olimit = op + maxOutputSize;
> +int max_distance = dynOffset ? MAX_DISTANCE_DYN : MAX_DISTANCE;
Lets mark this variable `const`. If the compiler doesn't realize that this
variable and `dynOffset` are compile time constants, I expect the speed to
be impacted.
>
> U32 forwardH;
> size_t refDelta = 0;
> @@ -245,6 +247,7 @@ static FORCE_INLINE int LZ4_compress_generic(
> for ( ; ; ) {
> const BYTE *match;
> BYTE *token;
> +int curr_offset;
>
> /* Find a match */
> {
> @@ -285,7 +288,7 @@ static FORCE_INLINE int LZ4_compress_generic(
> : 0)
> || ((tableType == byU16)
> ? 0
> -: (match + MAX_DISTANCE < ip))
> +: (match + max_distance < ip))
> || (LZ4_read32(match + refDelta)
> != LZ4_read32(ip)));
> }
> @@ -328,8 +331,26 @@ static FORCE_INLINE int LZ4_compress_generic(
>
> _next_match:
> /* Encode Offset */
> -LZ4_writeLE16(op, (U16)(ip - match));
> -op += 2;
> +if (dynOffset) {
> +curr_offset = (U16)(ip - match);
> +
> +/*
> + * If Ofsset is greater than 127, we need 2 bytes
> + * to store it. Otherwise 1 byte is enough.
> + */
> +if (curr_offset > 127) {
> +curr_offset = (curr_offset << 1) | DYN_BIT;
> +LZ4_writeLE16(op, (U16)curr_offset);
> +op += 2;
> +} else {
> +curr_offset = curr_offset << 1;
> +*op = (BYTE)curr_offset;
> +op++;
> +}
The standard way to do variable sized integers is to use the high-bit as
the control bit, not the low-bit. Do you have benchmarks to show that using
the low-bit is faster than using the high-bit? If so, lets comment in the
code, if not lets use the high-bit.
> +} else {
> +LZ4_writeLE16(op, (U16)(ip - match));
> +op += 2;
> +}
>
> /* Encode MatchLength */
> {
> @@ -480,39 +501,70 @@ static int LZ4_compress_fast_extState(
> return LZ4_compress_generic(ctx, source,
> dest, inputSize, 0,
> noLimit, byU16, noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
> else
> return LZ4_compress_generic(ctx, source,
> dest, inputSize, 0,
> noLimit, tableType, noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
> } else {
> if (inputSize < LZ4_64Klimit)
> return LZ4_compress_generic(ctx, source,
> dest, inputSize,
> maxOutputSize, limitedOutput, byU16, noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
> else
> return LZ4_compress_generic(ctx, source,
> dest, inputSize,
> maxOutputSize, limitedOutput, tableType,
>noDict,
> -noDictIssue, acceleration);
> +noDictIssue, acceleration, NoDynOffset);
> }
> }
>
> +static int LZ4_compress_fast_extState_dynamic(
> +void *state,
> +const char *source,
> +char *dest,
>
RE: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add documentation for controller and driver
Hi Randy, Thanks for reviewing the patch. I will address below mentioned comments in next version of patch. Thanks, Naga Sureshkumar Relli. > -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Thursday, March 15, 2018 5:27 AM > To: nagasureshkumarre...@gmail.com; boris.brezil...@bootlin.com; > rich...@nod.at; dw...@infradead.org; computersforpe...@gmail.com; > marek.va...@gmail.com; cyrille.pitc...@wedev4u.fr; > miquel.ray...@bootlin.com > Cc: linux-...@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek > ; Punnaiah Choudary Kalluri ; Naga > Sureshkumar Relli > Subject: Re: [LINUX PATCH v8 1/2] Documentation: nand: pl353: Add > documentation for controller and driver > > On 03/14/2018 03:48 AM, nagasureshkumarre...@gmail.com wrote: > > From: Naga Sureshkumar Relli > > > > Added notes about the controller and driver > > > > Signed-off-by: Naga Sureshkumar Relli > > --- > > Hi, > > > --- > > Documentation/mtd/nand/pl353-nand.txt | 92 > > +++ > > 1 file changed, 92 insertions(+) > > create mode 100644 Documentation/mtd/nand/pl353-nand.txt > > > > diff --git a/Documentation/mtd/nand/pl353-nand.txt > > b/Documentation/mtd/nand/pl353-nand.txt > > new file mode 100644 > > index 000..ac6fbd5 > > --- /dev/null > > +++ b/Documentation/mtd/nand/pl353-nand.txt > > @@ -0,0 +1,92 @@ > > +This documents provides some notes about the ARM pl353 smc controller > > +used in > > s/smc/SMC/ > > > +Zynq SOC and confined to NAND specific details. > > + > > +Overview of the controller > > +== > > + The SMC (PL353) supports two memory interfaces: > > + Interface 0 type SRAM. > > + Interface 1 type NAND. > > + This configuration supports the following configurable options: > > + . 32-bit or 64-bit AXI data width > > + . 8-bit, 16-bit, or 32-bit memory data width for interface 0 > > + . 8-bit, or 16-bit memory data width for interface 1 > > + . 1-4 chip selects on each interface > > + . SLC ECC block for interface 1 > > + > > +For more information, refer the below link for TRM > > +http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/ > > +DDI0380G_smc_pl350_series_r2p1_trm.pdf > > + > > +NAND memory accesses > > + > > + . Two phase NAND accesses > > + . NAND command phase transfers > > + . NAND data phase transfers > > + > > +Two phase NAND accesses > > + The SMC defines two phases of commands when transferring data to or > > +from NAND flash. > > + > > +Command phase > > + Commands and optional address information are written to the NAND > flash. > > +The command and address can be associated with either a data phase > > +operation to write to or read from the array, or a status/ID register > > transfer. > > + > > +Data phase > > + Data is either written to or read from the NAND flash. This data can > > +be either data transferred to or from the array, or status/ID register > information. > > + > > +NAND AXI address setup > > + AXI address Command phase Data phase > > + [31:24] Chip address Chip address > > + [23]NoOfAddCycles_2Reserved > > + [22]NoOfAddCycles_1Reserved > > + [21]NoOfAddCycles_0ClearCS > > + [20]End command valid End command valid > > + [19]0 1 > > + [18:11] End commandEnd command > > + [10:3] Start command [10] ECC Last > > + [9:3] Reserved > > + [2:0] Reserved Reserved > > + > > +ECC > > +=== > > +It operates on a number of 512 byte blocks of NAND memory and can > > +be programmed to store the ECC codes after the data in memory. For > > +writes, the ECC is written to the spare area of the page. For reads, > > +the result of a block ECC check are made available to the device driver. > > + > > +- > > +--- > > +| n * 512 blocks | extra | ecc| | > > +| | block | codes | | > > +- > > +--- > > + > > +The ECC calculation uses a simple Hamming code, using 1-bit > > +correction 2-bit detection. It starts when a valid read or write > > +command with a 512 byte aligned address is detected on the memory > interface. > > + > > +Driver details > > +== > > + The NAND driver has dependency with the pl353_smc memory > controller > > +driver for intializing the nand timing parameters, bus width, ECC > > +modes, > > initializing the NAND > > > +control and status information. > > + > > +Since the controller expects that the chipselect bit should be > > +cleared for the last data transfer i.e last 4 data bytes, the > > +existing nandbase page read/write routines f
Re: [PATCH v5 4/5] typec: tcpm: Represent source supply through power_supply
On 03/20/2018 07:33 AM, Adam Thomson wrote:
This commit adds a power_supply class instance to represent a
PD source's voltage and current properties. This provides an
interface for reading these properties from user-space or other
drivers.
For PPS enabled Sources, this also provides write access to set
the current and voltage and allows for swapping between standard
PDO and PPS APDO.
As this represents a superset of the information provided in the
fusb302 driver, the power_supply instance in that code is removed
as part of this change, so reverting the commit titled
'typec: tcpm: Represent source supply through power_supply class'
Signed-off-by: Adam Thomson
---
drivers/usb/typec/Kconfig | 1 +
drivers/usb/typec/fusb302/Kconfig | 2 +-
drivers/usb/typec/fusb302/fusb302.c | 63 +-
drivers/usb/typec/tcpm.c| 242 +++-
4 files changed, 245 insertions(+), 63 deletions(-)
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744..1ef606d 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -48,6 +48,7 @@ if TYPEC
config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
+ select POWER_SUPPLY
help
The Type-C Port Controller Manager provides a USB PD and USB Type-C
state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/Kconfig
b/drivers/usb/typec/fusb302/Kconfig
index 48a4f2f..fce099f 100644
--- a/drivers/usb/typec/fusb302/Kconfig
+++ b/drivers/usb/typec/fusb302/Kconfig
@@ -1,6 +1,6 @@
config TYPEC_FUSB302
tristate "Fairchild FUSB302 Type-C chip driver"
- depends on I2C && POWER_SUPPLY
+ depends on I2C
help
The Fairchild FUSB302 Type-C chip driver that works with
Type-C Port Controller Manager to provide USB PD and USB
diff --git a/drivers/usb/typec/fusb302/fusb302.c
b/drivers/usb/typec/fusb302/fusb302.c
index 06794c0..6a8f279 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -99,11 +98,6 @@ struct fusb302_chip {
/* lock for sharing chip states */
struct mutex lock;
- /* psy + psy status */
- struct power_supply *psy;
- u32 current_limit;
- u32 supply_voltage;
-
/* chip status */
enum toggling_mode toggling_mode;
enum src_current_status src_current_status;
@@ -861,13 +855,11 @@ static int tcpm_set_vbus(struct tcpc_dev *dev, bool on,
bool charge)
chip->vbus_on = on;
fusb302_log(chip, "vbus := %s", on ? "On" : "Off");
}
- if (chip->charge_on == charge) {
+ if (chip->charge_on == charge)
fusb302_log(chip, "charge is already %s",
charge ? "On" : "Off");
- } else {
+ else
chip->charge_on = charge;
- power_supply_changed(chip->psy);
- }
done:
mutex_unlock(&chip->lock);
@@ -883,11 +875,6 @@ static int tcpm_set_current_limit(struct tcpc_dev *dev,
u32 max_ma, u32 mv)
fusb302_log(chip, "current limit: %d ma, %d mv (not implemented)",
max_ma, mv);
- chip->supply_voltage = mv;
- chip->current_limit = max_ma;
-
- power_supply_changed(chip->psy);
-
return 0;
}
@@ -1686,43 +1673,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int fusb302_psy_get_property(struct power_supply *psy,
- enum power_supply_property psp,
- union power_supply_propval *val)
-{
- struct fusb302_chip *chip = power_supply_get_drvdata(psy);
-
- switch (psp) {
- case POWER_SUPPLY_PROP_ONLINE:
- val->intval = chip->charge_on;
- break;
- case POWER_SUPPLY_PROP_VOLTAGE_NOW:
- val->intval = chip->supply_voltage * 1000; /* mV -> µV */
- break;
- case POWER_SUPPLY_PROP_CURRENT_MAX:
- val->intval = chip->current_limit * 1000; /* mA -> µA */
- break;
- default:
- return -ENODATA;
- }
-
- return 0;
-}
-
-static enum power_supply_property fusb302_psy_properties[] = {
- POWER_SUPPLY_PROP_ONLINE,
- POWER_SUPPLY_PROP_VOLTAGE_NOW,
- POWER_SUPPLY_PROP_CURRENT_MAX,
-};
-
-static const struct power_supply_desc fusb302_psy_desc = {
- .name = "fusb302-typec-source",
- .type = POWER_SUPPLY_TYPE_USB_TYPE_C,
- .properties = fusb302_psy_properties,
- .num_properties = ARRAY_SIZE(fusb302_psy_properties),
- .get_property = fusb302_psy_get_property,
-};
-
static int init_gpio(struct fusb302_chip *chip)
{
struct device_node *node;
@@
Re: [PATCH v5 3/5] power: supply: Add 'usb_type' property and supporting code
On 03/20/2018 07:33 AM, Adam Thomson wrote:
This commit adds the 'usb_type' property to represent USB supplies
which can report a number of different types based on a connection
event.
Examples of this already exist in drivers whereby the existing 'type'
property is updated, based on an event, to represent what was
connected (e.g. USB, USB_DCP, USB_ACA, ...). Current implementations
however don't show all supported connectable types, so this knowledge
has to be exlicitly known for each driver that supports this.
The 'usb_type' property is intended to fill this void and show users
all possible USB types supported by a driver. The property, when read,
shows all available types for the driver, and the one currently chosen
is highlighted/bracketed. It is expected that the 'type' property
would then just show the top-level type 'USB', and this would be
static.
Currently the 'usb_type' enum contains all of the USB variant types
that exist for the 'type' enum at this time, and in addition has
SDP and PPS types. The mirroring is intentional so as to not impact
existing usage of the 'type' property.
Signed-off-by: Adam Thomson
Acked-by: Heikki Krogerus
Reviewed-by: Sebastian Reichel
---
Documentation/ABI/testing/sysfs-class-power | 12 +++
drivers/power/supply/power_supply_sysfs.c | 50 +
include/linux/power_supply.h| 16 +
3 files changed, 78 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-power
b/Documentation/ABI/testing/sysfs-class-power
index e046566..5e23e22 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -409,6 +409,18 @@ Description:
Access: Read
Valid values: Represented in 1/10 Degrees Celsius
+What: /sys/class/power_supply//usb_type
+Date: March 2018
+Contact: linux...@vger.kernel.org
+Description:
+ Reports what type of USB connection is currently active for
+ the supply, for example it can show if USB-PD capable source
+ is attached.
+
+ Access: Read-Only
+ Valid values: "Unknown", "SDP", "DCP", "CDP", "ACA", "C", "PD",
+ "PD_DRP", "PD_PPS", "BrickID"
+
What: /sys/class/power_supply//voltage_max
Date: January 2008
Contact: linux...@vger.kernel.org
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index 5204f11..b68def4 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -46,6 +46,11 @@
"USB_PD", "USB_PD_DRP", "BrickID"
};
+static const char * const power_supply_usb_type_text[] = {
+ "Unknown", "SDP", "DCP", "CDP", "ACA", "C",
+ "PD", "PD_DRP", "PD_PPS", "BrickID"
+};
+
static const char * const power_supply_status_text[] = {
"Unknown", "Charging", "Discharging", "Not charging", "Full"
};
@@ -73,6 +78,46 @@
"Unknown", "System", "Device"
};
+static ssize_t power_supply_show_usb_type(struct device *dev,
+ enum power_supply_usb_type *usb_types,
+ ssize_t num_usb_types,
+ union power_supply_propval *value,
+ char *buf)
+{
+ enum power_supply_usb_type usb_type;
+ ssize_t count = 0;
+ bool match = false;
+ int i;
+
+ if ((!usb_types) || (num_usb_types <= 0)) {
Unnecessary ( )
+ dev_warn(dev, "driver has no valid connected types\n");
Are those warnings useful or do they just clog the log ? Either case, if that
happens,
wouldn't it be better to detect the situation during registration and abort ?
+ return -ENODATA;
+ }
+
+ for (i = 0; i < num_usb_types; ++i) {
+ usb_type = usb_types[i];
+
+ if (value->intval == usb_type) {
+ count += sprintf(buf + count, "[%s] ",
+power_supply_usb_type_text[usb_type]);
+ match = true;
+ } else {
+ count += sprintf(buf + count, "%s ",
+power_supply_usb_type_text[usb_type]);
+ }
+ }
+
+ if (!match) {
+ dev_warn(dev, "driver reporting unsupported connected type\n");
+ return -EINVAL;
+ }
+
+ if (count)
+ buf[count - 1] = '\n';
+
+ return count;
+}
+
static ssize_t power_supply_show_property(struct device *dev,
struct device_attribute *attr,
char *buf) {
@@ -115,6 +160,10 @@ static ssize_t power_supply_show_property(struct device
*dev,
else if (off == POWER_SUPPLY_PROP_TYPE)
return sp
Re: [PATCH v5 1/5] typec: tcpm: Add core support for sink side PPS
On 03/20/2018 07:33 AM, Adam Thomson wrote:
This commit adds code to handle requesting of PPS APDOs. Switching
between standard PDOs and APDOs, and re-requesting an APDO to
modify operating voltage/current will be triggered by an
external call into TCPM.
Signed-off-by: Adam Thomson
Acked-by: Heikki Krogerus
---
drivers/usb/typec/tcpm.c | 524 +--
include/linux/usb/pd.h | 4 +-
include/linux/usb/tcpm.h | 2 +-
3 files changed, 513 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 4c0fc54..b4cf1ca 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -47,6 +47,7 @@
S(SNK_DISCOVERY_DEBOUNCE_DONE), \
S(SNK_WAIT_CAPABILITIES), \
S(SNK_NEGOTIATE_CAPABILITIES), \
+ S(SNK_NEGOTIATE_PPS_CAPABILITIES), \
S(SNK_TRANSITION_SINK), \
S(SNK_TRANSITION_SINK_VBUS),\
S(SNK_READY), \
@@ -166,6 +167,16 @@ struct pd_mode_data {
struct typec_altmode_desc altmode_desc[SVID_DISCOVERY_MAX];
};
+struct pd_pps_data {
+ u32 min_volt;
+ u32 max_volt;
+ u32 max_curr;
+ u32 out_volt;
+ u32 op_curr;
+ bool supported;
+ bool active;
+};
+
struct tcpm_port {
struct device *dev;
@@ -233,6 +244,7 @@ struct tcpm_port {
struct completion swap_complete;
int swap_status;
+ unsigned int negotiated_rev;
unsigned int message_id;
unsigned int caps_count;
unsigned int hard_reset_count;
@@ -259,6 +271,7 @@ struct tcpm_port {
unsigned int max_snk_ma;
unsigned int max_snk_mw;
unsigned int operating_snk_mw;
+ bool update_sink_caps;
/* Requested current / voltage */
u32 current_limit;
@@ -275,8 +288,13 @@ struct tcpm_port {
/* VDO to retry if UFP responder replied busy */
u32 vdo_retry;
- /* Alternate mode data */
+ /* PPS */
+ struct pd_pps_data pps_data;
+ struct completion pps_complete;
+ bool pps_pending;
+ int pps_status;
+ /* Alternate mode data */
struct pd_mode_data mode_data;
struct typec_altmode *partner_altmode[SVID_DISCOVERY_MAX];
struct typec_altmode *port_altmode[SVID_DISCOVERY_MAX];
@@ -494,6 +512,16 @@ static void tcpm_log_source_caps(struct tcpm_port *port)
pdo_max_voltage(pdo),
pdo_max_power(pdo));
break;
+ case PDO_TYPE_APDO:
+ if (pdo_apdo_type(pdo) == APDO_TYPE_PPS)
+ scnprintf(msg, sizeof(msg),
+ "%u-%u mV, %u mA",
+ pdo_pps_apdo_min_voltage(pdo),
+ pdo_pps_apdo_max_voltage(pdo),
+ pdo_pps_apdo_max_current(pdo));
+ else
+ strcpy(msg, "undefined APDO");
+ break;
default:
strcpy(msg, "undefined");
break;
@@ -777,11 +805,13 @@ static int tcpm_pd_send_source_caps(struct tcpm_port
*port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
port->pwr_role,
port->data_role,
+ port->negotiated_rev,
port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SOURCE_CAP,
port->pwr_role,
port->data_role,
+ port->negotiated_rev,
port->message_id,
port->nr_src_pdo);
}
@@ -802,11 +832,13 @@ static int tcpm_pd_send_sink_caps(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_CTRL_REJECT,
port->pwr_role,
port->data_role,
+ port->negotiated_rev,
port->message_id, 0);
} else {
msg.header = PD_HEADER_LE(PD_DATA_SINK_CAP,
port->pwr_role,
port->data_role,
+ port->negotiated_rev,
port->message_id,
port->nr_snk_pdo);
}
@@ -1173,6 +1205,7 @@ static void vdm_run_state_machine(struct tcpm_port *port)
msg.header = PD_HEADER_LE(PD_DATA_VENDOR_DEF,
Re: [PATCH v5 5/5] typec: tcpm: Add support for sink PPS related messages
On 03/20/2018 07:33 AM, Adam Thomson wrote:
This commit adds sink side support for Get_Status, Status,
Get_PPS_Status and PPS_Status handling. As there's the
potential for a partner to respond with Not_Supported,
handling of this message is also added. Sending of
Not_Supported is added to handle messagescreceived but not
yet handled.
Signed-off-by: Adam Thomson
Acked-by: Heikki Krogerus
---
drivers/usb/typec/tcpm.c | 152 ---
1 file changed, 143 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 18ab36f..148db99 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -19,7 +19,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -113,6 +115,11 @@
S(SNK_TRYWAIT_VBUS),\
S(BIST_RX), \
\
+ S(GET_STATUS_SEND), \
+ S(GET_STATUS_SEND_TIMEOUT), \
+ S(GET_PPS_STATUS_SEND), \
+ S(GET_PPS_STATUS_SEND_TIMEOUT), \
+ \
S(ERROR_RECOVERY), \
S(PORT_RESET), \
S(PORT_RESET_WAIT_OFF)
@@ -143,6 +150,7 @@ enum pd_msg_request {
PD_MSG_NONE = 0,
PD_MSG_CTRL_REJECT,
PD_MSG_CTRL_WAIT,
+ PD_MSG_CTRL_NOT_SUPP,
PD_MSG_DATA_SINK_CAP,
PD_MSG_DATA_SOURCE_CAP,
};
@@ -1398,10 +1406,42 @@ static int tcpm_validate_caps(struct tcpm_port *port,
const u32 *pdo,
/*
* PD (data, control) command handling functions
*/
+static inline enum tcpm_state ready_state(struct tcpm_port *port)
+{
+ if (port->pwr_role == TYPEC_SOURCE)
+ return SRC_READY;
+ else
+ return SNK_READY;
+}
static int tcpm_pd_send_control(struct tcpm_port *port,
enum pd_ctrl_msg_type type);
+static void tcpm_handle_alert(struct tcpm_port *port, const __le32 *payload,
+ int cnt)
+{
+ u32 p0 = le32_to_cpu(payload[0]);
+ unsigned int type = usb_pd_ado_type(p0);
+
+ if (!type) {
+ tcpm_log(port, "Alert message received with no type");
+ return;
+ }
+
+ /* Just handling non-battery alerts for now */
+ if (!(type & USB_PD_ADO_TYPE_BATT_STATUS_CHANGE)) {
+ switch (port->state) {
+ case SRC_READY:
+ case SNK_READY:
+ tcpm_set_state(port, GET_STATUS_SEND, 0);
+ break;
+ default:
+ tcpm_queue_message(port, PD_MSG_CTRL_WAIT);
+ break;
+ }
+ }
+}
+
static void tcpm_pd_data_request(struct tcpm_port *port,
const struct pd_message *msg)
{
@@ -1487,6 +1527,14 @@ static void tcpm_pd_data_request(struct tcpm_port *port,
tcpm_set_state(port, BIST_RX, 0);
}
break;
+ case PD_DATA_ALERT:
+ tcpm_handle_alert(port, msg->payload, cnt);
+ break;
+ case PD_DATA_BATT_STATUS:
+ case PD_DATA_GET_COUNTRY_INFO:
+ /* Currently unsupported */
+ tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+ break;
default:
tcpm_log(port, "Unhandled data message type %#x", type);
break;
@@ -1569,6 +1617,7 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
case PD_CTRL_REJECT:
case PD_CTRL_WAIT:
+ case PD_CTRL_NOT_SUPP:
switch (port->state) {
case SNK_NEGOTIATE_CAPABILITIES:
/* USB PD specification, Figure 8-43 */
@@ -1688,12 +1737,84 @@ static void tcpm_pd_ctrl_request(struct tcpm_port *port,
break;
}
break;
+ case PD_CTRL_GET_SOURCE_CAP_EXT:
+ case PD_CTRL_GET_STATUS:
+ case PD_CTRL_FR_SWAP:
+ case PD_CTRL_GET_PPS_STATUS:
+ case PD_CTRL_GET_COUNTRY_CODES:
+ /* Currently not supported */
+ tcpm_queue_message(port, PD_MSG_CTRL_NOT_SUPP);
+ break;
default:
tcpm_log(port, "Unhandled ctrl message type %#x", type);
break;
}
}
+static void tcpm_pd_ext_msg_request(struct tcpm_port *port,
+ const struct pd_message *msg)
+{
+ enum pd_ext_msg_type type = pd_header_type_le(msg->header);
+ unsigned int data_size =
pd_ext_header_data_size_le(msg->ext_msg.header);
+ u8 *data;
+
+ if (!(msg->ext_msg.header && PD_EXT_HDR_CHUNKED)) {
+ tcpm_log(port, "Unchunked extended messages unsupported");
+
[PATCH] watchdog: booke_wdt: Disable the watchdog prior to setting a new timeout value in order to avoid the following situation
A watchdog timer exception also occurs if the selected time base bit
transitions from 0 to 1 due
to an mtspr that writes a 1 to the bit when its previous value was 0.
Signed-off-by: Xiaofeng Wei
---
drivers/watchdog/booke_wdt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index 3ad1e44..70e742c 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -186,9 +186,15 @@ static int booke_wdt_stop(struct watchdog_device *wdog)
static int booke_wdt_set_timeout(struct watchdog_device *wdt_dev,
unsigned int timeout)
{
+ if (watchdog_active(wdt_dev))
+ on_each_cpu(__booke_wdt_disable, NULL, 0);
+
wdt_dev->timeout = timeout;
booke_wdt_set(wdt_dev);
+ if (watchdog_active(wdt_dev))
+ on_each_cpu(__booke_wdt_enable, wdt_dev, 0);
+
return 0;
}
--
2.9.3
[PATCH 0/2] Kexec_file: Load kernel at top of system ram
The current kexec_file ignores kexec_buf.top_down value when call arch_kexec_walk_mem() to allocate memory for loading kernel/initrd stuffs. This is not supposed to be what kexec_buf.top_down is used for. In patch 0001, introduce a new function walk_system_ram_res_rev() which is a variant of walk_system_ram_res(), walks through resources of System RAM from top to down. And patch 0001 is picked from AKASHI's patchset which adds arm64 kexec_file support. His next round of post won't need walk_system_ram_res_rev any more, so I take it into this patchset and use it in patch 0002. In patch 0002, check kexec_buf.top_down in arch_kexec_walk_mem(), if its value is 'true', call walk_system_ram_res_rev(). Otherwise call walk_system_ram_res(). AKASHI Takahiro (1): resource: add walk_system_ram_res_rev() Baoquan He (1): kexec_file: Load kernel at top of system RAM if required include/linux/ioport.h | 3 +++ kernel/kexec_file.c| 2 ++ kernel/resource.c | 63 ++ 3 files changed, 68 insertions(+) -- 2.13.6
[PATCH 1/2] resource: add walk_system_ram_res_rev()
From: AKASHI Takahiro
This function, being a variant of walk_system_ram_res() introduced in
commit 8c86e70acead ("resource: provide new functions to walk through
resources"), walks through a list of all the resources of System RAM
in reversed order, i.e., from higher to lower.
It will be used in kexec_file code.
Signed-off-by: AKASHI Takahiro
Signed-off-by: Baoquan He
---
include/linux/ioport.h | 3 +++
kernel/resource.c | 63 ++
2 files changed, 66 insertions(+)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index da0ebaec25f0..f12d95fe038b 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -277,6 +277,9 @@ extern int
walk_system_ram_res(u64 start, u64 end, void *arg,
int (*func)(struct resource *, void *));
extern int
+walk_system_ram_res_rev(u64 start, u64 end, void *arg,
+ int (*func)(struct resource *, void *));
+extern int
walk_iomem_res_desc(unsigned long desc, unsigned long flags, u64 start, u64
end,
void *arg, int (*func)(struct resource *, void *));
diff --git a/kernel/resource.c b/kernel/resource.c
index e270b5048988..f456fc95f1b2 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -470,6 +472,67 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
}
/*
+ * This function, being a variant of walk_system_ram_res(), calls the @func
+ * callback against all memory ranges of type System RAM which are marked as
+ * IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY in reversed order, i.e., from
+ * higher to lower.
+ */
+int walk_system_ram_res_rev(u64 start, u64 end, void *arg,
+ int (*func)(struct resource *, void *))
+{
+ struct resource res, *rams;
+ int rams_size = 16, i;
+ int ret = -1;
+
+ /* create a list */
+ rams = vmalloc(sizeof(struct resource) * rams_size);
+ if (!rams)
+ return ret;
+
+ res.start = start;
+ res.end = end;
+ res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
+ i = 0;
+ while ((res.start < res.end) &&
+ (!find_next_iomem_res(&res, IORES_DESC_NONE, true))) {
+ if (i >= rams_size) {
+ /* re-alloc */
+ struct resource *rams_new;
+ int rams_new_size;
+
+ rams_new_size = rams_size + 16;
+ rams_new = vmalloc(sizeof(struct resource)
+ * rams_new_size);
+ if (!rams_new)
+ goto out;
+
+ memcpy(rams_new, rams,
+ sizeof(struct resource) * rams_size);
+ vfree(rams);
+ rams = rams_new;
+ rams_size = rams_new_size;
+ }
+
+ rams[i].start = res.start;
+ rams[i++].end = res.end;
+
+ res.start = res.end + 1;
+ res.end = end;
+ }
+
+ /* go reverse */
+ for (i--; i >= 0; i--) {
+ ret = (*func)(&rams[i], arg);
+ if (ret)
+ break;
+ }
+
+out:
+ vfree(rams);
+ return ret;
+}
+
+/*
* This function calls the @func callback against all memory ranges, which
* are ranges marked as IORESOURCE_MEM and IORESOUCE_BUSY.
*/
--
2.13.6
[PATCH 2/2] kexec_file: Load kernel at top of system RAM if required
For kexec_file loading, if kexec_buf.top_down is 'true', the memory which is used to load kernel/initrd/purgatory is supposed to be allocated from top to down. This is also consistent with the old kexec loading interface. However, the current arch_kexec_walk_mem() doesn't do like this. It ignores checking kexec_buf.top_down, bug calls walk_system_ram_res() directly to go through all resources of System RAM, to try to find memory region which can contain the specific kexec buffer, then call locate_mem_hole_callback() to allocate memory in that found memory region from top to down. This is not right. Here add checking if kexec_buf.top_down is 'true' in arch_kexec_walk_mem(), if yes, call the newly added walk_system_ram_res_rev() to find memory region from top to down to load kernel. Signed-off-by: Baoquan He --- kernel/kexec_file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 57ec39995b23..76e6307f8971 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -445,6 +445,8 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf, IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY, crashk_res.start, crashk_res.end, kbuf, func); + else if (kbuf->top_down) + return walk_system_ram_res_rev(0, ULONG_MAX, kbuf, func); else return walk_system_ram_res(0, ULONG_MAX, kbuf, func); } -- 2.13.6
[PATCH] arm: avoid race condition issue in dump_backtrace
When we dump the backtrace of some specific task, there is a potential race
condition due to the task may be running on other cores if SMP enabled.
That is because for current implementation, if the task is not the current
task, we will get the registers used for unwind from cpu_context saved in
thread_info, which the snapshot before context switch, but if the task is
running on other cores, the registers and the content of stack are changed.
This may cause that we get the wrong backtrace or incomplete backtrace or
even crash the kernel.
To avoid this case, do not dump the backtrace of the task which is running
on other cores.
This patch cannot solve the issue completely but can shrink the window of
race condition.
Signed-off-by: Ji Zhang
---
arch/arm/kernel/traps.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 5e3633c..faa3d45 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -220,6 +220,10 @@ static void dump_backtrace(struct pt_regs *regs, struct
task_struct *tsk)
fp = frame_pointer(regs);
mode = processor_mode(regs);
} else if (tsk != current) {
+ if (tsk->state == TASK_RUNNING) {
+ pr_notice("Do not dump other running tasks\n");
+ return;
+ }
fp = thread_saved_fp(tsk);
mode = 0x10;
} else {
--
1.9.1
Re: [RFC PATCH] cpufreq: Calling init() of cpufreq_driver when policy inactive cpu online
On 21-03-18, 18:21, Shunyong Yang wrote: > When multiple cpus are related in one cpufreq policy, the first online cpu > will be chosen by default to handle cpufreq operations. In a CPPC case, > let's take two related cpus, cpu0 and cpu1 as an example. > > After system start, cpu0 is the first online cpu. Cpufreq policy will be > allocated and init() in cpufreq_driver will be called to initialize cpu0's > perf capabilities and policy parameters. Not exactly. The init() is called to initialize stuff for all the CPUs that should be part of policy->related_cpus after init() has returned. So you should initialize perf capabilities for all of them. > When cpu1 is online, current code > will not call init() in cpufreq_driver as policy has been allocated and > activated by cpu0. So, cpu1's perf capabilities are not initialized > (all 0s). > > When cpu0 is offline, policy->cpu will be shifted to cpu1. As cpu1's perf > capabilities are 0s, speed change will not take effect when setting > speed. > > This patch adds calling init() of cpufreq_driver when policy inactive cpu > comes to online. No CPU should be inactive here, its just that you haven't initialized it properly. And we are not going to call init() multiple times for a group of CPUs. That's not what the purpose of init() is. -- viresh
Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts
On Thu, Mar 22, 2018 at 09:52:18AM +0800, Jason Wang wrote:
>
>
> On 2018年03月20日 12:26, Jonathan Helman wrote:
> > > On Mar 19, 2018, at 7:31 PM, Jason Wang wrote:
> > >
> > >
> > >
> > > On 2018年03月20日 06:14, Jonathan Helman wrote:
> > > > Export the number of successful and failed hugetlb page
> > > > allocations via the virtio balloon driver. These 2 counts
> > > > come directly from the vm_events HTLB_BUDDY_PGALLOC and
> > > > HTLB_BUDDY_PGALLOC_FAIL.
> > > >
> > > > Signed-off-by: Jonathan Helman
> > > Reviewed-by: Jason Wang
> > Thanks.
> >
> > > > ---
> > > > drivers/virtio/virtio_balloon.c | 6 ++
> > > > include/uapi/linux/virtio_balloon.h | 4 +++-
> > > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/virtio/virtio_balloon.c
> > > > b/drivers/virtio/virtio_balloon.c
> > > > index dfe5684..6b237e3 100644
> > > > --- a/drivers/virtio/virtio_balloon.c
> > > > +++ b/drivers/virtio/virtio_balloon.c
> > > > @@ -272,6 +272,12 @@ static unsigned int update_balloon_stats(struct
> > > > virtio_balloon *vb)
> > > > pages_to_bytes(events[PSWPOUT]));
> > > > update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT,
> > > > events[PGMAJFAULT]);
> > > > update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT,
> > > > events[PGFAULT]);
> > > > +#ifdef CONFIG_HUGETLB_PAGE
> > > > + update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGALLOC,
> > > > + events[HTLB_BUDDY_PGALLOC]);
> > > > + update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGFAIL,
> > > > + events[HTLB_BUDDY_PGALLOC_FAIL]);
> > > > +#endif
> > > > #endif
> > > > update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
> > > > pages_to_bytes(i.freeram));
> > > > diff --git a/include/uapi/linux/virtio_balloon.h
> > > > b/include/uapi/linux/virtio_balloon.h
> > > > index 4e8b830..40297a3 100644
> > > > --- a/include/uapi/linux/virtio_balloon.h
> > > > +++ b/include/uapi/linux/virtio_balloon.h
> > > > @@ -53,7 +53,9 @@ struct virtio_balloon_config {
> > > > #define VIRTIO_BALLOON_S_MEMTOT 5 /* Total amount of memory */
> > > > #define VIRTIO_BALLOON_S_AVAIL6 /* Available memory as in /proc
> > > > */
> > > > #define VIRTIO_BALLOON_S_CACHES 7 /* Disk caches */
> > > > -#define VIRTIO_BALLOON_S_NR 8
> > > > +#define VIRTIO_BALLOON_S_HTLB_PGALLOC 8 /* Hugetlb page allocations
> > > > */
> > > > +#define VIRTIO_BALLOON_S_HTLB_PGFAIL 9 /* Hugetlb page allocation
> > > > failures */
> > > > +#define VIRTIO_BALLOON_S_NR 10
> > > > /*
> > > >* Memory statistics structure.
> > > Not for this patch, but it looks to me that exporting such nr through
> > > uapi is fragile.
> > Sorry, can you explain what you mean here?
> >
> > Jon
>
> Spec said "Within an output buffer submitted to the statsq, the device MUST
> ignore entries with tag values that it does not recognize". So exporting
> VIRTIO_BALLOON_S_NR seems useless and device implementation can not depend
> on such number in uapi.
>
> Thanks
Suggestions? I don't like to break build for people ...
> >
> > > Thanks
> >
> > -
> > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
> >
[PATCH] arm64: avoid race condition issue in dump_backtrace
When we dump the backtrace of some specific task, there is a potential race
condition due to the task may be running on other cores if SMP enabled.
That is because for current implementation, if the task is not the current
task, we will get the registers used for unwind from cpu_context saved in
thread_info, which is the snapshot before context switch, but if the task
is running on other cores, the registers and the content of stack are
changed.
This may cause that we get the wrong backtrace or incomplete backtrace or
even crash the kernel.
To avoid this case, do not dump the backtrace of the tasks which are
running on other cores.
This patch cannot solve the issue completely but can shrink the window of
race condition.
Signed-off-by: Ji Zhang
---
arch/arm64/kernel/traps.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index eb2d151..95749364 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -113,6 +113,9 @@ void dump_backtrace(struct pt_regs *regs, struct
task_struct *tsk)
if (tsk == current) {
frame.fp = (unsigned long)__builtin_frame_address(0);
frame.pc = (unsigned long)dump_backtrace;
+ else if (tsk->state == TASK_RUNNING) {
+ pr_notice("Do not dump other running tasks\n");
+ return;
} else {
/*
* task blocked in __switch_to
--
1.9.1
[PATCH v4 4/5] pintcrl: support bias-disable of generic and special pins simultaneously
For generic pins, parameter "arg" is 0 or 1.
For special pins, bias-disable is set by R0R1,
so we need transmited "00" to set bias-disable
When we set "bias-disable" as high-z property,
the parameter should be "MTK_PUPD_SET_R1R0_00".
Signed-off-by: Zhiyong Tao
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 3cf384f..f991ff3 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -293,7 +293,7 @@ static int mtk_pconf_set_pull_select(struct mtk_pinctrl
*pctl,
unsigned int pin, bool enable, bool isup, unsigned int arg)
{
unsigned int bit;
- unsigned int reg_pullen, reg_pullsel;
+ unsigned int reg_pullen, reg_pullsel, r1r0;
int ret;
/* Some pins' pull setting are very different,
@@ -301,8 +301,12 @@ static int mtk_pconf_set_pull_select(struct mtk_pinctrl
*pctl,
* resistor bit, so we need this special handle.
*/
if (pctl->devdata->spec_pull_set) {
+ /* For special pins, bias-disable is set by R1R0,
+* the parameter should be "MTK_PUPD_SET_R1R0_00".
+*/
+ r1r0 = enable ? arg : MTK_PUPD_SET_R1R0_00;
ret = pctl->devdata->spec_pull_set(mtk_get_regmap(pctl, pin),
- pin, pctl->devdata->port_align, isup, arg);
+ pin, pctl->devdata->port_align, isup, r1r0);
if (!ret)
return 0;
}
--
1.9.1
[PATCH v4 3/5] pinctrl: add mt2712 pinctrl driver
The commit includes mt2712 pinctrl driver.
Signed-off-by: Zhiyong Tao
---
drivers/pinctrl/mediatek/Kconfig |7 +
drivers/pinctrl/mediatek/Makefile |1 +
drivers/pinctrl/mediatek/pinctrl-mt2712.c | 634 +
drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1757 +
4 files changed, 2399 insertions(+)
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 3e59874..862c5db 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -32,6 +32,13 @@ config PINCTRL_MT8127
select PINCTRL_MTK
# For ARMv8 SoCs
+config PINCTRL_MT2712
+ bool "MediaTek MT2712 pin control"
+ depends on OF
+ depends on ARM64 || COMPILE_TEST
+ default ARM64 && ARCH_MEDIATEK
+ select PINCTRL_MTK
+
config PINCTRL_MT7622
bool "MediaTek MT7622 pin control"
depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile
b/drivers/pinctrl/mediatek/Makefile
index ed7d2b2..7959e77 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_PINCTRL_MTK) += pinctrl-mtk-common.o
# SoC Drivers
obj-$(CONFIG_PINCTRL_MT2701) += pinctrl-mt2701.o
+obj-$(CONFIG_PINCTRL_MT2712) += pinctrl-mt2712.o
obj-$(CONFIG_PINCTRL_MT8135) += pinctrl-mt8135.o
obj-$(CONFIG_PINCTRL_MT8127) += pinctrl-mt8127.o
obj-$(CONFIG_PINCTRL_MT7622) += pinctrl-mt7622.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2712.c
b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
new file mode 100644
index 000..d14511f
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt2712.c
@@ -0,0 +1,634 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Zhiyong Tao
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pinctrl-mtk-common.h"
+#include "pinctrl-mtk-mt2712.h"
+
+static const struct mtk_pin_spec_pupd_set_samereg mt2712_spec_pupd[] = {
+ MTK_PIN_PUPD_SPEC_SR(18, 0xe50, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(19, 0xe60, 12, 11, 10),
+ MTK_PIN_PUPD_SPEC_SR(20, 0xe50, 5, 4, 3),
+ MTK_PIN_PUPD_SPEC_SR(21, 0xe60, 15, 14, 13),
+ MTK_PIN_PUPD_SPEC_SR(22, 0xe50, 8, 7, 6),
+ MTK_PIN_PUPD_SPEC_SR(23, 0xe70, 2, 1, 0),
+
+ MTK_PIN_PUPD_SPEC_SR(30, 0xf30, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(31, 0xf30, 6, 5, 4),
+ MTK_PIN_PUPD_SPEC_SR(32, 0xf30, 10, 9, 8),
+ MTK_PIN_PUPD_SPEC_SR(33, 0xf30, 14, 13, 12),
+ MTK_PIN_PUPD_SPEC_SR(34, 0xf40, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(35, 0xf40, 6, 5, 4),
+ MTK_PIN_PUPD_SPEC_SR(36, 0xf40, 10, 9, 8),
+ MTK_PIN_PUPD_SPEC_SR(37, 0xc40, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(38, 0xc60, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(39, 0xc60, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(40, 0xc60, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(41, 0xc60, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(42, 0xc60, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(43, 0xc60, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(44, 0xc60, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(45, 0xc60, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(46, 0xc50, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(47, 0xda0, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(48, 0xd90, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(49, 0xdf0, 14, 13, 12),
+ MTK_PIN_PUPD_SPEC_SR(50, 0xdf0, 10, 9, 8),
+ MTK_PIN_PUPD_SPEC_SR(51, 0xdf0, 6, 5, 4),
+ MTK_PIN_PUPD_SPEC_SR(52, 0xdf0, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(53, 0xd50, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(54, 0xd80, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(55, 0xe00, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(56, 0xd40, 2, 1, 0),
+
+ MTK_PIN_PUPD_SPEC_SR(63, 0xc80, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(64, 0xdb0, 14, 13, 12),
+ MTK_PIN_PUPD_SPEC_SR(65, 0xdb0, 6, 5, 4),
+ MTK_PIN_PUPD_SPEC_SR(66, 0xdb0, 10, 9, 8),
+ MTK_PIN_PUPD_SPEC_SR(67, 0xcd0, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(68, 0xdb0, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(69, 0xc90, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(70, 0xcc0, 2, 1, 0),
+
+ MTK_PIN_PUPD_SPEC_SR(89, 0xce0, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(90, 0xdd0, 14, 13, 12),
+ MTK_PIN_PUPD_SPEC_SR(91, 0xdd0, 10, 9, 8),
+ MTK_PIN_PUPD_SPEC_SR(92, 0xdd0, 6, 5, 4),
+ MTK_PIN_PUPD_SPEC_SR(93, 0xdd0, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(94, 0xd20, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(95, 0xcf0, 2, 1, 0),
+ MTK_PIN_PUPD_SPEC_SR(96, 0xd30, 2, 1, 0),
+
+ MTK_PIN_PUPD_SPEC_SR(135, 0xe50, 11, 10, 9),
+ MTK_PIN_PUPD_SPEC_SR(136, 0xe50, 14, 13, 12),
+ MTK_PIN_PUPD_SPEC_SR(137, 0xe70, 5, 4, 3),
+ MTK_PIN_PUPD_SPEC_SR(138, 0xe70, 8, 7, 6),
+ MTK_PIN_PUPD_SPEC_SR(139, 0xe70, 11, 10, 9),
+ MTK_PIN_PUPD_SPEC_SR(140, 0xe70, 14, 13, 12),
+ MTK_PIN_PUPD_SPEC_SR(
[PATCH v4 0/5] PINCTRL: Mediatek pinctrl driver for mt2712
This series includes five patches: 1.Add mt2712 pintcrl head file. 2.Add mt2712 pinctrl device node. 3.Add mt2712 pinctrl driver. 4.Support bias-disable of generic and special pins simultaneously. 5.fix check warnings. Changes in patch v4: 1)fix check warnings for mt2712. 2)add fix check warnings patch for other ICs. Changes in patch v3: 1)Use SPDX identifiers for all new files. 2)Use right data for Copyright and Author. 3)Correct some spelling mistake. 4)Reusing original logic and change solution to support bias-disable of generic and special pins simultaneously. 5)Add some comments for the speical path of special pins bias-disable. Changes in patch v2: 1)Separate patch4 for supporting bias-disable of generic and special pins. 2)GPIO16~17 direction setting is changed as generic pins in mt2712 E2, So remove GPIO16~17 special direction setting and remove apmixedsys node in pinctrl device node. 3)Add pinmux define in "mt2712-pinfunc.h" and "pinctrl-mtk-mt2712.h" for mt2712 E2 design. Zhiyong Tao (5): arm64: dts: mt2712: add pintcrl file arm64: dts: mt2712: add pintcrl device node. pinctrl: add mt2712 pinctrl driver pintcrl: support bias-disable of generic and special pins simultaneously pinctrl: fix check warnings. arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1123 arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 18 + drivers/pinctrl/mediatek/Kconfig |7 + drivers/pinctrl/mediatek/Makefile |1 + drivers/pinctrl/mediatek/pinctrl-mt2712.c | 634 + drivers/pinctrl/mediatek/pinctrl-mtk-common.c |8 +- drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h | 840 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h | 1757 + drivers/pinctrl/mediatek/pinctrl-mtk-mt6397.h | 123 +- drivers/pinctrl/mediatek/pinctrl-mtk-mt8127.h | 429 ++ drivers/pinctrl/mediatek/pinctrl-mtk-mt8135.h | 609 +++-- drivers/pinctrl/mediatek/pinctrl-mtk-mt8173.h | 405 ++ 12 files changed, 4348 insertions(+), 1606 deletions(-) create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2712.c create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2712.h -- 2.6.4
[PATCH v4 2/5] arm64: dts: mt2712: add pintcrl device node.
This patch adds pintcrl device node for mt2712.
Signed-off-by: Zhiyong Tao
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index d7688bc..fb3b051 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include "mt2712-pinfunc.h"
/ {
compatible = "mediatek,mt2712";
@@ -258,6 +259,23 @@
#clock-cells = <1>;
};
+ syscfg_pctl_a: syscfg_pctl_a@10005000 {
+ compatible = "mediatek,mt2712-pctl-a-syscfg", "syscon";
+ reg = <0 0x10005000 0 0x1000>;
+ };
+
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt2712-pinctrl";
+ reg = <0 0x1000b000 0 0x1000>;
+ mediatek,pctl-regmap = <&syscfg_pctl_a>;
+ pins-are-numbered;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = ;
+ };
+
scpsys: scpsys@10006000 {
compatible = "mediatek,mt2712-scpsys", "syscon";
#power-domain-cells = <1>;
--
1.9.1
[PATCH v4 1/5] arm64: dts: mt2712: add pintcrl file
This patch adds pinctrl file for mt2712. Signed-off-by: Zhiyong Tao Reviewed-by: Rob Herring --- arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h | 1123 + 1 file changed, 1123 insertions(+) create mode 100644 arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h diff --git a/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h new file mode 100644 index 000..1b4cb0c --- /dev/null +++ b/arch/arm64/boot/dts/mediatek/mt2712-pinfunc.h @@ -0,0 +1,1123 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 MediaTek Inc. + * Author: Zhiyong Tao + * + */ +#ifndef __DTS_MT2712_PINFUNC_H +#define __DTS_MT2712_PINFUNC_H + +#include + +#define MT2712_PIN_0_EINT0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0) +#define MT2712_PIN_0_EINT0__FUNC_EINT0 (MTK_PIN_NO(0) | 1) +#define MT2712_PIN_0_EINT0__FUNC_MBIST_DIAG_SCANOUT (MTK_PIN_NO(0) | 2) +#define MT2712_PIN_0_EINT0__FUNC_DSIA_TE (MTK_PIN_NO(0) | 3) +#define MT2712_PIN_0_EINT0__FUNC_DSIC_TE (MTK_PIN_NO(0) | 4) +#define MT2712_PIN_0_EINT0__FUNC_DIN_D3 (MTK_PIN_NO(0) | 5) +#define MT2712_PIN_0_EINT0__FUNC_PURE_HW_PROTECT (MTK_PIN_NO(0) | 6) + +#define MT2712_PIN_1_EINT1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0) +#define MT2712_PIN_1_EINT1__FUNC_EINT1 (MTK_PIN_NO(1) | 1) +#define MT2712_PIN_1_EINT1__FUNC_IR_IN (MTK_PIN_NO(1) | 2) +#define MT2712_PIN_1_EINT1__FUNC_DSIB_TE (MTK_PIN_NO(1) | 3) +#define MT2712_PIN_1_EINT1__FUNC_DSID_TE (MTK_PIN_NO(1) | 4) +#define MT2712_PIN_1_EINT1__FUNC_DIN_D4 (MTK_PIN_NO(1) | 5) + +#define MT2712_PIN_2_EINT2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0) +#define MT2712_PIN_2_EINT2__FUNC_EINT2 (MTK_PIN_NO(2) | 1) +#define MT2712_PIN_2_EINT2__FUNC_IR_IN (MTK_PIN_NO(2) | 2) +#define MT2712_PIN_2_EINT2__FUNC_LCM_RST1 (MTK_PIN_NO(2) | 3) +#define MT2712_PIN_2_EINT2__FUNC_DIN_D5 (MTK_PIN_NO(2) | 5) + +#define MT2712_PIN_3_EINT3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0) +#define MT2712_PIN_3_EINT3__FUNC_EINT3 (MTK_PIN_NO(3) | 1) +#define MT2712_PIN_3_EINT3__FUNC_IR_IN (MTK_PIN_NO(3) | 2) +#define MT2712_PIN_3_EINT3__FUNC_LCM_RST0 (MTK_PIN_NO(3) | 3) +#define MT2712_PIN_3_EINT3__FUNC_DIN_D6 (MTK_PIN_NO(3) | 5) + +#define MT2712_PIN_4_PWM0__FUNC_GPIO4 (MTK_PIN_NO(4) | 0) +#define MT2712_PIN_4_PWM0__FUNC_PWM0 (MTK_PIN_NO(4) | 1) +#define MT2712_PIN_4_PWM0__FUNC_DISP0_PWM (MTK_PIN_NO(4) | 2) +#define MT2712_PIN_4_PWM0__FUNC_DISP1_PWM (MTK_PIN_NO(4) | 3) +#define MT2712_PIN_4_PWM0__FUNC_DIN_CLK (MTK_PIN_NO(4) | 5) + +#define MT2712_PIN_5_PWM1__FUNC_GPIO5 (MTK_PIN_NO(5) | 0) +#define MT2712_PIN_5_PWM1__FUNC_PWM1 (MTK_PIN_NO(5) | 1) +#define MT2712_PIN_5_PWM1__FUNC_DISP1_PWM (MTK_PIN_NO(5) | 2) +#define MT2712_PIN_5_PWM1__FUNC_DISP0_PWM (MTK_PIN_NO(5) | 3) +#define MT2712_PIN_5_PWM1__FUNC_DIN_VSYNC (MTK_PIN_NO(5) | 5) + +#define MT2712_PIN_6_PWM2__FUNC_GPIO6 (MTK_PIN_NO(6) | 0) +#define MT2712_PIN_6_PWM2__FUNC_PWM2 (MTK_PIN_NO(6) | 1) +#define MT2712_PIN_6_PWM2__FUNC_DISP0_PWM (MTK_PIN_NO(6) | 2) +#define MT2712_PIN_6_PWM2__FUNC_DISP1_PWM (MTK_PIN_NO(6) | 3) +#define MT2712_PIN_6_PWM2__FUNC_DISP2_PWM (MTK_PIN_NO(6) | 4) +#define MT2712_PIN_6_PWM2__FUNC_DIN_HSYNC (MTK_PIN_NO(6) | 5) + +#define MT2712_PIN_7_PWM3__FUNC_GPIO7 (MTK_PIN_NO(7) | 0) +#define MT2712_PIN_7_PWM3__FUNC_PWM3 (MTK_PIN_NO(7) | 1) +#define MT2712_PIN_7_PWM3__FUNC_DISP1_PWM (MTK_PIN_NO(7) | 2) +#define MT2712_PIN_7_PWM3__FUNC_DISP0_PWM (MTK_PIN_NO(7) | 3) +#define MT2712_PIN_7_PWM3__FUNC_LCM_RST2 (MTK_PIN_NO(7) | 4) +#define MT2712_PIN_7_PWM3__FUNC_DIN_D0 (MTK_PIN_NO(7) | 5) + +#define MT2712_PIN_8_PWM4__FUNC_GPIO8 (MTK_PIN_NO(8) | 0) +#define MT2712_PIN_8_PWM4__FUNC_PWM4 (MTK_PIN_NO(8) | 1) +#define MT2712_PIN_8_PWM4__FUNC_DISP0_PWM (MTK_PIN_NO(8) | 2) +#define MT2712_PIN_8_PWM4__FUNC_DISP1_PWM (MTK_PIN_NO(8) | 3) +#define MT2712_PIN_8_PWM4__FUNC_DSIA_TE (MTK_PIN_NO(8) | 4) +#define MT2712_PIN_8_PWM4__FUNC_DIN_D1 (MTK_PIN_NO(8) | 5) + +#define MT2712_PIN_9_PWM5__FUNC_GPIO9 (MTK_PIN_NO(9) | 0) +#define MT2712_PIN_9_PWM5__FUNC_PWM5 (MTK_PIN_NO(9) | 1) +#define MT2712_PIN_9_PWM5__FUNC_DISP1_PWM (MTK_PIN_NO(9) | 2) +#define MT2712_PIN_9_PWM5__FUNC_DISP0_PWM (MTK_PIN_NO(9) | 3) +#define MT2712_PIN_9_PWM5__FUNC_DSIB_TE (MTK_PIN_NO(9) | 4) +#define MT2712_PIN_9_PWM5__FUNC_DIN_D2 (MTK_PIN_NO(9) | 5) + +#define MT2712_PIN_10_PWM6__FUNC_GPIO10 (MTK_PIN_NO(10) | 0) +#define MT2712_PIN_10_PWM6__FUNC_PWM6 (MTK_PIN_NO(10) | 1) +#define MT2712_PIN_10_PWM6__FUNC_DISP0_PWM (MTK_PIN_NO(10) | 2) +#define MT2712_PIN_10_PWM6__FUNC_DISP1_PWM (MTK_PIN_NO(10) | 3) +#define MT2712_PIN_10_PWM6__FUNC_LCM_RST0 (MTK_PIN_NO(10) | 4) + +#define MT2712_PIN_11_PWM7__FUNC_GPIO11 (MTK_PIN_NO(11) | 0) +#define MT2712_PIN_11_PWM7__FUNC_PWM7 (MTK_PIN_NO(11) | 1) +#define MT2712_PIN_11_PWM7__FUNC_DISP1_PWM (MTK_PIN_NO(11) | 2) +#define MT2712_PIN_11_PWM7__FUNC_DISP0_PWM (MTK_PIN_NO(11) | 3) +#define MT2712_PIN_11_PWM7__FUNC_LCM_RST1 (MTK_PIN_NO(11) | 4) + +#define MT2712_PIN_12_IDDIG_P0__FUNC_GPIO12 (MTK_PIN_NO(12) | 0) +#define MT2712_PIN_12_IDDIG_P0__FUNC_IDDIG_A (MTK_PIN_NO(12) | 1) +#defi
Re: [RESEND PATCH v2 0/2] Add support for ZSTD-compressed kernel
On Wed, Mar 21, 2018 at 06:29:41PM -0700, Nick Terrell wrote: > This patch set adds support for a ZSTD-compressed kernel and ramdisk > images in the kernel boot process. It only integrates the support with > x86, though the first patch is generic to all architectures. I'm running this patch set since October on amd64 armhf arm64, no explosions -- besides the obvious when it's not applied yet I forget to reconfigure initramfs-tools. Which is getting tedious, so let's merge this already. :) I've tested initrd on all of these archs; here's a debug patch to check if you're actually using it. As for compressing the kernel itself: the second patch works as submitted (ie, x86 only). Porting it to other architectures is straightforward, but eg. on arm, most boards use u-boot which insists on decompressing the kernel by itself instead of passing control. EFI/grub should work, but I haven't tested that yet. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates.
Re: [PATCH 0/1] cover-letter/lz4: Implement lz4 with dynamic offset length.
On (03/21/18 19:56), Nick Terrell wrote:
[..]
> This seems like a reasonable extension to the algorithm, and it looks like
> LZ4_DYN is about a 5% improvement to compression ratio on your benchmark.
> The biggest question I have is if it is worthwhile to maintain a separate
> incompatible variant of LZ4 in the kernel without any upstream for a 5%
> gain? If we do want to go forward with this, we should perform more
> benchmarks.
>
> I commented in the patch, but because the `dynOffset` variable isn't a
> compile time static in LZ4_decompress_generic(), I suspect that the patch
> causes a regression in decompression speed for both LZ4 and LZ4_DYN. You'll
> need to re-run the benchmarks to first show that LZ4 before the patch
> performs the same as LZ4 after the patch. Then re-run the LZ4 vs LZ4_DYN
> benchmarks.
>
> I would also like to see a benchmark in user-space (with the code), so we
> can see the performance of LZ4 before and after the patch, as well as LZ4
> vs LZ4_DYN without anything else going on. I expect the extra branches in
> the decoding loop to have an impact on speed, and I would like to see how
> big the impact is without noise.
Yes, I've been thinking about this. There are more branches now
("to dyn or not to dyn") in compression/decompression hot path but
we see less instructions and branches in perf output at the end.
And my guess is that we have a lot of noise from zram and zsmalloc.
The data is XXX bytes shorter with dyn enabled, so we use YYY less
moves and ZZZ less branches while we copy the data to zsmalloc and
from zsmalloc, and I may be that's the root cause of "performance
gain" that we see in zram-fio tests. So may be we need to run
benchmarks against lz4, not zram+lz4.
> CC-ing Yann Collet, the author of LZ4
Great, thanks.
-ss
Re: [PATCH][next] phy: qcom-qusb2: fix missing assignment to an error return code
On 3/21/2018 11:15 PM, Colin King wrote:
From: Colin Ian King
The error return code is not being assigned to ret from the call
to clk_prepare_enable and consequently the current check on ret
picks up the previous error return. Fix this by adding in the
missing assignment to ret.
Detected by CoverityScan, CID#166020 ("Logically Dead code")
Fixes: 891a96f65ac3 ("phy: qcom-qusb2: Add support for runtime PM)
Signed-off-by: Colin Ian King
---
Acked-by: Vivek Gautam
regards
Vivek
drivers/phy/qualcomm/phy-qcom-qusb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c
b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 94afeac1a19e..6f5689a40884 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -439,7 +439,7 @@ static int __maybe_unused qusb2_phy_runtime_resume(struct
device *dev)
}
if (!qphy->has_se_clk_scheme) {
- clk_prepare_enable(qphy->ref_clk);
+ ret = clk_prepare_enable(qphy->ref_clk);
if (ret) {
dev_err(dev, "failed to enable ref clk, %d\n", ret);
goto disable_ahb_clk;
Re: [Bug 199003] console stalled, cause Hard LOCKUP.
On (03/22/18 11:14), Sergey Senozhatsky wrote:
[..]
> Looking at
>
> printk()->call_console_drivers()->serial8250_console_putchar()->wait_for_xmitr()
>
> ... wait_for_xmitr() can spin for over 1 second waiting for the UART_MSR_CTS
> bit.
[..]
> a 1+ second long busy loop in the console driver is quite close to
> "problems guaranteed". But, wait, there is even more. This wait_for_xmitr()
> busy wait is happening after every character we print on the console. So
> printk("foo") will generate 5 * wait_for_xmitr() busy loops [foo + \r + \n].
> They punch&touch watchdog a lot, so at the least the system won't get killed
> by the hardlockup detector. But at the same time, it's still potentially a
> 1+ second busy loop in the console driver * strlen(message).
One does not even need to have concurrent printk()-s in this case. A
single CPU doing several direct printks under spin_lock is already
enough:
CPUACPUB ~ CPUZ
spin_lock(&lock)
printk->wait_for_xmitr spin_lock(&lock)
printk->wait_for_xmitr
...
printk->wait_for_xmitr << lockups >>
printk->wait_for_xmitr
spin_unlock(&lock)
> Sometimes I really wish we had detached consoles. Direct printk()->console
> is nice and cool, but... we can't have it.
And this is, basically, what they do with printk_deferred(). We usually
use it to avoid deadlocks, but in this particular case it's used due to
the fact that direct printk() is way too painful, so they are detaching
printout and move it to another control path. Quite an interesting idea,
I must say.
-ss
Re: questions about header.S
Thanks very much for you hint! On 03/21/2018 05:57 PM, Thomas Gleixner wrote: > On Wed, 21 Mar 2018, Cao jin wrote: >> On 03/17/2018 06:01 PM, Cao jin wrote: >>> I find two small questions which confuse me a little. >>> >>> 1. >>> # Check signature at end of setup >>>cmpl$0x5a5aaa55, setup_sig >>>jne setup_bad >>> >>> setup_sig is defined in setup.ld, which points to the constant also >>> defined in setup.ld, so I don't figure out in which case they don't >>> equal and jump to setup_bad? > > That's a lame sanity check to make sure that nothing overwrote the loader. > I see. >>> In my test, drop these 2 lines seems fine, system can boot without any >>> obvious error. > > Sure it does as long as you have no corruption. > >>> 2. >>> # Zero the bss >>> movw$__bss_start, %di >>> movw$_end+3, %cx >>> xorl%eax, %eax >>> subw%di, %cx >>> shrw$2, %cx >>> rep; stosl >>> >>> It is not a big deal, but I think replace "_end" with "__bss_end" make >>> more sense, and "_end" is already aligned to word length. And, there is >>> no other code use symbol "__bss_end". So I don't know is there any >>> reason to use "_end" here? > > It doesn't matter at all. But its also pointless to change it. > It does not matter and is pointless to change for kernel itself. It just may confuse a little for newbies who has interests. -- Sincerely, Cao jin
Re: [PATCH v2] f2fs: no need to initialize zero value for GFP_F2FS_ZERO
On 2018/3/22 10:08, Yunlong Song wrote: > Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not > need to initialize zero value for its member any more. > > Signed-off-by: Yunlong Song Reviewed-by: Chao Yu Thanks,
Re: [PATCH v3 6/7] arm: dts: sun8i: a33: Add the DSI-related nodes
On Tue, Mar 6, 2018 at 9:56 PM, Maxime Ripard wrote:
> From: Maxime Ripard
>
> The A33 has a MIPI-DSI block, along with its D-PHY. Let's add it in order
> to use it in the relevant boards.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/sun8i-a33.dtsi | 44 +-
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi
> b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 50eb84fa246a..94cfa7b1bbfa 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -236,6 +236,11 @@
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <1>;
> +
> + tcon0_out_dsi0: endpoint@1 {
> + reg = <1>;
> + remote-endpoint =
> <&dsi0_in_tcon0>;
> + };
> };
> };
> };
> @@ -280,6 +285,45 @@
> #io-channel-cells = <0>;
> };
>
> + dsi0: dsi@1ca {
Nit: There's only one so you don't need the numbered suffix. Also,
is "dsi" specific enough, or should we use "mipi-dsi"
> + compatible = "allwinner,sun6i-a31-mipi-dsi";
> + reg = <0x01ca 0x1000>;
> + interrupts = ;
> + clocks = <&ccu CLK_BUS_MIPI_DSI>,
> +<&ccu CLK_DSI_SCLK>;
> + clock-names = "bus", "mod";
> + resets = <&ccu RST_BUS_MIPI_DSI>;
> + phys = <&dphy0>;
> + phy-names = "dphy";
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0>;
> +
> + dsi0_in_tcon0: endpoint {
> + remote-endpoint =
> <&tcon0_out_dsi0>;
> + };
> + };
> + };
> + };
> +
> + dphy0: d-phy@1ca1000 {
Same nit, and "dsi-phy" would be better.
Otherwise,
Reviewed-by: Chen-Yu Tsai
> + compatible = "allwinner,sun6i-a31-mipi-dphy";
> + reg = <0x01ca1000 0x1000>;
> + clocks = <&ccu CLK_BUS_MIPI_DSI>,
> +<&ccu CLK_DSI_DPHY>;
> + clock-names = "bus", "mod";
> + resets = <&ccu RST_BUS_MIPI_DSI>;
> + status = "disabled";
> + #phy-cells = <0>;
> + };
> +
> fe0: display-frontend@1e0 {
> compatible = "allwinner,sun8i-a33-display-frontend";
> reg = <0x01e0 0x2>;
> --
> git-series 0.9.1
Re: [PATCH 1/2] ACPI / PM: Use register_reboot_notifier() instead of pm_power_off_prepare
Hi Pavel,
On 21 March 2018 at 22:04, Pavel Machek wrote:
> On Wed 2018-03-21 19:30:16, Baolin Wang wrote:
>> We can register one notifier through register_reboot_notifier() function to
>> prepare to power off the system, then we can remove the
>> 'pm_power_off_prepare'
>> hook in following patch.
>>
>> Signed-off-by: Baolin Wang
>> ---
>> Note: Please help to review carefully, since I have no platform to test
>> this conversion.
>>
>> I saw there is another reboot notifier in this driver, I am not sure the
>> orders between them. I can change the priority of notifier to keep their
>> orders if it is necessary.
>
> I don't understand why this is good idea... and you should really test
> it. I'm sure you can find PC or notebook somewhere...
I want to test it, but I have no opensource board with x86
architecture. But I will try to find one or ask other guys to help to
test it. Thanks for your comments.
>> drivers/acpi/sleep.c | 22 --
>> 1 file changed, 16 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
>> index 46cde091..b3de894 100644
>> --- a/drivers/acpi/sleep.c
>> +++ b/drivers/acpi/sleep.c
>> @@ -1229,14 +1229,24 @@ static void acpi_sleep_hibernate_setup(void)
>> static inline void acpi_sleep_hibernate_setup(void) {}
>> #endif /* !CONFIG_HIBERNATION */
>>
>> -static void acpi_power_off_prepare(void)
>> +static int acpi_reboot_notify(struct notifier_block *this, unsigned long
>> code,
>> + void *x)
>> {
>> - /* Prepare to power off the system */
>> - acpi_sleep_prepare(ACPI_STATE_S5);
>> - acpi_disable_all_gpes();
>> - acpi_os_wait_events_complete();
>> + if (code == SYSTEM_POWER_OFF) {
>> + /* Prepare to power off the system */
>> + acpi_sleep_prepare(ACPI_STATE_S5);
>> + acpi_disable_all_gpes();
>> + acpi_os_wait_events_complete();
>> + }
>> +
>> + return NOTIFY_DONE;
>> }
>>
>> +static struct notifier_block acpi_reboot_notifier = {
>> + .notifier_call = acpi_reboot_notify,
>> + .priority = 0,
>> +};
>> +
>> static void acpi_power_off(void)
>> {
>> /* acpi_sleep_prepare(ACPI_STATE_S5) should have already been called */
>> @@ -1261,7 +1271,7 @@ int __init acpi_sleep_init(void)
>>
>> if (acpi_sleep_state_supported(ACPI_STATE_S5)) {
>> sleep_states[ACPI_STATE_S5] = 1;
>> - pm_power_off_prepare = acpi_power_off_prepare;
>> + register_reboot_notifier(&acpi_reboot_notifier);
>> pm_power_off = acpi_power_off;
>> } else {
>> acpi_no_s5 = true;
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
Baolin.wang
Best Regards
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gvt/scheduler.c
between commit:
fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
from Linus' tree and commit:
b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
index 068126404151,a55b4975c154..
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@@ -52,54 -52,29 +52,77 @@@ static void set_context_pdp_root_pointe
pdp_pair[i].val = pdp[7 - i];
}
+/*
+ * when populating shadow ctx from guest, we should not overrride oa related
+ * registers, so that they will not be overlapped by guest oa configs. Thus
+ * made it possible to capture oa data from host for both host and guests.
+ */
+static void sr_oa_regs(struct intel_vgpu_workload *workload,
+ u32 *reg_state, bool save)
+{
+ struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
+ u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
+ u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+ int i = 0;
+ u32 flex_mmio[] = {
+ i915_mmio_reg_offset(EU_PERF_CNTL0),
+ i915_mmio_reg_offset(EU_PERF_CNTL1),
+ i915_mmio_reg_offset(EU_PERF_CNTL2),
+ i915_mmio_reg_offset(EU_PERF_CNTL3),
+ i915_mmio_reg_offset(EU_PERF_CNTL4),
+ i915_mmio_reg_offset(EU_PERF_CNTL5),
+ i915_mmio_reg_offset(EU_PERF_CNTL6),
+ };
+
+ if (!workload || !reg_state || workload->ring_id != RCS)
+ return;
+
+ if (save) {
+ workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
+
+ for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
+ u32 state_offset = ctx_flexeu0 + i * 2;
+
+ workload->flex_mmio[i] = reg_state[state_offset + 1];
+ }
+ } else {
+ reg_state[ctx_oactxctrl] =
+ i915_mmio_reg_offset(GEN8_OACTXCONTROL);
+ reg_state[ctx_oactxctrl + 1] = workload->oactxctrl;
+
+ for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
+ u32 state_offset = ctx_flexeu0 + i * 2;
+ u32 mmio = flex_mmio[i];
+
+ reg_state[state_offset] = mmio;
+ reg_state[state_offset + 1] = workload->flex_mmio[i];
+ }
+ }
+}
+
+ static void update_shadow_pdps(struct intel_vgpu_workload *workload)
+ {
+ struct intel_vgpu *vgpu = workload->vgpu;
+ int ring_id = workload->ring_id;
+ struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
+ struct drm_i915_gem_object *ctx_obj =
+ shadow_ctx->engine[ring_id].state->obj;
+ struct execlist_ring_context *shadow_ring_context;
+ struct page *page;
+
+ if (WARN_ON(!workload->shadow_mm))
+ return;
+
+ if (WARN_ON(!atomic_read(&workload->shadow_mm->pincount)))
+ return;
+
+ page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
+ shadow_ring_context = kmap(page);
+ set_context_pdp_root_pointer(shadow_ring_context,
+ (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
+ kunmap(page);
+ }
+
static int populate_shadow_context(struct intel_vgpu_workload *workload)
{
struct intel_vgpu *vgpu = workload->vgpu;
pgpGlinVdYWAE.pgp
Description: OpenPGP digital signature
[PATCH] usbip: tools: usbipd: exclude exported devices from exportable device list
usbipd includes exported devices in response to exportable device list.
Exclude exported devices from exportable device list to avoid:
- import requests for devices that are exported only to fail the request.
- revealing devices that are imported by a client to another client.
Signed-off-by: Shuah Khan
---
tools/usb/usbip/src/usbipd.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/tools/usb/usbip/src/usbipd.c b/tools/usb/usbip/src/usbipd.c
index f8ff735eb100..32864c52942d 100644
--- a/tools/usb/usbip/src/usbipd.c
+++ b/tools/usb/usbip/src/usbipd.c
@@ -175,10 +175,21 @@ static int send_reply_devlist(int connfd)
struct list_head *j;
int rc, i;
+ /*
+* Exclude devices that are already exported to a client from
+* the exportable device list to avoid:
+* - import requests for devices that are exported only to
+*fail the request.
+* - revealing devices that are imported by a client to
+*another client.
+*/
+
reply.ndev = 0;
/* number of exported devices */
list_for_each(j, &driver->edev_list) {
- reply.ndev += 1;
+ edev = list_entry(j, struct usbip_exported_device, node);
+ if (edev->status != SDEV_ST_USED)
+ reply.ndev += 1;
}
info("exportable devices: %d", reply.ndev);
@@ -197,6 +208,9 @@ static int send_reply_devlist(int connfd)
list_for_each(j, &driver->edev_list) {
edev = list_entry(j, struct usbip_exported_device, node);
+ if (edev->status == SDEV_ST_USED)
+ continue;
+
dump_usb_device(&edev->udev);
memcpy(&pdu_udev, &edev->udev, sizeof(pdu_udev));
usbip_net_pack_usb_device(1, &pdu_udev);
--
2.14.1
Re: [PATCH v3 3/7] drm/sun4i: Add Allwinner A31 MIPI-DSI controller support
On Tue, Mar 6, 2018 at 9:56 PM, Maxime Ripard wrote:
> From: Maxime Ripard
>
> Most of the Allwinner SoCs since the A31 share the same MIPI-DSI
> controller.
>
> While that controller is mostly undocumented, the code is out there and has
> been cleaned up in order to be integrated into DRM. However, there's still
> some dark areas that are a bit unclear about how the block exactly
> operates.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/Kconfig | 10 +-
> drivers/gpu/drm/sun4i/Makefile |4 +-
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 102 ++-
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 42 +-
> drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 297 ++-
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | -
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 67 +-
Would it be possible to split the TCON parts to a second patch?
> 7 files changed, 1633 insertions(+)
> create mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c
> create mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> create mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index 882d85db9053..982db116a658 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -40,6 +40,16 @@ config DRM_SUN4I_BACKEND
> do some alpha blending and feed graphics to TCON. If M is
> selected the module will be called sun4i-backend.
>
> +config DRM_SUN6I_DSI
> + tristate "Allwinner A31 MIPI-DSI Controller Support"
> + default MACH_SUN8I
> + select CRC_CCITT
> + select DRM_MIPI_DSI
> + help
> + Choose this option if you want have an Allwinner SoC with
> + MIPI-DSI support. If M is selected the module will be called
> + sun6i-dsi
> +
> config DRM_SUN8I_MIXER
> tristate "Support for Allwinner Display Engine 2.0 Mixer"
> default MACH_SUN8I
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index 2b37a6abbb1d..84d8ed85e0c0 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -19,6 +19,9 @@ sun4i-tcon-y += sun4i_lvds.o
> sun4i-tcon-y += sun4i_tcon.o
> sun4i-tcon-y += sun4i_rgb.o
>
> +sun6i-dsi-y+= sun6i_mipi_dphy.o
> +sun6i-dsi-y+= sun6i_mipi_dsi.o
> +
> obj-$(CONFIG_DRM_SUN4I)+= sun4i-drm.o
> obj-$(CONFIG_DRM_SUN4I)+= sun4i-tcon.o
> obj-$(CONFIG_DRM_SUN4I)+= sun4i_tv.o
> @@ -26,4 +29,5 @@ obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
>
> obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
> obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o
> +obj-$(CONFIG_DRM_SUN6I_DSI)+= sun6i-dsi.o
> obj-$(CONFIG_DRM_SUN8I_MIXER) += sun8i-mixer.o
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 7e5134bfb028..72f37faec189 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -34,6 +34,7 @@
> #include "sun4i_lvds.h"
> #include "sun4i_rgb.h"
> #include "sun4i_tcon.h"
> +#include "sun6i_mipi_dsi.h"
> #include "sunxi_engine.h"
>
> static struct drm_connector *sun4i_tcon_get_connector(const struct
> drm_encoder *encoder)
> @@ -164,6 +165,7 @@ void sun4i_tcon_set_status(struct sun4i_tcon *tcon,
> case DRM_MODE_ENCODER_LVDS:
> is_lvds = true;
> /* Fallthrough */
> + case DRM_MODE_ENCODER_DSI:
> case DRM_MODE_ENCODER_NONE:
> channel = 0;
> break;
> @@ -257,6 +259,29 @@ static int sun4i_tcon_get_clk_delay(const struct
> drm_display_mode *mode,
> return delay;
> }
>
> +static void sun4i_tcon0_frame_control_enable(struct sun4i_tcon *tcon)
> +{
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_SEED_PR_REG, 1);
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_SEED_PG_REG, 3);
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_SEED_PB_REG, 5);
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_SEED_LR_REG, 7);
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_SEED_LG_REG, 11);
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_SEED_LB_REG, 13);
> +
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_TBL0_REG, 0x0101);
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_TBL1_REG, 0x1515);
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_TBL2_REG, 0x5757);
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_TBL3_REG, 0x7f7f);
> +
> + /*
> +* FIXME: This seems to only be the case for RGB666, but it's
> +* not clear when the TCON should be setup to something
> +* different
> +*/
> + regmap_write(tcon->regs, SUN4I_TCON_FRM_CTL_REG,
> +SUN4I_TCON_FRM_CTL_EN);
> +}
> +
This is for dithering. IIRC Jonathan Liu (might be wrong) had patches
c
Re: [PATCH v6 0/6] Add MediaTek PMIC keys support
Hi, Dmitry and Lee The series seems not being got merged. Are they good enough to be ready into the your tree? Recently I've tested the series with focusing on pwrkey event generated through interrupt when push and release the key on bpi-r2 board and then finally it's working fine. but for homekey it cannot be found on the board and thus I cannot have more tests more about it. Tested-by: Sean Wang Sean On Thu, 2018-03-22 at 10:03 +0800, Sean Wang (王志亘) wrote: > > > -Original Message- > > From: Linux-mediatek [mailto:linux-mediatek-boun...@lists.infradead.org] On > > Behalf Of Chen Zhong > > Sent: Wednesday, October 25, 2017 9:16 PM > > To: Dmitry Torokhov ; Rob Herring > > ; Lee Jones ; Alexandre Belloni > > > > Cc: Mark Rutland ; Alessandro Zummo > > ; devicet...@vger.kernel.org; Linus Walleij > > ; Jaechul Lee ; linux- > > ker...@vger.kernel.org; Krzysztof Kozlowski ; Javier > > Martinez Canillas ; linux- > > media...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; linux- > > in...@vger.kernel.org; Matthias Brugger ; Eddie > > Huang (S智) ; Chen Zhong (钟辰) > > ; Beomho Seo ; > > linux-...@vger.kernel.org > > Subject: [PATCH v6 0/6] Add MediaTek PMIC keys support > > > > MediaTek PMIC are multi-function devices that can handle key interrupts, > > typically there are two keys attached to PMIC, which called pwrkey and > > homekey. PWRKEY usually used to wake up system from sleep. Homekey can > > used as volume down key due to board design. Long press keys can shutdown > > PMIC, the mode can be choose to be one key only or two keys together. > > This series add support for key functions for MediaTek PMIC MT6397/MT6323. > > > > Changes since v5: > > - use __maybe_unused annotation instead of #ifdef guard > > - use of_* API instead of device_* API > > > > Changes since v4: > > - rebase to Linux 4.14-rc1 > > - add a common keyboard binding document > > - use child device tree node to define each key > > > > Changes since v3: > > - make the naming to be consistent as mtk_pmic or MTK_PMIC > > - add suspend/resume functions to enable/disable irq > > - change binding properties to define wakeup sources > > > > Changes since v2: > > - use standard properties for keycodes and debounce time > > - change to use platform_get_irq in leaf drivers > > - use better ways to define IRQ resources > > > > Changes since v1: > > - create irq mappings in mfd core driver instead of leaf drivers > > - remove some unused parts in mtk-pmic-keys driver > > > > Chen Zhong (6): > > mfd: mt6397: create irq mappings in mfd core driver > > dt-bindings: input: Add common keyboard document bindings > > dt-bindings: input: Add document bindings for mtk-pmic-keys > > dt-bindings: mfd: Add bindings for the keys as subnode of PMIC > > input: Add MediaTek PMIC keys support > > mfd: mt6397: Add PMIC keys support to MT6397 driver > > > > Documentation/devicetree/bindings/input/keys.txt | 8 + > > .../devicetree/bindings/input/mtk-pmic-keys.txt| 43 +++ > > Documentation/devicetree/bindings/mfd/mt6397.txt | 6 + > > drivers/input/keyboard/Kconfig | 9 + > > drivers/input/keyboard/Makefile| 1 + > > drivers/input/keyboard/mtk-pmic-keys.c | 339 > > + > > drivers/mfd/mt6397-core.c | 26 +- > > drivers/rtc/rtc-mt6397.c | 7 +- > > 8 files changed, 432 insertions(+), 7 deletions(-) create mode 100644 > > Documentation/devicetree/bindings/input/keys.txt > > create mode 100644 Documentation/devicetree/bindings/input/mtk-pmic- > > keys.txt > > create mode 100644 drivers/input/keyboard/mtk-pmic-keys.c > > > > -- > > 1.9.1 > > > > > > > > ___ > > Linux-mediatek mailing list > > linux-media...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [Bug 199003] console stalled, cause Hard LOCKUP.
Hello Steven,
On (03/21/18 09:44), Steven Rostedt wrote:
[..]
> > #4 [881ffb0b7540] delay_tsc at 81326724
> > #5 [881ffb0b7548] __const_udelay at 81326678
> > #6 [881ffb0b7558] wait_for_xmitr at 814056e0
> > #7 [881ffb0b7580] serial8250_console_putchar at 814058ac
> > #8 [881ffb0b75a0] uart_console_write at 8140035a
> > #9 [881ffb0b75d0] serial8250_console_write at 814057fe
> > #10 [881ffb0b7618] call_console_drivers.constprop.17 at 81087011
> > #11 [881ffb0b7640] console_unlock at 810889e9
> > #12 [881ffb0b7680] vprintk_emit at 81088df4
> > #13 [881ffb0b76f0] dev_vprintk_emit at 81428e72
> > #14 [881ffb0b77a8] dev_printk_emit at 81428eee
> > #15 [881ffb0b7808] __dev_printk at 8142937e
> > #16 [881ffb0b7818] dev_printk at 8142942d
> > #17 [881ffb0b7888] sdev_prefix_printk at 81463771
> > #18 [881ffb0b7918] scsi_prep_state_check at 814598e4
> > #19 [881ffb0b7928] scsi_prep_fn at 8145992d
> > #20 [881ffb0b7960] blk_peek_request at 812f0826
> > #21 [881ffb0b7988] scsi_request_fn at 8145b588
> > #22 [881ffb0b79f0] __blk_run_queue at 812ebd63
> > #23 [881ffb0b7a08] blk_queue_bio at 812f1013
> > -》acquired q->queue_lock and wait for console_write to finish
>
> What do you mean by "wait for console_write to finish" here?
*My guess*
I suppose a typical "printk->console_unlock() under spin_lock" thing
CPU0CPU1
spin_lock(&lock)
printk spin_lock(&lock)
console_unlock()
for (;;)
call_console_drivers()
While other CPUs printk->log_store() and some (or may be just one) is locked
up on spin_lock(&lock). So we have several lockup vectors here - one is
console_unlock() under spin_lock and the other one is CPUs spinning on the
very same spin_lock. So handoff should help here, no doubt. But it cannot help
if other CPUs will start to printk_deferred() instead of printk().
Looking at
printk()->call_console_drivers()->serial8250_console_putchar()->wait_for_xmitr()
... wait_for_xmitr() can spin for over 1 second waiting for the UART_MSR_CTS
bit.
static void wait_for_xmitr(struct uart_8250_port *up, int bits)
{
unsigned int status, tmout = 1;
/* Wait up to 10ms for the character(s) to be sent. */
for (;;) {
status = serial_in(up, UART_LSR);
up->lsr_saved_flags |= status & LSR_SAVE_FLAGS;
if ((status & bits) == bits)
break;
if (--tmout == 0)
break;
udelay(1);
touch_nmi_watchdog();
}
/* Wait up to 1s for flow control if necessary */
if (up->port.flags & UPF_CONS_FLOW) {
for (tmout = 100; tmout; tmout--) {
unsigned int msr = serial_in(up, UART_MSR);
up->msr_saved_flags |= msr & MSR_SAVE_FLAGS;
if (msr & UART_MSR_CTS)
break;
udelay(1);
touch_nmi_watchdog();
}
}
...
}
a 1+ second long busy loop in the console driver is quite close to
"problems guaranteed". But, wait, there is even more. This wait_for_xmitr()
busy wait is happening after every character we print on the console. So
printk("foo") will generate 5 * wait_for_xmitr() busy loops [foo + \r + \n].
They punch&touch watchdog a lot, so at the least the system won't get killed
by the hardlockup detector. But at the same time, it's still potentially a
1+ second busy loop in the console driver * strlen(message).
Sometimes I really wish we had detached consoles. Direct printk()->console
is nice and cool, but... we can't have it. I don't want to pressure for
printk_kthread, but look at all those consoles. There are not so many ways
out. What do you think?
-ss
linux-next: Signed-off-by missing for commit in the scsi-mkp tree
Hi Martin,
Commit
339faa8150fd ("scsi: smartpqi: workaround fw bug for oq deletion")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpAo2j4xF3lb.pgp
Description: OpenPGP digital signature
Applied "regulator: qcom_smd: Drop regulator/{machine,of_regulator} includes" to the regulator tree
The patch
regulator: qcom_smd: Drop regulator/{machine,of_regulator} includes
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 6a2e3c3ea31bba91191c4c1a8a6afd7f08f9399e Mon Sep 17 00:00:00 2001
From: Stephen Boyd
Date: Wed, 21 Mar 2018 11:48:11 -0700
Subject: [PATCH] regulator: qcom_smd: Drop regulator/{machine,of_regulator}
includes
These seem to be leftovers from previous developments of the driver but
they never got removed. Dropping them still allows the code to compile
so everything must be fine.
Signed-off-by: Stephen Boyd
Signed-off-by: Mark Brown
---
drivers/regulator/qcom_smd-regulator.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/regulator/qcom_smd-regulator.c
b/drivers/regulator/qcom_smd-regulator.c
index 940fe1b78411..0c6e681c7d89 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -17,8 +17,6 @@
#include
#include
#include
-#include
-#include
#include
struct qcom_rpm_reg {
--
2.16.2
[PATCH] [NOT FOR MERGING] lib: Be noisy about used decompression method.
It's too easy to build the initrd with wrong options during testing, after
which it may silently work anyway.
Signed-off-by: Adam Borowski
---
lib/decompress.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/decompress.c b/lib/decompress.c
index ab3fc90ffc64..556b9d916e10 100644
--- a/lib/decompress.c
+++ b/lib/decompress.c
@@ -78,7 +78,9 @@ decompress_fn __init decompress_method(const unsigned char
*inbuf, long len,
break;
}
- if (name)
+ if (name) {
*name = cf->name;
+ printk("Decompressing using %s.\n", *name);
+ }
return cf->decompressor;
}
--
2.16.2
[PATCH v2] f2fs: no need to initialize zero value for GFP_F2FS_ZERO
Since f2fs_inode_info is allocated with flag GFP_F2FS_ZERO, so we do not need to initialize zero value for its member any more. Signed-off-by: Yunlong Song --- fs/f2fs/super.c | 5 - 1 file changed, 5 deletions(-) diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 0c1fe9b..42d564c 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -827,7 +827,6 @@ static struct inode *f2fs_alloc_inode(struct super_block *sb) /* Initialize f2fs-specific inode info */ atomic_set(&fi->dirty_pages, 0); fi->i_current_depth = 1; - fi->i_advise = 0; init_rwsem(&fi->i_sem); INIT_LIST_HEAD(&fi->dirty_list); INIT_LIST_HEAD(&fi->gdirty_list); @@ -839,10 +838,6 @@ static struct inode *f2fs_alloc_inode(struct super_block *sb) init_rwsem(&fi->i_mmap_sem); init_rwsem(&fi->i_xattr_sem); -#ifdef CONFIG_QUOTA - memset(&fi->i_dquot, 0, sizeof(fi->i_dquot)); - fi->i_reserved_quota = 0; -#endif /* Will be used by directory only */ fi->i_dir_level = F2FS_SB(sb)->dir_level; -- 1.8.5.2
[PATCH -next] staging: mt7621-eth: fix return value check in mt7621_gsw_probe()
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Fixes: f079b6406348 ("staging: mt7621-eth: add gigabit switch driver (GSW)")
Signed-off-by: Wei Yongjun
---
drivers/staging/mt7621-eth/gsw_mt7621.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-eth/gsw_mt7621.c
b/drivers/staging/mt7621-eth/gsw_mt7621.c
index b49ee94..ce8d7d7 100644
--- a/drivers/staging/mt7621-eth/gsw_mt7621.c
+++ b/drivers/staging/mt7621-eth/gsw_mt7621.c
@@ -263,8 +263,8 @@ static int mt7621_gsw_probe(struct platform_device *pdev)
return -ENOMEM;
gsw->base = devm_ioremap_resource(&pdev->dev, res);
- if (!gsw->base)
- return -EADDRNOTAVAIL;
+ if (IS_ERR(gsw->base))
+ return PTR_ERR(gsw->base);
gsw->dev = &pdev->dev;
gsw->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
[PATCH -next] staging: mt7621-eth: fix return value check in mtk_probe()
In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Fixes: e3cbf478f846 ("staging: mt7621-eth: add the drivers core files")
Signed-off-by: Wei Yongjun
---
drivers/staging/mt7621-eth/mtk_eth_soc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-eth/mtk_eth_soc.c
b/drivers/staging/mt7621-eth/mtk_eth_soc.c
index 98b4462..dea4270 100644
--- a/drivers/staging/mt7621-eth/mtk_eth_soc.c
+++ b/drivers/staging/mt7621-eth/mtk_eth_soc.c
@@ -2077,8 +2077,8 @@ static int mtk_probe(struct platform_device *pdev)
return -ENOMEM;
eth->base = devm_ioremap_resource(&pdev->dev, res);
- if (!eth->base)
- return -EADDRNOTAVAIL;
+ if (IS_ERR(eth->base))
+ return PTR_ERR(eth->base);
spin_lock_init(ð->page_lock);
[PATCH -next] staging: mt7621-eth: fix return value check in mtk_connect_phy_node()
In case of error, the function of_phy_connect() returns NULL pointer not
ERR_PTR(). The IS_ERR() test in the return value check should be
replaced with NULL test.
Fixes: e3cbf478f846 ("staging: mt7621-eth: add the drivers core files")
Signed-off-by: Wei Yongjun
---
drivers/staging/mt7621-eth/mdio.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-eth/mdio.c
b/drivers/staging/mt7621-eth/mdio.c
index 96ecda9..9d71307 100644
--- a/drivers/staging/mt7621-eth/mdio.c
+++ b/drivers/staging/mt7621-eth/mdio.c
@@ -82,10 +82,10 @@ int mtk_connect_phy_node(struct mtk_eth *eth, struct
mtk_mac *mac,
phydev = of_phy_connect(eth->netdev[mac->id], phy_node,
mtk_phy_link_adjust, 0, phy_mode);
- if (IS_ERR(phydev)) {
+ if (!phydev) {
dev_err(eth->dev, "could not connect to PHY\n");
eth->phy->phy_node[port] = NULL;
- return PTR_ERR(phydev);
+ return -ENODEV;
}
phydev->supported &= PHY_GBIT_FEATURES;
[PATCH -next] staging: mt7621-gpio: mt7621: make symbol gc_map static
Fixes the following sparse warning:
drivers/staging/mt7621-gpio/gpio-mt7621.c:47:3: warning:
symbol 'gc_map' was not declared. Should it be static?
Signed-off-by: Wei Yongjun
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index 5c57abe..d00c1cd 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -38,7 +38,7 @@ enum mediatek_gpio_reg {
static int mediatek_gpio_irq;
static struct irq_domain *mediatek_gpio_irq_domain;
-struct mtk_gc {
+static struct mtk_gc {
struct gpio_chip chip;
spinlock_t lock;
int bank;
Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed
Found a patch which solves the dependency issue. In my testing (on
4.9, with Windows 2016, and also to Samba) as Pavel suggested this
appears to fix the problem, but I will let Srivatsa confirm that it
also fixes it for him. The two attached patches for 4.9 should work.
As an aside which may help some in testing stable true problems (as a
point of comparison or alternative), I did a complete backport of all
relevant CIFS/SMB3 patches (ie all patches to cifs.ko that are not
dependent on a VFS changes or global kernel API changes) for kernels
4.9 through 4.15
https://github.com/smfrench/smb3-cifs-linux-stable-backports
The individual patches that were included (and in a distinct directory
all cifs patches that were rejected due to global/VFS dependencies)
are also checked in -
https://github.com/smfrench/smb3-backported-patches.
Given the focus on security, these two git trees may be useful for
those who want a cifs.ko which includes all security and functional
improvements and fixes that more closely matches mainline cifs.ko
Srivatsa,
Let us know if those two patches fix your issue as expected.
On Fri, Mar 16, 2018 at 8:32 AM, Greg Kroah-Hartman
wrote:
> On Tue, Mar 13, 2018 at 10:21:45AM -0500, Steve French wrote:
>> There will be a fix needed to correct an oops in calc_signature,
>> besides the easy patch (smb3 validate negotiate patch).
>
> Ok, I still have no idea how to parse this for a stable tree submission.
>
> So can someone please just send me a simple "apply these git ids to tree
> X.X.y so we can fix the problem", otherwise I'm not going to do anything
> here as I'm really confused,
>
> greg k-h
--
Thanks,
Steve
From 8ac7b1d15dc973e2092ab2b1b5b698eb92e1d1c3 Mon Sep 17 00:00:00 2001
From: Steve French
Date: Sun, 11 Mar 2018 20:00:27 -0700
Subject: [PATCH 1/2] SMB3: Validate negotiate request must always be signed
According to MS-SMB2 3.2.55 validate_negotiate request must
always be signed. Some Windows can fail the request if you send it unsigned
See kernel bugzilla bug 197311
[Patch fixed up for kernel version 4.9]
CC: Stable
Acked-by: Ronnie Sahlberg
Signed-off-by: Steve French
---
fs/cifs/smb2pdu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 94c4c1901222..4c2eaf05a6a4 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -1712,6 +1712,9 @@ SMB2_ioctl(const unsigned int xid, struct cifs_tcon *tcon, u64 persistent_fid,
} else
iov[0].iov_len = get_rfc1002_length(req) + 4;
+ /* validate negotiate request must be signed - see MS-SMB2 3.2.5.5 */
+ if (opcode == FSCTL_VALIDATE_NEGOTIATE_INFO)
+ req->hdr.Flags |= SMB2_FLAGS_SIGNED;
rc = SendReceive2(xid, ses, iov, num_iovecs, &resp_buftype, 0);
rsp = (struct smb2_ioctl_rsp *)iov[0].iov_base;
--
2.14.1
From c5346223ca952a2868bd69a133251e517571 Mon Sep 17 00:00:00 2001
From: Pavel Shilovsky
Date: Mon, 7 Nov 2016 18:20:50 -0800
Subject: [PATCH 2/2] CIFS: Enable encryption during session setup phase
In order to allow encryption on SMB connection we need to exchange
a session key and generate encryption and decryption keys.
Signed-off-by: Pavel Shilovsky
---
fs/cifs/sess.c| 22 ++
fs/cifs/smb2pdu.c | 12 ++--
2 files changed, 12 insertions(+), 22 deletions(-)
diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index 538d9b55699a..c3db2a882aee 100644
--- a/fs/cifs/sess.c
+++ b/fs/cifs/sess.c
@@ -344,13 +344,12 @@ void build_ntlmssp_negotiate_blob(unsigned char *pbuffer,
/* BB is NTLMV2 session security format easier to use here? */
flags = NTLMSSP_NEGOTIATE_56 | NTLMSSP_REQUEST_TARGET |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
-ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
sec_blob->NegotiateFlags = cpu_to_le32(flags);
@@ -407,13 +406,12 @@ int build_ntlmssp_auth_blob(unsigned char **pbuffer,
flags = NTLMSSP_NEGOTIATE_56 |
NTLMSSP_REQUEST_TARGET | NTLMSSP_NEGOTIATE_TARGET_INFO |
NTLMSSP_NEGOTIATE_128 | NTLMSSP_NEGOTIATE_UNICODE |
- NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC;
- if (ses->server->sign) {
+ NTLMSSP_NEGOTIATE_NTLM | NTLMSSP_NEGOTIATE_EXTENDED_SEC |
+ NTLMSSP_NEGOTIATE_SEAL;
+ if (ses->server->sign)
flags |= NTLMSSP_NEGOTIATE_SIGN;
- if (!ses->server->session_estab ||
-ses->ntlmssp->sesskey_per_smbsess)
- flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
- }
+ if (!ses->server->session_estab || ses->ntlmssp->sesskey_per_smbsess)
+ flags |= NTLMSSP_NEGOTIATE_KEY_XCH;
tmp = *pbuffer + sizeof(AUTHENTICATE_MESSAGE);
sec_blob->NegotiateFlags = cpu_to_le32(fl
Re: mm/hmm: a simple question regarding devm_request_mem_region()
On Wed, Mar 21, 2018 at 08:32:54PM -0400, Jerome Glisse wrote: > > I am testing with drivers/char/hmm_dmirror.c from your git repository. > > > > The addr I got (before "- size") is actually 0x7f, so equally > > (1 << 40). > > > > So from your reply, it seems to me that HMM is supposed to request a > > region like it. > > The dummy driver by default test the private memory, i had patches to > make it test public memory too somewhere in a branch. So yes this is > expected from the dummy driver. HMM here is trying to get a region that > will not collide with any known existing resources. Idealy we would > like a platform/arch function for that but it is hard to justify it > nor is there a safe way to find such thing either from arch/platform > specific code (there isn't for x86 at least). > > For real device driver of pcie devices, the advice is to use the pci > bar region of the device. This way we know for sure we do not collide > with anything (ie use hmm_devmem_add_resource() not hmm_devmem_add() > but this need some code change for res->desc). I see. Thank you!
[PATCH v2] bpf: whitelist all syscalls for error injection
Error injection is a useful mechanism to fail arbitrary kernel
functions. However, it is often hard to guarantee an error propagates
appropriately to user space programs. By injecting into syscalls, we can
return arbitrary values to user space directly; this increases
flexibility and robustness in testing, allowing us to test user space
error paths effectively.
The following script, for example, fails calls to sys_open() from a
given pid:
from bcc import BPF
from sys import argv
pid = argv[1]
prog = r"""
int kprobe__SyS_open(struct pt_regs *ctx, const char *pathname, int flags)
{
u32 pid = bpf_get_current_pid_tgid();
if (pid == %s)
bpf_override_return(ctx, -ENOMEM);
return 0;
}
""" % pid
b = BPF(text=prog)
while 1:
b.perf_buffer_poll()
This patch whitelists all syscalls defined with SYSCALL_DEFINE and
COMPAT_SYSCALL_DEFINE for error injection. These changes are not
intended to be considered stable, and would normally be configured off.
Signed-off-by: Howard McLauchlan
---
Dominik,
I've updated the patch to support compat syscalls. Please let me know if there
are additional changes to be made.
Cheers,
V1->V2: added similar mechanism in compat.h, clarify commit
Based on 4.16-rc6
include/linux/compat.h | 3 +++
include/linux/syscalls.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/include/linux/compat.h b/include/linux/compat.h
index 16c3027074a2..857ddb1cfedf 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -33,6 +33,8 @@
#endif
#define COMPAT_SYSCALL_DEFINE0(name) \
+ asmlinkage long compat_sys_##name(void); \
+ ALLOW_ERROR_INJECTION(compat_sys_##name, ERRNO); \
asmlinkage long compat_sys_##name(void)
#define COMPAT_SYSCALL_DEFINE1(name, ...) \
@@ -51,6 +53,7 @@
#define COMPAT_SYSCALL_DEFINEx(x, name, ...) \
asmlinkage long compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__))\
__attribute__((alias(__stringify(compat_SyS##name; \
+ ALLOW_ERROR_INJECTION(compat_sys##name, ERRNO); \
static inline long C_SYSC##name(__MAP(x,__SC_DECL,__VA_ARGS__));\
asmlinkage long compat_SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__));\
asmlinkage long compat_SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__))\
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index a78186d826d7..e8c6d63ace78 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -191,6 +191,8 @@ static inline int is_syscall_trace_event(struct
trace_event_call *tp_event)
#define SYSCALL_DEFINE0(sname) \
SYSCALL_METADATA(_##sname, 0); \
+ asmlinkage long sys_##sname(void); \
+ ALLOW_ERROR_INJECTION(sys_##sname, ERRNO); \
asmlinkage long sys_##sname(void)
#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)
@@ -210,6 +212,7 @@ static inline int is_syscall_trace_event(struct
trace_event_call *tp_event)
#define __SYSCALL_DEFINEx(x, name, ...)
\
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
__attribute__((alias(__stringify(SyS##name; \
+ ALLOW_ERROR_INJECTION(sys##name, ERRNO);\
static inline long SYSC##name(__MAP(x,__SC_DECL,__VA_ARGS__)); \
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)); \
asmlinkage long SyS##name(__MAP(x,__SC_LONG,__VA_ARGS__)) \
--
2.14.1
[PATCH v3] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling
The definition of the GICR_CTLR.RWP control bit was expanded to indicate
status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress
or completed. Software must observe GICR_CTLR.RWP==0 after clearing
GICR_CTLR.EnableLPI from 1 to 0 and before writing GICR_PENDBASER and/or
GICR_PROPBASER, otherwise behavior is UNPREDICTABLE.
Signed-off-by: Shanker Donthineni
---
Changes since v2:
-Revert readl_relaxed_poll() usage since it's not usable in GICv3 probe().
-Changes to pr_xxx messages.
Changes since v1:
-Moved LPI disable code to a seperate function as Marc suggested.
-Mark's suggestion to use readl_relaxed_poll_timeout() helper functions.
drivers/irqchip/irq-gic-v3-its.c | 75 +++---
include/linux/irqchip/arm-gic-v3.h | 1 +
2 files changed, 62 insertions(+), 14 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 2cbb19c..c1e8a8e 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1875,16 +1876,6 @@ static void its_cpu_init_lpis(void)
gic_data_rdist()->pend_page = pend_page;
}
- /* Disable LPIs */
- val = readl_relaxed(rbase + GICR_CTLR);
- val &= ~GICR_CTLR_ENABLE_LPIS;
- writel_relaxed(val, rbase + GICR_CTLR);
-
- /*
-* Make sure any change to the table is observable by the GIC.
-*/
- dsb(sy);
-
/* set PROPBASE */
val = (page_to_phys(gic_rdists->prop_page) |
GICR_PROPBASER_InnerShareable |
@@ -3287,13 +3278,69 @@ static bool gic_rdists_supports_plpis(void)
return !!(gic_read_typer(gic_data_rdist_rd_base() + GICR_TYPER) &
GICR_TYPER_PLPIS);
}
+static int redist_disable_lpis(void)
+{
+ void __iomem *rbase = gic_data_rdist_rd_base();
+ u64 timeout = USEC_PER_SEC;
+ u64 val;
+
+ if (!gic_rdists_supports_plpis()) {
+ pr_info("CPU%d: LPIs not supported\n", smp_processor_id());
+ return -ENXIO;
+ }
+
+ val = readl_relaxed(rbase + GICR_CTLR);
+ if (!(val & GICR_CTLR_ENABLE_LPIS))
+ return 0;
+
+ pr_warn("CPU%d: Booted with LPIs enabled, memory probably corrupted\n",
+ smp_processor_id());
+ add_taint(TAINT_CRAP, LOCKDEP_STILL_OK);
+
+ /* Disable LPIs */
+ val &= ~GICR_CTLR_ENABLE_LPIS;
+ writel_relaxed(val, rbase + GICR_CTLR);
+
+ /* Make sure any change to GICR_CTLR is observable by the GIC */
+ dsb(sy);
+
+ /**
+* Software must observe RWP==0 after clearing GICR_CTLR.EnableLPIs
+* from 1 to 0 before programming GICR_PEND{PROP}BASER registers.
+* Bail out the driver probe() in case of timeout.
+*/
+ while (readl_relaxed(rbase + GICR_CTLR) & GICR_CTLR_RWP) {
+ if (!timeout) {
+ pr_err("CPU%d: Failed to observe RWP==0 after disabling
LPIs\n",
+ smp_processor_id());
+ return -ETIMEDOUT;
+ }
+ udelay(1);
+ timeout--;
+ }
+
+ /**
+* After it has been written to 1, it is IMPLEMENTATION DEFINED whether
+* the bit GICR_CTLR.EnableLPI becomes RES1 or can be cleared to 0.
+* Bail out the driver probe() on systems where it's RES1.
+*/
+ if (readl_relaxed(rbase + GICR_CTLR) & GICR_CTLR_ENABLE_LPIS) {
+ pr_err("CPU%d: Failed to disable LPIs\n", smp_processor_id());
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
int its_cpu_init(void)
{
if (!list_empty(&its_nodes)) {
- if (!gic_rdists_supports_plpis()) {
- pr_info("CPU%d: LPIs not supported\n",
smp_processor_id());
- return -ENXIO;
- }
+ int ret;
+
+ ret = redist_disable_lpis();
+ if (ret)
+ return ret;
+
its_cpu_init_lpis();
its_cpu_init_collection();
}
diff --git a/include/linux/irqchip/arm-gic-v3.h
b/include/linux/irqchip/arm-gic-v3.h
index b26eccc..c6f4c48 100644
--- a/include/linux/irqchip/arm-gic-v3.h
+++ b/include/linux/irqchip/arm-gic-v3.h
@@ -106,6 +106,7 @@
#define GICR_PIDR2 GICD_PIDR2
#define GICR_CTLR_ENABLE_LPIS (1UL << 0)
+#define GICR_CTLR_RWP (1UL << 3)
#define GICR_TYPER_CPU_NUMBER(r) (((r) >> 8) & 0x)
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies,
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: [virtio-dev] Re: [PATCH v2] virtio_balloon: export hugetlb page allocation counts
On 2018年03月20日 12:26, Jonathan Helman wrote:
On Mar 19, 2018, at 7:31 PM, Jason Wang wrote:
On 2018年03月20日 06:14, Jonathan Helman wrote:
Export the number of successful and failed hugetlb page
allocations via the virtio balloon driver. These 2 counts
come directly from the vm_events HTLB_BUDDY_PGALLOC and
HTLB_BUDDY_PGALLOC_FAIL.
Signed-off-by: Jonathan Helman
Reviewed-by: Jason Wang
Thanks.
---
drivers/virtio/virtio_balloon.c | 6 ++
include/uapi/linux/virtio_balloon.h | 4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index dfe5684..6b237e3 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -272,6 +272,12 @@ static unsigned int update_balloon_stats(struct
virtio_balloon *vb)
pages_to_bytes(events[PSWPOUT]));
update_stat(vb, idx++, VIRTIO_BALLOON_S_MAJFLT, events[PGMAJFAULT]);
update_stat(vb, idx++, VIRTIO_BALLOON_S_MINFLT, events[PGFAULT]);
+#ifdef CONFIG_HUGETLB_PAGE
+ update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGALLOC,
+ events[HTLB_BUDDY_PGALLOC]);
+ update_stat(vb, idx++, VIRTIO_BALLOON_S_HTLB_PGFAIL,
+ events[HTLB_BUDDY_PGALLOC_FAIL]);
+#endif
#endif
update_stat(vb, idx++, VIRTIO_BALLOON_S_MEMFREE,
pages_to_bytes(i.freeram));
diff --git a/include/uapi/linux/virtio_balloon.h
b/include/uapi/linux/virtio_balloon.h
index 4e8b830..40297a3 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -53,7 +53,9 @@ struct virtio_balloon_config {
#define VIRTIO_BALLOON_S_MEMTOT 5 /* Total amount of memory */
#define VIRTIO_BALLOON_S_AVAIL6 /* Available memory as in /proc */
#define VIRTIO_BALLOON_S_CACHES 7 /* Disk caches */
-#define VIRTIO_BALLOON_S_NR 8
+#define VIRTIO_BALLOON_S_HTLB_PGALLOC 8 /* Hugetlb page allocations */
+#define VIRTIO_BALLOON_S_HTLB_PGFAIL 9 /* Hugetlb page allocation failures
*/
+#define VIRTIO_BALLOON_S_NR 10
/*
* Memory statistics structure.
Not for this patch, but it looks to me that exporting such nr through uapi is
fragile.
Sorry, can you explain what you mean here?
Jon
Spec said "Within an output buffer submitted to the statsq, the device
MUST ignore entries with tag values that it does not recognize". So
exporting VIRTIO_BALLOON_S_NR seems useless and device implementation
can not depend on such number in uapi.
Thanks
Thanks
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
ITS ALL ABOUT FACEBOOK
Hello, Facebook is given out 14,000,000.USD (Fourteen Million Dollars) its all about 14 Please, respond with your Unique Code (FB/BF14-13M5250UD) using your registration email, to the Verification Department at; dustinmoskovitz.facebo...@gmail.com Dustin Moskovitz Facebook Team Copyright © 2018 Facebook Int'l
Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver
Hi
On Tuesday, March 20, 2018 06:20 PM, Emil Velikov wrote:
On 20 March 2018 at 06:24, hl wrote:
Hi Emil,
On Monday, March 19, 2018 09:09 PM, Emil Velikov wrote:
On 15 March 2018 at 02:35, hl wrote:
Hi Emil,
On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:
Hi Lin,
On 14 March 2018 at 09:12, Lin Huang wrote:
From: huang lin
Refactor Innolux P079ZCA panel driver, let it support
multi panel.
Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
Signed-off-by: Lin Huang
---
Changes in v2:
- Change regulator property name to meet the panel datasheet
Changes in v3:
- this patch only refactor P079ZCA panel to support multi panel,
support
P097PFG panel in another patch
Changes in v4:
- Modify the patch which suggest by Thierry
Thanks for splitting this up. I think there's another piece that fell
through the cracks.
I'm not deeply familiar with the driver, so just sharing some quick
notes.
struct innolux_panel {
struct drm_panel base;
struct mipi_dsi_device *link;
+ const struct panel_desc *desc;
struct backlight_device *backlight;
- struct regulator *supply;
+ struct regulator *vddi;
+ struct regulator *avdd;
+ struct regulator *avee;
These two seem are new addition, as opposed to a dummy refactor.
Are they optional, does one need them for the existing panel (separate
patch?) or only for the new one (squash with the new panel code)?
struct gpio_desc *enable_gpio;
bool prepared;
@@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel
*panel)
/* T8: 80ms - 1000ms */
msleep(80);
- err = regulator_disable(innolux->supply);
- if (err < 0)
- return err;
Good call on dropping the early return here.
@@ -207,19 +248,28 @@ static const struct drm_panel_funcs
innolux_panel_funcs = {
- innolux->supply = devm_regulator_get(dev, "power");
- if (IS_ERR(innolux->supply))
- return PTR_ERR(innolux->supply);
+ innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
+ if (!innolux)
+ return -ENOMEM;
+
+ innolux->desc = desc;
+ innolux->vddi = devm_regulator_get(dev, "power");
+ innolux->avdd = devm_regulator_get(dev, "avdd");
+ innolux->avee = devm_regulator_get(dev, "avee");
AFAICT devm_regulator_get returns a pointer which is unsuitable to be
passed into regulator_{enable,disable}.
Hence, the IS_ERR check should stay. If any of the regulators are
optional, you want to call regulator_{enable,disable} only as
applicable.
devm_regulator_get() will use dummy_regulator if there not regulator pass
to
driver, so it not affect regulator_{enable, disable}.
One of us is getting confused here:
devm_regulator_get does not _use_ a regulator, it returns a pointer to
a regulator, right?
According to the 4.16-rc6 codebase - one error
returns a ERR_PTR [1].
devm_regulator_get() will not reurn a ERR_PTR, it will pass NORMAL_GET mode
to
_regulator_get() when you call devm_regulator_get(), and with following
code:
Just before the _regulator_get() call we have "return ERR_PTR(-ENOMEM);"
See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/devres.c?h=v4.16-rc6#n34
Okay, i got what you concern now, yes, you are right, i will keep IS_ERR
checking here.
With the pointer dereferenced in regulator_enable [2], without a
IS_ERR check, hence thing will go boom(?)
These three regulator are
optional,
the p079zca will use "power" and ,
so i think it better not to check ERR here.
What should happen if p079zca is missing "power" or p097pgf - "avdd" and
"avee"?
Obviously the latter two should be introduced with the p097pgf support.
i think it need dts to make sure configure the power node correct, if
missing
"power" node fo p079zca or "avdd" "avee" node for p097pgf, the panel can
not work, but do not affcet other driver, the kernel do not crash(as i
explain before and i also test it).
If you know it won't work just don't continue? And yes, it will crash ;-)
Either way, if you don't like my feedback so be it.
HTH
Emil
P.S. As a non native English speaker to another - spell checker helps a lot ;-)
[PATCH v2 4/4] signal/x86: Move nosig handling at the end of exit_to_usermode_loop.
Handling of restarting a system call for nosig should be done after
all possible calls of do_signal, to see if one of them actually
delivers signal or not.
Before this change, restarting a system call for nosig may be followed
by a call of handle_signal which would try to change the system call
returning -EINTR instead, but it is too late to do so.
In this patch, the function name of do_signal is changed, to avoid
breakage of building User Mode Linux.
Signed-off-by: NIIBE Yutaka
---
arch/x86/entry/common.c | 6 +-
arch/x86/include/asm/signal.h | 4 +++-
arch/x86/kernel/signal.c | 6 +++---
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 74f6eee15179..14e4da298887 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -137,6 +137,8 @@ static long syscall_trace_enter(struct pt_regs *regs)
static void exit_to_usermode_loop(struct pt_regs *regs, u32 cached_flags)
{
+ int sig_result = 0;
+
/*
* In order to return to user mode, we need to have IRQs off with
* none of EXIT_TO_USERMODE_LOOP_FLAGS set. Several of these flags
@@ -159,7 +161,7 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32
cached_flags)
/* deal with pending signal delivery */
if (cached_flags & _TIF_SIGPENDING)
- do_signal(regs);
+ sig_result |= do_signal_x86(regs);
if (cached_flags & _TIF_NOTIFY_RESUME) {
clear_thread_flag(TIF_NOTIFY_RESUME);
@@ -177,6 +179,8 @@ static void exit_to_usermode_loop(struct pt_regs *regs, u32
cached_flags)
if (!(cached_flags & EXIT_TO_USERMODE_LOOP_FLAGS))
break;
}
+ if (unlikely(sig_result == DO_SIGNAL_NOSIG))
+ nosig_restart_syscall(regs);
}
/* Called with IRQs disabled. */
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index 6517df6d9938..32a861950a63 100644
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -34,8 +34,10 @@ typedef sigset_t compat_sigset_t;
#endif /* __ASSEMBLY__ */
#include
+#define DO_SIGNAL_DELIVERED1
+#define DO_SIGNAL_NOSIG2
#ifndef __ASSEMBLY__
-extern void do_signal(struct pt_regs *regs);
+extern int do_signal_x86(struct pt_regs *regs);
extern void nosig_restart_syscall(struct pt_regs *regs);
#define __ARCH_HAS_SA_RESTORER
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 9c24df5ca2d4..4a852aa60118 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -803,17 +803,17 @@ static inline unsigned long get_nr_restart_syscall(const
struct pt_regs *regs)
* want to handle. Thus you cannot kill init even with a SIGKILL even by
* mistake.
*/
-void do_signal(struct pt_regs *regs)
+int do_signal_x86(struct pt_regs *regs)
{
struct ksignal ksig;
if (get_signal(&ksig)) {
/* Whee! Actually deliver the signal. */
handle_signal(&ksig, regs);
- return;
+ return DO_SIGNAL_DELIVERED;
}
- nosig_restart_syscall(regs);
+ return DO_SIGNAL_NOSIG;
}
void nosig_restart_syscall(struct pt_regs *regs)
--
2.11.0
[PATCH v2 2/4] signal/x86: do_signal: syscall restart should be done only once.
do_signal may be called multiple times from exit_to_usermode_loop. In those multiple calls, only the one should handle restarting the system call. When actually delivering a signal, make sure the register will not be examined again as syscall errno by another call of do_signal. Signed-off-by: NIIBE Yutaka --- arch/x86/kernel/signal.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c index cdfb82031243..e709b54a01b8 100644 --- a/arch/x86/kernel/signal.c +++ b/arch/x86/kernel/signal.c @@ -729,6 +729,7 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs) regs->ip -= 2; break; } + regs->orig_ax = -1; } /* -- 2.11.0
[PATCH v2 3/4] signal/x86: Move restore_saved_sigmask().
Call to restore_saved_sigmask is only needed when it is from a system call. It is only woken up system call which uses saved_sigmask. Specifically, they are pselect, ppoll, and epoll_pwait. Signed-off-by: NIIBE Yutaka --- arch/x86/kernel/signal.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c index e709b54a01b8..9c24df5ca2d4 100644 --- a/arch/x86/kernel/signal.c +++ b/arch/x86/kernel/signal.c @@ -834,13 +834,13 @@ void nosig_restart_syscall(struct pt_regs *regs) regs->ip -= 2; break; } - } - /* -* If there's no signal to deliver, we just put the saved sigmask -* back. -*/ - restore_saved_sigmask(); + /* +* If there's no signal to deliver, we just put the +* saved sigmask back. +*/ + restore_saved_sigmask(); + } } void signal_fault(struct pt_regs *regs, void __user *frame, char *where) -- 2.11.0
[PATCH v2 1/4] signal/x86: Factor out nosig handling.
Make a function for swing at the ball but actually no ball.
Signed-off-by: NIIBE Yutaka
---
arch/x86/include/asm/signal.h | 1 +
arch/x86/kernel/signal.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/arch/x86/include/asm/signal.h b/arch/x86/include/asm/signal.h
index 5f9012ff52ed..6517df6d9938 100644
--- a/arch/x86/include/asm/signal.h
+++ b/arch/x86/include/asm/signal.h
@@ -36,6 +36,7 @@ typedef sigset_t compat_sigset_t;
#include
#ifndef __ASSEMBLY__
extern void do_signal(struct pt_regs *regs);
+extern void nosig_restart_syscall(struct pt_regs *regs);
#define __ARCH_HAS_SA_RESTORER
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index 4cdc0b27ec82..cdfb82031243 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -812,6 +812,11 @@ void do_signal(struct pt_regs *regs)
return;
}
+ nosig_restart_syscall(regs);
+}
+
+void nosig_restart_syscall(struct pt_regs *regs)
+{
/* Did we come from a system call? */
if (syscall_get_nr(current, regs) >= 0) {
/* Restart the system call - no handlers present */
--
2.11.0
[PATCH v2 0/4] Fix no signal delivery at do_signal
Hello, Background: I tried to fix my own problem in suspend-to-ram with USB devices (some device doesn't work well after suspend/resume). I know it's common problems. Well, while I identified some problems of USB devices and drivers, I did try my best. I fixed a USB device implementation of mine. Then, I also located and fixed bugs in a USB user space driver which I maintain. Now, I think I found a kernel problem. After suspend/resume, in my USB user space driver, a task sends a signal to another task, then, pselect is woken up by the signal. In this situation, a signal handler is called correctly, but it seems that the pselect is restarted. Expected behavior is woken pselect returning -EINTR. Looking the code, my theory is: It is a fake signal by suspend which wakes up pselect to be frozen, and after resume, real signal is sent. When both of signals are handled in a single call of exit_to_usermode_loop, by two calls of do_signal, firstly for fake signal and secondly for real signal, the system call is restarted wrongly, where it should return -EINTR. Here is a patch series of mine for x86. I'd suggest architecture maintainers to do similar if an architecture supports suspend/resume. I found that, in arch/arm, it does differently. When it finds no signal delivery at do_signal, it restarts the system call soon, breaking the loop. This approach also works. Changes from v1: * Title change of cover leter * Avoid User Mode Linux breakage * Only call nosig_restart_syscall when really needed * Add 'unlikely'. NIIBE Yutaka (4): signal/x86: Factor out nosig handling. signal/x86: do_signal: syscall restart should be done only once. signal/x86: Move restore_saved_sigmask(). signal/x86: Move nosig handling at the end of exit_to_usermode_loop. arch/x86/entry/common.c | 6 +- arch/x86/include/asm/signal.h | 5 - arch/x86/kernel/signal.c | 22 ++ 3 files changed, 23 insertions(+), 10 deletions(-) -- 2.11.0
Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer
On Wed, Mar 21, 2018 at 3:11 PM, Bae, Chang Seok wrote: > On 3/20/18, 17:47, "Andy Lutomirski" wrote: >>If I've understood all your emails right, when you looked at existing >>ptrace users, you found that all of them that write to gs and/or >>gs_base do it as part of a putregs call that writes them at the same >>time. If so, then your patch does exactly the same thing that my old >>patches did, but your patch is much more complicated. So why did you >>add all that complexity? > > What is tried to be provided is backward compatibility by emulating > “mov gs (fs) …” when index is only changed and preserve a (given) base value > in other cases. mov to gs changes GSBASE even if GS was unchanged. But it's not clear to me that you've identified any case where emulating this behavior is useful.
Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer
On Wed, Mar 21, 2018 at 7:01 AM, Metzger, Markus T wrote: >> -Original Message- >> From: Andy Lutomirski [mailto:l...@kernel.org] >> Sent: 21 March 2018 01:47 > > Hello Andy, > >> I retract this particular comment. But I still think that all this >> complexity needs to >> be more clearly justified. My objection to the old approach wasn't that I >> thought >> it was obviously wrong -- I thought that someone needed to survey existing >> ptrace() users and see if anyone needed the fancier code that you're adding. >> Did >> you find something that needs this fancy code? > > There are 3 cases: > - only FS changed, e.g. "p $fs = ..." If a person literally types that, I have no problem if they get different behavior on different systems. If it's some existing program that needs to keep working, then we may be out of luck, since gdb seems to use SETREGS. > - only FS_BASE changed, e.g. "p $fs_base = ..." That's fine no matter what, I think. > - both change, e.g. "p foo()" when restoring the original register state on > return > from the inferior call This is the interesting case. If everything that matters uses SETREGS, then I think we're in good shape, and we should probably just make writing to FS using ptrace on FSGSBASE systems *not* change FSBASE, since that way is much simpler.
Re: linux-next: build failure after merge of the sound-asoc tree
On Wed, Mar 21, 2018 at 11:15:16AM +0530, Mukunda,Vijendar wrote: > There is a patch dependency . > Below patch not merged yet. We submitted for upstream review. > [PATCH V2] ASoC: dwc: I2S Controller instance param added You need to mention dependencies between patches when publishing and I don't seem to have a copy of that patch, according to the list archives Alex asked you to make some chnages to it. signature.asc Description: PGP signature
Re: [PATCH 13/15] x86/fsgsbase/64: With FSGSBASE, compare GS bases on paranoid_entry
On Wed, Mar 21, 2018 at 10:03 PM, H. Peter Anvin wrote: > On 03/20/18 07:58, Andy Lutomirski wrote: >>> On Mar 19, 2018, at 10:49 AM, Chang S. Bae wrote: >>> >>> When FSGSBASE is enabled, SWAPGS needs if and only if (current) >>> GS base is not the kernel's. >>> >>> FSGSBASE instructions allow user to write any value on GS base; >>> even negative. Sign check on the current GS base is not >>> sufficient. Fortunately, reading GS base is fast. Kernel GS >>> base is also known from the offset table with the CPU number. >> >> The original version of these patches (mine and Andi’s) didn’t have >> this comparison, didn’t need RDMSR, and didn’t allow malicious user >> programs to cause the kernel to run decently large chunks of code with >> the reverse of the expected GS convention. Why did you change it? >> >> I really really don't like having a corner case like this that can and >> will be triggered by malicious user code but that is hard to write a >> self-test for because it involves guessing a 64-bit magic number. >> Untestable corner cases in the x86 entry code are bad. >> > > What corner case are you talking about? > > If user GS_BASE and kernel GS_BASE happen to be identical, then SWAPGS > is a nop and it does not matter one iota which is is user space and > which is kernel space. They are just numbers, and swapping one number > with itself doesn't do anything (in fact, opcode 0x90 was used for NOP > because it aliased to xchg [e]ax,[e]ax on pre-64-bit hardware.) > On current kernels, MSR_GS_BASE points to kernel percpu data and MSR_KERNEL_GS_BASE is the user's GSBASE value. If you *write* to MSR_KERNEL_GS_BASE, you modify the user's value. With Andi's/my patches, it works exactly the same way on !FSGSBASE and, if FSGSBASE is on, then, when we're in a paranoid entry, MSR_GS_BASE is the live kernel value, the value upon return is stashed in an entry asm register, and MSR_KERNEL_GS_BASE is whatever it was before we entered. Sure, it's more complicated, but if something starts writing to MSR_KERNEL_GS_BASE in the context of a paranoid entry, the behavior will at least be consistently screwy. With these patches, MSR_GS_BASE points to the kernel percpu data and MSR_KERNEL_GS_BASE is the user's value, but writing to MSR_KERNEL_GS_BASE will change the *kernel* value if we happen to be in a paranoid context while running malicious user code. But only when running malicious user code. In the absence of some compelling reason why #3 is better than #2, I don't like it. If you want to argue for using rdpid or lsl to find the kernel gs base and then load it unconditionally with wrgsbase, I'd be fine with that. But this compare-and-swapgs just seems unnecessarily subject to manipulation.
Re: [PATCH] MIPS: ralink: remove ralink_halt()
On Wed, Mar 21 2018, James Hogan wrote:
> On Tue, Mar 20, 2018 at 07:29:51PM +1100, NeilBrown wrote:
>>
>> ralink_halt() does nothing that machine_halt()
>> doesn't already do, so it adds no value.
>>
>> It actually causes incorrect behaviour due to the
>> "unreachable()" at the end. This tell the compiler that the
>> end of the function will never be reached, which isn't true.
>> The compiler responds by not adding a 'return' instruction,
>> so control simply moves on to whatever bytes come afterwards
>> in memory. In my tested, that was the ralink_restart()
>> function. This means that an attempt to 'halt' the machine
>> would actually cause a reboot.
>>
>> So remove ralink_halt() so that a 'halt' really does halt.
>>
>> Signed-off-by: NeilBrown
>
> Thanks, I've cosmetically tweaked the commit message (mainly reflow to
> 72 characters) and added:
>
> Fixes: c06e836ada59 ("MIPS: ralink: adds reset code")
> Cc: # 3.9+
>
> and applied for 4.16.
>
> BTW, I'm intrigued to know if there's a particular reason you don't
> author / sign-off as "Neil Brown"? Its supposed to be real names, though
> "NeilBrown" is hardly difficult to figure out so I don't actually
> object.
I started using NeilBrown way back when I was an undergrad student and
it stuck. When you grow up as a Brown, you know your name isn't going
to make you unique. e.g. I'm not an author of "Red Hat Linux System
Administration Unleashed" (he has a space in his name!!). So I chose a
different way to make my name distinctive.
Yes, it isn't technically compliant - you are the second person to
comment in the nearly twenty years I've been working on Linux :-)
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Re: [PATCH 03/15] mm/hmm: HMM should have a callback before MM is destroyed v2
On Wed, Mar 21, 2018 at 05:11:10PM -0700, John Hubbard wrote: > On 03/21/2018 04:37 PM, Jerome Glisse wrote: > > On Wed, Mar 21, 2018 at 04:10:32PM -0700, John Hubbard wrote: > >> On 03/21/2018 03:46 PM, Jerome Glisse wrote: > >>> On Wed, Mar 21, 2018 at 03:16:04PM -0700, John Hubbard wrote: > On 03/21/2018 11:03 AM, Jerome Glisse wrote: > > On Tue, Mar 20, 2018 at 09:14:34PM -0700, John Hubbard wrote: > >> On 03/19/2018 07:00 PM, jgli...@redhat.com wrote: > >>> From: Ralph Campbell > > > > [...] > > > > That is just illegal, the release callback is not allowed to trigger > > invalidation all it does is kill all device's threads and stop device > > page fault from happening. So there is no deadlock issues. I can re- > > inforce the comment some more (see [1] for example on what it should > > be). > > That rule is fine, and it is true that the .release callback will not > directly trigger any invalidations. However, the problem is in letting > any *existing* outstanding operations finish up. We have to let > existing operations "drain", in order to meet the requirement that > everything is done when .release returns. > > For example, if a device driver thread is in the middle of working > through > its fault buffer, it will call migrate_vma(), which will in turn unmap > pages. That will cause an hmm_invalidate_range() callback, which tries > to take hmm->mirrors_sems, and we deadlock. > > There's no way to "kill" such a thread while it's in the middle of > migrate_vma(), you have to let it finish up. > > > Also it is illegal for the sync callback to trigger any mmu_notifier > > callback. I thought this was obvious. The sync callback should only > > update device page table and do _nothing else_. No way to make this > > re-entrant. > > That is obvious, yes. I am not trying to say there is any problem with > that rule. It's the "drain outstanding operations during .release", > above, that is the real problem. > >>> > >>> Maybe just relax the release callback wording, it should stop any > >>> more processing of fault buffer but not wait for it to finish. In > >>> nouveau code i kill thing but i do not wait hence i don't deadlock. > >> > >> But you may crash, because that approach allows .release to finish > >> up, thus removing the mm entirely, out from under (for example) > >> a migrate_vma call--or any other call that refers to the mm. > > > > No you can not crash on mm as it will not vanish before you are done > > with it as mm will not be freed before you call hmm_unregister() and > > you should not call that from release, nor should you call it before > > everything is flush. However vma struct might vanish ... i might have > > assume wrongly about the down_write() always happening in exit_mmap() > > This might be a solution to force serialization. > > > > OK. My details on mm destruction were inaccurate, but we do agree now > that that the whole virtual address space is being torn down at the same > time as we're trying to use it, so I think we're on the same page now. > > >> > >> It doesn't seem too hard to avoid the problem, though: maybe we > >> can just drop the lock while doing the mirror->ops->release callback. > >> There are a few ways to do this, but one example is: > >> > >> -- take the lock, > >> -- copy the list to a local list, deleting entries as you go, > >> -- drop the lock, > >> -- iterate through the local list copy and > >> -- issue the mirror->ops->release callbacks. > >> > >> At this point, more items could have been added to the list, so repeat > >> the above until the original list is empty. > >> > >> This is subject to a limited starvation case if mirror keep getting > >> registered, but I think we can ignore that, because it only lasts as long > >> as > >> mirrors keep getting added, and then it finishes up. > > > > The down_write is better solution and easier just 2 line of code. > > OK. I'll have a better idea when I see it. > > > > >> > >>> > >>> What matter is to stop any further processing. Yes some fault might > >>> be in flight but they will serialize on various lock. > >> > >> Those faults in flight could already be at a point where they have taken > >> whatever locks they need, so we don't dare let the mm get destroyed while > >> such fault handling is in progress. > > > > mm can not vanish until hmm_unregister() is call, vma will vanish before. > > OK, yes. And we agree that vma vanishing is a problem. > > > > >> So just do not > >>> wait in the release callback, kill thing. I might have a bug where i > >>> still fill in GPU page table in nouveau, i will check nouveau code > >>> for that. > >> > >> Again, we can't "kill" a thread of execution (this would often be an > >> interrupt bottom half context, btw) while it is, for example, > >> in the middle of migrate_
Re: [PATCH] perf util: Display warning when perf report/annotate is missing some libs
On 3/22/2018 2:52 AM, Arnaldo Carvalho de Melo wrote: Em Wed, Mar 21, 2018 at 05:04:46PM +0100, Jiri Olsa escreveu: On Wed, Mar 21, 2018 at 12:43:15PM -0300, Arnaldo Carvalho de Melo wrote: Em Wed, Mar 21, 2018 at 12:40:35PM -0300, Arnaldo Carvalho de Melo escreveu: Em Wed, Mar 21, 2018 at 04:38:07PM +0100, Jiri Olsa escreveu: On Wed, Mar 21, 2018 at 10:11:10AM +0800, Jin, Yao wrote: Hi Jiri, I'm still thinking it's worth displaying the warning when perf missing some libraries. Somebody just told me that perf didn't work well. While after some investigations, I found it's just missing some libraries when building the perf. But I have spent some time on getting the root cause. If with this patch, it should be very easily to know that. true.. Arnaldo, any feedback on this one? Lemme re-read the thread... Well, how about we make it harder to build without key libraries? I.e. if we detect that what we consider a core set of libraries isn't found in the system, then we stop the build, warn about it and ask the user to confirm that the build should proceed by passing some explicit -DI_KNOW_WHAT_I_AM_DOING___PROCEED=doit hum, not sure we want to complicate the build even more than it is now :-\ and IMO it still won't help much in Jin's problem, if user forces the build anyway Well, if a user _forces_ a build, not taking into consideration a warning that _is_ emitted and _stops_ the build, about the functionality it will lose by doing forcing the build, then comes back and complains that that functionality is not present, then it becomes difficult to help this user... :-) On the other hand, if the user forgets to install an important library, the warning is emitted but the build proceeds, no explicit action was performed, just a warning wasn't noticed, and the user complains, then I'd say: "hey, are you sure library foo devel files were present when you build it?", i.e. the support back and forth Jin is trying to avoid. And for users that _saw_ the warning, _knew_ they _didn't_ want that functionality, to be reminded while running, say 'perf report' that something they _decided not to have_ isn't present, then that could be annoying, no? Lemme try another idea: what if we do something like gcc does and print the features present when showing the version? I.e.: [acme@jouet perf]$ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.3.1 20180303 (Red Hat 7.3.1-5) (GCC) [acme@jouet perf]$ - Arnaldo Is this too complicated for perf newbie to understand? For my problem, the mistake only occurs on perf newbie. I just think, it'd better return a direct and clear message to them. Maybe they don't know or don't use -v or -vv to do more investigation by themselves. Thanks Jin Yao
[PATCH 04/15] mm/hmm: unregister mmu_notifier when last HMM client quit v3
From: Jérôme Glisse
This code was lost in translation at one point. This properly call
mmu_notifier_unregister_no_release() once last user is gone. This
fix the zombie mm_struct as without this patch we do not drop the
refcount we have on it.
Changed since v1:
- close race window between a last mirror unregistering and a new
mirror registering, which could have lead to use after free()
kind of bug
Changed since v2:
- Avoid issue if there is multiple call to hmm_mirror_register()
(which lead to use after free).
Signed-off-by: Jérôme Glisse
Cc: Evgeny Baskakov
Cc: Ralph Campbell
Cc: Mark Hairgrove
Cc: John Hubbard
---
mm/hmm.c | 39 ---
1 file changed, 36 insertions(+), 3 deletions(-)
diff --git a/mm/hmm.c b/mm/hmm.c
index 34c16297f65e..5b21d458db60 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -233,13 +233,24 @@ int hmm_mirror_register(struct hmm_mirror *mirror, struct
mm_struct *mm)
if (!mm || !mirror || !mirror->ops)
return -EINVAL;
+again:
mirror->hmm = hmm_register(mm);
if (!mirror->hmm)
return -ENOMEM;
down_write(&mirror->hmm->mirrors_sem);
- list_add(&mirror->list, &mirror->hmm->mirrors);
- up_write(&mirror->hmm->mirrors_sem);
+ if (mirror->hmm->mm == NULL) {
+ /*
+* A racing hmm_mirror_unregister() is about to destroy the hmm
+* struct. Try again to allocate a new one.
+*/
+ up_write(&mirror->hmm->mirrors_sem);
+ mirror->hmm = NULL;
+ goto again;
+ } else {
+ list_add(&mirror->list, &mirror->hmm->mirrors);
+ up_write(&mirror->hmm->mirrors_sem);
+ }
return 0;
}
@@ -254,11 +265,33 @@ EXPORT_SYMBOL(hmm_mirror_register);
*/
void hmm_mirror_unregister(struct hmm_mirror *mirror)
{
- struct hmm *hmm = mirror->hmm;
+ bool should_unregister = false;
+ struct mm_struct *mm;
+ struct hmm *hmm;
+
+ if (mirror->hmm == NULL)
+ return;
+ hmm = mirror->hmm;
down_write(&hmm->mirrors_sem);
list_del_init(&mirror->list);
+ should_unregister = list_empty(&hmm->mirrors);
+ mirror->hmm = NULL;
+ mm = hmm->mm;
+ hmm->mm = NULL;
up_write(&hmm->mirrors_sem);
+
+ if (!should_unregister || mm == NULL)
+ return;
+
+ spin_lock(&mm->page_table_lock);
+ if (mm->hmm == hmm) {
+ mm->hmm = NULL;
+ }
+ spin_unlock(&mm->page_table_lock);
+
+ mmu_notifier_unregister_no_release(&hmm->mmu_notifier, mm);
+ kfree(hmm);
}
EXPORT_SYMBOL(hmm_mirror_unregister);
--
2.14.3
Re: [RFC PATCH v2 0/4] Eliminate zone->lock contention for will-it-scale/page_fault1 and parallel free
On Wed, Mar 21, 2018 at 01:44:25PM -0400, Daniel Jordan wrote: > On 03/20/2018 04:54 AM, Aaron Lu wrote: > ...snip... > > reduced zone->lock contention on free path from 35% to 1.1%. Also, it > > shows good result on parallel free(*) workload by reducing zone->lock > > contention from 90% to almost zero(lru lock increased from almost 0 to > > 90% though). > > Hi Aaron, I'm looking through your series now. Just wanted to mention that > I'm seeing the same interaction between zone->lock and lru_lock in my own > testing. IOW, it's not enough to fix just one or the other: both need > attention to get good performance on a big system, at least in this > microbenchmark we've both been using. Agree. > > There's anti-scaling at high core counts where overall system page faults per > second actually decrease with more CPUs added to the test. This happens when > either zone->lock or lru_lock contention are completely removed, but the > anti-scaling goes away when both locks are fixed. > > Anyway, I'll post some actual data on this stuff soon. Looking forward to that, thanks. In the meantime, I'll also try your lru_lock optimization work on top of this patchset to see if the lock contention shifts back to zone->lock.
[PATCH 03/15] mm/hmm: HMM should have a callback before MM is destroyed v3
From: Ralph Campbell
The hmm_mirror_register() function registers a callback for when
the CPU pagetable is modified. Normally, the device driver will
call hmm_mirror_unregister() when the process using the device is
finished. However, if the process exits uncleanly, the struct_mm
can be destroyed with no warning to the device driver.
Changed since v1:
- dropped VM_BUG_ON()
- cc stable
Changed since v2:
- drop stable
- Split list removale and call to driver release callback. This
allow the release callback to wait on any pending fault handler
without deadlock.
Signed-off-by: Ralph Campbell
Signed-off-by: Jérôme Glisse
Cc: Evgeny Baskakov
Cc: Mark Hairgrove
Cc: John Hubbard
---
include/linux/hmm.h | 10 ++
mm/hmm.c| 29 -
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/include/linux/hmm.h b/include/linux/hmm.h
index 36dd21fe5caf..fa7b51f65905 100644
--- a/include/linux/hmm.h
+++ b/include/linux/hmm.h
@@ -218,6 +218,16 @@ enum hmm_update_type {
* @update: callback to update range on a device
*/
struct hmm_mirror_ops {
+ /* release() - release hmm_mirror
+*
+* @mirror: pointer to struct hmm_mirror
+*
+* This is called when the mm_struct is being released.
+* The callback should make sure no references to the mirror occur
+* after the callback returns.
+*/
+ void (*release)(struct hmm_mirror *mirror);
+
/* sync_cpu_device_pagetables() - synchronize page tables
*
* @mirror: pointer to struct hmm_mirror
diff --git a/mm/hmm.c b/mm/hmm.c
index 320545b98ff5..34c16297f65e 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -160,6 +160,32 @@ static void hmm_invalidate_range(struct hmm *hmm,
up_read(&hmm->mirrors_sem);
}
+static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm)
+{
+ struct hmm_mirror *mirror;
+ struct hmm *hmm = mm->hmm;
+
+ down_write(&hmm->mirrors_sem);
+ mirror = list_first_entry_or_null(&hmm->mirrors, struct hmm_mirror,
+ list);
+ while (mirror) {
+ list_del_init(&mirror->list);
+ if (mirror->ops->release) {
+ /*
+* Drop mirrors_sem so callback can wait on any pending
+* work that might itself trigger mmu_notifier callback
+* and thus would deadlock with us.
+*/
+ up_write(&hmm->mirrors_sem);
+ mirror->ops->release(mirror);
+ down_write(&hmm->mirrors_sem);
+ }
+ mirror = list_first_entry_or_null(&hmm->mirrors, struct
hmm_mirror,
+ list);
+ }
+ up_write(&hmm->mirrors_sem);
+}
+
static void hmm_invalidate_range_start(struct mmu_notifier *mn,
struct mm_struct *mm,
unsigned long start,
@@ -185,6 +211,7 @@ static void hmm_invalidate_range_end(struct mmu_notifier
*mn,
}
static const struct mmu_notifier_ops hmm_mmu_notifier_ops = {
+ .release= hmm_release,
.invalidate_range_start = hmm_invalidate_range_start,
.invalidate_range_end = hmm_invalidate_range_end,
};
@@ -230,7 +257,7 @@ void hmm_mirror_unregister(struct hmm_mirror *mirror)
struct hmm *hmm = mirror->hmm;
down_write(&hmm->mirrors_sem);
- list_del(&mirror->list);
+ list_del_init(&mirror->list);
up_write(&hmm->mirrors_sem);
}
EXPORT_SYMBOL(hmm_mirror_unregister);
--
2.14.3
Re: [RFC PATCH 2/3] x86/io: implement 256-bit IO read and write
On Tue, Mar 20, 2018 at 7:42 AM, Alexander Duyck wrote: > > Instead of framing this as an enhanced version of the read/write ops > why not look at replacing or extending something like the > memcpy_fromio or memcpy_toio operations? Yes, doing something like "memcpy_fromio_avx()" is much more palatable, in that it works like the crypto functions do - if you do big chunks, the "kernel_fpu_begin/end()" isn't nearly the issue it can be otherwise. Note that we definitely have seen hardware that *depends* on the regular memcpy_fromio()" not doing big reads. I don't know how hardware people screw it up, but it's clearly possible. So it really needs to be an explicitly named function that basically a driver can use to say "my hardware really likes big aligned accesses" and explicitly ask for some AVX version if possible. Linus
Re: [PATCH V7 00/13] drivers: Boot Constraint core
On 23-02-18, 15:53, Viresh Kumar wrote: > Problem statement: > > Some devices are powered ON by the bootloader before the bootloader > handovers control to Linux. It maybe important for some of those devices > to keep working until the time a Linux device driver probes the device > and reconfigure its resources. > > A typical example of that can be the LCD controller, which is used by > the bootloaders to show image(s) while the platform is booting into > Linux. The LCD controller can be using some resources, like clk, > regulators, etc, that are shared between several devices. These shared > resources should be configured to satisfy need of all the users. If > another device's (X) driver gets probed before the LCD controller driver > in this case, then it may end up disabling or reconfiguring these > resources to ranges satisfying the current users (only device X) and > that can make the LCD screen unstable. > > Another case can be a debug serial port enabled from the bootloader. > > Of course we can have more complex cases where the same resource is > getting used by two devices while the kernel boots and the order in > which devices get probed wouldn't matter as the other device will surely > break then. And we have a _real_ use case for this complex scenario as well. Georgi (cc'd) is currently working[1] on implementing generic support for the interconnect bus, which tries to play with the bandwidth of the bus based on how much are the requirements from different parts of the SoC. The 4th version was posted recently by him, and things are looking good/positive. The bootloader configures the interconnect to provide sufficient bandwidth for all the devices which are used during boot, few of them are the CPUs, serial and the LCD controller. As the kernel starts taking control of things, the drivers being probed start putting their requirements on the interconnect bus. Because the interconnect doesn't have any representation from the devices which are not yet initialized by the kernel, the interconnect core incorrectly reduces the bandwidth of the bus to a level unacceptable to the devices running currently, like the CPUs and this makes kernel boot awfully slow. This is not an ordering problem as no matter which device we probe first, we are going to break something else. Georgi already tried using the boot constraint patches to solve this complex problem, and its a perfect fit. -- viresh [1] http://lkml.kernel.org/r/20180309210958.16672-1-georgi.dja...@linaro.org
Re: [PATCH V3 0/1] scsi: ufs: Add support for Auto-Hibernate Idle Timer
Adrian, > Here is V3, now re-based on top of patch "scsi: ufs: sysfs:reworking of the > rpm_lvl and spm_lvl entries". > > Michał Potomski has previously sent a patch for Auto-Hibernate, but this > patch is slightly different, based on the latest ufs-sysfs changes, it also > takes care to restore auto-hibernate during resume, and otherwise avoids > updating the register if the device is runtime suspended. Also a default > value of 150ms is set. Applied to 4.17/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] scsi: ufs: sysfs: reworking of the rpm_lvl and spm_lvl entries
Adrian, > On 01/03/18 12:48, Stanislav Nijnikov wrote: >> Read from these files will return the integed value of the chosen power >> management level now. Separate entries were added to show the target >> UFS device and UIC link states. The description of the possible power >> managements levels was added to the ABI file. The on-write behaviour of >> these entries wasn't changed. >> >> Signed-off-by: Stanislav Nijnikov > > Acked-by: Adrian Hunter Applied to 4.17/scsi-queue. Thank you! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v9 00/24] Speculative page faults
Hi, Laurent 2018-03-14 1:59 GMT+08:00 Laurent Dufour : > This is a port on kernel 4.16 of the work done by Peter Zijlstra to > handle page fault without holding the mm semaphore [1]. > > The idea is to try to handle user space page faults without holding the > mmap_sem. This should allow better concurrency for massively threaded > process since the page fault handler will not wait for other threads memory > layout change to be done, assuming that this change is done in another part > of the process's memory space. This type page fault is named speculative > page fault. If the speculative page fault fails because of a concurrency is > detected or because underlying PMD or PTE tables are not yet allocating, it > is failing its processing and a classic page fault is then tried. > > The speculative page fault (SPF) has to look for the VMA matching the fault > address without holding the mmap_sem, this is done by introducing a rwlock > which protects the access to the mm_rb tree. Previously this was done using > SRCU but it was introducing a lot of scheduling to process the VMA's > freeing > operation which was hitting the performance by 20% as reported by Kemi Wang > [2].Using a rwlock to protect access to the mm_rb tree is limiting the > locking contention to these operations which are expected to be in a O(log > n) > order. In addition to ensure that the VMA is not freed in our back a > reference count is added and 2 services (get_vma() and put_vma()) are > introduced to handle the reference count. When a VMA is fetch from the RB > tree using get_vma() is must be later freeed using put_vma(). Furthermore, > to allow the VMA to be used again by the classic page fault handler a > service is introduced can_reuse_spf_vma(). This service is expected to be > called with the mmap_sem hold. It checked that the VMA is still matching > the specified address and is releasing its reference count as the mmap_sem > is hold it is ensure that it will not be freed in our back. In general, the > VMA's reference count could be decremented when holding the mmap_sem but it > should not be increased as holding the mmap_sem is ensuring that the VMA is > stable. I can't see anymore the overhead I got while will-it-scale > benchmark anymore. > > The VMA's attributes checked during the speculative page fault processing > have to be protected against parallel changes. This is done by using a per > VMA sequence lock. This sequence lock allows the speculative page fault > handler to fast check for parallel changes in progress and to abort the > speculative page fault in that case. > > Once the VMA is found, the speculative page fault handler would check for > the VMA's attributes to verify that the page fault has to be handled > correctly or not. Thus the VMA is protected through a sequence lock which > allows fast detection of concurrent VMA changes. If such a change is > detected, the speculative page fault is aborted and a *classic* page fault > is tried. VMA sequence lockings are added when VMA attributes which are > checked during the page fault are modified. > > When the PTE is fetched, the VMA is checked to see if it has been changed, > so once the page table is locked, the VMA is valid, so any other changes > leading to touching this PTE will need to lock the page table, so no > parallel change is possible at this time. > > The locking of the PTE is done with interrupts disabled, this allows to > check for the PMD to ensure that there is not an ongoing collapsing > operation. Since khugepaged is firstly set the PMD to pmd_none and then is > waiting for the other CPU to have catch the IPI interrupt, if the pmd is > valid at the time the PTE is locked, we have the guarantee that the > collapsing opertion will have to wait on the PTE lock to move foward. This > allows the SPF handler to map the PTE safely. If the PMD value is different > than the one recorded at the beginning of the SPF operation, the classic > page fault handler will be called to handle the operation while holding the > mmap_sem. As the PTE lock is done with the interrupts disabled, the lock is > done using spin_trylock() to avoid dead lock when handling a page fault > while a TLB invalidate is requested by an other CPU holding the PTE. > > Support for THP is not done because when checking for the PMD, we can be > confused by an in progress collapsing operation done by khugepaged. The > issue is that pmd_none() could be true either if the PMD is not already > populated or if the underlying PTE are in the way to be collapsed. So we > cannot safely allocate a PMD if pmd_none() is true. > > This series a new software performance event named 'speculative-faults' or > 'spf'. It counts the number of successful page fault event handled in a > speculative way. When recording 'faults,spf' events, the faults one is > counting the total number of page fault events while 'spf' is only counting > the part of the faults processed in a speculative way. > > There are some trace
Re: [PATCH v3] drm/xen-front: Add support for Xen PV display frontend
On 03/21/2018 10:58 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Add support for Xen para-virtualized frontend display driver. Accompanying backend [1] is implemented as a user-space application and its helper library [2], capable of running as a Weston client or DRM master. Configuration of both backend and frontend is done via Xen guest domain configuration options [3]. I won't claim that I really understand what's going on here as far as DRM stuff is concerned but I didn't see any obvious issues with Xen bits. So for that you can tack on my Reviewed-by: Boris Ostrovsky
