Re: [PATCH 2/2] Revert "mfd: cros_ec: Use devm_kzalloc for private data"
On Wed, 20 Jun 2018, Dmitry Torokhov wrote: > This reverts commit 3aa2177e47878f7e7616da8a2050c44f22301b6e. > > Linux device objects are refcounted and thus should not be allocated > with devm API as they may outlive the timeframe of another device being > bound to a driver. > --- > drivers/mfd/cros_ec_dev.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] dma: add support for reporting pause and resume separately
Hi Marek,
On 02-07-18, 15:08, Marek Szyprowski wrote:
> 'cmd_pause' DMA channel capability means that respective DMA engine
> supports both pausing and resuming given DMA channel. However, in some
> cases it is important to know if DMA channel can be paused without the
> need to resume it. This is a typical requirement for proper residue
> reading on transfer timeout in UART drivers. There are also some DMA
> engines with limited hardware, which doesn't really support resuming.
Am curious given that your hardware does not support resume, what was motivation
for adding pause?
> Reporting pause and resume capabilities separately allows UART drivers to
> properly check for the really required capabilities and operate in DMA
> mode also in systems with limited DMA hardware. On the other hand drivers,
> which rely on full channel suspend/resume support, should now check for
> both 'pause' and 'resume' features.
>
> Existing clients of dma_get_slave_caps() have been checked and the only
> driver which rely on proper channel resuming is soc-generic-dmaengine-pcm
> driver, which has been updated to check the newly added capability.
> Existing 'cmd_pause' now only indicates that DMA engine support pausing
> given DMA channel.
The change looks fine to me. I was hoping that serial would also check
this..
Mark, Lars you okay with this?
>
> Signed-off-by: Marek Szyprowski
> ---
> This patch is a follow-up of the Vinod's advise from the following
> discussion:
> https://www.spinics.net/lists/linux-samsung-soc/msg63166.html
> ---
> drivers/dma/dmaengine.c | 8 ++--
> include/linux/dmaengine.h | 5 -
> sound/soc/soc-generic-dmaengine-pcm.c | 2 +-
> 3 files changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 08ba8473a284..84ac38dbdb65 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -500,12 +500,8 @@ int dma_get_slave_caps(struct dma_chan *chan, struct
> dma_slave_caps *caps)
> caps->max_burst = device->max_burst;
> caps->residue_granularity = device->residue_granularity;
> caps->descriptor_reuse = device->descriptor_reuse;
> -
> - /*
> - * Some devices implement only pause (e.g. to get residuum) but no
> - * resume. However cmd_pause is advertised as pause AND resume.
> - */
> - caps->cmd_pause = !!(device->device_pause && device->device_resume);
> + caps->cmd_pause = !!device->device_pause;
> + caps->cmd_resume = !!device->device_resume;
> caps->cmd_terminate = !!device->device_terminate_all;
>
> return 0;
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 861be5cab1df..c8c3a7a93802 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -415,7 +415,9 @@ enum dma_residue_granularity {
> * each type, the dma controller should set BIT() and same
> * should be checked by controller as well
> * @max_burst: max burst capability per-transfer
> - * @cmd_pause: true, if pause and thereby resume is supported
> + * @cmd_pause: true, if pause is supported (i.e. for reading residue or
> + * for resume later)
> + * @cmd_resume: true, if resume is supported
> * @cmd_terminate: true, if terminate cmd is supported
> * @residue_granularity: granularity of the reported transfer residue
> * @descriptor_reuse: if a descriptor can be reused by client and
> @@ -427,6 +429,7 @@ struct dma_slave_caps {
> u32 directions;
> u32 max_burst;
> bool cmd_pause;
> + bool cmd_resume;
> bool cmd_terminate;
> enum dma_residue_granularity residue_granularity;
> bool descriptor_reuse;
> diff --git a/sound/soc/soc-generic-dmaengine-pcm.c
> b/sound/soc/soc-generic-dmaengine-pcm.c
> index 56a541b9ff9e..76c46d793843 100644
> --- a/sound/soc/soc-generic-dmaengine-pcm.c
> +++ b/sound/soc/soc-generic-dmaengine-pcm.c
> @@ -156,7 +156,7 @@ static int dmaengine_pcm_set_runtime_hwparams(struct
> snd_pcm_substream *substrea
>
> ret = dma_get_slave_caps(chan, &dma_caps);
> if (ret == 0) {
> - if (dma_caps.cmd_pause)
> + if (dma_caps.cmd_pause && dma_caps.cmd_resume)
> hw.info |= SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME;
> if (dma_caps.residue_granularity <=
> DMA_RESIDUE_GRANULARITY_SEGMENT)
> hw.info |= SNDRV_PCM_INFO_BATCH;
> --
> 2.17.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
~Vinod
Re: [PATCH] mm/memblock: replace u64 with phys_addr_t where appropriate
On Tue, Jul 03, 2018 at 12:57:22PM -0700, Andrew Morton wrote:
> On Tue, 3 Jul 2018 20:05:06 +0300 Mike Rapoport
> wrote:
>
> > Most functions in memblock already use phys_addr_t to represent a physical
> > address with __memblock_free_late() being an exception.
> >
> > This patch replaces u64 with phys_addr_t in __memblock_free_late() and
> > switches several format strings from %llx to %pa to avoid casting from
> > phys_addr_t to u64.
> >
> > ...
> >
> > @@ -1343,9 +1343,9 @@ void * __init memblock_virt_alloc_try_nid_raw(
> > {
> > void *ptr;
> >
> > - memblock_dbg("%s: %llu bytes align=0x%llx nid=%d from=0x%llx
> > max_addr=0x%llx %pF\n",
> > -__func__, (u64)size, (u64)align, nid, (u64)min_addr,
> > -(u64)max_addr, (void *)_RET_IP_);
> > + memblock_dbg("%s: %llu bytes align=0x%llx nid=%d from=%pa max_addr=%pa
> > %pF\n",
> > +__func__, (u64)size, (u64)align, nid, &min_addr,
> > +&max_addr, (void *)_RET_IP_);
> >
>
> Did you see all this checkpatch noise?
>
> : WARNING: Deprecated vsprintf pointer extension '%pF' - use %pS instead
> : #54: FILE: mm/memblock.c:1348:
> : + memblock_dbg("%s: %llu bytes align=0x%llx nid=%d from=%pa max_addr=%pa
> %pF\n",
> : +__func__, (u64)size, (u64)align, nid, &min_addr,
> : +&max_addr, (void *)_RET_IP_);
> : ...
> :
Sorry, my bad...
> * - 'S' For symbolic direct pointers (or function descriptors) with offset
> * - 's' For symbolic direct pointers (or function descriptors) without offset
> * - 'F' Same as 'S'
> * - 'f' Same as 's'
>
> I'm not sure why or when all that happened.
>
> I suppose we should do that as a separate patch sometime.
>
--
Sincerely yours,
Mike.
linux-kernel@vger.kernel.org
FYI, we noticed the following commit (built with gcc-7):
commit: 32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f ("[PATCH] perf tests: Fix
regex for record+probe_libc_inet_pton.sh")
url:
https://github.com/0day-ci/linux/commits/Sandipan-Das/perf-tests-Fix-regex-for-record-probe_libc_inet_pton-sh/20180521-130408
in testcase: perf-sanity-tests
with following parameters:
perf_compiler: gcc
on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
2018-05-22 17:41:14 sudo
/usr/src/linux-perf-x86_64-fedora-25-32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f/tools/perf/perf
test 62
62: probe libc's inet_pton & backtrace it with ping : FAILED!
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
Xiaolong
#!/bin/sh
export_top_env()
{
export suite='perf-sanity-tests'
export testcase='perf-sanity-tests'
export category='functional'
export
job_origin='/lkp/lkp/src/allot/rand/vm-lkp-nex04-8G/perf-sanity-tests.yaml'
export testbox='vm-lkp-nex04-8G-2'
export tbox_group='vm-lkp-nex04-8G'
export kconfig='x86_64-fedora-25'
export compiler='gcc-7'
export queue='bisect'
export branch='linux-devel/devel-spot-201805211347'
export commit='32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f'
export submit_id='5b03dff30b9a932b3a767d71'
export
job_file='/lkp/scheduled/vm-lkp-nex04-8G-2/perf-sanity-tests-gcc-debian-x86_64-2016-08-31.cgz-32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f-20180522-11066-yve2a-1.yaml'
export id='1bdd8b616b538b8db798a8cdad4603b67ca4566f'
export model='qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3'
export nr_vm=10
export nr_cpu=2
export memory='8G'
export hdd_partitions='/dev/vda'
export need_linux_perf=true
export need_kconfig='CONFIG_KVM_GUEST=y'
export ssh_base_port=23250
export rootfs='debian-x86_64-2016-08-31.cgz'
export enqueue_time='2018-05-22 17:16:35 +0800'
export _id='5b03e2ff0b9a932b3a767d72'
export
_rt='/result/perf-sanity-tests/gcc/vm-lkp-nex04-8G/debian-x86_64-2016-08-31.cgz/x86_64-fedora-25/gcc-7/32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f'
export user='lkp'
export
result_root='/result/perf-sanity-tests/gcc/vm-lkp-nex04-8G/debian-x86_64-2016-08-31.cgz/x86_64-fedora-25/gcc-7/32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f/0'
export LKP_SERVER='inn'
export max_uptime=3600
export initrd='/osimage/debian/debian-x86_64-2016-08-31.cgz'
export bootloader_append='root=/dev/ram0
user=lkp
job=/lkp/scheduled/vm-lkp-nex04-8G-2/perf-sanity-tests-gcc-debian-x86_64-2016-08-31.cgz-32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f-20180522-11066-yve2a-1.yaml
ARCH=x86_64
kconfig=x86_64-fedora-25
branch=linux-devel/devel-spot-201805211347
commit=32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f
BOOT_IMAGE=/pkg/linux/x86_64-fedora-25/gcc-7/32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f/vmlinuz-4.17.0-rc5-00073-g32a4deb
max_uptime=3600
RESULT_ROOT=/result/perf-sanity-tests/gcc/vm-lkp-nex04-8G/debian-x86_64-2016-08-31.cgz/x86_64-fedora-25/gcc-7/32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f/0
LKP_SERVER=inn
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
console=tty0
earlyprintk=ttyS0,115200
console=ttyS0,115200
vga=normal
rw'
export
modules_initrd='/pkg/linux/x86_64-fedora-25/gcc-7/32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f/modules.cgz'
export
bm_initrd='/osimage/deps/debian-x86_64-2016-08-31.cgz/run-ipconfig_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/lkp_2018-05-14.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/rsync-rootfs_2016-11-15.cgz,/osimage/deps/debian-x86_64-2016-08-31.cgz/perf-sanity-tests_2017-12-29.cgz,/osimage/pkg/debian-x86_64-2016-08-31.cgz/perf-x86_64-771c577c23ba_2018-05-21.cgz'
export
linux_perf_initrd='/pkg/linux/x86_64-fedora-25/gcc-7/32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f/linux-perf.cgz'
export lkp_initrd='/lkp/lkp/lkp-x86_64.cgz'
export site='inn'
export LKP_CGI_PORT=80
export LKP_CIFS_PORT=139
export
kernel='/pkg/linux/x86_64-fedora-25/gcc-7/32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f/vmlinuz-4.17.0-rc5-00073-g32a4deb'
export dequeue_time='2018-05-22 17:33:08 +0800'
export
job_initrd='/lkp/scheduled/vm-lkp-nex04-8G-2/perf-sanity-tests-gcc-debian-x86_64-2016-08-31.cgz-32a4debc7c89ee5e29c0bbdfdd3ae0ce0e01057f-20180522-11066-yve2a-1.cgz'
[ -n "$LKP_SRC" ] ||
export LKP_SRC=/lkp/${user:-lkp}/src
}
run_job()
{
echo $$ > $TMP/
Re: [PATCH] mm/memblock: replace u64 with phys_addr_t where appropriate
On Tue, Jul 03, 2018 at 01:24:07PM -0700, Joe Perches wrote:
> On Tue, 2018-07-03 at 12:57 -0700, Andrew Morton wrote:
> > Did you see all this checkpatch noise?
> >
> > : WARNING: Deprecated vsprintf pointer extension '%pF' - use %pS instead
> > : #54: FILE: mm/memblock.c:1348:
> > : + memblock_dbg("%s: %llu bytes align=0x%llx nid=%d from=%pa max_addr=%pa
> > %pF\n",
> > : + __func__, (u64)size, (u64)align, nid, &min_addr,
> > : + &max_addr, (void *)_RET_IP_);
> > : ...
>
> %p[Ff] got deprecated by commit 04b8eb7a4ccd9ef9343e2720ccf2a5db8cfe2f67
>
> I think it'd be simplest to just convert
> all the %pF and %pf uses all at once.
>
> $ git grep --name-only "%p[Ff]" | \
> xargs sed -i -e 's/%pF/%pS/' -e 's/%pf/%ps/'
>
> and remove the appropriate Documentation bit.
>
Something like this:
>From 0d3e7cf494123c2640b9a892160d2e2430787004 Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Wed, 4 Jul 2018 09:55:50 +0300
Subject: [PATCH] treewide: retire '%pF/%pf'
%p[Ff] got deprecated by commit 04b8eb7a4ccd9ef9343e2720ccf2a5db8cfe2f67
("symbol lookup: introduce dereference_symbol_descriptor()")
Replace their uses with %p[Ss] with
$ git grep --name-only "%p[Ff]" | \
xargs sed -i -e 's/%pF/%pS/' -e 's/%pf/%ps/'
Suggested-by: Joe Perches
Signed-off-by: Mike Rapoport
---
Documentation/core-api/printk-formats.rst | 10 --
arch/alpha/kernel/pci_iommu.c | 20 ++--
arch/arm/mm/alignment.c | 2 +-
arch/arm/nwfpe/fpmodule.c | 2 +-
arch/microblaze/mm/pgtable.c | 2 +-
arch/sparc/kernel/ds.c| 2 +-
arch/um/kernel/sysrq.c| 2 +-
arch/x86/include/asm/trace/exceptions.h | 2 +-
arch/x86/kernel/irq_64.c | 2 +-
arch/x86/mm/extable.c | 4 ++--
arch/x86/xen/multicalls.c | 2 +-
drivers/acpi/device_pm.c | 2 +-
drivers/base/power/main.c | 6 +++---
drivers/base/syscore.c| 12 ++--
drivers/block/drbd/drbd_receiver.c| 2 +-
drivers/block/floppy.c| 10 +-
drivers/cpufreq/cpufreq.c | 2 +-
drivers/md/bcache/closure.c | 4 ++--
drivers/mmc/core/quirks.h | 2 +-
drivers/nvdimm/bus.c | 2 +-
drivers/nvdimm/dimm_devs.c| 2 +-
drivers/pci/pci-driver.c | 14 +++---
drivers/pci/quirks.c | 4 ++--
drivers/pnp/quirks.c | 2 +-
drivers/scsi/esp_scsi.c | 2 +-
fs/btrfs/tests/free-space-tree-tests.c| 4 ++--
fs/f2fs/f2fs.h| 2 +-
fs/pstore/inode.c | 2 +-
fs/xfs/scrub/trace.h | 2 +-
include/trace/events/btrfs.h | 2 +-
include/trace/events/cpuhp.h | 4 ++--
include/trace/events/preemptirq.h | 2 +-
include/trace/events/rcu.h| 4 ++--
include/trace/events/sunrpc.h | 2 +-
include/trace/events/timer.h | 8
include/trace/events/vmscan.h | 4 ++--
include/trace/events/workqueue.h | 4 ++--
include/trace/events/xen.h| 2 +-
init/main.c | 6 +++---
kernel/async.c| 4 ++--
kernel/events/uprobes.c | 2 +-
kernel/fail_function.c| 2 +-
kernel/irq/debugfs.c | 2 +-
kernel/irq/handle.c | 2 +-
kernel/irq/manage.c | 2 +-
kernel/irq/spurious.c | 4 ++--
kernel/rcu/tree.c | 2 +-
kernel/stop_machine.c | 2 +-
kernel/time/sched_clock.c | 2 +-
kernel/time/timer.c | 2 +-
kernel/workqueue.c| 12 ++--
lib/error-inject.c| 2 +-
lib/percpu-refcount.c | 4 ++--
lib/vsprintf.c| 8 ++--
mm/memblock.c | 16
mm/memory.c | 2 +-
mm/vmscan.c | 2 +-
net/ceph/osd_client.c | 2 +-
net/core/net-procfs.c | 2 +-
net/core/netpoll.c| 4 ++--
tools/lib/traceevent/event-parse.c| 4 ++--
61 files changed, 117 insertions(+), 131 deletions(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentation/core-api/printk-formats.rst
index 25dc591..302af61 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -70,8 +70,6 @@ Symbols/Function Pointers
%pS versatile_init+0x0/0x110
%ps versatile_init
- %pF versatile_init+0x0/
Re: [PATCH 1/4] i2c: imx: Fix reinit_completion() use
Cc += Yuan Yao who authored DMA support and the NXP team.
On Wed, May 23, 2018 at 11:56:20AM +0200, Esben Haabendal wrote:
> From: Esben Haabendal
>
> Make sure to call reinit_completion() before dma is started to avoid race
> condition where reinit_compleition() is called after complete() and before
s/compleition/completion/
> wait_for_completion_timeout().
Is this a theoretical problem, or did it trigger on your side?
> Signed-off-by: Esben Haabendal
Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
Reviewed-by: Uwe Kleine-König
> ---
> drivers/i2c/busses/i2c-imx.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index d7267dd9c7bf..6fca5e64cffb 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -377,6 +377,7 @@ static int i2c_imx_dma_xfer(struct imx_i2c_struct
> *i2c_imx,
> goto err_desc;
> }
>
> + reinit_completion(&dma->cmd_complete);
> txdesc->callback = i2c_imx_dma_callback;
> txdesc->callback_param = i2c_imx;
> if (dma_submit_error(dmaengine_submit(txdesc))) {
> @@ -631,7 +632,6 @@ static int i2c_imx_dma_write(struct imx_i2c_struct
> *i2c_imx,
>* The first byte must be transmitted by the CPU.
>*/
> imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
> - reinit_completion(&i2c_imx->dma->cmd_complete);
> time_left = wait_for_completion_timeout(
> &i2c_imx->dma->cmd_complete,
> msecs_to_jiffies(DMA_TIMEOUT));
> @@ -690,7 +690,6 @@ static int i2c_imx_dma_read(struct imx_i2c_struct
> *i2c_imx,
> if (result)
> return result;
>
> - reinit_completion(&i2c_imx->dma->cmd_complete);
> time_left = wait_for_completion_timeout(
> &i2c_imx->dma->cmd_complete,
> msecs_to_jiffies(DMA_TIMEOUT));
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v1] ARM: dts: imx6sl-evk: keep sw4 always on
Hi, On Wed, 4 Jul 2018 01:42:54 + Robin Gong wrote: > On 二, 2018-07-03 at 08:10 -0300, Fabio Estevam wrote: > > Hi Anson, > > > > On Tue, Jul 3, 2018 at 4:44 AM, Anson Huang > > wrote: > > > > > > > > It is NOT easy to identify which switch is critical or NOT, and > > > different platforms > > > have different board design, it will introduce many platform > > > specified code, so I think > > > just revert the pfuze100 switch enable/disable patch should be OK > > > for now. > > I have sent the pfuze100 regulator patch revert and it is linux-next > > now. Should probably reach 4.18-rc4. > > > > > > > > After a couple of release cycles, add the pfuze100 switch > > > enable/disable patch > > > back to support this feature, I believe users should switch to new > > > dtb with "regulator-always-on" > > > existing already. > > That will still break old dtb compatibility. > > > > You cannot force users to use "regulator-always-on" and the old dtbs > > need to always work. > > > > So whatever new feature you need to introduce it needs to be done in > > such a way that the existing dtb's will continue working. > But actually existing dtb is not right since the critical power rail > missing 'regulator-always-on'. It's a fix patch for dts, not related > with following dtb/kernel break rules, just a simple dts patch. Why > should we make promise for the wrong dtbs? > Because they are living in the outside world on real devices. Lothar Waßmann
Offerte
Sehr geehrte Damen und Herren, ich habe bemerkt, dass Sie Ihr Angebot zum größten Teil an Firmen richten und deswegen möchte ich Ihnen ein Produkt anbieten, welches zur Erhöhung der Anzahl Ihrer Kunden erheblich beitragen wird. Die Datenbanken der Firmen sind in für Sie interessante und relevante Zielgruppen untergliedert. Der neue Katalog enthält 187.764 schweizerische Firmen und stellt solche Daten zur Verfügung wie: Namen der Firma, Firmenanschrift, Kontaktdaten des Firmeninhabers oder des Managers, E-Mail-Adresse, Telefonummer, Faxnummer, Branche usw. http://www.topadressen-ch.net/?page=catalog *** 1. Schweiz 2018 ( 187 764 ) - 149 EUR ( bis zum 04.07.2018 ) *** Die Verwendungsmöglichkeiten der Datenbanken sind praktisch unbegrenzt und Sie können durch Verwendung der von uns entwickelten Programme des personalisierten Versendens von Angeboten u.ä. mittels E-mailing bzw. Fax effektive und sichere Werbekampagnen damit durchführen. Bitte informieren Sie sich über die weiteren Details einmal unverbindlich auf unseren Webseite: http://www.topadressen-ch.net/?page=catalog MfG GL-Team
Re: [PATCH v2 01/32] mtd: rawnand: add hooks that may be called during nand_scan()
Hi Miquel,
On Tue, 3 Jul 2018 23:59:58 +0200
Miquel Raynal wrote:
> In order to remove the limitation that forbids dynamic allocation in
> nand_scan_ident(), we must create a path that will be the same for all
> controller drivers. The idea is to use nand_scan() instead of the widely
> implemented nand_scan_ident()/nand_scan_tail() couple. In order to
> achieve this, controller drivers will need to adjust some parameters
> between these two functions depending on the NAND chip wired on them.
>
> For that, a hook called ->attach_chip() is created in the
> nand_hw_control structure. This structure may be referenced by two ways:
> 1/ if the driver does not implement its own controller, the
>chip->controller hook is not populated before nand_scan() so it
>cannot be dereferenced: use chip->hwcontrol instead (which is
>statically allocated and will be referenced later by chip->controller
>anyway).
> 2/ through chip->controller if the driver implements its own controller.
>
> Another hook, ->detach_chip() is also introduced in order to clean the
> controller driver's potential allocations in case of failure of
> nand_scan_tail(). There is no need for the controller driver to call the
> ->detach_chip() hook directly upon error after a successful nand_scan().
> In this situation, calling nand_release() as before is enough.
>
> Signed-off-by: Miquel Raynal
> ---
> drivers/mtd/nand/raw/nand_base.c | 21 +++--
> include/linux/mtd/rawnand.h | 6 ++
> 2 files changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/nand_base.c
> b/drivers/mtd/nand/raw/nand_base.c
> index faac82b1e058..97a74d48b0cf 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -6712,11 +6712,23 @@ EXPORT_SYMBOL(nand_scan_tail);
> int nand_scan_with_ids(struct mtd_info *mtd, int maxchips,
> struct nand_flash_dev *ids)
> {
> + struct nand_chip *chip = mtd_to_nand(mtd);
> int ret;
>
> ret = nand_scan_ident(mtd, maxchips, ids);
> - if (!ret)
> - ret = nand_scan_tail(mtd);
> + if (ret)
> + return ret;
> +
> + if (chip->controller->attach_chip) {
> + ret = chip->controller->attach_chip(chip);
> + if (ret)
> + return ret;
> + }
> +
> + ret = nand_scan_tail(mtd);
> + if (ret && chip->controller->detach_chip)
> + chip->controller->detach_chip(chip);
> +
> return ret;
> }
> EXPORT_SYMBOL(nand_scan_with_ids);
> @@ -6744,7 +6756,12 @@ void nand_cleanup(struct nand_chip *chip)
>
> /* Free manufacturer priv data. */
> nand_manufacturer_cleanup(chip);
> +
> + /* Free controller specific allocations after chip identification */
> + if (chip->controller->detach_chip)
> + chip->controller->detach_chip(chip);
> }
> +
> EXPORT_SYMBOL_GPL(nand_cleanup);
>
> /**
> diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
> index 0c6fb316b409..81654211e520 100644
> --- a/include/linux/mtd/rawnand.h
> +++ b/include/linux/mtd/rawnand.h
> @@ -517,11 +517,17 @@ struct nand_id {
> * @wq: wait queue to sleep on if a NAND operation is in
> * progress used instead of the per chip wait queue
> * when a hw controller is available.
> + * @attach_chip: Callback that may be called between nand_detect() and
> + * nand_scan_tail() during nand_scan() (optional).
> + * @detach_chip: Callback that may be called if nand_scan_tail() fails
> + * (optional).
> */
> struct nand_hw_control {
> spinlock_t lock;
> struct nand_chip *active;
> wait_queue_head_t wq;
> + int (*attach_chip)(struct nand_chip *chip);
> + void (*detach_chip)(struct nand_chip *chip);
> };
Can we instead declare a nand_controller_ops struct and then have
nand_hw_control point to it. Something like:
struct nand_controller_ops {
int (*attach_chip)(struct nand_chip *chip);
void (*detach_chip)(struct nand_chip *chip);
};
struct nand_hw_control {
...
const struct nand_controller_ops *ops;
};
>
> static inline void nand_hw_control_init(struct nand_hw_control *nfc)
Regards,
Boris
Re: [PATCH v4 08/18] net: davinci_emac: potentially get the MAC address from MTD
On Tue, Jul 03, 2018 at 09:39:51AM -0700, Florian Fainelli wrote:
>
>
> On 06/29/2018 02:40 AM, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski
> >
> > On da850-evm board we can read the MAC address from MTD. It's currently
> > done in the relevant board file, but we want to get rid of all the MAC
> > reading callbacks from the board file (SPI and NAND). Move the reading
> > of the MAC address from SPI to the emac driver's probe function.
>
> This should be made something generic to all drivers, not just something
> the davinci_emac driver does, something like this actually:
>
> https://lkml.org/lkml/2018/3/24/312
...and that's would also make it work when MAC address is stored
in 24c08 EEPROM, which is quite common.
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > drivers/net/ethernet/ti/davinci_emac.c | 20 ++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/ti/davinci_emac.c
> > b/drivers/net/ethernet/ti/davinci_emac.c
> > index a1a6445b5a7e..48e6a7755811 100644
> > --- a/drivers/net/ethernet/ti/davinci_emac.c
> > +++ b/drivers/net/ethernet/ti/davinci_emac.c
> > @@ -67,7 +67,7 @@
> > #include
> > #include
> > #include
> > -
> > +#include
> > #include
> > #include
> >
> > @@ -1783,7 +1783,10 @@ static int davinci_emac_probe(struct platform_device
> > *pdev)
> > struct cpdma_params dma_params;
> > struct clk *emac_clk;
> > unsigned long emac_bus_frequency;
> > -
> > +#ifdef CONFIG_MTD
> > + size_t mac_addr_len;
> > + struct mtd_info *mtd;
> > +#endif /* CONFIG_MTD */
> >
> > /* obtain emac clock from kernel */
> > emac_clk = devm_clk_get(&pdev->dev, NULL);
> > @@ -1815,6 +1818,19 @@ static int davinci_emac_probe(struct platform_device
> > *pdev)
> > goto err_free_netdev;
> > }
> >
> > +#ifdef CONFIG_MTD
> > + mtd = get_mtd_device_nm("MAC-Address");
> > + if (!IS_ERR(mtd)) {
> > + rc = mtd_read(mtd, 0, ETH_ALEN,
> > + &mac_addr_len, priv->mac_addr);
> > + if (rc == 0)
> > + dev_info(&pdev->dev,
> > +"Read MAC addr from SPI Flash: %pM\n",
> > +priv->mac_addr);
> > + put_mtd_device(mtd);
> > + }
> > +#endif /* CONFIG_MTD */
> > +
> > /* MAC addr and PHY mask , RMII enable info from platform_data */
> > memcpy(priv->mac_addr, pdata->mac_addr, ETH_ALEN);
> > priv->phy_id = pdata->phy_id;
> >
>
> --
> Florian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 02/32] mtd: rawnand: brcmnand: convert driver to nand_scan()
On Tue, 3 Jul 2018 23:59:59 +0200
Miquel Raynal wrote:
> Two helpers have been added to the core to make ECC-related
> configuration between the detection phase and the final NAND scan. Use
> these hooks and convert the driver to just use nand_scan() instead of
> both nand_scan_ident() and nand_scan_tail().
>
> Signed-off-by: Miquel Raynal
> ---
> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 43
> ++--
> 1 file changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> index 1306aaa7a8bf..99ab7b93756c 100644
> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> @@ -2208,6 +2208,28 @@ static int brcmnand_setup_dev(struct brcmnand_host
> *host)
> return 0;
> }
>
> +static int brcmnand_attach_chip(struct nand_chip *chip)
> +{
> + struct mtd_info *mtd = nand_to_mtd(chip);
> + struct brcmnand_host *host = nand_get_controller_data(chip);
> + int ret;
> +
> + if (chip->bbt_options & NAND_BBT_USE_FLASH)
> + chip->bbt_options |= NAND_BBT_NO_OOB;
> +
> + if (brcmnand_setup_dev(host))
> + return -ENXIO;
> +
> + chip->ecc.size = host->hwcfg.sector_size_1k ? 1024 : 512;
> +
> + /* only use our internal HW threshold */
> + mtd->bitflip_threshold = 1;
> +
> + ret = brcmstb_choose_ecc_layout(host);
> +
> + return ret;
> +}
> +
> static int brcmnand_init_cs(struct brcmnand_host *host, struct device_node
> *dn)
> {
> struct brcmnand_controller *ctrl = host->ctrl;
> @@ -2267,10 +2289,6 @@ static int brcmnand_init_cs(struct brcmnand_host
> *host, struct device_node *dn)
> nand_writereg(ctrl, cfg_offs,
> nand_readreg(ctrl, cfg_offs) & ~CFG_BUS_WIDTH);
>
> - ret = nand_scan_ident(mtd, 1, NULL);
> - if (ret)
> - return ret;
> -
> chip->options |= NAND_NO_SUBPAGE_WRITE;
> /*
>* Avoid (for instance) kmap()'d buffers from JFFS2, which we can't DMA
> @@ -2279,21 +2297,8 @@ static int brcmnand_init_cs(struct brcmnand_host
> *host, struct device_node *dn)
>*/
> chip->options |= NAND_USE_BOUNCE_BUFFER;
>
> - if (chip->bbt_options & NAND_BBT_USE_FLASH)
> - chip->bbt_options |= NAND_BBT_NO_OOB;
> -
> - if (brcmnand_setup_dev(host))
> - return -ENXIO;
> -
> - chip->ecc.size = host->hwcfg.sector_size_1k ? 1024 : 512;
> - /* only use our internal HW threshold */
> - mtd->bitflip_threshold = 1;
> -
> - ret = brcmstb_choose_ecc_layout(host);
> - if (ret)
> - return ret;
> -
> - ret = nand_scan_tail(mtd);
> + chip->controller->attach_chip = brcmnand_attach_chip;
Hm, this assignment should be done once, when initializing the
controller (in brcmnand_probe()), not every time you add a NAND chip.
> + ret = nand_scan(mtd, 1);
> if (ret)
> return ret;
>
Re: [PATCH v2] gpiolib: Defer on non-DT find_chip_by_name() failure
On Wed, 4 Jul 2018 00:18:19 +0200 Janusz Krzysztofik wrote: > Avoid replication of error code conversion in non-DT GPIO consumers' > code by returning -EPROBE_DEFER from gpiod_find() in case a chip > identified by its label in a registered lookup table is not ready. > > See https://lkml.org/lkml/2018/5/30/176 for example case. > > Suggested-by: Boris Brezillon > Signed-off-by: Janusz Krzysztofik > Reviewed-by: Boris Brezillon > --- > Changelog > v2: fix typo (latar -> later) - thanks Boris and Andy for catching this > > I'm not sure if adding both Suggested-by: and Reviewed-by: heades both > with the same person name is in line with good practices, please remove > one if not. I don't think that's a problem. Suggesting a solution and agreeing on the implementation are 2 different things, so both are not mutually exclusive IMO.
Re: [PATCH 3/3] clk: meson: add sub EMMC clock controller driver
Hi Martin
On 07/04/18 02:58, Martin Blumenstingl wrote:
> Hi Yixun,
>
> apart from what Jerome found this looks good to me.
> one small "issue" and a question are inline below
>
> On Tue, Jul 3, 2018 at 9:00 AM Yixun Lan wrote:
>>
>> This patch will add a EMMC clock controller driver support,
>> It provide a mux and divider clock.
>>
>> This clock driver can be protentially used by either EMMC and
>> NAND driver.
>>
>> Signed-off-by: Yixun Lan
>> ---
>> drivers/clk/meson/Kconfig | 9 +++
>> drivers/clk/meson/Makefile| 1 +
>> drivers/clk/meson/emmc-clkc.c | 136 ++
>> 3 files changed, 146 insertions(+)
>> create mode 100644 drivers/clk/meson/emmc-clkc.c
>>
>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>> index efaa70f682b4..2f27ff08e4eb 100644
>> --- a/drivers/clk/meson/Kconfig
>> +++ b/drivers/clk/meson/Kconfig
>> @@ -15,6 +15,15 @@ config COMMON_CLK_MESON_AO
>> select COMMON_CLK_REGMAP_MESON
>> select RESET_CONTROLLER
>>
>> +config COMMON_CLK_EMMC_MESON
>> + tristate "Meson EMMC Sub Clock Controller Driver"
>> + depends on COMMON_CLK_AMLOGIC
>> + select MFD_SYSCON
>> + select REGMAP
>> + help
>> + Support for the EMMC sub clock controller on AmLogic Meson
>> Platform,
>> + Say Y if you want this clock enabled.
>> +
>> config COMMON_CLK_REGMAP_MESON
>> bool
>> select REGMAP
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index 72ec8c40d848..2f04f77ba4de 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -9,4 +9,5 @@ obj-$(CONFIG_COMMON_CLK_MESON8B) += meson8b.o
>> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o gxbb-aoclk-32k.o
>> obj-$(CONFIG_COMMON_CLK_AXG)+= axg.o axg-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
>> +obj-$(CONFIG_COMMON_CLK_EMMC_MESON)+= emmc-clkc.o
>> obj-$(CONFIG_COMMON_CLK_REGMAP_MESON) += clk-regmap.o
>> diff --git a/drivers/clk/meson/emmc-clkc.c b/drivers/clk/meson/emmc-clkc.c
>> new file mode 100644
>> index ..cf5bb9f34327
>> --- /dev/null
>> +++ b/drivers/clk/meson/emmc-clkc.c
>> @@ -0,0 +1,136 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Amlogic Meson EMMC Sub Clock Controller Driver
>> + *
>> + * Copyright (c) 2018 Amlogic, inc.
>> + * Author: Yixun Lan
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +#include "clkc.h"
>> +
>> +#define SD_EMMC_CLOCK 0
>> +#define MUX_CLK_NUM_PARENTS2
>> +#define EMMC_MAX_CLKS 2
>> +#define CLK_NAME_LEN 48
>> +
>> +static struct clk_regmap_mux_data emmc_clkc_mux_data = {
>> + .offset = SD_EMMC_CLOCK,
>> + .mask = 0x3,
>> + .shift = 6,
>> +};
>> +
>> +static struct clk_regmap_div_data emmc_clkc_div_data = {
>> + .offset = SD_EMMC_CLOCK,
>> + .shift = 0,
>> + .width = 6,
>> + .flags = CLK_DIVIDER_ROUND_CLOSEST | CLK_DIVIDER_ONE_BASED,
>> +};
>> +
>> +static const struct of_device_id clkc_match_table[] = {
>> + { .compatible = "amlogic,emmc-clkc" },
> shouldn't this be "amlogic,meson-axg-emmc-clkc" (and optionally also
> "amlogic,meson-gx-emmc-clkc")?
>
sounds good to me..
is it a convention to always make the compatible specific ?..
>> + {}
>> +};
>> +
>> +static int emmc_clkc_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct clk_regmap *mux, *div;
>> + struct regmap *map;
>> + struct clk *clk;
>> + int i, ret;
>> + const char *parent_names[MUX_CLK_NUM_PARENTS];
>> + struct clk_init_data init;
>> + char mux_name[CLK_NAME_LEN], div_name[CLK_NAME_LEN];
>> + struct clk_hw_onecell_data *onecell_data;
>> +
>> + map = syscon_node_to_regmap(dev->of_node);
>> +
>> + mux = devm_kzalloc(dev, sizeof(*mux), GFP_KERNEL);
>> + div = devm_kzalloc(dev, sizeof(*div), GFP_KERNEL);
>> +
>> + onecell_data = devm_kzalloc(dev, sizeof(*onecell_data) +
>> + sizeof(*onecell_data->hws) *
>> EMMC_MAX_CLKS,
>> + GFP_KERNEL);
>> +
>> + if (!mux || !div || !onecell_data)
>> + return -ENOMEM;
>> +
>> + for (i = 0; i < MUX_CLK_NUM_PARENTS; i++) {
>> + char name[8];
>> +
>> + snprintf(name, sizeof(name), "clkin%d", i);
>> + clk = devm_clk_get(dev, name);
>> + if (IS_ERR(clk)) {
>> + if (clk != ERR_PTR(-EPROBE_DEFER))
>> + dev_err(dev, "Missing clock %s\n", name);
>> + return PTR_ERR(clk);
>> + }
>> +
>> + parent_names[i] = __clk_get_name(clk);
>> + }
>> +
>> + mux->map = map;
>> + mux->data = &emmc_clkc_mux_data;
>> +
>>
Re: [RFC PATCH 3/4] misc: Add bmc-misc-ctrl
On Tue, 3 Jul 2018, at 17:24, Greg KH wrote:
> On Tue, Jul 03, 2018 at 05:04:12PM +1000, Andrew Jeffery wrote:
> > bmc-misc-ctrl is used to expose miscellaneous Baseboard
> > Management Controller (BMC) hardware features described in the devicetree
> > to userspace.
> >
> > Signed-off-by: Andrew Jeffery
> > ---
> > MAINTAINERS | 1 +
> > drivers/misc/Kconfig | 8 +
> > drivers/misc/Makefile| 1 +
> > drivers/misc/bmc-misc-ctrl.c | 363 +++
> > 4 files changed, 373 insertions(+)
> > create mode 100644 drivers/misc/bmc-misc-ctrl.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 9766d7832d8b..30d39440b6f2 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2741,6 +2741,7 @@ R:Andrew Jeffery
> > L: open...@lists.ozlabs.org (moderated for non-subscribers)
> > S: Supported
> > F: Documentation/devicetree/bindings/misc/bmc-misc-ctrl.txt
> > +F: drivers/misc/bmc-misc-ctrl.c
> >
> > BPF (Safe dynamic programs and tools)
> > M: Alexei Starovoitov
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 3726eacdf65d..f46bc8208b50 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -513,6 +513,14 @@ config MISC_RTSX
> > tristate
> > default MISC_RTSX_PCI || MISC_RTSX_USB
> >
> > +config BMC_MISC_CTRL
> > + tristate "Miscellaneous BMC Control Interfaces"
> > + depends on REGMAP && MFD_SYSCON
> > + help
> > + Say yes to expose scratch registers used to communicate between the
> > + host and BMC along with other miscellaneous control interfaces
> > + provided by BMC SoCs
> > +
> > source "drivers/misc/c2port/Kconfig"
> > source "drivers/misc/eeprom/Kconfig"
> > source "drivers/misc/cb710/Kconfig"
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index af22bbc3d00c..4fb2fac7a486 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -58,3 +58,4 @@ obj-$(CONFIG_ASPEED_LPC_SNOOP)+= aspeed-lpc-snoop.o
> > obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
> > obj-$(CONFIG_OCXL) += ocxl/
> > obj-$(CONFIG_MISC_RTSX)+= cardreader/
> > +obj-$(CONFIG_BMC_MISC_CTRL) += bmc-misc-ctrl.o
> > diff --git a/drivers/misc/bmc-misc-ctrl.c b/drivers/misc/bmc-misc-ctrl.c
> > new file mode 100644
> > index ..ff907029163f
> > --- /dev/null
> > +++ b/drivers/misc/bmc-misc-ctrl.c
> > @@ -0,0 +1,363 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +// Copyright 2018 IBM Corp.
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct bmc_ctrl {
> > + struct device *dev;
> > + struct regmap *map;
> > + bool ro;
> > + u32 shift;
> > + u32 mask;
> > + struct kobj_attribute mask_attr;
> > + const char *label;
> > + struct kobj_attribute label_attr;
> > + union {
> > + struct {
> > + u32 value;
> > + struct kobj_attribute value_attr;
> > + };
> > + struct {
> > + u32 read;
> > + u32 set;
> > + u32 clear;
> > + struct kobj_attribute read_attr;
> > + struct kobj_attribute set_attr;
> > + struct kobj_attribute clear_attr;
> > + };
>
> What is this crazy union for? Why are you messing around with "raw"
> kobject attributes? This is a device, you should never have to mess
> with sysfs calls or kobject calls or structures directly. If you do,
> that's a huge hint something is wrong here.
>
>
> > + };
> > +};
> > +
> > +static ssize_t bmc_misc_rmw_show(struct kobject *kobj,
> > + struct kobj_attribute *attr, char *buf)
> > +{
> > + struct bmc_ctrl *ctrl;
> > + unsigned int val;
> > + int rc;
> > +
> > + ctrl = container_of(attr, struct bmc_ctrl, value_attr);
> > + rc = regmap_read(ctrl->map, ctrl->value, &val);
> > + if (rc)
> > + return rc;
> > +
> > + val = (val & ctrl->mask) >> ctrl->shift;
> > +
> > + return sprintf(buf, "%u\n", val);
> > +}
> > +
> > +static ssize_t bmc_misc_rmw_store(struct kobject *kobj,
> > +struct kobj_attribute *attr,
> > +const char *buf, size_t count)
> > +{
> > + struct bmc_ctrl *ctrl;
> > + long val;
> > + int rc;
> > +
> > + rc = kstrtol(buf, 0, &val);
> > + if (rc)
> > + return rc;
> > +
> > + ctrl = container_of(attr, struct bmc_ctrl, value_attr);
> > + val <<= ctrl->shift;
> > + if (val & ~ctrl->mask)
> > + return -EINVAL;
> > + rc = regmap_update_bits(ctrl->map, ctrl->value, ctrl->mask, val);
> > +
> > + return rc < 0 ? rc : count;
> > +}
> > +
> > +static void bmc_misc_add_rmw_attrs(struct bmc_ctrl *ctrl,
> > + struct attribute *attrs[6])
> > +{
> > + sysfs_attr_init(&ctrl->
[rcu:dev 119/161] ERROR: "rcu_barrier" [net/sctp/sctp.ko] undefined!
tree: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev head: 472755d5ff3ee21ad16e0a0a06e087b7569eaffe commit: 16bf6b3b61864e444bae5e4a7cf121f777893a8c [119/161] rcu: Express Tiny RCU updates in terms of RCU rather than RCU-sched config: m68k-sun3_defconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 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 git checkout 16bf6b3b61864e444bae5e4a7cf121f777893a8c # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=m68k All errors (new ones prefixed by >>): ERROR: "rcu_barrier" [net/sunrpc/auth_gss/auth_rpcgss.ko] undefined! >> ERROR: "rcu_barrier" [net/sctp/sctp.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/xt_osf.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/xt_hashlimit.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/nfnetlink_queue.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/nf_tables.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/nf_conntrack.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_list_set.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_netportnet.ko] >> undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_netport.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_netnet.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_netiface.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_net.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_mac.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_ipportnet.ko] >> undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_ipportip.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_ipport.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_ipmark.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_hash_ip.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_bitmap_port.ko] undefined! >> ERROR: "rcu_barrier" [net/netfilter/ipset/ip_set_bitmap_ipmac.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] mm/memblock: replace u64 with phys_addr_t where appropriate
On (07/04/18 10:03), Mike Rapoport wrote:
> > %p[Ff] got deprecated by commit 04b8eb7a4ccd9ef9343e2720ccf2a5db8cfe2f67
> >
> > I think it'd be simplest to just convert
> > all the %pF and %pf uses all at once.
> >
> > $ git grep --name-only "%p[Ff]" | \
> > xargs sed -i -e 's/%pF/%pS/' -e 's/%pf/%ps/'
> >
> > and remove the appropriate Documentation bit.
> >
>
> Something like this:
>
> From 0d3e7cf494123c2640b9a892160d2e2430787004 Mon Sep 17 00:00:00 2001
> From: Mike Rapoport
> Date: Wed, 4 Jul 2018 09:55:50 +0300
> Subject: [PATCH] treewide: retire '%pF/%pf'
>
> %p[Ff] got deprecated by commit 04b8eb7a4ccd9ef9343e2720ccf2a5db8cfe2f67
> ("symbol lookup: introduce dereference_symbol_descriptor()")
>
> Replace their uses with %p[Ss] with
>
> $ git grep --name-only "%p[Ff]" | \
> xargs sed -i -e 's/%pF/%pS/' -e 's/%pf/%ps/'
Sorry, NACK on lib/vsprintf.c part
I definitely didn't want to do this tree-wide pf->ps conversion when
I introduced my patch set. pf/pF should have never existed, true,
but I think we must support pf/pF in vsprintf(). Simply because it
has been around for *far* too long. People tend to develop "habits",
you know, I'm quite sure ppc/hppa/etc folks still do [and will] use
pf/pF occasionally.
-ss
Re: [PATCH v8 0/6] mtd: rawnand: add NVIDIA Tegra NAND flash support
Hi Thierry, Hi Miquel, On 25.06.2018 14:34, Miquel Raynal wrote: > Hi Stefan, > > On Sun, 24 Jun 2018 23:27:21 +0200, Stefan Agner > wrote: > >> Eigth and hopefully final revision gets rid of nand_release() as >> suggested by Boris. >> >> -- >> Stefan >> >> Changes since v1: >> - Split controller and NAND chip structure >> - Add BCH support >> - Allow to select algorithm and strength using device tree >> - Improve HW ECC error reporting and use DEC_STATUS_BUF only >> - Use SPDX license identifier >> - Use per algorithm mtd_ooblayout_ops >> - Use setup_data_interface callback for NAND timing configuration >> >> Changes since v2: >> - Set clock rate using assigned-clocks >> - Use BIT() macro >> - Fix and improve timing calculation >> - Improve ECC error handling >> - Store OOB layout for tag area in Tegra chip structure >> - Update/fix bindings >> - Use more specific variable names (replace "value") >> - Introduce nand-is-boot-medium >> - Choose sensible ECC strenght automatically >> - Use wait_for_completion_timeout >> - Print register dump on completion timeout >> - Unify tegra_nand_(read|write)_page in tegra_nand_page_xfer >> >> Changes since v3: >> - Implement tegra_nand_(read|write)_raw using DMA >> - Implement tegra_nand_(read|write)_oob using DMA >> - Name registers according to Tegra 2 Technical Reference Manual (v02p) >> - Use wait_for_completion_io_timeout to account for IO >> - Get chip select id from device tree reg property >> - Clear interrupts and reinit wait queues in case command/DMA times out >> - Set default MTD name after nand_set_flash_node >> - Move MODULE_DEVICE_TABLE after declaration of tegra_nand_of_match >> - Make (rs|bch)_strength static >> >> Changes since v4: >> - Pass OOB area to nand_check_erased_ecc_chunk >> - Pass algorithm specific bits_per_step to tegra_nand_get_strength >> - Store ECC layout in chip structure >> - Fix pointer assignment (use NULL) >> - Removed obsolete header delay.h >> - Fixed newlines >> - Use non-_io variant of wait_for_completion_timeout >> >> Changes since v5: >> - Drop extra OOB bytes support >> >> Changes since v6: >> - checkpatch.pl fixes >> >> Changes since v7: >> - Replace nand_release() with mtd_device_unregister() + nand_cleanup() >> >> Lucas Stach (1): >> ARM: dts: tegra: add Tegra20 NAND flash controller node >> >> Stefan Agner (5): >> mtd: rawnand: add Reed-Solomon error correction algorithm >> mtd: rawnand: add an option to specify NAND chip as a boot device >> mtd: rawnand: tegra: add devicetree binding >> mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver >> ARM: dts: tegra: enable NAND flash on Colibri T20 >> >> .../devicetree/bindings/mtd/nand.txt |6 +- >> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 + >> MAINTAINERS |7 + >> arch/arm/boot/dts/tegra20-colibri-512.dtsi| 16 + >> arch/arm/boot/dts/tegra20.dtsi| 15 + >> drivers/mtd/nand/raw/Kconfig | 10 + >> drivers/mtd/nand/raw/Makefile |1 + >> drivers/mtd/nand/raw/nand_base.c |4 + >> drivers/mtd/nand/raw/tegra_nand.c | 1230 + >> include/linux/mtd/rawnand.h |7 + >> 10 files changed, 1359 insertions(+), 1 deletion(-) >> create mode 100644 >> Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt >> create mode 100644 drivers/mtd/nand/raw/tegra_nand.c >> > > Series applied to nand/next. I just changed the subject of patch3/6 to > be "dt-bindings: mtd: add tegra NAND controller binding". > It seems "series applied" refers to the MTD part... I guess patch 5 and 6 have to go through Tegra tree, Thierry? -- Stefan
Re: [PATCH v1] mfd: intel-lpss: Add Ice Lake PCI IDs
On Wed, 27 Jun 2018, Andy Shevchenko wrote: > From: Mika Westerberg > > Intel Ice Lake has the same LPSS than Intel Cannon Lake. Add the new IDs > to the list of supported devices. > > Signed-off-by: Mika Westerberg > Signed-off-by: Andy Shevchenko > --- > drivers/mfd/intel-lpss-pci.c | 13 + > 1 file changed, 13 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2] leds: ledtrig-morse: send out morse code
Hi Pavel, On Wed, Jul 04, 2018 at 08:53:05AM +0200, Pavel Machek wrote: > As I stated before, I don't think morse encoder belongs in kernel. On the opposite, I think that the kernel needs to be a bit more autonomous when it comes to reporting its own issues. Being able to report a panic when userland cannot be accessed for example is the reason why we've seen various features such as blinking keyboard LEDs for this. > LED pattern trigger should be merged, instead. Well, just like we have LED and LED triggers in the kernel, I think having a generic way to use patterns could be nice and in this case Morse could be one such pattern, but if that means it's limited to userland to configure it then it sadly voids all of its benefits. Last, as I showed on my previous mail in this thread, the Morse encoding can be brought to 36 bytes, which is much less than even the registration code needed to feed it. At some point we need to focus on code efficiency and doing things right instead of how too many layers look like from far away. While I don't need Morse right now I consider it as a nice addition I would definitely enable by default on all my boards if it helps provide details about what prevents my system from booting or what just killed it. Cheers, Willy
Re: [PATCH v3 4/4] arm64: dts: mediatek: add mt6765 support
On 04/07/18 02:52, Mars Cheng wrote:
> This adds basic chip support for MT6765 SoC.
>
> Signed-off-by: Mars Cheng
> ---
> arch/arm64/boot/dts/mediatek/Makefile |1 +
> arch/arm64/boot/dts/mediatek/mt6765-evb.dts | 33 ++
> arch/arm64/boot/dts/mediatek/mt6765.dtsi| 155
> +++
> 3 files changed, 189 insertions(+)
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6765-evb.dts
> create mode 100644 arch/arm64/boot/dts/mediatek/mt6765.dtsi
>
[...]
> +
> + gic: interrupt-controller@c00 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + #redistributor-regions = <1>;
> + interrupt-parent = <&gic>;
> + interrupt-controller;
> + reg = <0 0x0c00 0 0x4>, // distributor
> + <0 0x0c10 0 0x20>, // redistributor
> + <0 0x0c40 0 0x4>; // gicc
For the second time: please add *all* the GIC CPU interface regions,
described in the Cortex-A53 TRM[1] (GICC, GICH, and GICV).
Thanks,
M.
[1]
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0500g/ch09s02s01.html
--
Jazz is not dead. It just smells funny...
Re: [PATCH 2/3] perf arm64: Generate system call table from asm/unistd.h
Hi Kim,
On Tue, Jul 03, 2018 at 12:32:28PM -0500, Kim Phillips wrote:
> This should speed up accessing new system calls introduced with the
> kernel rather than waiting for libaudit updates to include them.
>
> Using the existing other arch scripts resulted in this error:
>
> tools/perf/arch/arm64/entry/syscalls//mksyscalltbl: 25: printf:
> __NR3264_ftruncate: expected numeric value
>
> because, unlike other arches, asm-generic's unistd.h does things like:
>
> #define __NR_ftruncate __NR3264_ftruncate
>
> Turning the scripts printf's %d into a %s resulted in this in the
> generated syscalls.c file:
>
> static const char *syscalltbl_arm64[] = {
> [__NR3264_ftruncate] = "ftruncate",
>
> So we use the host C compiler to fold the macros, and print them out
> from within a temporary C program, in order to get the correct output:
>
> static const char *syscalltbl_arm64[] = {
> [46] = "ftruncate",
>
> Cc: Ravi Bangoria
> Cc: Alexander Shishkin
> Cc: Hendrik Brueckner
> Cc: Jiri Olsa
> Cc: Michael Ellerman
> Cc: Namhyung Kim
> Cc: Thomas Richter
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Signed-off-by: Kim Phillips
> ---
> tools/perf/arch/arm64/Makefile| 21
> .../arch/arm64/entry/syscalls/mksyscalltbl| 54 +++
> 2 files changed, 75 insertions(+)
> create mode 100755 tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
>
> diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
> index 91de4860faad..85fdf4949db3 100644
> --- a/tools/perf/arch/arm64/Makefile
> +++ b/tools/perf/arch/arm64/Makefile
> @@ -4,3 +4,24 @@ PERF_HAVE_DWARF_REGS := 1
> endif
> PERF_HAVE_JITDUMP := 1
> PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
> +
> +#
> +# Syscall table generation for perf
> +#
> +
> +out:= $(OUTPUT)arch/arm64/include/generated/asm
> +header := $(out)/syscalls.c
> +sysdef := $(srctree)/tools/arch/arm64/include/uapi/asm/unistd.h
> +sysprf := $(srctree)/tools/perf/arch/arm64/entry/syscalls/
> +systbl := $(sysprf)/mksyscalltbl
> +
> +# Create output directory if not already present
> +_dummy := $(shell [ -d '$(out)' ] || mkdir -p '$(out)')
> +
> +$(header): $(sysdef) $(systbl)
> + $(Q)$(SHELL) '$(systbl)' '$(CC)' '$(HOSTCC)' $(sysdef) > $@
> +
> +clean::
> + $(call QUIET_CLEAN, arm64) $(RM) $(header)
> +
> +archheaders: $(header)
> diff --git a/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
> b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
> new file mode 100755
> index ..1148302b7194
> --- /dev/null
> +++ b/tools/perf/arch/arm64/entry/syscalls/mksyscalltbl
> @@ -0,0 +1,54 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Generate system call table for perf. Derived from
> +# powerpc script.
> +#
> +# Copyright IBM Corp. 2017
> +# Author(s): Hendrik Brueckner
> +# Changed by: Ravi Bangoria
> +# Changed by: Kim Phillips
> +
> +gcc=$1
> +hostcc=$2
> +input=$3
> +
> +if ! test -r $input; then
> + echo "Could not read input file" >&2
> + exit 1
> +fi
> +
> +create_table_from_c()
> +{
> + local last_sc
For the sake of completion, also add the "sc" and "nr" local variables.
> +
> + create_table_base=`mktemp -u /tmp/create-table-XXX`
- The -u is considered to be unsafe. But from below, I think you require
this for the .c/.x file. Alternatively, you could create the file
(and prefer using more X for the template) and append to it. Or pipe
the C code to the $hostcc command, e.g.,
$hostcc -o $create_table_base -x c -
which would require a single temp file that would be overwritten by gcc.
> + echo "#include " > ${create_table_base}.c
> + echo "#include \"$input\"" >> ${create_table_base}.c
> +
> + echo "int main(int argc, char *argv[])" >> ${create_table_base}.c
> + echo "{" >> ${create_table_base}.c
As alternative to these echos, use
cat >> ${create_table_base}.c <<-EoHEADER
#include
#include "$input"
int main(int argc, char *argv[])
{
EoHeader
which is at least for larger portions a bit more readable.
> + while read sc nr; do
> + echo " printf(\"\\\t[%d] = \\\"$sc\\\",\\\n\", __NR_$sc);" >>
> ${create_table_base}.c
> + last_sc=$sc
> + done
> + echo " printf(\"#define SYSCALLTBL_ARM64_MAX_ID %d\\\n\",
> __NR_$last_sc);" >> ${create_table_base}.c
> + echo "}" >> ${create_table_base}.c
> +
> + $hostcc -o ${create_table_base}.x ${create_table_base}.c
> + ${create_table_base}.x
> +}
> +
> +create_table()
> +{
> + echo "static const char *syscalltbl_arm64[] = {"
> + create_table_from_c
> + echo '};'
> +
> + $RM -f ${create_table_base}.[cx]
The $RM is obtained from the (make) environment. I would prefer using rm here
to be able to run as standalone.
> +}
> +
> +$gcc -E -dM -x c $input\
> + |sed -ne 's/^#define __NR_//p' \
> + |sort -t' ' -k2 -nu\
Re: [PATCH v3] mfd: arizona: Don't use regmap_read_poll_timeout
On Thu, 28 Jun 2018, Charles Keepax wrote:
> Some Arizona CODECs have a small timing window where they will
> NAK an I2C transaction if it happens before the boot done bit is
> set. This can cause the read of the register containing the boot
> done bit to fail until it is set. Since regmap_read_poll_timeout
> will abort polling if a read fails it can't be reliably used to
> poll the boot done bit over I2C.
>
> Do a partial revert of ef84f885e037 ("mfd: arizona: Refactor
> arizona_poll_reg"), removing the regmap_read_poll_timeout but
> leaving the refactoring to make the arizona_poll_reg take more
> sensible arguments.
>
> Fixes: ef84f885e037 ("mfd: arizona: Refactor arizona_poll_reg")
> Signed-off-by: Charles Keepax
> ---
>
> Changes since v2:
> - Refactor to remove initialisation of ret variable
>
> Thanks,
> Charles
>
> drivers/mfd/arizona-core.c | 34 ++
> 1 file changed, 26 insertions(+), 8 deletions(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/5] mfd: ti_am335x_tscadc: Don't mark TSCADC MFD as wakeup capable
On Sat, 30 Jun 2018, Vignesh R wrote: > Currently tscadc MFD is marked as wakeup capable which incorrect > because, its actually touch event by child TSC device that wakes up the > system. Therefore, remove device_init_wakeup() call that marks TSCADC > device as wakeup capable in favor of moving to mark TSC input device as > wakeup capable later. > > Signed-off-by: Vignesh R > --- > drivers/mfd/ti_am335x_tscadc.c | 1 - > 1 file changed, 1 deletion(-) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 3/3] perf trace arm64: Use generated syscall table
On Tue, Jul 03, 2018 at 12:32:38PM -0500, Kim Phillips wrote:
> This should speed up accessing new system calls introduced with the
> kernel rather than waiting for libaudit updates to include them.
>
> It also enables users to specify wildcards, for example, perf trace -e
> 'open*', just like was already possible on x86, s390, and powerpc, which
> means arm64 can now pass the "Check open filename arg using perf trace +
> vfs_getname" test.
>
> Cc: Ravi Bangoria
> Cc: Alexander Shishkin
> Cc: Hendrik Brueckner
> Cc: Jiri Olsa
> Cc: Michael Ellerman
> Cc: Namhyung Kim
> Cc: Thomas Richter
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Arnaldo Carvalho de Melo
> Signed-off-by: Kim Phillips
> ---
> tools/perf/Makefile.config | 2 ++
> tools/perf/util/syscalltbl.c | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
> index b5ac356ba323..3126155810bb 100644
> --- a/tools/perf/Makefile.config
> +++ b/tools/perf/Makefile.config
> @@ -54,6 +54,8 @@ endif
>
> ifeq ($(SRCARCH),arm64)
>NO_PERF_REGS := 0
> + NO_SYSCALL_TABLE := 0
> + CFLAGS += -I$(OUTPUT)arch/arm64/include/generated
>LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
> endif
>
> diff --git a/tools/perf/util/syscalltbl.c b/tools/perf/util/syscalltbl.c
> index 0ee7f568d60c..3393d7ee9401 100644
> --- a/tools/perf/util/syscalltbl.c
> +++ b/tools/perf/util/syscalltbl.c
> @@ -38,6 +38,10 @@ static const char **syscalltbl_native =
> syscalltbl_powerpc_64;
> #include
> const int syscalltbl_native_max_id = SYSCALLTBL_POWERPC_32_MAX_ID;
> static const char **syscalltbl_native = syscalltbl_powerpc_32;
> +#elif defined(__aarch64__)
> +#include
> +const int syscalltbl_native_max_id = SYSCALLTBL_ARM64_MAX_ID;
> +static const char **syscalltbl_native = syscalltbl_arm64;
> #endif
>
> struct syscall {
Looks good.
Reviewed-by: Hendrik Brueckner
Re: [PATCH 3/5] mfd: ti_am335x_tscadc: Keep ADC interface on if child is wakeup capable
On Sat, 30 Jun 2018, Vignesh R wrote: > If a child device like touchscreen is wakeup capable, then keep ADC > interface on, so that a touching resistive screen will generate wakeup > event to the system. > > Signed-off-by: Vignesh R > --- > drivers/mfd/ti_am335x_tscadc.c | 13 + > 1 file changed, 13 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr
On Wed, 4 Jul 2018, Yang, Bin wrote:
> thanks for reviewing my patch. I will update a new patch version based
> on your feedback soon
Take your time.
> On Tue, 2018-07-03 at 15:57 +0200, Thomas Gleixner wrote:
> Below is the new commit comment I will use in new patch version soon
> > Please do not use the output of git show for submitting a patch. Use
> > git format-patch(1). >
>
> I use "git send-email -1" to submit patch for review. Should I run "git
> format-patch" first and send the patch as email?
git send-email is fine, but it should not result in the changelog being
indented by a bunch of spaces. That's why I assumed that you used git show
because that's exacty the format. I'm not using it, so I can't give you
advise there.
> ===
> If cpu supports "pdpe1gb", kernel will try its best to use 1G big page.
> When changing a 4K page attr inside 1G page range, __change_page_attr()
> will either consume this 4K page into the 1G page, or it splits 1G page
> into 2M pages and tries again. The retry will either consume the 4K
> page into a 2MB page, or it splits 2MB page into 4K pages.
> try_preserve_large_page() is called by __change_page_attr() to decide
I know what calls try_preserve_large_page(), but you still fail to explain
the full call chain including parameters which I asked for.
> it by checking all 4K pages inside the big page one by one.
After your change this will still happen. You just shortcut the inner
workings, but you are still not explaining why the shortcut is necessary in
the first place.
The try_preserve_large_page() logic should not need any of this unless
there is a subtle implementation bug. If that's the case, then the bug
needs to be isolated and fixed and not papered over by magic short cuts.
> This issue is discovered during kernel boot time optimization.
> Sometimes, free_initmem() returns after about 600ms on my x86_64 board
> with 4GB memory.
>
> Since it is a common issue of x86_64, it can be reproduced by qemu too.
> We can add some logs in try_preserve_large_page() function to measure
> the loop count and elapsed time. Please make sure the host CPU has
> "pdpe1gb" flag and run below qemu command to reproduce it:
>
> qemu-system-x86_64 -enable-kvm -cpu host -serial mon:stdio -m 4G
> -nographic -kernel bzImage -initrd ramdisk.img -append "console=ttyS0"
>
> Since default x86_64 kernel enables CONFIG_RANDOMIZE_BASE, it needs to
Huch? What as this to do with randomize base?
> try many times to let init memory be randomized in a 1G page range.
And no, I'm not interested in random qemu commands and adding logs into
something. You already did the investigation, but you fail to provide the
information. And I'm not asking for random timing logs, I ask about a
proper explanation why this happens even if it's supposed not to happen.
> This patch try to cache the last address which had been checked just
See Documentation/process/submitting-patches.rst and search for 'This
patch'
> now. If the next address is in same big page with same attr, the cache
> will be used without full range check.
> > > @@ -552,16 +552,20 @@ static int
> > > try_preserve_large_page(pte_t *kpte, unsigned long address,
> > > struct cpa_data *cpa)
> > > {
> > > + static unsigned long address_cache;
> > > + static unsigned long do_split_cache = 1;
> >
> > What are the life time and protection rules of these static variables
> > and
> > why are they static in the first place.
>
> they will be protected by pgd_lock. They only cache previous "do_split"
> result and will be refreshed every time.
So why is there no comment explaining this? And I'm still not convinced
about pgd_lock being the real protection. pgd_lock protects against
concurrent page table manipulations, but it does not protect against
concurrent calls of the change_page_attr logic at all. That's what cpa_lock
does.
> > > unsigned long nextpage_addr, numpages, pmask, psize, addr,
> > > pfn, old_pfn;
> > > pte_t new_pte, old_pte, *tmp;
> > > pgprot_t old_prot, new_prot, req_prot;
> > > int i, do_split = 1;
> > > enum pg_level level;
> > >
> > > - if (cpa->force_split)
> > > + spin_lock(&pgd_lock);
> > > + if (cpa->force_split) {
> > > + do_split_cache = 1;
> >
> > Returns with pgd_lock held which will immediately lockup the system
> > on the
> > next spin_lock(&pgd_lock) operation.
> I am so sorry to make such stupid mistake. force_split was not hit on
> my board :(
> >
> > Also what's the point of storing the already available information of
> > cpa->force_split in yet another variable? This enforces taking the
> > lock on
> > every invocation for no reason.
> As you know, do_split is initialized as 1. If do_split_cache == 1, the
> cache value will not be used. If force_split == 1, cache value should
> be expired. Since do_split_cache is protected by this lock, it needs to
> task this lock here.
No. It can be done w/o the lock and without touching the cache
variable. cpa->f
Re: [PATCH] rtc: OMAP: Add support for rtc-only mode
Hi,
On 04/07/2018 12:03:45+0530, Keerthy wrote:
> Prepare rtc driver for rtc-only mode. This involes splitting the power-off
> function so that an external driver can initiate the programming of
> setting the power_off to be triggered in the next second.
>
I'm sorry, I don't see the point, can't you use
of_device_is_system_power_controller and set the correct pm_power_off
callback?
> Signed-off-by: Keerthy
> ---
> drivers/rtc/interface.c | 12
> drivers/rtc/rtc-omap.c | 164
> ++--
> include/linux/rtc.h | 2 +
> 3 files changed, 130 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
> index 6d4012d..d8b70f0 100644
> --- a/drivers/rtc/interface.c
> +++ b/drivers/rtc/interface.c
> @@ -1139,3 +1139,15 @@ int rtc_set_offset(struct rtc_device *rtc, long offset)
> trace_rtc_set_offset(offset, ret);
> return ret;
> }
> +
> +/**
> + * rtc_power_off_program - Some of the rtc are hooked on to PMIC_EN
> + * line and can be used to power off the SoC.
> + *
> + * Kernel interface to program rtc to power off
> + */
> +void rtc_power_off_program(struct rtc_device *rtc)
> +{
> + rtc->ops->power_off_program(rtc->dev.parent);
> +}
> +EXPORT_SYMBOL_GPL(rtc_power_off_program);
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 3908639..4dcee1c 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /*
> @@ -131,6 +132,8 @@
> #define KICK0_VALUE 0x83e70b13
> #define KICK1_VALUE 0x95a4f1e0
>
> +#define SHUTDOWN_TIME_SEC1
> +
> struct omap_rtc;
>
> struct omap_rtc_device_type {
> @@ -415,6 +418,77 @@ static int omap_rtc_set_alarm(struct device *dev, struct
> rtc_wkalrm *alm)
>
> static struct omap_rtc *omap_rtc_power_off_rtc;
>
> +/**
> + * omap_rtc_power_off_program: Set the pmic power off sequence. The RTC
> + * generates pmic_pwr_enable control, which can be used to control an
> external
> + * PMIC.
> + */
> +void omap_rtc_power_off_program(struct device *dev)
> +{
> + u32 val;
> + struct rtc_time tm;
> + unsigned long time;
> + int seconds;
> +
> + omap_rtc_power_off_rtc->type->unlock(omap_rtc_power_off_rtc);
> +
> + /* Clear any existing ALARM2 event */
> + rtc_writel(omap_rtc_power_off_rtc, OMAP_RTC_STATUS_REG,
> +OMAP_RTC_STATUS_ALARM2);
> +
> + pr_info("System will go to power_off state in approx. %d second\n",
> + SHUTDOWN_TIME_SEC);
> +
> +again:
> + /* Read rtc time */
> + tm.tm_sec = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_SECONDS_REG);
> + seconds = tm.tm_sec;
> + tm.tm_min = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_MINUTES_REG);
> + tm.tm_hour = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_HOURS_REG);
> + tm.tm_mday = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_DAYS_REG);
> + tm.tm_mon = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_MONTHS_REG);
> + tm.tm_year = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_YEARS_REG);
> + bcd2tm(&tm);
> +
> + /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
> + rtc_tm_to_time(&tm, &time);
> +
> + /* Convert seconds since 01-01-1970 00:00:00 to Gregorian date */
> + rtc_time_to_tm(time + SHUTDOWN_TIME_SEC, &tm);
> +
> + if (tm2bcd(&tm) < 0)
> + return;
> +
> + /* After wait_not_busy, we have at least 15us until the next second. */
> + rtc_wait_not_busy(omap_rtc_power_off_rtc);
> +
> + /* Our calculations started right before the rollover, try again */
> + if (seconds != rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_SECONDS_REG))
> + goto again;
> +
> + /*
> + * pmic_pwr_enable is controlled by means of ALARM2 event. So here
> + * programming alarm2 expiry time and enabling alarm2 interrupt
> + */
> + rtc_write(omap_rtc_power_off_rtc, OMAP_RTC_ALARM2_SECONDS_REG,
> + tm.tm_sec);
> + rtc_write(omap_rtc_power_off_rtc, OMAP_RTC_ALARM2_MINUTES_REG,
> + tm.tm_min);
> + rtc_write(omap_rtc_power_off_rtc, OMAP_RTC_ALARM2_HOURS_REG,
> + tm.tm_hour);
> + rtc_write(omap_rtc_power_off_rtc, OMAP_RTC_ALARM2_DAYS_REG,
> + tm.tm_mday);
> + rtc_write(omap_rtc_power_off_rtc, OMAP_RTC_ALARM2_MONTHS_REG,
> + tm.tm_mon);
> + rtc_write(omap_rtc_power_off_rtc, OMAP_RTC_ALARM2_YEARS_REG,
> + tm.tm_year);
> +
> + /* Enable alarm2 interrupt */
> + val = rtc_readl(omap_rtc_power_off_rtc, OMAP_RTC_INTERRUPTS_REG);
> + rtc_writel(omap_rtc_power_off_rtc, OMAP_RTC_INTERRUPTS_REG, val |
> +OMAP_RTC_INTERRUPTS_IT_ALARM2);
> +}
> +
> /*
> * omap_rtc_poweroff: RTC-controlled power off
> *
> @@ -431,45 +505,19 @@ static int omap_rtc_set_alarm(struct device *dev,
> struct rtc_wkal
Re: [PATCH v2 1/1] mmc: sunxi: Disable irq during pm_suspend
On Wed, Jul 04, 2018 at 09:28:59AM +0300, Stefan Mavrodiev wrote:
> When mmc host controller enters suspend state, the clocks are
> disabled, but irqs are not. For some reason the irqchip emits
> false interrupts, which causes system lock loop.
>
> Debug log is:
> ...
> sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded 5120
> sunxi-mmc 1c11000.mmc: enabling the clock
> sunxi-mmc 1c11000.mmc: cmd 13(814d) arg 1 ie 0xbbc6 len 0
> sunxi-mmc 1c11000.mmc: irq: rq (ptrval) mi 0004 idi
> sunxi-mmc 1c11000.mmc: cmd 6(8146) arg 3210101 ie 0xbbc6 len 0
> sunxi-mmc 1c11000.mmc: irq: rq (ptrval) mi 0004 idi
> sunxi-mmc 1c11000.mmc: cmd 13(814d) arg 1 ie 0xbbc6 len 0
> sunxi-mmc 1c11000.mmc: irq: rq (ptrval) mi 0004 idi
> mmc1: new DDR MMC card at address 0001
> mmcblk1: mmc1:0001 AGND3R 14.6 GiB
> mmcblk1boot0: mmc1:0001 AGND3R partition 1 4.00 MiB
> mmcblk1boot1: mmc1:0001 AGND3R partition 2 4.00 MiB
> sunxi-mmc 1c11000.mmc: cmd 18(80003352) arg 0 ie 0xfbc2 len 409
> sunxi-mmc 1c11000.mmc: irq: rq (ptrval) mi 4000 idi 0002
>mmcblk1: p1
> sunxi-mmc 1c11000.mmc: irq: rq (null) mi idi
> sunxi-mmc 1c11000.mmc: irq: rq (null) mi idi
> sunxi-mmc 1c11000.mmc: irq: rq (null) mi idi
> sunxi-mmc 1c11000.mmc: irq: rq (null) mi idi
> and so on...
>
> This issue apears on eMMC cards, routed on MMC2 slot. The patch is
> tested with A20-OLinuXino-MICRO/LIME/LIME2 boards.
>
> Fixes: 9a8e1e8cc2c0 ("mmc: sunxi: Add runtime_pm support")
> Signed-off-by: Stefan Mavrodiev
Acked-by: Maxime Ripard
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Mike, On Wed, Jul 4, 2018 at 8:28 AM Mike Rapoport wrote: > In m68k the physical memory is described by [memory_start, memory_end] for > !MMU variant and by m68k_memory array of memory ranges for the MMU version. > This information is directly use to register the physical memory with > memblock. > > The reserve_bootmem() calls are replaced with memblock_reserve() and the > bootmap bitmap allocation is simply dropped. > > Since the MMU variant creates early mappings only for the small part of the > memory we force bottom-up allocations in memblock. > > Signed-off-by: Mike Rapoport Thanks a lot for doing this! My virtual Atari (using ARAnyM) now has +12KiB of memory available: -Memory: 267976K/276480K available (3037K kernel code, 304K rwdata, 792K rodata, 148K init, 168K bss, 8504K reserved, 0K cma-reserved) +Memory: 267988K/276480K available (3036K kernel code, 304K rwdata, 792K rodata, 152K init, 168K bss, 8492K reserved, 0K cma-reserved) However, a WARNING is triggered. With memblock_debug=1: Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED memblock_reserve: [0x-0x00439fff] paging_init+0x172/0x462 memblock_reserve: [0x0043a000-0x0043afff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043b000-0x0043bfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043c000-0x0043cfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043d000-0x0043dfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043e000-0x0043efff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0043f000-0x0043] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044-0x00440fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00441000-0x00441fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00442000-0x00442fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00443000-0x00443fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00444000-0x00444fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00445000-0x00445fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00446000-0x00446fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00447000-0x00447fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00448000-0x00448fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00449000-0x00449fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044a000-0x0044afff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044b000-0x0044bfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044c000-0x0044cfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044d000-0x0044dfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044e000-0x0044efff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0044f000-0x0044] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045-0x00450fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00451000-0x00451fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00452000-0x00452fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00453000-0x00453fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00454000-0x00454fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00455000-0x00455fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00456000-0x00456fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00457000-0x00457fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00458000-0x00458fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00459000-0x00459fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045a000-0x0045afff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045b000-0x0045bfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045c000-0x0045cfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045d000-0x0045dfff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045e000-0x0045efff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0045f000-0x0045] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0046-0x00460fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00461000-0x00461fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00462000-0x00462fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00463000-0x00463fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00464000-0x00464fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00465000-0x00465fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00466000-0x00466fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00467000-0x00467fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00468000-0x00468fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x00469000-0x00469fff] __alloc_memory_core_early+0x86/0xb8 memblock_reserve: [0x0046a000-0x0046afff] __alloc_memo
Re: [PATCH v8 0/6] mtd: rawnand: add NVIDIA Tegra NAND flash support
Hi Stefan, Stefan Agner wrote on Wed, 04 Jul 2018 09:33:44 +0200: > Hi Thierry, Hi Miquel, > > On 25.06.2018 14:34, Miquel Raynal wrote: > > Hi Stefan, > > > > On Sun, 24 Jun 2018 23:27:21 +0200, Stefan Agner > > wrote: > > > >> Eigth and hopefully final revision gets rid of nand_release() as > >> suggested by Boris. > >> > >> -- > >> Stefan > >> > >> Changes since v1: > >> - Split controller and NAND chip structure > >> - Add BCH support > >> - Allow to select algorithm and strength using device tree > >> - Improve HW ECC error reporting and use DEC_STATUS_BUF only > >> - Use SPDX license identifier > >> - Use per algorithm mtd_ooblayout_ops > >> - Use setup_data_interface callback for NAND timing configuration > >> > >> Changes since v2: > >> - Set clock rate using assigned-clocks > >> - Use BIT() macro > >> - Fix and improve timing calculation > >> - Improve ECC error handling > >> - Store OOB layout for tag area in Tegra chip structure > >> - Update/fix bindings > >> - Use more specific variable names (replace "value") > >> - Introduce nand-is-boot-medium > >> - Choose sensible ECC strenght automatically > >> - Use wait_for_completion_timeout > >> - Print register dump on completion timeout > >> - Unify tegra_nand_(read|write)_page in tegra_nand_page_xfer > >> > >> Changes since v3: > >> - Implement tegra_nand_(read|write)_raw using DMA > >> - Implement tegra_nand_(read|write)_oob using DMA > >> - Name registers according to Tegra 2 Technical Reference Manual (v02p) > >> - Use wait_for_completion_io_timeout to account for IO > >> - Get chip select id from device tree reg property > >> - Clear interrupts and reinit wait queues in case command/DMA times out > >> - Set default MTD name after nand_set_flash_node > >> - Move MODULE_DEVICE_TABLE after declaration of tegra_nand_of_match > >> - Make (rs|bch)_strength static > >> > >> Changes since v4: > >> - Pass OOB area to nand_check_erased_ecc_chunk > >> - Pass algorithm specific bits_per_step to tegra_nand_get_strength > >> - Store ECC layout in chip structure > >> - Fix pointer assignment (use NULL) > >> - Removed obsolete header delay.h > >> - Fixed newlines > >> - Use non-_io variant of wait_for_completion_timeout > >> > >> Changes since v5: > >> - Drop extra OOB bytes support > >> > >> Changes since v6: > >> - checkpatch.pl fixes > >> > >> Changes since v7: > >> - Replace nand_release() with mtd_device_unregister() + nand_cleanup() > >> > >> Lucas Stach (1): > >> ARM: dts: tegra: add Tegra20 NAND flash controller node > >> > >> Stefan Agner (5): > >> mtd: rawnand: add Reed-Solomon error correction algorithm > >> mtd: rawnand: add an option to specify NAND chip as a boot device > >> mtd: rawnand: tegra: add devicetree binding > >> mtd: rawnand: add NVIDIA Tegra NAND Flash controller driver > >> ARM: dts: tegra: enable NAND flash on Colibri T20 > >> > >> .../devicetree/bindings/mtd/nand.txt |6 +- > >> .../bindings/mtd/nvidia-tegra20-nand.txt | 64 + > >> MAINTAINERS |7 + > >> arch/arm/boot/dts/tegra20-colibri-512.dtsi| 16 + > >> arch/arm/boot/dts/tegra20.dtsi| 15 + > >> drivers/mtd/nand/raw/Kconfig | 10 + > >> drivers/mtd/nand/raw/Makefile |1 + > >> drivers/mtd/nand/raw/nand_base.c |4 + > >> drivers/mtd/nand/raw/tegra_nand.c | 1230 + > >> include/linux/mtd/rawnand.h |7 + > >> 10 files changed, 1359 insertions(+), 1 deletion(-) > >> create mode 100644 > >> Documentation/devicetree/bindings/mtd/nvidia-tegra20-nand.txt > >> create mode 100644 drivers/mtd/nand/raw/tegra_nand.c > >> > > > > Series applied to nand/next. I just changed the subject of patch3/6 to > > be "dt-bindings: mtd: add tegra NAND controller binding". > > > > It seems "series applied" refers to the MTD part... > > I guess patch 5 and 6 have to go through Tegra tree, Thierry? Indeed :) Regards, Miquèl
Re: [PATCH v2] leds: ledtrig-morse: send out morse code
Hi Willy,
On Wed, Jul 4, 2018 at 4:41 AM Willy Tarreau wrote:
> On Tue, Jul 03, 2018 at 09:43:06PM +0300, Andy Shevchenko wrote:
> > > + {'a', ".-"},
> > > + {'b', "-..."},
> >
> > Do you expect this to be changed somehow?
> > Otherwise we might just to keep two char arrays of alphas and digits
> > in an order of ascii appearance.
> >
> > In the code something like
> >
> > ch = tolower(x);
> > if (isalpha(ch))
> > code = alphas[ch - 'a'];
> > else if (isdigit(ch))
> > code = digits[ch - '0'];
> > else
> > code = unknown;
> >
> > > + {0, NULL},
> >
> > And this will gone, you just provide it with known size,
>
> Well, in this case it's even possible to go further and avoid storing
> 36 strings. Indeed, no representation is longer than 5 symbols, so you
> can use 5 bits for the encoding (0=".", 1="-") and 3 bits for the
> length, it gives you a single byte per character instead of a pointer
> to a string plus 6 chars. Then in order to make it readable, 5 macros
Hehe, https://lkml.org/lkml/2018/6/28/544 ;-)
> can be provided to emit the code :
>
> #define MORSE1(a,b) (1 | ((a)<<3))
> #define MORSE2(a,b) (2 | ((a)<<3)|((b)<<4))
> #define MORSE3(a,b,c) (3 | ((a)<<3)|((b)<<4)|((c)<<5))
> #define MORSE4(a,b,c,d) (4 | ((a)<<3)|((b)<<4)|((c)<<5)|((d)<<6))
> #define MORSE5(a,b,c,d,e) (5 | ((a)<<3)|((b)<<4)|((c)<<5)|((d)<<6)|((e)<<7))
>
> Then all chars may be defined like this :
>
> ['a'] = MORSE2(0,1),
> ['b'] = MORSE4(1,0,0,0),
> ['c'] = MORSE4(1,0,1,0),
> ['d'] = MORSE3(1,0,0),
> ['e'] = MORSE1(0),
Nice!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 4/4] arm64: dts: mediatek: add mt6765 support
Hi Marc
On Wed, 2018-07-04 at 08:35 +0100, Marc Zyngier wrote:
> On 04/07/18 02:52, Mars Cheng wrote:
> > This adds basic chip support for MT6765 SoC.
> >
> > Signed-off-by: Mars Cheng
> > ---
> > arch/arm64/boot/dts/mediatek/Makefile |1 +
> > arch/arm64/boot/dts/mediatek/mt6765-evb.dts | 33 ++
> > arch/arm64/boot/dts/mediatek/mt6765.dtsi| 155
> > +++
> > 3 files changed, 189 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6765-evb.dts
> > create mode 100644 arch/arm64/boot/dts/mediatek/mt6765.dtsi
> >
>
> [...]
>
> > +
> > + gic: interrupt-controller@c00 {
> > + compatible = "arm,gic-v3";
> > + #interrupt-cells = <3>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + #redistributor-regions = <1>;
> > + interrupt-parent = <&gic>;
> > + interrupt-controller;
> > + reg = <0 0x0c00 0 0x4>, // distributor
> > + <0 0x0c10 0 0x20>, // redistributor
> > + <0 0x0c40 0 0x4>; // gicc
>
> For the second time: please add *all* the GIC CPU interface regions,
> described in the Cortex-A53 TRM[1] (GICC, GICH, and GICV).
>
MT6765 has no GICH/GICV/ITS in mediatek design. Have confirmed with our
designer.
MT6797 had similar question from you. Sorry for not mentioned it first.
http://lists.infradead.org/pipermail/linux-mediatek/2017-February/008074.html
Thanks.
> Thanks,
>
> M.
>
> [1]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__infocenter.arm.com_help_topic_com.arm.doc.ddi0500g_ch09s02s01.html&d=DwICaQ&c=X9NHckmGz7LNQmqtvpDCYVnn6eFXNivfZeknqiAo-n0&r=Ph_SbcClVGRWmGxVhfr-5CZF9ffiUOE7TZ47ns4ROh4&m=9L01qJc7apuzwLobX_nhN0ik8IFdu_X7hJ139x5dNNw&s=0zeZXtWPeITLj01RSxAQ6NfNkTUu9Il0Dddgk07-6QA&e=
>
Re: [RFC][PATCH] selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET is in progress
On Tue, Jul 03, 2018 at 12:36:27PM -0700, John Stultz wrote:
> In the past we've warned when ADJ_OFFSET was in progress, usually
> caused by ntpd or some other time adjusting daemon running in non
> steady sate, which can cause the skew calculations to be incorrect
Good idea.
> Thus, this patch sets a flag which we check when we fail so that
> we don't cause false negatives.
I'd suggest to check few more things to better detect when something
is adjusting the clock. The offset should be zero also at the end of
the test and the frequency and tick should be the same as at the
beginning of the test. This will detect daemons that set the frequency
of the clock directly, not using adjtime() or the PLL.
Something like this:
@@ -137,9 +135,10 @@ int main(int argv, char **argc)
printf(" %lld.%i(act)", ppm/1000, abs((int)(ppm%1000)));
if (llabs(eppm - ppm) > 1000) {
- if (adj_offset_bad) {
+ if (tx1.offset || tx2.offset ||
+ tx1.freq != tx2.freq || tx1.tick != tx2.tick) {
printf("[SKIP]\n");
- return ksft_exit_skip("ADJ_OFFSET in progress. Shutdown
NTPd or other time steering daemons\n");
+ return ksft_exit_skip("The clock was adjusted. Shutdown
ntpd or other time steering daemons\n");
}
printf("[FAILED]\n");
return ksft_exit_fail();
--
Miroslav Lichvar
Re: [PATCH 1/3] clk: tegra: refactor 7.1 div calculation
On Tue, 3 Jul 2018 11:10:21 -0400 Peter Geis wrote: > Good Morning, > > Just a heads up. > During compilation with your patches, I get the following warning: > > In file included from ./arch/arm/include/asm/div64.h:127:0, > from ./include/linux/kernel.h:174, > from drivers/clk/tegra/div71.c:17: > drivers/clk/tegra/div71.c: In function ‘div71_get’: > ./include/asm-generic/div64.h:222:28: warning: comparison of distinct > pointer types lacks a cast >(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ > ^ > drivers/clk/tegra/div71.c:40:2: note: in expansion of macro ‘do_div’ >do_div(divider_ux1, rate); >^~ > > Very Respectfully, > Peter Geis > That's indeed true. Looks like this warning is produced only on 32-bit arm as it uses a different variant of the do_div macro than arm64. Thanks, -Aapo
Re: [PATCH v2] mfd: as3722: disable auto power on when AC OK
On Tue, 03 Jul 2018, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> On ams AS3722, power on when AC OK is enabled by default.
> Making this option as disable by default and enable only
> when platform need this explicitly.
>
> Signed-off-by: Laxman Dewangan
> Reviewed-by: Bibek Basu
> Tested-by: Bibek Basu
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> Changes in v2:
> - Document device tree property as suggested by Stefan.
> - Rename SEQ1 to SEQU1 as per datasheet as suggested by Stefan.
> - Drop reference to downstream commit as suggested by Lee.
>
> Documentation/devicetree/bindings/mfd/as3722.txt | 2 ++
> drivers/mfd/as3722.c | 12
> include/linux/mfd/as3722.h | 3 +++
> 3 files changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/as3722.txt
> b/Documentation/devicetree/bindings/mfd/as3722.txt
> index 5297b2210704..2a665741d7fe 100644
> --- a/Documentation/devicetree/bindings/mfd/as3722.txt
> +++ b/Documentation/devicetree/bindings/mfd/as3722.txt
> @@ -20,6 +20,8 @@ Optional properties:
> - ams,enable-internal-i2c-pullup: Boolean property, to enable internal
> pullup on
> i2c scl/sda pins. Missing this will disable internal pullup on i2c
> scl/sda lines.
> +- ams,enable-ac-ok-power-on: Boolean property, to enable exit out of power
> off
> + mode with AC_OK pin (pin enabled in power off mode).
This needs a DT Ack.
> Optional submodule and their properties:
> ===
> diff --git a/drivers/mfd/as3722.c b/drivers/mfd/as3722.c
> index f87342c211bc..4d069ed21ff6 100644
> --- a/drivers/mfd/as3722.c
> +++ b/drivers/mfd/as3722.c
> @@ -349,6 +349,8 @@ static int as3722_i2c_of_probe(struct i2c_client *i2c,
> "ams,enable-internal-int-pullup");
> as3722->en_intern_i2c_pullup = of_property_read_bool(np,
> "ams,enable-internal-i2c-pullup");
> + as3722->en_ac_ok_pwr_on = of_property_read_bool(np,
> + "ams,enable-ac-ok-power-on");
> as3722->irq_flags = irqd_get_trigger_type(irq_data);
> dev_dbg(&i2c->dev, "IRQ flags are 0x%08lx\n", as3722->irq_flags);
> return 0;
> @@ -360,6 +362,7 @@ static int as3722_i2c_probe(struct i2c_client *i2c,
> struct as3722 *as3722;
> unsigned long irq_flags;
> int ret;
> + u8 val = 0;
>
> as3722 = devm_kzalloc(&i2c->dev, sizeof(struct as3722), GFP_KERNEL);
> if (!as3722)
> @@ -398,6 +401,15 @@ static int as3722_i2c_probe(struct i2c_client *i2c,
> if (ret < 0)
> return ret;
>
> + if (as3722->en_ac_ok_pwr_on)
> + val = AS3722_CTRL_SEQU1_AC_OK_PWR_ON;
> + ret = as3722_update_bits(as3722, AS3722_CTRL_SEQU1_REG,
> + AS3722_CTRL_SEQU1_AC_OK_PWR_ON, val);
What is the default value?
If 0, you could place all of this code inside the "if
(as3722->en_ac_ok_pwr_on)" and save on a few unnecessary cycles.
> + if (ret < 0) {
> + dev_err(as3722->dev, "CTRLsequ1 update failed: %d\n", ret);
> + return ret;
> + }
> +
> ret = devm_mfd_add_devices(&i2c->dev, -1, as3722_devs,
> ARRAY_SIZE(as3722_devs), NULL, 0,
> regmap_irq_get_domain(as3722->irq_data));
> diff --git a/include/linux/mfd/as3722.h b/include/linux/mfd/as3722.h
> index 51e6f9414575..b404a5af9bba 100644
> --- a/include/linux/mfd/as3722.h
> +++ b/include/linux/mfd/as3722.h
> @@ -296,6 +296,8 @@
> #define AS3722_ADC1_CONV_NOTREADYBIT(7)
> #define AS3722_ADC1_SOURCE_SELECT_MASK 0x1F
>
> +#define AS3722_CTRL_SEQU1_AC_OK_PWR_ON BIT(0)
> +
> /* GPIO modes */
> #define AS3722_GPIO_MODE_MASK0x07
> #define AS3722_GPIO_MODE_INPUT 0x00
> @@ -391,6 +393,7 @@ struct as3722 {
> unsigned long irq_flags;
> bool en_intern_int_pullup;
> bool en_intern_i2c_pullup;
> + bool en_ac_ok_pwr_on;
> struct regmap_irq_chip_data *irq_data;
> };
>
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
On Wed 04-07-18 09:44:14, Geert Uytterhoeven wrote: [...] > [ cut here ] > WARNING: CPU: 0 PID: 0 at mm/memblock.c:230 > memblock_find_in_range_node+0x11c/0x1be > memblock: bottom-up allocation failed, memory hotunplug may be affected This only means that hotplugable memory might contain non-movable memory now. But does your system even support memory hotplug. I would be really surprised. So I guess we just want this instead diff --git a/mm/memblock.c b/mm/memblock.c index cc16d70b8333..c0dde95593fd 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -228,7 +228,8 @@ phys_addr_t __init_memblock memblock_find_in_range_node(phys_addr_t size, * so we use WARN_ONCE() here to see the stack trace if * fail happens. */ - WARN_ONCE(1, "memblock: bottom-up allocation failed, memory hotunplug may be affected\n"); + WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE), + "memblock: bottom-up allocvation failed, memory hotunplug may be affected\n"); } return __memblock_find_range_top_down(start, end, size, align, nid, -- Michal Hocko SUSE Labs
Re: [PATCH] mm/memblock: replace u64 with phys_addr_t where appropriate
On (07/04/18 10:03), Mike Rapoport wrote: > arch/alpha/kernel/pci_iommu.c | 20 ++-- > arch/arm/mm/alignment.c | 2 +- > arch/arm/nwfpe/fpmodule.c | 2 +- > arch/microblaze/mm/pgtable.c | 2 +- > arch/sparc/kernel/ds.c| 2 +- > arch/um/kernel/sysrq.c| 2 +- > arch/x86/include/asm/trace/exceptions.h | 2 +- > arch/x86/kernel/irq_64.c | 2 +- > arch/x86/mm/extable.c | 4 ++-- > arch/x86/xen/multicalls.c | 2 +- Isn't it "funny" that parisc, ia64, powerpc don't use pf/pF in arch code, but x86, arm, etc. do use pf/pF in arch code? Surely, I do understand why we have pf/pF in mm, drivers and all over the place. But still, I'm surprised. -ss
Re: [PATCH] mfd: ti_am335x_tscadc: Fix struct clk memory leak
On Wed, 04 Jul 2018, Zumeng Chen wrote: > Use devm_elk_get() to let Linux manage struct clk memory to avoid the > following > memory leakage report: > > unreferenced object 0xdd75efc0 (size 64): > comm "systemd-udevd", pid 186, jiffies 4294945126 (age 1195.750s) > hex dump (first 32 bytes): > 61 64 63 5f 74 73 63 5f 66 63 6b 00 00 00 00 00 adc_tsc_fck. > 00 00 00 00 92 03 00 00 00 00 00 00 00 00 00 00 > backtrace: > [] kmemleak_alloc+0x40/0x74 > [] __kmalloc_track_caller+0x198/0x388 > [] kstrdup+0x40/0x5c > [] kstrdup_const+0x30/0x3c > [] __clk_create_clk+0x60/0xac > [] clk_get_sys+0x74/0x144 > [] clk_get+0x5c/0x68 > [] ti_tscadc_probe+0x260/0x468 [ti_am335x_tscadc] > [] platform_drv_probe+0x60/0xac > [] driver_probe_device+0x214/0x2dc > [] __driver_attach+0x94/0xc0 > [] bus_for_each_dev+0x90/0xa0 > [] driver_attach+0x28/0x30 > [] bus_add_driver+0x184/0x1ec > [] driver_register+0xb0/0xf0 > [] __platform_driver_register+0x40/0x54 > > Signed-off-by: Zumeng Chen > --- > drivers/mfd/ti_am335x_tscadc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v5 12/12] mfd: cros_ec: Add throttler sub-device
On Tue, 03 Jul 2018, Matthias Kaehlcke wrote: > Instantiate the CrOS EC throttler if it is enabled in the kernel > configuration. > > Signed-off-by: Matthias Kaehlcke > Reviewed-by: Brian Norris > --- > Changes in v5: > - added 'Reviewed-by: Brian Norris ' tag > > Changes in v4: > - register throttler in cros_ec_dev.c instead of cros_ec.c > > Changes in v3: > - patch added to series > --- > drivers/mfd/cros_ec_dev.c | 19 +++ > 1 file changed, 19 insertions(+) For my own reference: Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3 4/4] arm64: dts: mediatek: add mt6765 support
On 04/07/18 08:47, Mars Cheng wrote:
> Hi Marc
>
> On Wed, 2018-07-04 at 08:35 +0100, Marc Zyngier wrote:
>> On 04/07/18 02:52, Mars Cheng wrote:
>>> This adds basic chip support for MT6765 SoC.
>>>
>>> Signed-off-by: Mars Cheng
>>> ---
>>> arch/arm64/boot/dts/mediatek/Makefile |1 +
>>> arch/arm64/boot/dts/mediatek/mt6765-evb.dts | 33 ++
>>> arch/arm64/boot/dts/mediatek/mt6765.dtsi| 155
>>> +++
>>> 3 files changed, 189 insertions(+)
>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6765-evb.dts
>>> create mode 100644 arch/arm64/boot/dts/mediatek/mt6765.dtsi
>>>
>>
>> [...]
>>
>>> +
>>> + gic: interrupt-controller@c00 {
>>> + compatible = "arm,gic-v3";
>>> + #interrupt-cells = <3>;
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + #redistributor-regions = <1>;
>>> + interrupt-parent = <&gic>;
>>> + interrupt-controller;
>>> + reg = <0 0x0c00 0 0x4>, // distributor
>>> + <0 0x0c10 0 0x20>, // redistributor
>>> + <0 0x0c40 0 0x4>; // gicc
>>
>> For the second time: please add *all* the GIC CPU interface regions,
>> described in the Cortex-A53 TRM[1] (GICC, GICH, and GICV).
>>
>
> MT6765 has no GICH/GICV/ITS in mediatek design. Have confirmed with our
> designer.
The only way *not* to have GICH or GICV is to assert GICCDISABLE on the
CPU, in which case you don't have GICC either, nor any support for the
GICv3 at all. So either the designer is wrong or the documentation is
wrong. Which one is it, do you think?
As for the ITS, that's a perfectly optional part of the design, and not
part of the CPU.
> MT6797 had similar question from you. Sorry for not mentioned it first.
>
> http://lists.infradead.org/pipermail/linux-mediatek/2017-February/008074.html
Well, that's wrong too.
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH v6] Add udmabuf misc device
On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote: > On 07/04/2018 07:53 AM, Gerd Hoffmann wrote: > > On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote: > > > On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote: > > > > A driver to let userspace turn memfd regions into dma-bufs. > > > > > > > > Use case: Allows qemu create dmabufs for the vga framebuffer or > > > > virtio-gpu ressources. Then they can be passed around to display > > > > those guest things on the host. To spice client for classic full > > > > framebuffer display, and hopefully some day to wayland server for > > > > seamless guest window display. > > > > > > > > qemu test branch: > > > >https://git.kraxel.org/cgit/qemu/log/?h=sirius/udmabuf > > > > > > > > Cc: David Airlie > > > > Cc: Tomeu Vizoso > > > > Cc: Laurent Pinchart > > > > Cc: Daniel Vetter > > > > Signed-off-by: Gerd Hoffmann > > > > > > I think some ack for a 2nd use-case, like virtio-wl or whatever would be > > > really cool. To give us some assurance that this is generically useful. > > > > Tomeu? Laurent? > > Sorry, but I think I will need some help to understand how this could help > in the virtio-wl case [adding Zach Reizner to CC]. > > Any graphics buffers that are allocated with memfd will be shared with the > compositor via wl_shm, without need for dmabufs. Within one machine, yes. Once virtualization is added to the mix things become more complicated ... When using virtio-gpu the guest will allocate graphics buffers from normal (guest) ram, then register these buffers (which are allowed to be scattered) with the host as resource. qemu can use memfd to allocate guest ram. Now, with the help of udmabuf, qemu can create a *host* dma-buf for the *guest* graphics buffer. That dma-buf can be used by qemu internally (mmap it to get a linear mapping of the resource, to avoid copying). It can be passed on to spice-client, to display the guest framebuffer. And I think it could also be quite useful to pass guest wayland windows to the host compositor, without mapping host-allocated buffers into the guest, so we don't have do deal with the "find some address space for the mapping" issue in the first place. There are more things needed to complete this of course, but it's a building block ... cheers, Gerd
Re: [PATCH v2 0/8] add support for relative references in jump tables
On Mon, Jul 02, 2018 at 08:11:37PM +0200, Ard Biesheuvel wrote:
> This series implements support for emitting the data structures associated
> with jump tables as 32-bit relative references instead of absolute
> references, which take up more space on builds that target 64-bit
> architectures, or implement self relocation [or both].
>
> This series enables it for arm64 and x86, although other architectures
> might benefit as well.
Hello Ard,
feel free to add the patch below which adds support for s390 to your series.
> Changes since v1:
> - change the relative reference to the static key to a 64-bit wide one on 64
> bit architectures; this is necessary on arm64, which allows modules to
> reside anywhere within a 4 GB window covering the core kernel text, which
> means a 32-bit signed quantity with its +/- 2 GB range is insufficient.
> Note that x86_64 changes are in preparation that widen the relocation
> range as well (using the PIE linker), so I assumed that the same change
> is appropriate for x86 as well.
FWIW, kernel modules on s390 are since ages more than 2GB away from the
core kernel text. So this is required for s390 as well.
>From 77d87236f3d5474f33c25534d8ba2c7c54c88c55 Mon Sep 17 00:00:00 2001
From: Heiko Carstens
Date: Wed, 4 Jul 2018 09:13:37 +0200
Subject: [PATCH] s390/jump_label: switch to relative references
Signed-off-by: Heiko Carstens
---
arch/s390/Kconfig | 1 +
arch/s390/include/asm/jump_label.h | 40 +++---
arch/s390/kernel/jump_label.c | 11 ++-
3 files changed, 23 insertions(+), 29 deletions(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index baed39772c84..0349fb06a2ec 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -121,6 +121,7 @@ config S390
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_JUMP_LABEL
+ select HAVE_ARCH_JUMP_LABEL_RELATIVE
select CPU_NO_EFFICIENT_FFS if !HAVE_MARCH_Z9_109_FEATURES
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_SOFT_DIRTY
diff --git a/arch/s390/include/asm/jump_label.h
b/arch/s390/include/asm/jump_label.h
index 40f651292aa7..e2d3e6c43395 100644
--- a/arch/s390/include/asm/jump_label.h
+++ b/arch/s390/include/asm/jump_label.h
@@ -14,41 +14,33 @@
* We use a brcl 0,2 instruction for jump labels at compile time so it
* can be easily distinguished from a hotpatch generated instruction.
*/
-static __always_inline bool arch_static_branch(struct static_key *key, bool
branch)
+static inline bool arch_static_branch(struct static_key *key, bool branch)
{
- asm_volatile_goto("0: brcl 0,"__stringify(JUMP_LABEL_NOP_OFFSET)"\n"
- ".pushsection __jump_table, \"aw\"\n"
- ".balign 8\n"
- ".quad 0b, %l[label], %0\n"
- ".popsection\n"
- : : "X" (&((char *)key)[branch]) : : label);
-
+ asm_volatile_goto("0: brcl
0,"__stringify(JUMP_LABEL_NOP_OFFSET)"\n"
+ ".pushsection __jump_table,\"aw\"\n"
+ ".balign 8\n"
+ ".long0b-.,%l[label]-.\n"
+ ".quad%0-.\n"
+ ".popsection\n"
+ : : "X" (&((char *)key)[branch]) : : label);
return false;
label:
return true;
}
-static __always_inline bool arch_static_branch_jump(struct static_key *key,
bool branch)
+static inline bool arch_static_branch_jump(struct static_key *key, bool branch)
{
- asm_volatile_goto("0: brcl 15, %l[label]\n"
- ".pushsection __jump_table, \"aw\"\n"
- ".balign 8\n"
- ".quad 0b, %l[label], %0\n"
- ".popsection\n"
- : : "X" (&((char *)key)[branch]) : : label);
-
+ asm_volatile_goto("0: brcl 15,%l[label]\n"
+ ".pushsection __jump_table,\"aw\"\n"
+ ".balign 8\n"
+ ".long0b-.,%l[label]-.\n"
+ ".quad%0-.\n"
+ ".popsection\n"
+ : : "X" (&((char *)key)[branch]) : : label);
return false;
label:
return true;
}
-typedef unsigned long jump_label_t;
-
-struct jump_entry {
- jump_label_t code;
- jump_label_t target;
- jump_label_t key;
-};
-
#endif /* __ASSEMBLY__ */
#endif
diff --git a/arch/s390/kernel/jump_label.c b/arch/s390/kernel/jump_label.c
index 43f8430fb67d..50a1798604a8 100644
--- a/arch/s390/kernel/jump_label.c
+++ b/arch/s390/kernel/jump_label.c
@@ -33,13 +33,13 @@ static void jump_label_make_branch(struct jump_entry
*entry, struct insn *insn)
{
/* brcl 15,offset */
insn->opcode = 0xc0f4;
- insn->offset = (entry->target - entry->code) >> 1;
+ insn->offset = (jump_entry_target(entry) - jump_entry_code(entry)) >> 1;
}
stati
Re: [PATCH 3/3] clk: meson: add sub EMMC clock controller driver
On Wed, 2018-07-04 at 15:17 +0800, Yixun Lan wrote: > > you are describing the mux and the divider here > > however, meson-gx-mmc.c has a few more clock related bits: > > - CLK_CORE_PHASE_MASK > > - CLK_TX_PHASE_MASK > > - CLK_RX_PHASE_MASK > > - CLK_V2_TX_DELAY_MASK / CLK_V3_TX_DELAY_MASK > > - CLK_V2_RX_DELAY_MASK / CLK_V3_RX_DELAY_MASK > > - CLK_V2_ALWAYS_ON / CLK_V3_ALWAYS_ON > > > > are these used for the MMC clock or are some of these routed to the > > NAND pins as well? > > There clocks are not used in NAND driver.. > > I understand your concern here, if there clocks are also routed to NAND > pins, then we also need to implement them here > actually, to answer your question, I need to query the ASIC team.. Even if the NAND driver does not need to change the phases, it might need to make sure these phases are reset on init. It would not hurt to handle these phases in your clock controller.
Re: [RFC v3 PATCH 4/5] mm: mmap: zap pages with read mmap_sem for large mapping
On Tue 03-07-18 11:22:17, Yang Shi wrote: > > > On 7/2/18 11:09 PM, Michal Hocko wrote: > > On Mon 02-07-18 13:48:45, Andrew Morton wrote: > > > On Mon, 2 Jul 2018 16:05:02 +0200 Michal Hocko wrote: > > > > > > > On Fri 29-06-18 20:15:47, Andrew Morton wrote: > > > > [...] > > > > > Would one of your earlier designs have addressed all usecases? I > > > > > expect the dumb unmap-a-little-bit-at-a-time approach would have? > > > > It has been already pointed out that this will not work. > > > I said "one of". There were others. > > Well, I was aware only about two potential solutions. Either do the > > heavy lifting under the shared lock and do the rest with the exlusive > > one and this, drop the lock per parts. Maybe I have missed others? > > > > > > You simply > > > > cannot drop the mmap_sem during unmap because another thread could > > > > change the address space under your feet. So you need some form of > > > > VM_DEAD and handle concurrent and conflicting address space operations. > > > Unclear that this is a problem. If a thread does an unmap of a range > > > of virtual address space, there's no guarantee that upon return some > > > other thread has not already mapped new stuff into that address range. > > > So what's changed? > > Well, consider the following scenario: > > Thread A = calling mmap(NULL, sizeA) > > Thread B = calling munmap(addr, sizeB) > > > > They do not use any external synchronization and rely on the atomic > > munmap. Thread B only munmaps range that it knows belongs to it (e.g. > > called mmap in the past). It should be clear that ThreadA should not > > get an address from the addr, sizeB range, right? In the most simple case > > it will not happen. But let's say that the addr, sizeB range has > > unmapped holes for what ever reasons. Now anytime munmap drops the > > exclusive lock after handling one VMA, Thread A might find its sizeA > > range and use it. ThreadB then might remove this new range as soon as it > > gets its exclusive lock again. > > I'm a little bit confused here. If ThreadB already has unmapped that range, > then ThreadA uses it. It sounds not like a problem since ThreadB should just > go ahead to handle the next range when it gets its exclusive lock again, > right? I don't think of why ThreadB would re-visit that range to remove it. Not if the new range overlap with the follow up range that ThreadB does. Example B: munmap [X][XX] [XX] B: breaks the lock after processing the first vma. A: mmap [] B: munmap retakes the lock and revalidate from the last vm_end because the old vma->vm_next might be gone B: [XXX][X] [XX] so you munmap part of the range. Sure you can plan some tricks and skip over vmas that do not start above your last vma->vm_end or something like that but I expect there are other can of worms hidden there. -- Michal Hocko SUSE Labs
Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header
On Wed 04-07-18 10:25:30, 禹舟键 wrote: > Hi Andy > The const char array need to be used by the new func > mem_cgroup_print_oom_context and some funcs in oom_kill.c in the > second patch. Just declare it in oom.h and define in oom.c -- Michal Hocko SUSE Labs
Re: [PATCH v4] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.
Hi Chanwoo,
On 04/07/18 03:06, Chanwoo Choi wrote:
> Hi Enric,
>
> On 2018년 07월 03일 22:29, Enric Balletbo i Serra wrote:
>> When the devfreq driver and the governor driver are built as modules,
>> the call to devfreq_add_device() or governor_store() fails because the
>> governor driver is not loaded at the time the devfreq driver loads. The
>> devfreq driver has a build dependency on the governor but also should
>> have a runtime dependency. We need to make sure that the governor driver
>> is loaded before the devfreq driver.
>>
>> This patch fixes this bug by adding a try_then_request_governor()
>> function. First tries to find the governor, and then, if it is not found,
>> it requests the module and tries again.
>>
>> Fixes: 1b5c1be2c88e (PM / devfreq: map devfreq drivers to governor using
>> name)
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>>
>> Changes in v4:
>> - Kept "locked" devfreq_list from the return of find_devfreq_governor() to
>> the unlock of governor_store(). Requested by MyungJoo Ham.
>>
>> Changes in v3:
>> - Remove unneded change in dev_err message.
>> - Fix err returned value in case to not find the governor.
>>
>> Changes in v2:
>> - Add a new function to request the module and call that function from
>> devfreq_add_device and governor_store.
>>
>> drivers/devfreq/devfreq.c | 53 ++-
>> 1 file changed, 47 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index 0b5b3abe054e..4ea6b19879a1 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
>> @@ -11,6 +11,7 @@
>> */
>>
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -221,6 +222,46 @@ static struct devfreq_governor
>> *find_devfreq_governor(const char *name)
>> return ERR_PTR(-ENODEV);
>> }
>>
>> +/**
>> + * try_then_request_governor() - Try to find the governor and request the
>> + * module if is not found.
>> + * @name: name of the governor
>
> Usually, devfreq used 'governor_name' indicating the name of governor.
> you better to use 'governor_name' instead of 'name' for more readability.
>
I don't mind to change if you want. But let me try to convince you first. I used
name for two reasons:
1. I saw that you are using governor_name sometimes, but find_devfreq_governor
uses name not governor_name. IMHO the function name in these two specific cases
'try_then_request_governor(name)' is enough readable.
2. If we want to use governor_name and then do not have the line exceeding the
80 characters I need to split the function in two lines. For me the readability
is better when you have all in one line.
If I did not convince you, just let me now and I'll change for governor_name :)
>> + *
>> + * Search the list of devfreq governors and request the module and try again
>> + * if is not found. This can happen when both drivers (the governor driver
>> + * and the driver that call devfreq_add_device) are built as modules.
>> + * devfreq_list_lock should be held by the caller.
>> + *
>> + * Return: The matched governor's pointer.
>
> Usually, devfreq.c didn;t use the 'Return: ...'. So, you better to explain
> what is returned from this function with function description.
>
OK.
>> + */
>> +static struct devfreq_governor *try_then_request_governor(const char *name)
>
> ditto. (name -> governor_name)
>
I convinced you? ;)
>> +{
>> +struct devfreq_governor *governor;
>> +int err = 0;
>
> You have to check whether governor name is NULL or not.
>
> if (IS_ERR_OR_NULL(name)) {
> pr_err("DEVFREQ: %s: Invalid parameters\n", __func__);
> return ERR_PTR(-EINVAL);
> }
>
Right.
>> +
>> +WARN(!mutex_is_locked(&devfreq_list_lock),
>> + "devfreq_list_lock must be locked.");
>> +
>> +governor = find_devfreq_governor(name);
>> +if (IS_ERR(governor)) {
>> +mutex_unlock(&devfreq_list_lock);
>> +
>> +if (!strncmp(name, DEVFREQ_GOV_SIMPLE_ONDEMAND,
>> + DEVFREQ_NAME_LEN))
>> +err = request_module("governor_%s", "simpleondemand");
>> +else
>> +err = request_module("governor_%s", name);
>> +if (err)
>> +return NULL;
>
> When error happen, you unlock the mutex. If failed to request module,
> you should restore the previous state. Please mutex_lock(&devfreq_list_lock)
> before return.
>
Oh right, my bad.
>> +
>> +mutex_lock(&devfreq_list_lock);
>> +
>> +governor = find_devfreq_governor(name);
>> +}
>> +
>> +return governor;
>> +}
>> +
>> static int devfreq_notify_transition(struct devfreq *devfreq,
>> struct devfreq_freqs *freqs, unsigned int state)
>> {
>> @@ -643,11 +684,9 @@ struct devfreq *devfreq_add_device(struct device *dev,
>> srcu_init_notifie
Re: [PATCH 03/12] drm/dp: add helpers for drm_dp_set_adjust_request_pre_emphasis and drm_dp_set_adjust_request_voltage
On Tue, Jul 03, 2018 at 11:02:14AM +0100, Damian Kos wrote:
> From: Quentin Schulz
>
> We already have functions to get the adjust request voltage and
> pre-emphasis for a lane so it makes also sense to be able to set them so
> that we can then easily update them via a DPCD write.
>
> Add helpers for drm_dp_set_adjust_request_pre_emphasis and
> drm_dp_set_adjust_request_voltage that respectively set the
> pre-emphasis and voltage of a lane in the link status array.
>
> Signed-off-by: Quentin Schulz
> Signed-off-by: Damian Kos
Hm usually this is source dependent - some sources only have one
adj/pre-emph value for all lanes, some only 2 (for groups of 2), some for
all four. That's kinda why we don't have helpers for this stuff.
An excellent way to show that your new helpers are useful would be to go
through existing drivers and convert them over, where it makes sense. Same
kinda holds for patch 1.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_dp_helper.c | 28
> include/drm/drm_dp_helper.h |4
> 2 files changed, 32 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 3bc2e98..ca2f469 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -120,6 +120,34 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> +void drm_dp_set_adjust_request_voltage(u8 link_status[DP_LINK_STATUS_SIZE],
> +int lane, u8 volt)
> +{
> + int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
> + int s = ((lane & 1) ?
> + DP_ADJUST_VOLTAGE_SWING_LANE1_SHIFT :
> + DP_ADJUST_VOLTAGE_SWING_LANE0_SHIFT);
> + int idx = i - DP_LANE0_1_STATUS;
> +
> + link_status[idx] &= ~(DP_ADJUST_VOLTAGE_SWING_LANE0_MASK << s);
> + link_status[idx] |= volt << s;
> +}
> +EXPORT_SYMBOL(drm_dp_set_adjust_request_voltage);
> +
> +void drm_dp_set_adjust_request_pre_emphasis(u8
> link_status[DP_LINK_STATUS_SIZE],
> + int lane, u8 pre_emphasis)
> +{
> + int i = DP_ADJUST_REQUEST_LANE0_1 + (lane >> 1);
> + int s = ((lane & 1) ?
> + DP_ADJUST_PRE_EMPHASIS_LANE1_SHIFT :
> + DP_ADJUST_PRE_EMPHASIS_LANE0_SHIFT);
> + int idx = i - DP_LANE0_1_STATUS;
> +
> + link_status[idx] &= ~(DP_ADJUST_PRE_EMPHASIS_LANE0_MASK << s);
> + link_status[idx] |= pre_emphasis << s;
> +}
> +EXPORT_SYMBOL(drm_dp_set_adjust_request_pre_emphasis);
> +
> void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> udelay(100);
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index a488af0..6e64b2a 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -946,6 +946,10 @@ u8 drm_dp_get_adjust_request_voltage(const u8
> link_status[DP_LINK_STATUS_SIZE],
>int lane);
> u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane);
> +void drm_dp_set_adjust_request_voltage(u8 link_status[DP_LINK_STATUS_SIZE],
> +int lane, u8 volt);
> +void drm_dp_set_adjust_request_pre_emphasis(u8
> link_status[DP_LINK_STATUS_SIZE],
> + int lane, u8 pre_emphasis);
>
> #define DP_BRANCH_OUI_HEADER_SIZE0xc
> #define DP_RECEIVER_CAP_SIZE 0xf
> --
> 1.7.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 0/2] Allwinner A64 timer workaround
On 03/07/18 19:42, Samuel Holland wrote: > On 07/03/18 10:09, Marc Zyngier wrote: >> On 11/05/18 03:27, Samuel Holland wrote: >>> Hello, >>> >>> Several people (including me) have experienced extremely large system >>> clock jumps on their A64-based devices, apparently due to the architectural >>> timer going backward, which is interpreted by Linux as the timer wrapping >>> around after 2^56 cycles. >>> >>> Investigation led to discovery of some obvious problems with this SoC's >>> architectural timer, and this patch series introduces what I believe is >>> the simplest workaround. More details are in the commit message for patch >>> 1. Patch 2 simply enables the workaround in the device tree. >> >> What's the deal with this series? There was a couple of nits to address, and >> I was more or less expecting a v2. > > I got reports that people were still occasionally having clock jumps after > applying this series, so I wanted to attempt a more complete fix, but I > haven't > had time to do any deeper investigation. I think this series is still > beneficial > even if it's not a complete solution, so I'll come back with another patch on > top of this if/once I get it fully fixed. > > I'll prepare a v2 with a bounded loop. Presumably, 3 * (max CPU Hz) / (24MHz > timer) ≈ 150 should be a conservative iteration limit? Should be OK. Maxime: How do you want to deal with the documentation aspect? We need an erratum number, but AFAIU the concept hasn't made it into the silicom vendor's brain yet. Any chance you could come up with something that uniquely identifies this? > Also, does this make sense to CC to stable? Probably not, as the HW never worked, so it is not a regression. Thanks, M. -- Jazz is not dead. It just smells funny...
[PATCH -next] mtd: spinand: Fix missing unlock on error path
Add the missing unlock before return from function
spinand_mtd_(read|write) in the error handling case.
Fixes: c898e0526fb6 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Signed-off-by: Wei Yongjun
---
drivers/mtd/nand/spi/core.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 17d207a..8ac1ba95 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -560,12 +560,16 @@ static int spinand_mtd_read(struct mtd_info *mtd, loff_t
from,
nanddev_io_for_each_page(nand, from, ops, &iter) {
ret = spinand_select_target(spinand, iter.req.pos.target);
- if (ret)
+ if (ret) {
+ mutex_unlock(&spinand->lock);
return ret;
+ }
ret = spinand_ecc_enable(spinand, enable_ecc);
- if (ret)
+ if (ret) {
+ mutex_unlock(&spinand->lock);
return ret;
+ }
ret = spinand_read_page(spinand, &iter.req, enable_ecc);
if (ret < 0 && ret != -EBADMSG)
@@ -609,11 +613,11 @@ static int spinand_mtd_write(struct mtd_info *mtd, loff_t
to,
nanddev_io_for_each_page(nand, to, ops, &iter) {
ret = spinand_select_target(spinand, iter.req.pos.target);
if (ret)
- return ret;
+ break;
ret = spinand_ecc_enable(spinand, enable_ecc);
if (ret)
- return ret;
+ break;
ret = spinand_write_page(spinand, &iter.req);
if (ret)
Re: [PATCH v2 3/3] m68k: switch to MEMBLOCK + NO_BOOTMEM
Hi Michael,
On Wed, Jul 4, 2018 at 9:54 AM Michal Hocko wrote:
> On Wed 04-07-18 09:44:14, Geert Uytterhoeven wrote:
> [...]
> > [ cut here ]
> > WARNING: CPU: 0 PID: 0 at mm/memblock.c:230
> > memblock_find_in_range_node+0x11c/0x1be
> > memblock: bottom-up allocation failed, memory hotunplug may be affected
>
> This only means that hotplugable memory might contain non-movable memory
> now. But does your system even support memory hotplug. I would be really
No it doesn't.
> surprised. So I guess we just want this instead
> diff --git a/mm/memblock.c b/mm/memblock.c
> index cc16d70b8333..c0dde95593fd 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -228,7 +228,8 @@ phys_addr_t __init_memblock
> memblock_find_in_range_node(phys_addr_t size,
> * so we use WARN_ONCE() here to see the stack trace if
> * fail happens.
> */
> - WARN_ONCE(1, "memblock: bottom-up allocation failed, memory
> hotunplug may be affected\n");
> + WARN_ONCE(IS_ENABLED(CONFIG_MEMORY_HOTREMOVE),
> + "memblock: bottom-up allocvation
> failed, memory hotunplug may be affected\n");
> }
>
> return __memblock_find_range_top_down(start, end, size, align, nid,
Thanks, that does the trick!
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH -next] mtd: spinand: Fix missing unlock on error path
On Wed, 4 Jul 2018 08:29:39 +
Wei Yongjun wrote:
> Add the missing unlock before return from function
> spinand_mtd_(read|write) in the error handling case.
>
> Fixes: c898e0526fb6 ("mtd: nand: Add core infrastructure to support SPI
> NANDs")
> Signed-off-by: Wei Yongjun
> ---
> drivers/mtd/nand/spi/core.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index 17d207a..8ac1ba95 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -560,12 +560,16 @@ static int spinand_mtd_read(struct mtd_info *mtd,
> loff_t from,
>
> nanddev_io_for_each_page(nand, from, ops, &iter) {
> ret = spinand_select_target(spinand, iter.req.pos.target);
> - if (ret)
> + if (ret) {
> + mutex_unlock(&spinand->lock);
> return ret;
> + }
Why not
if (ret)
break;
?
>
> ret = spinand_ecc_enable(spinand, enable_ecc);
> - if (ret)
> + if (ret) {
> + mutex_unlock(&spinand->lock);
> return ret;
> + }
Ditto.
>
> ret = spinand_read_page(spinand, &iter.req, enable_ecc);
> if (ret < 0 && ret != -EBADMSG)
> @@ -609,11 +613,11 @@ static int spinand_mtd_write(struct mtd_info *mtd,
> loff_t to,
> nanddev_io_for_each_page(nand, to, ops, &iter) {
> ret = spinand_select_target(spinand, iter.req.pos.target);
> if (ret)
> - return ret;
> + break;
>
> ret = spinand_ecc_enable(spinand, enable_ecc);
> if (ret)
> - return ret;
> + break;
>
> ret = spinand_write_page(spinand, &iter.req);
> if (ret)
>
[PATCH -next] mtd: spinand: Fix error return code in spinand_init()
Fix to return error code -ENOMEM from the kzalloc() error handling
case instead of 0, as done elsewhere in this function.
Fixes: c898e0526fb6 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Signed-off-by: Wei Yongjun
---
drivers/mtd/nand/spi/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 17d207a..011683e 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -985,8 +985,10 @@ static int spinand_init(struct spinand_device *spinand)
spinand->databuf = kzalloc(nanddev_page_size(nand) +
nanddev_per_page_oobsize(nand),
GFP_KERNEL);
- if (!spinand->databuf)
+ if (!spinand->databuf) {
+ ret = -ENOMEM;
goto err_free_bufs;
+ }
spinand->oobbuf = spinand->databuf + nanddev_page_size(nand);
Re: [PATCH v4] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.
Hi Enric, On 2018년 07월 04일 17:16, Enric Balletbo i Serra wrote: > Hi Chanwoo, > > On 04/07/18 03:06, Chanwoo Choi wrote: >> Hi Enric, >> >> On 2018년 07월 03일 22:29, Enric Balletbo i Serra wrote: >>> When the devfreq driver and the governor driver are built as modules, >>> the call to devfreq_add_device() or governor_store() fails because the >>> governor driver is not loaded at the time the devfreq driver loads. The >>> devfreq driver has a build dependency on the governor but also should >>> have a runtime dependency. We need to make sure that the governor driver >>> is loaded before the devfreq driver. >>> >>> This patch fixes this bug by adding a try_then_request_governor() >>> function. First tries to find the governor, and then, if it is not found, >>> it requests the module and tries again. >>> >>> Fixes: 1b5c1be2c88e (PM / devfreq: map devfreq drivers to governor using >>> name) >>> Signed-off-by: Enric Balletbo i Serra >>> --- >>> >>> Changes in v4: >>> - Kept "locked" devfreq_list from the return of find_devfreq_governor() to >>> the unlock of governor_store(). Requested by MyungJoo Ham. >>> >>> Changes in v3: >>> - Remove unneded change in dev_err message. >>> - Fix err returned value in case to not find the governor. >>> >>> Changes in v2: >>> - Add a new function to request the module and call that function from >>> devfreq_add_device and governor_store. >>> >>> drivers/devfreq/devfreq.c | 53 ++- >>> 1 file changed, 47 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c >>> index 0b5b3abe054e..4ea6b19879a1 100644 >>> --- a/drivers/devfreq/devfreq.c >>> +++ b/drivers/devfreq/devfreq.c >>> @@ -11,6 +11,7 @@ >>> */ >>> >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -221,6 +222,46 @@ static struct devfreq_governor >>> *find_devfreq_governor(const char *name) >>> return ERR_PTR(-ENODEV); >>> } >>> >>> +/** >>> + * try_then_request_governor() - Try to find the governor and request the >>> + * module if is not found. >>> + * @name: name of the governor >> >> Usually, devfreq used 'governor_name' indicating the name of governor. >> you better to use 'governor_name' instead of 'name' for more readability. >> > > I don't mind to change if you want. But let me try to convince you first. I > used > name for two reasons: > 1. I saw that you are using governor_name sometimes, but find_devfreq_governor > uses name not governor_name. IMHO the function name in these two specific > cases > 'try_then_request_governor(name)' is enough readable. OK. skip the my comment of changing the variable name. Thanks. > 2. If we want to use governor_name and then do not have the line exceeding the > 80 characters I need to split the function in two lines. For me the > readability > is better when you have all in one line. > > If I did not convince you, just let me now and I'll change for governor_name > :) > (snip) -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH -next] mtd: spinand: Fix error return code in spinand_init()
On Wed, 4 Jul 2018 08:34:58 +
Wei Yongjun wrote:
> Fix to return error code -ENOMEM from the kzalloc() error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: c898e0526fb6 ("mtd: nand: Add core infrastructure to support SPI
> NANDs")
> Signed-off-by: Wei Yongjun
Acked-by: Boris Brezillon
> ---
> drivers/mtd/nand/spi/core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index 17d207a..011683e 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -985,8 +985,10 @@ static int spinand_init(struct spinand_device *spinand)
> spinand->databuf = kzalloc(nanddev_page_size(nand) +
> nanddev_per_page_oobsize(nand),
> GFP_KERNEL);
> - if (!spinand->databuf)
> + if (!spinand->databuf) {
> + ret = -ENOMEM;
> goto err_free_bufs;
> + }
>
> spinand->oobbuf = spinand->databuf + nanddev_page_size(nand);
>
Re: [PATCH] rtc: OMAP: Add support for rtc-only mode
On Wednesday 04 July 2018 01:11 PM, Alexandre Belloni wrote:
> Hi,
>
> On 04/07/2018 12:03:45+0530, Keerthy wrote:
>> Prepare rtc driver for rtc-only mode. This involes splitting the power-off
>> function so that an external driver can initiate the programming of
>> setting the power_off to be triggered in the next second.
>>
>
> I'm sorry, I don't see the point, can't you use
> of_device_is_system_power_controller and set the correct pm_power_off
> callback?
Thanks for the quick response.
The commit message did not capture that point apologies for that.
Basically there are two parts to this:
1) RTC plus DDR in self-refresh is power a saving mode where in the
entire system including the different voltage rails from PMIC are
shutdown except the ones feeding on to RTC and DDR. DDR is kept in
self-refresh hence the contents are preserved. RTC ALARM2 is connected
to PMIC_EN line once we the ALARM2 is triggered we enter the mode with
DDR in self-refresh and RTC Ticking. After a predetermined time an RTC
ALARM1 triggers waking up the system[1]. The control goes to bootloader.
The bootloader then checks RTC scratchpad registers to confirm it was an
rtc_only wakeup and follows a different path, configure bare minimal
clocks for ddr and then jumps to the resume address in another RTC
scratchpad registers and transfers the control to Kernel. Kernel then
restores the saved context. omap_rtc_power_off_program does the ALARM2
programming part.
[1] http://www.ti.com/lit/ug/spruhl7h/spruhl7h.pdf Page 2884
2) Power-off: This is usual poweroff mode. omap_rtc_power_off calls the
above omap_rtc_power_off_program function and in addition to that
programs the OMAP_RTC_PMIC_REG for any external wake ups for PMIC like
the pushbutton and shuts off the PMIC.
Hence the split in omap_rtc_power_off. The omap_rtc_power_off_program
caters to rtc_only mode which is NOT poweroff but more of a timed boot.
I can add all the details in the commit message in the next version.
Thanks for pointing to of_device_is_system_power_controller function i
can use this while assigning the pm_power_off function.
>
>> Signed-off-by: Keerthy
>> ---
>> drivers/rtc/interface.c | 12
>> drivers/rtc/rtc-omap.c | 164
>> ++--
>> include/linux/rtc.h | 2 +
>> 3 files changed, 130 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
>> index 6d4012d..d8b70f0 100644
>> --- a/drivers/rtc/interface.c
>> +++ b/drivers/rtc/interface.c
>> @@ -1139,3 +1139,15 @@ int rtc_set_offset(struct rtc_device *rtc, long
>> offset)
>> trace_rtc_set_offset(offset, ret);
>> return ret;
>> }
>> +
>> +/**
>> + * rtc_power_off_program - Some of the rtc are hooked on to PMIC_EN
>> + * line and can be used to power off the SoC.
>> + *
>> + * Kernel interface to program rtc to power off
>> + */
>> +void rtc_power_off_program(struct rtc_device *rtc)
>> +{
>> +rtc->ops->power_off_program(rtc->dev.parent);
>> +}
>> +EXPORT_SYMBOL_GPL(rtc_power_off_program);
>> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
>> index 3908639..4dcee1c 100644
>> --- a/drivers/rtc/rtc-omap.c
>> +++ b/drivers/rtc/rtc-omap.c
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> /*
>> @@ -131,6 +132,8 @@
>> #define KICK0_VALUE 0x83e70b13
>> #define KICK1_VALUE 0x95a4f1e0
>>
>> +#define SHUTDOWN_TIME_SEC 1
>> +
>> struct omap_rtc;
>>
>> struct omap_rtc_device_type {
>> @@ -415,6 +418,77 @@ static int omap_rtc_set_alarm(struct device *dev,
>> struct rtc_wkalrm *alm)
>>
>> static struct omap_rtc *omap_rtc_power_off_rtc;
>>
>> +/**
>> + * omap_rtc_power_off_program: Set the pmic power off sequence. The RTC
>> + * generates pmic_pwr_enable control, which can be used to control an
>> external
>> + * PMIC.
>> + */
>> +void omap_rtc_power_off_program(struct device *dev)
>> +{
>> +u32 val;
>> +struct rtc_time tm;
>> +unsigned long time;
>> +int seconds;
>> +
>> +omap_rtc_power_off_rtc->type->unlock(omap_rtc_power_off_rtc);
>> +
>> +/* Clear any existing ALARM2 event */
>> +rtc_writel(omap_rtc_power_off_rtc, OMAP_RTC_STATUS_REG,
>> + OMAP_RTC_STATUS_ALARM2);
>> +
>> +pr_info("System will go to power_off state in approx. %d second\n",
>> +SHUTDOWN_TIME_SEC);
>> +
>> +again:
>> +/* Read rtc time */
>> +tm.tm_sec = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_SECONDS_REG);
>> +seconds = tm.tm_sec;
>> +tm.tm_min = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_MINUTES_REG);
>> +tm.tm_hour = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_HOURS_REG);
>> +tm.tm_mday = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_DAYS_REG);
>> +tm.tm_mon = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_MONTHS_REG);
>> +tm.tm_year = rtc_read(omap_rtc_power_off_rtc, OMAP_RTC_YEARS_REG);
>> +bcd2tm(&tm);
>> +
>
Re: [PATCH v6 21/21] s390: doc: detailed specifications for AP virtualization
On 03.07.2018 16:56, Tony Krowiak wrote: > On 07/03/2018 03:46 AM, Harald Freudenberger wrote: >> On 02.07.2018 18:28, Halil Pasic wrote: >>> >>> On 06/29/2018 11:11 PM, Tony Krowiak wrote: This patch provides documentation describing the AP architecture and design concepts behind the virtualization of AP devices. It also includes an example of how to configure AP devices for exclusive use of KVM guests. Signed-off-by: Tony Krowiak --- >>> [..] + +Reserve APQNs for exclusive use of KVM guests +- +The following block diagram illustrates the mechanism by which APQNs are +reserved: + + +--+ + remove | | unbind + +--->+ cex4queue driver +<---+ + | | | | + | +--+ | + | | + | | + | | +++-+ register +--+ +-+--+ +| +<-+ | bind | | +| ap_bus | | vfio_ap driver +<-+ admin | +| +->+ | | | ++--+ probe +---++-+ ++ + | | + create | | store APQN + | | + v v + +---++-+ + | | + | matrix device | + | | + +--+ + +The process for reserving an AP queue for use by a KVM guest is: + +* The vfio-ap driver during its initialization will perform the following: + * Create the 'vfio_ap' root device - /sys/devices/vfio_ap + * Create the 'matrix' device in the 'vfio_ap' root + * Register the matrix device with the device core +* Register with the ap_bus for AP queue devices of type 10 devices (CEX4 and + newer) and to provide the vfio_ap driver's probe and remove callback + interfaces. The reason why older devices are not supported is because there + are no systems available on which to test. +* The admin unbinds queue cc. from the cex4queue device driver. This results + in the ap_bus calling the the device driver's remove interface which + unbinds the cc. queue device from the driver. >>> What if the queue cc. is already in use? AFAIU unbind is almost as >>> radical as >>> pulling a cable. What is the proper procedure an admin should follow before >>> doing >>> the unbind? >> What do you mean on this level with 'in use'? A unbind destroys the >> association >> between device and driver. There is no awareness of 'in use' or 'not in use' >> on this >> level. This is a hard unbind. > > According to my reading of the code, the remove callback for the AP queue > drivers > flushes the queue before it is disconnected from the driver. Do you concur > Harald? Yes, you are right. I checked this. The unbind triggers a zcrypt_cex4_queue_remove() which calls ap_queue_remove() which calls ap_flush_queue(). The ap_flush_queue() function does: - for all requests which are queued these are 'received' with -EAGAIN and thus the zcrypt api tries to re-schedule these requests on another apqn. - for all requests which have been sent to the ap but there is no answer yet these are 'reveived' with -EAGAIN and the zcrypt_api tries to re-schedule these requests. [Well, this may in the end lead to some requests sent double...] Looks like the unbind is handled in a smooth way :-) > +* The admin binds the cc. queue to the vfio_ap device driver. This results + in the ap_bus calling the device vfio_ap driver's probe interface to bind + queue cc. to the driver. The vfio_ap device driver will store the APQN for + the queue in the matrix device + >>> [..] >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-s390" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >
Re: [PATCH v4] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.
Hi Enric, Please send this patch to stable-kernel mailing list. Regards, Chanwoo Choi On 2018년 07월 04일 17:26, Chanwoo Choi wrote: > Hi Enric, > > On 2018년 07월 04일 17:16, Enric Balletbo i Serra wrote: >> Hi Chanwoo, >> >> On 04/07/18 03:06, Chanwoo Choi wrote: >>> Hi Enric, >>> >>> On 2018년 07월 03일 22:29, Enric Balletbo i Serra wrote: When the devfreq driver and the governor driver are built as modules, the call to devfreq_add_device() or governor_store() fails because the governor driver is not loaded at the time the devfreq driver loads. The devfreq driver has a build dependency on the governor but also should have a runtime dependency. We need to make sure that the governor driver is loaded before the devfreq driver. This patch fixes this bug by adding a try_then_request_governor() function. First tries to find the governor, and then, if it is not found, it requests the module and tries again. Fixes: 1b5c1be2c88e (PM / devfreq: map devfreq drivers to governor using name) Signed-off-by: Enric Balletbo i Serra --- Changes in v4: - Kept "locked" devfreq_list from the return of find_devfreq_governor() to the unlock of governor_store(). Requested by MyungJoo Ham. Changes in v3: - Remove unneded change in dev_err message. - Fix err returned value in case to not find the governor. Changes in v2: - Add a new function to request the module and call that function from devfreq_add_device and governor_store. drivers/devfreq/devfreq.c | 53 ++- 1 file changed, 47 insertions(+), 6 deletions(-) diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 0b5b3abe054e..4ea6b19879a1 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -11,6 +11,7 @@ */ #include +#include #include #include #include @@ -221,6 +222,46 @@ static struct devfreq_governor *find_devfreq_governor(const char *name) return ERR_PTR(-ENODEV); } +/** + * try_then_request_governor() - Try to find the governor and request the + * module if is not found. + * @name: name of the governor >>> >>> Usually, devfreq used 'governor_name' indicating the name of governor. >>> you better to use 'governor_name' instead of 'name' for more readability. >>> >> >> I don't mind to change if you want. But let me try to convince you first. I >> used >> name for two reasons: >> 1. I saw that you are using governor_name sometimes, but >> find_devfreq_governor >> uses name not governor_name. IMHO the function name in these two specific >> cases >> 'try_then_request_governor(name)' is enough readable. > > OK. skip the my comment of changing the variable name. Thanks. > >> 2. If we want to use governor_name and then do not have the line exceeding >> the >> 80 characters I need to split the function in two lines. For me the >> readability >> is better when you have all in one line. >> >> If I did not convince you, just let me now and I'll change for governor_name >> :) >> > > (snip) >
Re: [PATCH v8 1/2] mfd: bd71837: mfd driver for ROHM BD71837 PMIC
Hello Enric, Lee and others.
Thanks again for taking the time to review the patch! I do appreciate
the effort. Especially because I find reviewing to be quite hard work.
You spotted some obvious things to change but additionally commented on
things which I would rather not change. (Namely the platdata usage and
replacing gotos with in-pklace returns). I would like to get opinion
from Lee on these before implementing the changes. So I will cook new
åatch only after I know what changes are required. Please see my view on
suggested changes below.
On Tue, Jul 03, 2018 at 11:26:00AM +0200, Enric Balletbo Serra wrote:
> One doubt regarding the probe function and few comments.
>
> Missatge de Matti Vaittinen del
> dia dv., 29 de juny 2018 a les 11:47:
> >
> > ROHM BD71837 PMIC MFD driver providing interrupts and support
> > for three subsystems:
> > - clk
> > - Regulators
> > - input/power-key
> >
> > fix too long lines
>
> I guess that this message is not intended to be here.
Right. That's a leftover from squash commit. Good catch!
>
> > +static int bd71837_i2c_probe(struct i2c_client *i2c,
> > + const struct i2c_device_id *id)
> > +{
> > + struct bd71837 *bd71837;
> > + struct bd71837_board *board_info;
> > + int ret = -EINVAL;
> > +
> > + board_info = dev_get_platdata(&i2c->dev);
>
> Sorry in advance if I am missing something, but isn't this always NULL?
At the moment, yes. But the idea is that one using this PMIC could
relatively easily get rid of the "depends on OF" if the PMIC is controlled
for example using X86 family chips. So platdata is a mechanism that
could be used to bring in for example the irq information - or perhaps
the chip type when I add support to BD71847. I can remove the platdata
for now if it really bothers - but if it does not, then I would like to
keep it in.
>
> > +
> > + if (!board_info) {
>
> then this check is not required
Yes. But as I said, I would like to keep this so that platdata could be
used for giving the HW information to driver on certain architectures,
But as I said - if this is a problem it can be removed. Please let me
know if platdata usage is a "show stopper" here.
>
> > + board_info = devm_kzalloc(&i2c->dev, sizeof(*board_info),
> > + GFP_KERNEL);
> > + if (!board_info) {
> > + ret = -ENOMEM;
> > + goto err_out;
>
> Now that you use devm calls and you don't need to unwind things I
> think is better to use plain returns. So,
>
> return -ENOMEM;
I have never really understood why use of gotos in error handling is
discouraged. Personally I would always choose single point of exit from
a function when it is simple enough to achieve (like in this case). I've
written and fixed way too many functions which leak resources or
accidentally keep a lock when exiting from error branches. But I know
many colleagues like you who prefer not to have gotos but in place returns
instead. So I guess I'll leave the final call on this to the one who is
maintainer for this code. And it is true there is no things to unwind
now - which does not mean that next updater won't add such. But as I
said, I know plenty of people share your view - and even though I rather
maintain code with only one exit the final call is on subsystem maintainer
here.
>
> > + } else if (i2c->irq) {
>
> IMO this else is confusing, also maybe you want to warn about the
> missing interrupt.
Right. The else is completely unnecessary as we have goto in previous
if. Nicely spotted-
>
> if (!i2c->irq) {
> dev_err(&i2c->dev, "No IRQ configured!);
> return -EINVAL;
> }
>
> > + board_info->gpio_intr = i2c->irq;
>
> Is board_info really necessary?
>
As explained before the idea of board info is to be able to provide the
HW description without device-tree. It could be used for example to provide
the regulator information to sub device(s). I have not tested/used this
mechanism as my development setup relies on DT - but I like to keep this
as an option for those who need to work on archs which do not have DT
support.
> > + } else {
> > + ret = -ENOENT;
> > + goto err_out;
> > + }
>
> and remove the else
>
> > + }
> > +
> > + if (!board_info)
> > + goto err_out;
> > +
>
> This is redundant.
Right. We have alloc check abowe and goto error there.
> > + bd71837 = devm_kzalloc(&i2c->dev, sizeof(struct bd71837),
> > GFP_KERNEL);
> > + if (bd71837 == NULL)
>
> if (!bd71837)
>
Right.
> > + return -ENOMEM;
> > +
> > + i2c_set_clientdata(i2c, bd71837);
> > + bd71837->dev = &i2c->dev;
> > + bd71837->i2c_client = i2c;
> > + bd71837->chip_irq = board_info->gpio_intr;
>
> bd71837->chip_irq = i2c->irq;
>
Maybe not if we want to keep the platdata support
Re: [PATCH 1/3] soc: amlogic: Add Meson GX Clock Measure driver
Hi Martin,
On 03/07/2018 21:18, Martin Blumenstingl wrote:
> Hi Neil,
>
> On Tue, Jul 3, 2018 at 3:23 PM Neil Armstrong wrote:
>>
>> The Amlogic Meson GX SoCs embeds a clock measurer IP to measure the internal
>> clock paths frequencies.
>> The precision is in the order of the MHz.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/soc/amlogic/Kconfig| 8 ++
>> drivers/soc/amlogic/Makefile | 1 +
>> drivers/soc/amlogic/meson-gx-clk-measure.c | 224
>> +
>> 3 files changed, 233 insertions(+)
>> create mode 100644 drivers/soc/amlogic/meson-gx-clk-measure.c
>>
>> diff --git a/drivers/soc/amlogic/Kconfig b/drivers/soc/amlogic/Kconfig
>> index b04f6e4..4a3217d 100644
>> --- a/drivers/soc/amlogic/Kconfig
>> +++ b/drivers/soc/amlogic/Kconfig
>> @@ -1,5 +1,13 @@
>> menu "Amlogic SoC drivers"
>>
>> +config MESON_GX_CLK_MEASURE
>> + bool "Amlogic Meson GX SoC Clock Measure driver"
>> + depends on ARCH_MESON || COMPILE_TEST
>> + default ARCH_MESON
>> + help
>> + Say yes to support of Measuring a set of internal SoC clocks
>> + from the debugfs interface.
>> +
>> config MESON_GX_SOCINFO
>> bool "Amlogic Meson GX SoC Information driver"
>> depends on ARCH_MESON || COMPILE_TEST
>> diff --git a/drivers/soc/amlogic/Makefile b/drivers/soc/amlogic/Makefile
>> index 8fa3218..a0ad966 100644
>> --- a/drivers/soc/amlogic/Makefile
>> +++ b/drivers/soc/amlogic/Makefile
>> @@ -1,3 +1,4 @@
>> +obj-$(CONFIG_MESON_GX_CLK_MEASURE) += meson-gx-clk-measure.o
>> obj-$(CONFIG_MESON_GX_SOCINFO) += meson-gx-socinfo.o
>> obj-$(CONFIG_MESON_GX_PM_DOMAINS) += meson-gx-pwrc-vpu.o
>> obj-$(CONFIG_MESON_MX_SOCINFO) += meson-mx-socinfo.o
>> diff --git a/drivers/soc/amlogic/meson-gx-clk-measure.c
>> b/drivers/soc/amlogic/meson-gx-clk-measure.c
>> new file mode 100644
>> index 000..434d9f3
>> --- /dev/null
>> +++ b/drivers/soc/amlogic/meson-gx-clk-measure.c
[...]
>> + CLK_MSR_ID(57, "wave420l_c"),
>> + CLK_MSR_ID(58, "wave420l_b"),
> AFAIK the Chips&Media WAVE420L video codec is only available on GXM (S912)
> I assume reading this on GXBB or GXL simply reads 0?
Yes
>
>> + CLK_MSR_ID(59, "hcodec"),
>> + CLK_MSR_ID(60, "alt_32k"),
>> + CLK_MSR_ID(61, "gpio_msr"),
>> + CLK_MSR_ID(62, "hevc"),
>> + CLK_MSR_ID(66, "vid_lock"),
>> + CLK_MSR_ID(70, "pwm_f"),
>> + CLK_MSR_ID(71, "pwm_e"),
>> + CLK_MSR_ID(72, "pwm_d"),
>> + CLK_MSR_ID(73, "pwm_C"),
> should this be pwm_c (instead of pwm_C)?
>
>> + CLK_MSR_ID(75, "aoclkx2_int"),
>> + CLK_MSR_ID(76, "aoclk_int"),
>> + CLK_MSR_ID(77, "rng_ring_osc_0"),
>> + CLK_MSR_ID(78, "rng_ring_osc_1"),
>> + CLK_MSR_ID(79, "rng_ring_osc_2"),
>> + CLK_MSR_ID(80, "rng_ring_osc_3"),
>> + CLK_MSR_ID(81, "vapb"),
>> + CLK_MSR_ID(82, "ge2d"),
>> +};
> I did a quick check whether the clock IDs are really the same for all GX SoCs:
> apart from clocks missing on older SoCs (see for example the WAVE420L
> clocks above) there were only minor renames but no conflicts!
I did the same work ! I will add this detail to the commit log.
Thanks for checking ;-)
>
>> +
>> +static int meson_gx_measure_id(struct meson_gx_msr *priv, unsigned int id)
>> +{
>> + unsigned int val;
>> + int ret;
>> +
>> + regmap_write(priv->regmap, MSR_CLK_REG0, 0);
>> +
>> + /* Set measurement gate to 50uS */
>> + regmap_update_bits(priv->regmap, MSR_CLK_REG0, MSR_CLK_DIV,
>> + FIELD_PREP(MSR_CLK_DIV, DIV_50US));
>> +
>> + /* Set ID */
>> + regmap_update_bits(priv->regmap, MSR_CLK_REG0, MSR_CLK_SRC,
>> + FIELD_PREP(MSR_CLK_SRC, id));
>> +
>> + /* Enable & Start */
>> + regmap_update_bits(priv->regmap, MSR_CLK_REG0,
>> + MSR_RUN | MSR_ENABLE,
>> + MSR_RUN | MSR_ENABLE);
>> +
>> + ret = regmap_read_poll_timeout(priv->regmap, MSR_CLK_REG0,
>> + val, !(val & MSR_BUSY), 10, 1000);
>> + if (ret)
>> + return ret;
>> +
>> + /* Disable */
>> + regmap_update_bits(priv->regmap, MSR_CLK_REG0, MSR_ENABLE, 0);
>> +
>> + /* Get the value in MHz*64 */
>> + regmap_read(priv->regmap, MSR_CLK_REG2, &val);
>> +
>> + return (((val + 31) & MSR_VAL_MASK) / 64) * 100;
>> +}
>> +
>> +static int clk_msr_show(struct seq_file *s, void *data)
>> +{
>> + struct meson_gx_msr_id *clk_msr_id = s->private;
>> + int val;
>> +
>> + val = meson_gx_measure_id(clk_msr_id->priv, clk_msr_id->id);
>> + if (val < 0)
>> + return val;
>> +
>> + seq_printf(s, "%d\n", val);
With jerome, we managed to have a much higher precision by cycling over the
divider
and checking when the counter overflows. And I will print the precision in the
clock debugfs
entry.
>> +
>>
RE: [PATCH] net: ethernet: gianfar_ethtool: remove redundant variable last_rule_idx
>-Original Message- >From: Colin King [mailto:colin.k...@canonical.com] >Sent: Wednesday, July 4, 2018 10:55 AM >To: Claudiu Manoil ; David S . Miller >; net...@vger.kernel.org >Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org >Subject: [PATCH] net: ethernet: gianfar_ethtool: remove redundant variable >last_rule_idx > >From: Colin Ian King > >Variable last_rule_idx is being assigned but is never used hence it is >redundant and can be removed. > >Cleans up clang warning: >warning: variable 'last_rule_idx' set but not used [-Wunused-but-set-variable] > >Signed-off-by: Colin Ian King Acked-by: Claudiu Manoil
Re: [PATCH v2] mtd: atmel-quadspi: add suspend/resume hooks
Hi, Claudiu,
On 06/04/2018 11:46 AM, Claudiu Beznea wrote:
> Implement suspend/resume hooks.
>
> Signed-off-by: Claudiu Beznea
> ---
>
> Changes in v2:
> - use __maybe_unused instead of #ifdef CONFIG_PM_SLEEP
>
> drivers/mtd/spi-nor/atmel-quadspi.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c
> b/drivers/mtd/spi-nor/atmel-quadspi.c
> index 6c5708bacad8..ceaaef47f02e 100644
> --- a/drivers/mtd/spi-nor/atmel-quadspi.c
> +++ b/drivers/mtd/spi-nor/atmel-quadspi.c
> @@ -737,6 +737,26 @@ static int atmel_qspi_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static int __maybe_unused atmel_qspi_suspend(struct device *dev)
> +{
> + struct atmel_qspi *aq = dev_get_drvdata(dev);
> +
> + clk_disable_unprepare(aq->clk);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused atmel_qspi_resume(struct device *dev)
> +{
> + struct atmel_qspi *aq = dev_get_drvdata(dev);
> +
> + clk_prepare_enable(aq->clk);
You missed to verify the return value of clk_prepare_enable. Otherwise looks
good. I've also looked over the test with suspending while copying on a ubifs
mounted on QSPI NOR, looks good too.
After checking the return value, please add:
Reviewed-by: Tudor Ambarus
Best,
ta
> +
> + return atmel_qspi_init(aq);
> +}
> +
> +static SIMPLE_DEV_PM_OPS(atmel_qspi_pm_ops, atmel_qspi_suspend,
> + atmel_qspi_resume);
>
> static const struct of_device_id atmel_qspi_dt_ids[] = {
> { .compatible = "atmel,sama5d2-qspi" },
> @@ -749,6 +769,7 @@ static struct platform_driver atmel_qspi_driver = {
> .driver = {
> .name = "atmel_qspi",
> .of_match_table = atmel_qspi_dt_ids,
> + .pm = &atmel_qspi_pm_ops,
> },
> .probe = atmel_qspi_probe,
> .remove = atmel_qspi_remove,
>
[PATCH v5] PM / devfreq: Fix devfreq_add_device() when drivers are built as modules.
When the devfreq driver and the governor driver are built as modules,
the call to devfreq_add_device() or governor_store() fails because the
governor driver is not loaded at the time the devfreq driver loads. The
devfreq driver has a build dependency on the governor but also should
have a runtime dependency. We need to make sure that the governor driver
is loaded before the devfreq driver.
This patch fixes this bug by adding a try_then_request_governor()
function. First tries to find the governor, and then, if it is not found,
it requests the module and tries again.
Fixes: 1b5c1be2c88e (PM / devfreq: map devfreq drivers to governor using name)
Signed-off-by: Enric Balletbo i Serra
---
Changes in v5:
- Requested by MyungJoo and Chanwoo.
- Fix returning without the lock acquired after request_module.
- Requested by Chanwoo.
- In request governor function check if governor name is NULL or not.
- Remove some unrelated changes (added/removed some blank lines).
Changes in v4:
- Kept "locked" devfreq_list from the return of find_devfreq_governor() to
the unlock of governor_store(). Requested by MyungJoo Ham.
Changes in v3:
- Remove unneded change in dev_err message.
- Fix err returned value in case to not find the governor.
Changes in v2:
- Add a new function to request the module and call that function from
devfreq_add_device and governor_store.
drivers/devfreq/devfreq.c | 53 ---
1 file changed, 49 insertions(+), 4 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 0b5b3abe054e..aa92fbf9f0dd 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
#include
@@ -221,6 +222,49 @@ static struct devfreq_governor
*find_devfreq_governor(const char *name)
return ERR_PTR(-ENODEV);
}
+/**
+ * try_then_request_governor() - Try to find the governor and request the
+ * module if is not found.
+ * @name: name of the governor
+ *
+ * Search the list of devfreq governors and request the module and try again
+ * if is not found. This can happen when both drivers (the governor driver
+ * and the driver that call devfreq_add_device) are built as modules.
+ * devfreq_list_lock should be held by the caller. Returns the matched
+ * governor's pointer.
+ */
+static struct devfreq_governor *try_then_request_governor(const char *name)
+{
+ struct devfreq_governor *governor;
+ int err = 0;
+
+ if (IS_ERR_OR_NULL(name)) {
+ pr_err("DEVFREQ: %s: Invalid parameters\n", __func__);
+ return ERR_PTR(-EINVAL);
+ }
+ WARN(!mutex_is_locked(&devfreq_list_lock),
+"devfreq_list_lock must be locked.");
+
+ governor = find_devfreq_governor(name);
+ if (IS_ERR(governor)) {
+ mutex_unlock(&devfreq_list_lock);
+
+ if (!strncmp(name, DEVFREQ_GOV_SIMPLE_ONDEMAND,
+DEVFREQ_NAME_LEN))
+ err = request_module("governor_%s", "simpleondemand");
+ else
+ err = request_module("governor_%s", name);
+ /* Restore previous state before return */
+ mutex_lock(&devfreq_list_lock);
+ if (err)
+ return NULL;
+
+ governor = find_devfreq_governor(name);
+ }
+
+ return governor;
+}
+
static int devfreq_notify_transition(struct devfreq *devfreq,
struct devfreq_freqs *freqs, unsigned int state)
{
@@ -645,9 +689,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(&devfreq->lock);
mutex_lock(&devfreq_list_lock);
- list_add(&devfreq->node, &devfreq_list);
- governor = find_devfreq_governor(devfreq->governor_name);
+ governor = try_then_request_governor(devfreq->governor_name);
if (IS_ERR(governor)) {
dev_err(dev, "%s: Unable to find governor for the device\n",
__func__);
@@ -663,12 +706,14 @@ struct devfreq *devfreq_add_device(struct device *dev,
__func__);
goto err_init;
}
+
+ list_add(&devfreq->node, &devfreq_list);
+
mutex_unlock(&devfreq_list_lock);
return devfreq;
err_init:
- list_del(&devfreq->node);
mutex_unlock(&devfreq_list_lock);
device_unregister(&devfreq->dev);
@@ -989,7 +1034,7 @@ static ssize_t governor_store(struct device *dev, struct
device_attribute *attr,
return -EINVAL;
mutex_lock(&devfreq_list_lock);
- governor = find_devfreq_governor(str_governor);
+ governor = try_then_request_governor(str_governor);
if (IS_ERR(governor)) {
ret = PTR_ERR(governor);
goto out;
--
2.18.0
Re: [V9fs-developer] [PATCH] fs: 9p: Adding new return type vm_fault_t
LGTM
On 2018/7/2 23:49, Souptick Joarder wrote:
> Use new return type vm_fault_t for page_mkwrite
> handler.
>
> see commit 1c8f422059ae ("mm: change return type to
> vm_fault_t") for reference.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
Acked-by: Jun Piao
> ---
> fs/9p/vfs_file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c
> index 03c9e32..5f2e48d 100644
> --- a/fs/9p/vfs_file.c
> +++ b/fs/9p/vfs_file.c
> @@ -533,7 +533,7 @@ int v9fs_file_fsync_dotl(struct file *filp, loff_t start,
> loff_t end,
> return retval;
> }
>
> -static int
> +static vm_fault_t
> v9fs_vm_page_mkwrite(struct vm_fault *vmf)
> {
> struct v9fs_inode *v9inode;
> --
> 1.9.1
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> V9fs-developer mailing list
> v9fs-develo...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/v9fs-developer
>
Re: [REGRESSION] "Locked" and "Pss" in /proc/*/smaps are the same
On 07/03/2018 06:20 PM, Daniel Colascione wrote: > On Tue, Jul 3, 2018 at 12:36 AM, Vlastimil Babka wrote: >> +CC >> >> On 07/01/2018 08:31 PM, Thomas Lindroth wrote: >>> While looking around in /proc on my v4.14.52 system I noticed that >>> all processes got a lot of "Locked" memory in /proc/*/smaps. A lot >>> more memory than a regular user can usually lock with mlock(). >>> >>> commit 493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317 (v4.14-rc1) seems >>> to have changed the behavior of "Locked". > > Thanks for fixing that. I submitted a patch [1] for this bug and some > others a while ago, but the patch didn't make it into the tree because > or wasn't split up correctly or something, and I had to do other work. Hmm I see. I pondered about the patch and wondered if the scenarios it fixes are really possible for smaps_rollup. Did you observe them in practice? Namely: - when seq_file starts and stops multiple times on a single open file description - when it issues multiple show calls for the same iterator value I don't think it can happen when all positions but the last one just return SEQ_SKIP. Anyway I think the seq_file iterator API usage for smaps_rollup is unnecessary. Semantically the file shows only one "element" and that's the set of rollup values for all vmas. Letting seq_file do the iteration over vmas brings only complications? > [1] https://marc.info/?l=linux-mm&m=151927723128134&w=2 >
Re: [PATCH] refcount: always allow checked forms
On Tue, Jul 03, 2018 at 11:01:02AM +0100, Mark Rutland wrote:
> In many cases, it would be useful to be able to use the full
> sanity-checked refcount helpers regardless of CONFIG_REFCOUNT_FULL, as
> this would help to avoid duplicate warnings where callers try to
> sanity-check refcount manipulation.
>
> This patch refactors things such that the full refcount helpers were
> always built, as refcount_${op}_checked(), such that they can be used
> regardless of CONFIG_REFCOUNT_FULL. This will allow code which *always*
> wants a checked refcount to opt-in, avoiding the need to duplicate the
> logic for warnings.
>
> There should be no functional change as a result of this patch.
>
> Signed-off-by: Mark Rutland
> Cc: Boqun Feng
> Cc: David Sterba
> Cc: Ingo Molnar
> Cc: Kees Cook
> Cc: Peter Zijlstra
> Cc: Peter Zijlstra
> Cc: Will Deacon
I dare to give it my
Reviewed-by: David Sterba
as my POC implementations were crap and Mark's version is much better.
> ---
> include/linux/refcount.h | 27 +---
> lib/refcount.c | 53
> +++-
> 2 files changed, 45 insertions(+), 35 deletions(-)
>
> Dave pointed out that it would be useful to be able to opt-in to full checks
> regardless of CONFIG_REFCOUNT_FULL, so that we can simplify callsites where we
> always want checks. I've spotted a few of these in code which is still
> awaiting
> conversion.
The motivation was code like
WARN_ON(refcount_read(&ref));
if (refcount_dec_and_test(&ref)) { ... }
so the warning is redundant for REFCOUNT_FULL, but I'm going to use the
_checked versions everywhere the performance of refcounts is not
critical.
Re: [PATCH v7 0/4] mfd/regulator/clk/input: bd71837: ROHM BD71837 PMIC driver
On Tue, Jul 03, 2018 at 08:02:00AM +0100, Lee Jones wrote: > On Thu, 21 Jun 2018, Matti Vaittinen wrote: > > > On Tue, Jun 19, 2018 at 01:55:31PM +0300, Matti Vaittinen wrote: > > > Patch series adding support for ROHM BD71837 PMIC. > > > > > What is the preferred way when I send updated patches: > > > > 1. always resend _all_ unapplied patches even if there is no changes to > >some of them. (patch-vN mail thread contains _all_ unapplied patches) > > 2. only resend changed patches (patch-vN mail thread contains only > >patches that were changed from patch-vN-1) > > > > I have currently used approach 1 - so that no patches would be > > accidentally forgotten - but downside is that people need to check if > > they have already reviewed some of the patches. I'd rather not caused > > any extra work. What is the most convenient way for you guys? > > Option 1 is preferred. > > Just ensure you apply any tags you have collected so reviewers can see > which patches are pending a review. It's also a good idea to keep a > succinct change log between the "--" marker and the diff stat where > you can state "v4: No change" or the like. Right. Thanks. Just one question - what if I get reviewed-by for a patch which I later rework? Like this MFD patch where I got reviewed-by from Linus Walleij for v6 - but which I reworked due to comments from Enric and Dmitry. I have not kept the reviewed-by as the patch is not exactly the same Linus was originally reviewing. I guess the tags should be only kept for patches which are unchanged, right? > > -- > Lee Jones [李琼斯] > Linaro Services Technical Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header
On Wed, Jul 4, 2018 at 5:25 AM, 禹舟键 wrote:
> Hi Andy
> The const char array need to be used by the new func
> mem_cgroup_print_oom_context and some funcs in oom_kill.c in the
> second patch.
Did I understand correctly that the array is added by you in this solely patch?
Did I understand correctly that it's used only in one module
(oom_kill.c in new version)?
If both are true, just move it to the C file.
If you need a synchronization, a) put a comment, b) create another
enum item (like FOO_BAR_MAX) at the end and use it in the array as a
fixed size,
>
> Thanks
>
>>
>> On Sat, Jun 30, 2018 at 7:38 PM, wrote:
>> > From: yuzhoujian
>> >
>> > The current system wide oom report prints information about the victim
>> > and the allocation context and restrictions. It, however, doesn't
>> > provide any information about memory cgroup the victim belongs to. This
>> > information can be interesting for container users because they can find
>> > the victim's container much more easily.
>> >
>> > I follow the advices of David Rientjes and Michal Hocko, and refactor
>> > part of the oom report. After this patch, users can get the memcg's
>> > path from the oom report and check the certain container more quickly.
>> >
>> > The oom print info after this patch:
>> > oom-kill:constraint=,nodemask=,oom_memcg=,task_memcg=,task=,pid=,uid=
>>
>>
>> > +static const char * const oom_constraint_text[] = {
>> > + [CONSTRAINT_NONE] = "CONSTRAINT_NONE",
>> > + [CONSTRAINT_CPUSET] = "CONSTRAINT_CPUSET",
>> > + [CONSTRAINT_MEMORY_POLICY] = "CONSTRAINT_MEMORY_POLICY",
>> > + [CONSTRAINT_MEMCG] = "CONSTRAINT_MEMCG",
>> > +};
>>
>> I'm not sure why we have this in the header.
>>
>> This produces a lot of noise when W=1.
>>
>> In file included from
>> /home/andy/prj/linux-topic-mfld/include/linux/memcontrol.h:31:0,
>> from /home/andy/prj/linux-topic-mfld/include/net/sock.h:58,
>> from /home/andy/prj/linux-topic-mfld/include/linux/tcp.h:23,
>> from /home/andy/prj/linux-topic-mfld/include/linux/ipv6.h:87,
>> from /home/andy/prj/linux-topic-mfld/include/net/ipv6.h:16,
>> from
>> /home/andy/prj/linux-topic-mfld/net/ipv4/netfilter/nf_log_ipv4.c:17:
>> /home/andy/prj/linux-topic-mfld/include/linux/oom.h:32:27: warning:
>> ‘oom_constraint_text’ defined but not used [-W
>> unused-const-variable=]
>> static const char * const oom_constraint_text[] = {
>> ^~~
>> CC [M] net/ipv4/netfilter/iptable_nat.o
>>
>>
>> If you need (but looking at the code you actually don't if I didn't
>> miss anything) it in several places, just export.
>> Otherwise put it back to memcontrol.c.
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 0/8] add support for relative references in jump tables
On 4 July 2018 at 09:59, Heiko Carstens wrote:
> On Mon, Jul 02, 2018 at 08:11:37PM +0200, Ard Biesheuvel wrote:
>> This series implements support for emitting the data structures associated
>> with jump tables as 32-bit relative references instead of absolute
>> references, which take up more space on builds that target 64-bit
>> architectures, or implement self relocation [or both].
>>
>> This series enables it for arm64 and x86, although other architectures
>> might benefit as well.
>
> Hello Ard,
>
> feel free to add the patch below which adds support for s390 to your series.
>
Thanks, I will incorporate it into v3 and beyond.
>> Changes since v1:
>> - change the relative reference to the static key to a 64-bit wide one on 64
>> bit architectures; this is necessary on arm64, which allows modules to
>> reside anywhere within a 4 GB window covering the core kernel text, which
>> means a 32-bit signed quantity with its +/- 2 GB range is insufficient.
>> Note that x86_64 changes are in preparation that widen the relocation
>> range as well (using the PIE linker), so I assumed that the same change
>> is appropriate for x86 as well.
>
> FWIW, kernel modules on s390 are since ages more than 2GB away from the
> core kernel text. So this is required for s390 as well.
>
OK, good to know.
--
Ard.
> From 77d87236f3d5474f33c25534d8ba2c7c54c88c55 Mon Sep 17 00:00:00 2001
> From: Heiko Carstens
> Date: Wed, 4 Jul 2018 09:13:37 +0200
> Subject: [PATCH] s390/jump_label: switch to relative references
>
> Signed-off-by: Heiko Carstens
> ---
> arch/s390/Kconfig | 1 +
> arch/s390/include/asm/jump_label.h | 40
> +++---
> arch/s390/kernel/jump_label.c | 11 ++-
> 3 files changed, 23 insertions(+), 29 deletions(-)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index baed39772c84..0349fb06a2ec 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -121,6 +121,7 @@ config S390
> select HAVE_ALIGNED_STRUCT_PAGE if SLUB
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_JUMP_LABEL
> + select HAVE_ARCH_JUMP_LABEL_RELATIVE
> select CPU_NO_EFFICIENT_FFS if !HAVE_MARCH_Z9_109_FEATURES
> select HAVE_ARCH_SECCOMP_FILTER
> select HAVE_ARCH_SOFT_DIRTY
> diff --git a/arch/s390/include/asm/jump_label.h
> b/arch/s390/include/asm/jump_label.h
> index 40f651292aa7..e2d3e6c43395 100644
> --- a/arch/s390/include/asm/jump_label.h
> +++ b/arch/s390/include/asm/jump_label.h
> @@ -14,41 +14,33 @@
> * We use a brcl 0,2 instruction for jump labels at compile time so it
> * can be easily distinguished from a hotpatch generated instruction.
> */
> -static __always_inline bool arch_static_branch(struct static_key *key, bool
> branch)
> +static inline bool arch_static_branch(struct static_key *key, bool branch)
> {
> - asm_volatile_goto("0: brcl 0,"__stringify(JUMP_LABEL_NOP_OFFSET)"\n"
> - ".pushsection __jump_table, \"aw\"\n"
> - ".balign 8\n"
> - ".quad 0b, %l[label], %0\n"
> - ".popsection\n"
> - : : "X" (&((char *)key)[branch]) : : label);
> -
> + asm_volatile_goto("0: brcl
> 0,"__stringify(JUMP_LABEL_NOP_OFFSET)"\n"
> + ".pushsection __jump_table,\"aw\"\n"
> + ".balign 8\n"
> + ".long0b-.,%l[label]-.\n"
> + ".quad%0-.\n"
> + ".popsection\n"
> + : : "X" (&((char *)key)[branch]) : : label);
> return false;
> label:
> return true;
> }
>
> -static __always_inline bool arch_static_branch_jump(struct static_key *key,
> bool branch)
> +static inline bool arch_static_branch_jump(struct static_key *key, bool
> branch)
> {
> - asm_volatile_goto("0: brcl 15, %l[label]\n"
> - ".pushsection __jump_table, \"aw\"\n"
> - ".balign 8\n"
> - ".quad 0b, %l[label], %0\n"
> - ".popsection\n"
> - : : "X" (&((char *)key)[branch]) : : label);
> -
> + asm_volatile_goto("0: brcl 15,%l[label]\n"
> + ".pushsection __jump_table,\"aw\"\n"
> + ".balign 8\n"
> + ".long0b-.,%l[label]-.\n"
> + ".quad%0-.\n"
> + ".popsection\n"
> + : : "X" (&((char *)key)[branch]) : : label);
> return false;
> label:
> return true;
> }
>
> -typedef unsigned long jump_label_t;
> -
> -struct jump_entry {
> - jump_label_t code;
> - jump_label_t target;
> - jump_label_t key;
> -};
> -
> #endif /* __ASSEMBLY__ */
> #endif
> diff --git a/arch/s390/kernel/jump_label.c b/arch/s390/kernel/jump_label.c
> index 43f8430fb67d..50a1798604a8 100644
> --- a/arch/s390/kernel/jump_label.c
> +++
[BUG] Serial/dma stall/failure after "dmaengine: fsl-edma: extract common fsl-edma code (no changes in behavior intended)"
Hi,
The commit 6ad069123f03bebe4315dea13d44845854ca6043 ("dmaengine:
fsl-edma: extract common fsl-edma code (no changes in behavior
intended)"), even though marked as no changes in behavior intended...
make serial console with DMA broken after boot. The console just hangs
- is not responsive even to SysRq. Usually after finishing boot -
before or after login prompt. Sometimes login is allowed and then it
hangs during printing dmesg.
Board: Toradex Colibri VF50 (NXP VF500, Cortex A5, serial configured
with DMA) on Iris Carrier.
Commit found with bisect:
git bisect start
# bad: [bce40927669338cc4a361fc97d46bf650573ce5c] Add linux-next
specific files for 20180704
git bisect bad bce40927669338cc4a361fc97d46bf650573ce5c
# good: [410da1e12ffed61129d61df5b7adce4d08c7f17c] net/smc: fix up
merge error with poll changes
git bisect good 410da1e12ffed61129d61df5b7adce4d08c7f17c
# good: [decd57900d6fd743f7ddc1329400f4bd9cf54284] Merge
remote-tracking branch 'crypto/master'
git bisect good decd57900d6fd743f7ddc1329400f4bd9cf54284
# good: [e9484bb660753ca8a35d219db000fff967b70a2c] Merge
remote-tracking branch 'tip/auto-latest'
git bisect good e9484bb660753ca8a35d219db000fff967b70a2c
# bad: [20adee487b5f252d3f38197d43487c004273d3d0] Merge
remote-tracking branch 'slave-dma/next'
git bisect bad 20adee487b5f252d3f38197d43487c004273d3d0
# good: [2df2577dce1d5fd98cac342fe857677a0556421b] Merge
remote-tracking branch 'tty/tty-next'
git bisect good 2df2577dce1d5fd98cac342fe857677a0556421b
# good: [03b17ed8410a61f4f337c7bcfded1f744182edd5] spi: spi-fsl-dspi:
Fix imprecise abort on VF500 during probe
git bisect good 03b17ed8410a61f4f337c7bcfded1f744182edd5
# good: [85e1d42663a0c163002961d2685be952067b0dc2] staging:
mt7621-eth: Fix memory leak in mtk_add_mac() error path
git bisect good 85e1d42663a0c163002961d2685be952067b0dc2
# good: [b244f917acb7e1f492c40f6f4cf7be860a5065a5] staging: rtl8188eu:
remove blank lines
git bisect good b244f917acb7e1f492c40f6f4cf7be860a5065a5
# good: [b244f917acb7e1f492c40f6f4cf7be860a5065a5] staging: rtl8188eu:
remove blank lines
git bisect good b244f917acb7e1f492c40f6f4cf7be860a5065a5
# good: [b244f917acb7e1f492c40f6f4cf7be860a5065a5] staging: rtl8188eu:
remove blank lines
git bisect good b244f917acb7e1f492c40f6f4cf7be860a5065a5
# good: [6c796f514b7f8d0fef4733b971a5ded9e9a74490] Merge
remote-tracking branch 'staging/staging-next'
git bisect good 6c796f514b7f8d0fef4733b971a5ded9e9a74490
# good: [14dfa379ffd3ffd73729a72c289e9db6780a60ab] Merge branch
'topic/ste' into next
git bisect good 14dfa379ffd3ffd73729a72c289e9db6780a60ab
# good: [c1199875d327a9b3bbb3fb1cca0d467d3e625fbb] dmaengine:
imx-sdma: Use GFP_NOWAIT for dma allocations
git bisect good c1199875d327a9b3bbb3fb1cca0d467d3e625fbb
# bad: [15efb0b488596a929bc00ce23aeb746ee6a7c14d] dmaengine: fsl-edma:
fix trailing whitespace
git bisect bad 15efb0b488596a929bc00ce23aeb746ee6a7c14d
# bad: [5c1355ad87a2c138049bfafa753b44046492aebc] dmaengine: fsl-edma:
add ColdFire mcf5441x edma support
git bisect bad 5c1355ad87a2c138049bfafa753b44046492aebc
# bad: [6ad069123f03bebe4315dea13d44845854ca6043] dmaengine: fsl-edma:
extract common fsl-edma code (no changes in behavior intended)
git bisect bad 6ad069123f03bebe4315dea13d44845854ca6043
# first bad commit: [6ad069123f03bebe4315dea13d44845854ca6043]
dmaengine: fsl-edma: extract common fsl-edma code (no changes in
behavior intended)
Defconfig and boot log attached. I could not find any obvious error in boot log.
Let me know if you need more data.
Best regards,
Krzysztof
vf_defconfig
Description: Binary data
[0.00] Memory policy: Data cache writeback
[0.00] cma: Reserved 16 MiB at 0x8700
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] random: get_random_bytes called from start_kernel+0xa0/0x3fc with crng_init=0
[0.00] Built 1 zonelists, mobility grouping on. Total pages: 32512
[0.00] Kernel command line: ip=:eth0: root=/dev/nfs console=tty1 console=ttyLP0,115200n8 consoleblank=0
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 103836K/131072K available (6144K kernel code, 192K rwdata, 1604K rodata, 1024K init, 142K bss, 10852K reserved, 16384K cma-reserved)
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0x8880 - 0xff80 (1904 MB)
[0.00] lowmem : 0x8000 - 0x8800 ( 128 MB)
[0.00] modules : 0x7f00 - 0x8000 ( 16 MB)
[0.00] .text : 0x(ptrval) - 0x(ptrval) (7136 kB)
[0.00] .init : 0x(ptrval) - 0x(ptrval) (1024 kB)
[0.00] .data : 0x(ptrval) - 0x(ptrval) ( 193 kB)
[0.00].bss : 0x(ptrva
[tip:x86/urgent] x86/hyper-v: Fix the circular dependency in IPI enlightenment
Commit-ID: 5e6f19db2deca9e7eaa378447c77616b35693399
Gitweb: https://git.kernel.org/tip/5e6f19db2deca9e7eaa378447c77616b35693399
Author: K. Y. Srinivasan
AuthorDate: Tue, 3 Jul 2018 16:01:55 -0700
Committer: Ingo Molnar
CommitDate: Wed, 4 Jul 2018 10:50:03 +0200
x86/hyper-v: Fix the circular dependency in IPI enlightenment
The IPI hypercalls depend on being able to map the Linux notion of CPU ID
to the hypervisor's notion of the CPU ID. The array hv_vp_index[] provides
this mapping. Code for populating this array depends on the IPI functionality.
Break this circular dependency.
Tested-by: Michael Kelley
Signed-off-by: K. Y. Srinivasan
Acked-by: Thomas Gleixner
Cc: Linus Torvalds
Cc: michael.h.kel...@microsoft.com
Cc: Peter Zijlstra
Cc: a...@canonical.com
Cc: de...@linuxdriverproject.org
Cc: gre...@linuxfoundation.org
Cc: jasow...@redhat.com
Cc: o...@aepfle.de
Cc: sthem...@microsoft.com
Cc: vkuzn...@redhat.com
Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
Link: http://lkml.kernel.org/r/20180703230155.15160-1-...@linuxonhyperv.com
Signed-off-by: Ingo Molnar
---
arch/x86/hyperv/hv_apic.c | 5 +
arch/x86/hyperv/hv_init.c | 5 -
arch/x86/include/asm/mshyperv.h | 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index f68855499391..63d7c196739f 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -114,6 +114,8 @@ static bool __send_ipi_mask_ex(const struct cpumask *mask,
int vector)
ipi_arg->vp_set.format = HV_GENERIC_SET_SPARSE_4K;
nr_bank = cpumask_to_vpset(&(ipi_arg->vp_set), mask);
}
+ if (nr_bank == -1)
+ goto ipi_mask_ex_done;
if (!nr_bank)
ipi_arg->vp_set.format = HV_GENERIC_SET_ALL;
@@ -158,6 +160,9 @@ static bool __send_ipi_mask(const struct cpumask *mask, int
vector)
for_each_cpu(cur_cpu, mask) {
vcpu = hv_cpu_number_to_vp_number(cur_cpu);
+ if (vcpu == -1)
+ goto ipi_mask_done;
+
/*
* This particular version of the IPI hypercall can
* only target upto 64 CPUs.
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 4c431e1c1eff..04159893702e 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -265,7 +265,7 @@ void __init hyperv_init(void)
{
u64 guest_id, required_msrs;
union hv_x64_msr_hypercall_contents hypercall_msr;
- int cpuhp;
+ int cpuhp, i;
if (x86_hyper_type != X86_HYPER_MS_HYPERV)
return;
@@ -293,6 +293,9 @@ void __init hyperv_init(void)
if (!hv_vp_index)
return;
+ for (i = 0; i < num_possible_cpus(); i++)
+ hv_vp_index[i] = -1;
+
hv_vp_assist_page = kcalloc(num_possible_cpus(),
sizeof(*hv_vp_assist_page), GFP_KERNEL);
if (!hv_vp_assist_page) {
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 3cd14311edfa..dee3f7347253 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -281,6 +281,8 @@ static inline int cpumask_to_vpset(struct hv_vpset *vpset,
*/
for_each_cpu(cpu, cpus) {
vcpu = hv_cpu_number_to_vp_number(cpu);
+ if (vcpu == -1)
+ return -1;
vcpu_bank = vcpu / 64;
vcpu_offset = vcpu % 64;
__set_bit(vcpu_offset, (unsigned long *)
Re: [PATCH v2] mtd: atmel-quadspi: add suspend/resume hooks
On 04/07/2018 11:42:25+0300, Tudor Ambarus wrote:
> Hi, Claudiu,
>
> On 06/04/2018 11:46 AM, Claudiu Beznea wrote:
> > Implement suspend/resume hooks.
> >
> > Signed-off-by: Claudiu Beznea
> > ---
> >
> > Changes in v2:
> > - use __maybe_unused instead of #ifdef CONFIG_PM_SLEEP
> >
> > drivers/mtd/spi-nor/atmel-quadspi.c | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c
> > b/drivers/mtd/spi-nor/atmel-quadspi.c
> > index 6c5708bacad8..ceaaef47f02e 100644
> > --- a/drivers/mtd/spi-nor/atmel-quadspi.c
> > +++ b/drivers/mtd/spi-nor/atmel-quadspi.c
> > @@ -737,6 +737,26 @@ static int atmel_qspi_remove(struct platform_device
> > *pdev)
> > return 0;
> > }
> >
> > +static int __maybe_unused atmel_qspi_suspend(struct device *dev)
> > +{
> > + struct atmel_qspi *aq = dev_get_drvdata(dev);
> > +
> > + clk_disable_unprepare(aq->clk);
> > +
> > + return 0;
> > +}
> > +
> > +static int __maybe_unused atmel_qspi_resume(struct device *dev)
> > +{
> > + struct atmel_qspi *aq = dev_get_drvdata(dev);
> > +
> > + clk_prepare_enable(aq->clk);
>
> You missed to verify the return value of clk_prepare_enable. Otherwise looks
Which will never fail, there is no point in checking it.
> good. I've also looked over the test with suspending while copying on a ubifs
> mounted on QSPI NOR, looks good too.
>
> After checking the return value, please add:
> Reviewed-by: Tudor Ambarus
>
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()
On Wed, Jul 4, 2018 at 9:37 AM, Nikolaus Voss wrote: > On Wed, 4 Jul 2018, Andy Shevchenko wrote: >> >> On Tue, Jul 3, 2018 at 9:06 AM, Nikolaus Voss >> wrote: >>> >>> struct i2c_device_id argument of probe() is not used, so use probe_new() >>> instead. >>> >> >> This makes... >> >>> MODULE_DEVICE_TABLE(i2c, st_accel_id_table); >> >> >> ...this table obsolete IIUC. At least that's what I did when switched >> to ->probe_new() in some drivers. >> >> If I'm mistaken (again? :-) ) I would hear from someone to point me >> how it can be used after a switch. > > > It is still used by the i2c-core in i2c_device_match() if DT and ACPI > matching fails. > And it is used to create the corresponding modaliases for > driver loading. My question is "How?!" I don't really see any points to match against it after switching to ->probe_new(). Could you point me to the code path in i2c (or OF?) core for that? > So it is necessary for non-DT/ non-ACPI systems and used for > fallback matching if no match is found in of_device_ids. -- With Best Regards, Andy Shevchenko
[PATCH v2 1/2] f2fs: fix to avoid broken of dnode block list
f2fs recovery flow is relying on dnode block link list, it means fsynced
file recovery depends on previous dnode's persistence in the list, so
during fsync() we should wait on all regular inode's dnode writebacked
before issuing flush.
By this way, we can avoid dnode block list being broken by out-of-order
IO submission due to IO scheduler or driver.
Signed-off-by: Chao Yu
---
v2: add missing definition modification in f2fs.h.
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/file.c | 17 -
fs/f2fs/node.c | 4 ++--
3 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 859ecde81dd0..a9da5a089cb4 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -2825,7 +2825,7 @@ pgoff_t f2fs_get_next_page_offset(struct dnode_of_data
*dn, pgoff_t pgofs);
int f2fs_get_dnode_of_data(struct dnode_of_data *dn, pgoff_t index, int mode);
int f2fs_truncate_inode_blocks(struct inode *inode, pgoff_t from);
int f2fs_truncate_xattr_node(struct inode *inode);
-int f2fs_wait_on_node_pages_writeback(struct f2fs_sb_info *sbi, nid_t ino);
+int f2fs_wait_on_node_pages_writeback(struct f2fs_sb_info *sbi);
int f2fs_remove_inode_page(struct inode *inode);
struct page *f2fs_new_inode_page(struct inode *inode);
struct page *f2fs_new_node_page(struct dnode_of_data *dn, unsigned int ofs);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 752ff678bfe0..ecca7b833268 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -292,19 +292,10 @@ static int f2fs_do_sync_file(struct file *file, loff_t
start, loff_t end,
goto sync_nodes;
}
- /*
-* If it's atomic_write, it's just fine to keep write ordering. So
-* here we don't need to wait for node write completion, since we use
-* node chain which serializes node blocks. If one of node writes are
-* reordered, we can see simply broken chain, resulting in stopping
-* roll-forward recovery. It means we'll recover all or none node blocks
-* given fsync mark.
-*/
- if (!atomic) {
- ret = f2fs_wait_on_node_pages_writeback(sbi, ino);
- if (ret)
- goto out;
- }
+
+ ret = f2fs_wait_on_node_pages_writeback(sbi);
+ if (ret)
+ goto out;
/* once recovery info is written, don't need to tack this */
f2fs_remove_ino_entry(sbi, ino, APPEND_INO);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 849c2ed9c152..0810c8117d46 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1710,7 +1710,7 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
return ret;
}
-int f2fs_wait_on_node_pages_writeback(struct f2fs_sb_info *sbi, nid_t ino)
+int f2fs_wait_on_node_pages_writeback(struct f2fs_sb_info *sbi)
{
pgoff_t index = 0;
struct pagevec pvec;
@@ -1726,7 +1726,7 @@ int f2fs_wait_on_node_pages_writeback(struct f2fs_sb_info
*sbi, nid_t ino)
for (i = 0; i < nr_pages; i++) {
struct page *page = pvec.pages[i];
- if (ino && ino_of_node(page) == ino) {
+ if (IS_DNODE(page) && is_cold_node(page)) {
f2fs_wait_on_page_writeback(page, NODE, true);
if (TestClearPageError(page))
ret = -EIO;
--
2.18.0.rc1
Re: [PATCH v6] Add udmabuf misc device
Hi, > > Hmm, does MAINTAINERS need an update then? Maintainer and mailing lists > > listed in the "DMA BUFFER SHARING FRAMEWORK" entry are on Cc. > > Yeah, maintainers entry with you as maintainer plus dri-devel as mailing > list plus drm-misc as repo would be good. Just grep for drm-misc.git for > tons of examples. There is an *existing* entry covering drivers/dma-buf/, and I've dropped udmabuf.c into that directory, so I've assumed get_maintainers.pl picks up all relevant dma-buf folks ... Covering udmabuf.c maintainance is a different issue. I could just add myself to the existing entry, or create a new one specifically for udmabuf. > > Who should be Cc'ed? > > dim add-missing-cc ftw :-) That just uses get_maintainer.pl according to the docs, so that wouldn't change things as that is wired up as sendemail.cccmd already. Except that dim would probably add the list of people to the commit message. cheers, Gerd
Re: [PATCH v2 1/2] IIO: st_accel_i2c.c: Simplify access to driver data
On Wed, Jul 4, 2018 at 9:56 AM, Nikolaus Voss wrote: > On Wed, 4 Jul 2018, Andy Shevchenko wrote: >> >> On Tue, Jul 3, 2018 at 8:41 AM, Nikolaus Voss >> wrote: >>> >>> Use device_get_match_data API to simplify access to driver data. >> >> >> ..._data() >> >> But. You actually don't use it below. > It is used, see below. I meant the API call you mentioned in the commit message is not used in this version and below you agree to use it eventually. >>> Let acpi_device_id table entries point to the same driver data as >>> of_device_id table entries and uniquify access to driver data by using >>> device_get_match_data API. >> >> >>> #include >>> #include >>> #include >> >> >>> +#include >> >> >> (linux/property.h) >> >>> + match = of_device_get_match_data(&client->dev); >>> + if (!match) >>> + match = acpi_device_get_match_data(&client->dev); >> >> >> What I meant is to simply call >> >> match = device_get_match_data(...); > > > Ok, this works, thank you. I will prepare a new patch version. > > This is where the match data is used: > >> >>> + if (match) >>> + strlcpy(client->name, match, sizeof(client->name)); > In this driver, match data is used to map DT compatible strings/ ACPI CIDs > to the key strings (.._ACCEL_DEV_NAME) which are used to identify the actual > device (and are also used in i2c_device_id table). -- With Best Regards, Andy Shevchenko
[PATCH v2 0/3] serial: 8250_dw: add fractional divisor support
For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a valid divisor latch fraction register. The fractional divisor width is 4bits ~ 6bits. patch1 lets serial8250_get_divisor() get uart_port * as param patch2 introduces necessary hooks to 8250 core. patch3 implements the fractional divisor support for Synopsys DW 8250. Since v1: - add an extra patch to let serial8250_get_divisor() get uart_port * as param - take Andy's suggestions to "integrates hooks in the same way like it's done for the rest of 8250 ones". Many thanks to Andy. Jisheng Zhang (3): serial: 8250: let serial8250_get_divisor() get uart_port * as param serial: 8250: introduce get_divisor() and set_divisor() hook serial: 8250_dw: add fractional divisor support drivers/tty/serial/8250/8250_core.c | 4 +++ drivers/tty/serial/8250/8250_dw.c | 53 + drivers/tty/serial/8250/8250_port.c | 33 ++ include/linux/serial_core.h | 7 4 files changed, 90 insertions(+), 7 deletions(-) -- 2.18.0
[PATCH v2 1/3] serial: 8250: let serial8250_get_divisor() get uart_port * as param
Align serial8250_get_divisor() with serial8250_set_divisor() to accept
uart_port pointer as the first parameter. No functionality changes.
Signed-off-by: Jisheng Zhang
---
drivers/tty/serial/8250/8250_port.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index cf541aab2bd0..709fe6b4265c 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2498,11 +2498,11 @@ static unsigned int npcm_get_divisor(struct
uart_8250_port *up,
return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud + 2) - 2;
}
-static unsigned int serial8250_get_divisor(struct uart_8250_port *up,
+static unsigned int serial8250_get_divisor(struct uart_port *port,
unsigned int baud,
unsigned int *frac)
{
- struct uart_port *port = &up->port;
+ struct uart_8250_port *up = up_to_u8250p(port);
unsigned int quot;
/*
@@ -2636,7 +2636,7 @@ serial8250_do_set_termios(struct uart_port *port, struct
ktermios *termios,
cval = serial8250_compute_lcr(up, termios->c_cflag);
baud = serial8250_get_baud_rate(port, termios, old);
- quot = serial8250_get_divisor(up, baud, &frac);
+ quot = serial8250_get_divisor(port, baud, &frac);
/*
* Ok, we're now changing the port state. Do it with
@@ -3197,7 +3197,7 @@ static void serial8250_console_restore(struct
uart_8250_port *up)
termios.c_cflag = port->state->port.tty->termios.c_cflag;
baud = serial8250_get_baud_rate(port, &termios, NULL);
- quot = serial8250_get_divisor(up, baud, &frac);
+ quot = serial8250_get_divisor(port, baud, &frac);
serial8250_set_divisor(port, baud, quot, frac);
serial_port_out(port, UART_LCR, up->lcr);
--
2.18.0
Re: [PATCH v22 2/4] mailbox: mediatek: Add Mediatek CMDQ driver
Hi, Houlong:
On Wed, 2018-07-04 at 08:10 +0800, houlong wei wrote:
> On Fri, 2018-06-29 at 15:08 +0800, CK Hu wrote:
> > Hi, Houlong:
> >
> > Some inline comment.
> >
> > On Wed, 2018-06-27 at 19:16 +0800, Houlong Wei wrote:
> > > This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> > > CMDQ is used to help write registers with critical time limitation,
> > > such as updating display configuration during the vblank. It controls
> > > Global Command Engine (GCE) hardware to achieve this requirement.
> > > Currently, CMDQ only supports display related hardwares, but we expect
> > > it can be extended to other hardwares for future requirements.
> > >
> > > Signed-off-by: Houlong Wei
> > > Signed-off-by: HS Liao
> > > Signed-off-by: CK Hu
> > > ---
> > > drivers/mailbox/Kconfig | 10 +
> > > drivers/mailbox/Makefile |2 +
> > > drivers/mailbox/mtk-cmdq-mailbox.c | 634
> > > ++
> > > include/linux/mailbox/mtk-cmdq-mailbox.h | 70
> > > 4 files changed, 716 insertions(+)
> > > create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> > > create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> > >
> >
> > [...]
> >
> > > +
> > > +static int cmdq_thread_reset(struct cmdq *cmdq, struct cmdq_thread
> > > *thread)
> > > +{
> > > + u32 warm_reset;
> > > +
> > > + writel(CMDQ_THR_DO_WARM_RESET, thread->base + CMDQ_THR_WARM_RESET);
> > > + if (readl_poll_timeout_atomic(thread->base + CMDQ_THR_WARM_RESET,
> > > + warm_reset, !(warm_reset & CMDQ_THR_DO_WARM_RESET),
> > > + 0, 10)) {
> > > + dev_err(cmdq->mbox.dev, "reset GCE thread 0x%x failed\n",
> > > + (u32)(thread->base - cmdq->base));
> > > + return -EFAULT;
> > > + }
> > > + writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base + CMDQ_THR_SLOT_CYCLES);
> >
> > The CMDQ_THR_SLOT_CYCLES looks like not relevant to reset. Maybe you
> > just need to set this value when startup.
>
> Will move configuration of CMDQ_THR_SLOT_CYCLES to cmdq_xlate() where is
> startup of a GCE thread.
>
> >
> > > +
> > > + return 0;
> > > +}
> > > +
> >
> > [...]
> >
> > > +
> > > +static void cmdq_task_exec(struct cmdq_pkt *pkt, struct cmdq_thread
> > > *thread)
> > > +{
> > > + struct cmdq *cmdq;
> > > + struct cmdq_task *task;
> > > + unsigned long curr_pa, end_pa;
> > > +
> > > + cmdq = dev_get_drvdata(thread->chan->mbox->dev);
> > > +
> > > + /* Client should not flush new tasks if suspended. */
> > > + WARN_ON(cmdq->suspended);
> > > +
> > > + task = kzalloc(sizeof(*task), GFP_ATOMIC);
> > > + task->cmdq = cmdq;
> > > + INIT_LIST_HEAD(&task->list_entry);
> > > + task->pa_base = pkt->pa_base;
> > > + task->thread = thread;
> > > + task->pkt = pkt;
> > > +
> > > + if (list_empty(&thread->task_busy_list)) {
> > > + WARN_ON(clk_enable(cmdq->clock) < 0);
> > > + WARN_ON(cmdq_thread_reset(cmdq, thread) < 0);
> > > +
> > > + writel(task->pa_base, thread->base + CMDQ_THR_CURR_ADDR);
> > > + writel(task->pa_base + pkt->cmd_buf_size,
> > > +thread->base + CMDQ_THR_END_ADDR);
> > > + writel(thread->priority, thread->base + CMDQ_THR_PRIORITY);
> > > + writel(CMDQ_THR_IRQ_EN, thread->base + CMDQ_THR_IRQ_ENABLE);
> > > + writel(CMDQ_THR_ENABLED, thread->base + CMDQ_THR_ENABLE_TASK);
> > > +
> > > + if (thread->timeout_ms != CMDQ_NO_TIMEOUT)
> > > + mod_timer(&thread->timeout,
> > > + jiffies + msecs_to_jiffies(thread->timeout_ms));
> >
> > I think the timeout processing should be done by client driver. The
> > total time to execute a command buffer does not depend on GCE HW speed
> > because the WFE (wait for event) command would wait for client HW event,
> > so the total time depend on how long a client HW send this event to GCE
> > and the timeout processing should be client driver's job. Each client
> > may have different timeout processing mechanism, for example, if display
> > could dynamic change panel frame rate between 120Hz and 60Hz, and the
> > timeout time is 2 frame, so it may dynamically change timeout time
> > between 17ms and 33ms. Another reason is that display have interrupt
> > every vblank, and it could check timeout in that interrupt, so the timer
> > in cmdq driver looks redundant. Because each client would define its own
> > timeout processing mechanism, so it's not wise to put timeout processing
> > in cmdq driver.
>
> The client drivers' owners strongly hope to keep the current timeout
> mechanism, the reasons are below.
> 1. If remove, all clients should add timeout mechanism and the code will
> be redundant.
> 2. If timeout happens, only GCE driver can do reset and continue to
> execute next packet.
For the reason 2, GCE should not continue execute next packet because
the packets may have dependency. So GCE driver could only drop all
packet (this is what you do in cmdq_th
[PATCH v2 2/3] serial: 8250: introduce get_divisor() and set_divisor() hook
Add these two hooks so that they can be overridden with driver specific
implementations.
Signed-off-by: Jisheng Zhang
---
drivers/tty/serial/8250/8250_core.c | 4
drivers/tty/serial/8250/8250_port.c | 27 +++
include/linux/serial_core.h | 7 +++
3 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index 9342fc2ee7df..a0bb77290747 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1023,6 +1023,10 @@ int serial8250_register_8250_port(struct uart_8250_port
*up)
uart->port.get_mctrl = up->port.get_mctrl;
if (up->port.set_mctrl)
uart->port.set_mctrl = up->port.set_mctrl;
+ if (up->port.get_divisor)
+ uart->port.get_divisor = up->port.get_divisor;
+ if (up->port.set_divisor)
+ uart->port.set_divisor = up->port.set_divisor;
if (up->port.startup)
uart->port.startup = up->port.startup;
if (up->port.shutdown)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index 709fe6b4265c..ce0dc17f18ee 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2498,9 +2498,9 @@ static unsigned int npcm_get_divisor(struct
uart_8250_port *up,
return DIV_ROUND_CLOSEST(port->uartclk, 16 * baud + 2) - 2;
}
-static unsigned int serial8250_get_divisor(struct uart_port *port,
- unsigned int baud,
- unsigned int *frac)
+static unsigned int serial8250_do_get_divisor(struct uart_port *port,
+ unsigned int baud,
+ unsigned int *frac)
{
struct uart_8250_port *up = up_to_u8250p(port);
unsigned int quot;
@@ -2532,6 +2532,16 @@ static unsigned int serial8250_get_divisor(struct
uart_port *port,
return quot;
}
+static unsigned int serial8250_get_divisor(struct uart_port *port,
+ unsigned int baud,
+ unsigned int *frac)
+{
+ if (port->get_divisor)
+ return port->get_divisor(port, baud, frac);
+
+ return serial8250_do_get_divisor(port, baud, frac);
+}
+
static unsigned char serial8250_compute_lcr(struct uart_8250_port *up,
tcflag_t c_cflag)
{
@@ -2570,7 +2580,7 @@ static unsigned char serial8250_compute_lcr(struct
uart_8250_port *up,
return cval;
}
-static void serial8250_set_divisor(struct uart_port *port, unsigned int baud,
+static void serial8250_do_set_divisor(struct uart_port *port, unsigned int
baud,
unsigned int quot, unsigned int quot_frac)
{
struct uart_8250_port *up = up_to_u8250p(port);
@@ -2603,6 +2613,15 @@ static void serial8250_set_divisor(struct uart_port
*port, unsigned int baud,
}
}
+static void serial8250_set_divisor(struct uart_port *port, unsigned int baud,
+ unsigned int quot, unsigned int quot_frac)
+{
+ if (port->set_divisor)
+ port->set_divisor(port, baud, quot, quot_frac);
+ else
+ serial8250_do_set_divisor(port, baud, quot, quot_frac);
+}
+
static unsigned int serial8250_get_baud_rate(struct uart_port *port,
struct ktermios *termios,
struct ktermios *old)
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 06ea4eeb09ab..406edae44ca3 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -127,6 +127,13 @@ struct uart_port {
struct ktermios *);
unsigned int(*get_mctrl)(struct uart_port *);
void(*set_mctrl)(struct uart_port *, unsigned int);
+ unsigned int(*get_divisor)(struct uart_port *,
+ unsigned int baud,
+ unsigned int *frac);
+ void(*set_divisor)(struct uart_port *,
+ unsigned int baud,
+ unsigned int quot,
+ unsigned int quot_frac);
int (*startup)(struct uart_port *port);
void(*shutdown)(struct uart_port *port);
void(*throttle)(struct uart_port *port);
--
2.18.0
[PATCH] tpm: Fix NULL pointer dereference in tpm_transmit()
During system shutdown, tpm_class_shutdown() when called with TPM_CHIP_FLAG_TPM2 flag set, makes chip->ops NULL. However tpm_chip_unregister() called later in shutdown sequence tries to access chip->ops in tpm_try_transmit() leading the NULL pointer dereference. This patch fixes this issue. Below is the trace for reference: BUG: unable to handle kernel NULL pointer dereference at 0048 IP: tpm_transmit+0x267/0x565 PGD 0 P4D 0 Oops: [#1] PREEMPT SMP NOPTI ... task: 937c847fe580 task.stack: a79f80b04000 RIP: 0010:tpm_transmit+0x267/0x565 RSP: 0018:a79f80b07c08 EFLAGS: 00010286 RAX: RBX: 937ca9bc8000 RCX: 937c847fe580 RDX: RSI: 0002 RDI: 98e3cd40 RBP: a79f80b07c88 R08: 0001fff4 R09: R10: R11: R12: a79f80b07cd4 R13: 008c R14: ffc3 R15: FS: 7ef31f747740() GS:937caed0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0048 CR3: 0001243d2000 CR4: 001406e0 Call Trace: tpm_transmit_cmd+0x25/0x70 tpm2_shutdown+0x69/0xa3 ? __radix_tree_replace+0xd9/0x120 ? idr_replace_ext+0x92/0xb6 tpm_chip_unregister+0xaa/0xdb cr50_i2c_shutdown+0x1e/0x41 device_shutdown+0x157/0x193 kernel_power_off+0x35/0x6e SYSC_reboot+0x120/0x1a3 ? do_writepages+0x36/0x6e ? do_writepages+0x36/0x6e ? sync_inodes_one_sb+0x17/0x17 ? _raw_spin_unlock+0xe/0x20 ? iput+0x87/0x1bd do_syscall_64+0x64/0x72 entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Signed-off-by: Shirish S --- drivers/char/tpm/tpm-interface.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index e32f6e8..b14d196 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -411,6 +411,14 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip, unsigned long stop; bool need_locality; + /* chip->ops is made NULL in tpm_class_shutdown() +* This case is hit when tpm_chip_unregister() is called post +* tpm_class_shutdown(), hence exit early and return +* transmit operation not permitted +*/ + if (!chip->ops) + return -EPERM; + rc = tpm_validate_command(chip, space, buf, bufsiz); if (rc == -EINVAL) return rc; -- 2.7.4
Re: [PATCH] mm/memblock: replace u64 with phys_addr_t where appropriate
On Wed, 2018-07-04 at 16:23 +0900, Sergey Senozhatsky wrote:
> On (07/04/18 10:03), Mike Rapoport wrote:
> > > %p[Ff] got deprecated by commit 04b8eb7a4ccd9ef9343e2720ccf2a5db8cfe2f67
> > >
> > > I think it'd be simplest to just convert
> > > all the %pF and %pf uses all at once.
> > >
> > > $ git grep --name-only "%p[Ff]" | \
> > > xargs sed -i -e 's/%pF/%pS/' -e 's/%pf/%ps/'
> > >
> > > and remove the appropriate Documentation bit.
> > >
> >
> > Something like this:
> >
> > From 0d3e7cf494123c2640b9a892160d2e2430787004 Mon Sep 17 00:00:00 2001
> > From: Mike Rapoport
> > Date: Wed, 4 Jul 2018 09:55:50 +0300
> > Subject: [PATCH] treewide: retire '%pF/%pf'
> >
> > %p[Ff] got deprecated by commit 04b8eb7a4ccd9ef9343e2720ccf2a5db8cfe2f67
> > ("symbol lookup: introduce dereference_symbol_descriptor()")
> >
> > Replace their uses with %p[Ss] with
> >
> > $ git grep --name-only "%p[Ff]" | \
> > xargs sed -i -e 's/%pF/%pS/' -e 's/%pf/%ps/'
>
>
> Sorry, NACK on lib/vsprintf.c part
>
> I definitely didn't want to do this tree-wide pf->ps conversion when
> I introduced my patch set. pf/pF should have never existed, true,
> but I think we must support pf/pF in vsprintf(). Simply because it
> has been around for *far* too long.
And? checkpatch warns about %p[Ff] uses.
> People tend to develop "habits",
> you know, I'm quite sure ppc/hppa/etc folks still do [and will] use
> pf/pF occasionally.
There's this saying about habits made to be broken.
This is one of those habits.
I'd expect more people probably get the %pS or %ps wrong
than use %pF.
And most people probably look for examples in code and
copy instead of thinking what's correct, so removing old
and deprecated uses from existing code is a good thing.
[PATCH v2 3/3] serial: 8250_dw: add fractional divisor support
For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
valid divisor latch fraction register. The fractional divisor width is
4bits ~ 6bits.
Now the preparation is done, it's easy to add the feature support.
This patch firstly checks the component version during probe, if
version >= 4.00a, then calculates the fractional divisor width, then
setups dw specific get_divisor() and set_divisor() hook.
Signed-off-by: Jisheng Zhang
---
drivers/tty/serial/8250/8250_dw.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index aff04f1de3a5..b9630f633388 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -31,9 +31,12 @@
/* Offsets for the DesignWare specific registers */
#define DW_UART_USR0x1f /* UART Status Register */
+#define DW_UART_DLF0xc0 /* Divisor Latch Fraction Register */
#define DW_UART_CPR0xf4 /* Component Parameter Register */
#define DW_UART_UCV0xf8 /* UART Component Version */
+#define DW_FRAC_MIN_VERS 0x3430302A
+
/* Component Parameter Register bits */
#define DW_UART_CPR_ABP_DATA_WIDTH (3 << 0)
#define DW_UART_CPR_AFCE_MODE (1 << 4)
@@ -65,6 +68,7 @@ struct dw8250_data {
unsigned intskip_autocfg:1;
unsigned intuart_16550_compatible:1;
+ unsigned intdlf_size:3;
};
static inline int dw8250_modify_msr(struct uart_port *p, int offset, int value)
@@ -351,6 +355,33 @@ static bool dw8250_idma_filter(struct dma_chan *chan, void
*param)
return param == chan->device->dev->parent;
}
+/*
+ * For version >= 4.00a, the dw uarts have a valid divisor latch fraction
+ * register. Calculate divisor with extra 4bits ~ 6bits fractional portion.
+ */
+static unsigned int dw8250_get_divisor(struct uart_port *p,
+ unsigned int baud,
+ unsigned int *frac)
+{
+ unsigned int quot;
+ struct dw8250_data *d = p->private_data;
+
+ quot = DIV_ROUND_CLOSEST(p->uartclk << (d->dlf_size - 4), baud);
+ *frac = quot & (~0U >> (32 - d->dlf_size));
+
+ return quot >> d->dlf_size;
+}
+
+static void dw8250_set_divisor(struct uart_port *p, unsigned int baud,
+ unsigned int quot, unsigned int quot_frac)
+{
+ struct uart_8250_port *up = up_to_u8250p(p);
+
+ serial_port_out(p, DW_UART_DLF >> p->regshift, quot_frac);
+ serial_port_out(p, UART_LCR, up->lcr | UART_LCR_DLAB);
+ serial_dl_write(up, quot);
+}
+
static void dw8250_quirks(struct uart_port *p, struct dw8250_data *data)
{
if (p->dev->of_node) {
@@ -414,6 +445,28 @@ static void dw8250_setup_port(struct uart_port *p)
dev_dbg(p->dev, "Designware UART version %c.%c%c\n",
(reg >> 24) & 0xff, (reg >> 16) & 0xff, (reg >> 8) & 0xff);
+ /*
+* For version >= 4.00a, the dw uarts have a valid divisor latch
+* fraction register. Calculate the fractional divisor width.
+*/
+ if (reg >= DW_FRAC_MIN_VERS) {
+ struct dw8250_data *d = p->private_data;
+
+ if (p->iotype == UPIO_MEM32BE) {
+ iowrite32be(~0U, p->membase + DW_UART_DLF);
+ reg = ioread32be(p->membase + DW_UART_DLF);
+ } else {
+ writel(~0U, p->membase + DW_UART_DLF);
+ reg = readl(p->membase + DW_UART_DLF);
+ }
+ d->dlf_size = fls(reg);
+
+ if (d->dlf_size) {
+ p->get_divisor = dw8250_get_divisor;
+ p->set_divisor = dw8250_set_divisor;
+ }
+ }
+
if (p->iotype == UPIO_MEM32BE)
reg = ioread32be(p->membase + DW_UART_CPR);
else
--
2.18.0
[PATCH 0/4] rtc: omap: fixes and clean ups
Here are a couple of fixes for issues discovered through inspection along with some clean ups. Johan Johan Hovold (4): rtc: omap: fix potential crash on power off rtc: omap: fix resource leak in registration error path rtc: omap: add missing register lock in error path rtc: omap: drop unnecessary register unlock around reads drivers/rtc/rtc-omap.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) -- 2.18.0
Re: [PATCH 0/2] Allwinner A64 timer workaround
On Wed, Jul 04, 2018 at 09:16:32AM +0100, Marc Zyngier wrote: > On 03/07/18 19:42, Samuel Holland wrote: > > On 07/03/18 10:09, Marc Zyngier wrote: > >> On 11/05/18 03:27, Samuel Holland wrote: > >>> Hello, > >>> > >>> Several people (including me) have experienced extremely large system > >>> clock jumps on their A64-based devices, apparently due to the > >>> architectural > >>> timer going backward, which is interpreted by Linux as the timer wrapping > >>> around after 2^56 cycles. > >>> > >>> Investigation led to discovery of some obvious problems with this SoC's > >>> architectural timer, and this patch series introduces what I believe is > >>> the simplest workaround. More details are in the commit message for patch > >>> 1. Patch 2 simply enables the workaround in the device tree. > >> > >> What's the deal with this series? There was a couple of nits to address, > >> and > >> I was more or less expecting a v2. > > > > I got reports that people were still occasionally having clock jumps after > > applying this series, so I wanted to attempt a more complete fix, but I > > haven't > > had time to do any deeper investigation. I think this series is still > > beneficial > > even if it's not a complete solution, so I'll come back with another patch > > on > > top of this if/once I get it fully fixed. > > > > I'll prepare a v2 with a bounded loop. Presumably, 3 * (max CPU Hz) / (24MHz > > timer) ≈ 150 should be a conservative iteration limit? > > Should be OK. > > Maxime: How do you want to deal with the documentation aspect? We need > an erratum number, but AFAIU the concept hasn't made it into the silicom > vendor's brain yet. Any chance you could come up with something that > uniquely identifies this? Yeah, I don't know how we can address that unfortunately. Or maybe we can call it timer-broken-1 ? It's as good as an ID than any other ID :) Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
[PATCH 3/4] rtc: omap: add missing register lock in error path
For completeness re-lock the registers also in the power-off error path.
Signed-off-by: Johan Hovold
---
drivers/rtc/rtc-omap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6a7b804c3074..7f9ee559dd99 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -449,6 +449,7 @@ static void omap_rtc_power_off(void)
if (tm2bcd(&tm) < 0) {
dev_err(&rtc->rtc->dev, "power off failed\n");
+ rtc->type->lock(rtc);
return;
}
--
2.18.0
[PATCH 4/4] rtc: omap: drop unnecessary register unlock around reads
Drop unnecessary register write-unlock around two read accesses.
Signed-off-by: Johan Hovold
---
drivers/rtc/rtc-omap.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 7f9ee559dd99..323ff55cc165 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -583,9 +583,7 @@ static int rtc_pinconf_get(struct pinctrl_dev *pctldev,
u32 val;
u16 arg = 0;
- rtc->type->unlock(rtc);
val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
- rtc->type->lock(rtc);
switch (param) {
case PIN_CONFIG_INPUT_ENABLE:
@@ -615,9 +613,7 @@ static int rtc_pinconf_set(struct pinctrl_dev *pctldev,
u32 param_val;
int i;
- rtc->type->unlock(rtc);
val = rtc_readl(rtc, OMAP_RTC_PMIC_REG);
- rtc->type->lock(rtc);
/* active low by default */
val |= OMAP_RTC_PMIC_EXT_WKUP_POL(pin);
--
2.18.0
[PATCH 1/4] rtc: omap: fix potential crash on power off
Do not set the system power-off callback and omap power-off rtc pointer
until we're done setting up our device to avoid leaving stale pointers
around after a late probe error.
Fixes: 97ea1906b3c2 ("rtc: omap: Support ext_wakeup configuration")
Cc: stable # 4.9
Cc: Marcin Niestroj
Cc: Tony Lindgren
Signed-off-by: Johan Hovold
---
drivers/rtc/rtc-omap.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 39086398833e..c214b69a8787 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -861,13 +861,6 @@ static int omap_rtc_probe(struct platform_device *pdev)
goto err;
}
- if (rtc->is_pmic_controller) {
- if (!pm_power_off) {
- omap_rtc_power_off_rtc = rtc;
- pm_power_off = omap_rtc_power_off;
- }
- }
-
/* Support ext_wakeup pinconf */
rtc_pinctrl_desc.name = dev_name(&pdev->dev);
@@ -884,6 +877,13 @@ static int omap_rtc_probe(struct platform_device *pdev)
rtc_nvmem_register(rtc->rtc, &omap_rtc_nvmem_config);
+ if (rtc->is_pmic_controller) {
+ if (!pm_power_off) {
+ omap_rtc_power_off_rtc = rtc;
+ pm_power_off = omap_rtc_power_off;
+ }
+ }
+
return 0;
err:
--
2.18.0
[PATCH 2/4] rtc: omap: fix resource leak in registration error path
Make sure to deregister the pin controller in case rtc registration
fails.
Fixes: 57072758623f ("rtc: omap: switch to rtc_register_device")
Cc: stable # 4.14
Cc: Alexandre Belloni
Signed-off-by: Johan Hovold
---
drivers/rtc/rtc-omap.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index c214b69a8787..6a7b804c3074 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -873,7 +873,7 @@ static int omap_rtc_probe(struct platform_device *pdev)
ret = rtc_register_device(rtc->rtc);
if (ret)
- goto err;
+ goto err_deregister_pinctrl;
rtc_nvmem_register(rtc->rtc, &omap_rtc_nvmem_config);
@@ -886,6 +886,8 @@ static int omap_rtc_probe(struct platform_device *pdev)
return 0;
+err_deregister_pinctrl:
+ pinctrl_unregister(rtc->pctldev);
err:
clk_disable_unprepare(rtc->clk);
device_init_wakeup(&pdev->dev, false);
--
2.18.0
Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()
On Wed, 4 Jul 2018, Andy Shevchenko wrote: On Wed, Jul 4, 2018 at 9:37 AM, Nikolaus Voss wrote: On Wed, 4 Jul 2018, Andy Shevchenko wrote: On Tue, Jul 3, 2018 at 9:06 AM, Nikolaus Voss wrote: struct i2c_device_id argument of probe() is not used, so use probe_new() instead. This makes... MODULE_DEVICE_TABLE(i2c, st_accel_id_table); ...this table obsolete IIUC. At least that's what I did when switched to ->probe_new() in some drivers. If I'm mistaken (again? :-) ) I would hear from someone to point me how it can be used after a switch. It is still used by the i2c-core in i2c_device_match() if DT and ACPI matching fails. And it is used to create the corresponding modaliases for driver loading. My question is "How?!" I don't really see any points to match against it after switching to ->probe_new(). Could you point me to the code path in i2c (or OF?) core for that? As written above in i2c-core-base.c: i2c_device_match() -> i2c_match_id(driver->id_table,... This is used for driver matching before probe() or probe_new() of the device driver can be called. probe_new() actually is a function signature change only. Niko
[PATCH -next v2] mtd: spinand: fix missing unlock on error
Add the missing unlock before return from function
spinand_mtd_(read|write) in the error handling case.
Fixes: c898e0526fb6 ("mtd: nand: Add core infrastructure to support SPI NANDs")
Signed-off-by: Wei Yongjun
---
v1 -> v2: using break instead of return
---
drivers/mtd/nand/spi/core.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 17d207a..e072464 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -561,11 +561,12 @@ static int spinand_mtd_read(struct mtd_info *mtd, loff_t
from,
nanddev_io_for_each_page(nand, from, ops, &iter) {
ret = spinand_select_target(spinand, iter.req.pos.target);
if (ret)
- return ret;
+ break;
ret = spinand_ecc_enable(spinand, enable_ecc);
if (ret)
- return ret;
+ break;
+
ret = spinand_read_page(spinand, &iter.req, enable_ecc);
if (ret < 0 && ret != -EBADMSG)
@@ -609,11 +610,11 @@ static int spinand_mtd_write(struct mtd_info *mtd, loff_t
to,
nanddev_io_for_each_page(nand, to, ops, &iter) {
ret = spinand_select_target(spinand, iter.req.pos.target);
if (ret)
- return ret;
+ break;
ret = spinand_ecc_enable(spinand, enable_ecc);
if (ret)
- return ret;
+ break;
ret = spinand_write_page(spinand, &iter.req);
if (ret)
[PATCH] mtd: rawnand: tegra: check bounds of die_nr properly
The Tegra driver currently only support a single chip select, hence
check boundaries accordingly. This fixes a off by one issue catched
with Smatch:
drivers/mtd/nand/raw/tegra_nand.c:476 tegra_nand_select_chip()
warn: array off by one? 'nand->cs[die_nr]'
Also warn in case the stack asks for a chip select we currently do
not support.
Reported-by: Dan Carpenter
Signed-off-by: Stefan Agner
---
drivers/mtd/nand/raw/tegra_nand.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/tegra_nand.c
b/drivers/mtd/nand/raw/tegra_nand.c
index 4daa88d814134..e65ef584df0b9 100644
--- a/drivers/mtd/nand/raw/tegra_nand.c
+++ b/drivers/mtd/nand/raw/tegra_nand.c
@@ -468,7 +468,9 @@ static void tegra_nand_select_chip(struct mtd_info *mtd,
int die_nr)
struct tegra_nand_chip *nand = to_tegra_chip(chip);
struct tegra_nand_controller *ctrl = to_tegra_ctrl(chip->controller);
- if (die_nr < 0 || die_nr > 1) {
+ WARN_ON(die_nr >= ARRAY_SIZE(nand->cs));
+
+ if (die_nr < 0 || die_nr > 0) {
ctrl->cur_cs = -1;
return;
}
--
2.18.0
Re: [PATCH 1/1] X86/Hyper-V:: Fix the circular dependency in IPI enlightenment.
k...@linuxonhyperv.com writes:
> From: "K. Y. Srinivasan"
>
> The IPI hypercalls depend on being able to map the Linux notion of CPU ID
> to the hypervisor's notion of the CPU ID. The array hv_vp_index[] provides
> this mapping. Code for populating this array depends on the IPI functionality.
> Break this circular dependency.
>
> Fixes: 68bb7bfb7985 ("X86/Hyper-V: Enable IPI enlightenments")
>
> Signed-off-by: K. Y. Srinivasan
> Tested-by: Michael Kelley
> ---
> arch/x86/hyperv/hv_apic.c | 5 +
> arch/x86/hyperv/hv_init.c | 5 -
> arch/x86/include/asm/mshyperv.h | 2 ++
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
> index f68855499391..63d7c196739f 100644
> --- a/arch/x86/hyperv/hv_apic.c
> +++ b/arch/x86/hyperv/hv_apic.c
> @@ -114,6 +114,8 @@ static bool __send_ipi_mask_ex(const struct cpumask
> *mask, int vector)
> ipi_arg->vp_set.format = HV_GENERIC_SET_SPARSE_4K;
> nr_bank = cpumask_to_vpset(&(ipi_arg->vp_set), mask);
> }
> + if (nr_bank == -1)
> + goto ipi_mask_ex_done;
> if (!nr_bank)
> ipi_arg->vp_set.format = HV_GENERIC_SET_ALL;
>
> @@ -158,6 +160,9 @@ static bool __send_ipi_mask(const struct cpumask *mask,
> int vector)
>
> for_each_cpu(cur_cpu, mask) {
> vcpu = hv_cpu_number_to_vp_number(cur_cpu);
> + if (vcpu == -1)
> + goto ipi_mask_done;
> +
Nit: hv_vp_index is u32 *, it would make sense to use U32_MAX instead of
'-1' everywhere in this patch.
> /*
>* This particular version of the IPI hypercall can
>* only target upto 64 CPUs.
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index 4c431e1c1eff..04159893702e 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -265,7 +265,7 @@ void __init hyperv_init(void)
> {
> u64 guest_id, required_msrs;
> union hv_x64_msr_hypercall_contents hypercall_msr;
> - int cpuhp;
> + int cpuhp, i;
>
> if (x86_hyper_type != X86_HYPER_MS_HYPERV)
> return;
> @@ -293,6 +293,9 @@ void __init hyperv_init(void)
> if (!hv_vp_index)
> return;
>
> + for (i = 0; i < num_possible_cpus(); i++)
> + hv_vp_index[i] = -1;
> +
> hv_vp_assist_page = kcalloc(num_possible_cpus(),
> sizeof(*hv_vp_assist_page), GFP_KERNEL);
> if (!hv_vp_assist_page) {
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index 3cd14311edfa..dee3f7347253 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -281,6 +281,8 @@ static inline int cpumask_to_vpset(struct hv_vpset *vpset,
>*/
> for_each_cpu(cpu, cpus) {
> vcpu = hv_cpu_number_to_vp_number(cpu);
> + if (vcpu == -1)
> + return -1;
> vcpu_bank = vcpu / 64;
> vcpu_offset = vcpu % 64;
> __set_bit(vcpu_offset, (unsigned long *)
--
Vitaly
Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()
On Wed, Jul 4, 2018 at 12:09 PM, Nikolaus Voss wrote: > On Wed, 4 Jul 2018, Andy Shevchenko wrote: >> >> On Wed, Jul 4, 2018 at 9:37 AM, Nikolaus Voss >> wrote: >>> >>> On Wed, 4 Jul 2018, Andy Shevchenko wrote: On Tue, Jul 3, 2018 at 9:06 AM, Nikolaus Voss wrote: > > > struct i2c_device_id argument of probe() is not used, so use > probe_new() > instead. > This makes... > MODULE_DEVICE_TABLE(i2c, st_accel_id_table); ...this table obsolete IIUC. At least that's what I did when switched to ->probe_new() in some drivers. If I'm mistaken (again? :-) ) I would hear from someone to point me how it can be used after a switch. >>> >>> >>> >>> It is still used by the i2c-core in i2c_device_match() if DT and ACPI >>> matching fails. >> >> >>> And it is used to create the corresponding modaliases for >>> driver loading. >> >> >> My question is "How?!" >> I don't really see any points to match against it after switching to >> ->probe_new(). >> >> Could you point me to the code path in i2c (or OF?) core for that? > > > As written above in i2c-core-base.c: i2c_device_match() -> > i2c_match_id(driver->id_table,... > > This is used for driver matching before probe() or probe_new() of the device > driver can be called. probe_new() actually is a function signature change > only. Okay, IIUC we got a match. What should we do with it? The table is not used in ->probe_new() (in i2c core), so, you can't say which line matched there. -- With Best Regards, Andy Shevchenko
Re: [PATCH] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr
You are completely right. After considering, I think my patch is like a
workaround but not real fix. I am trying to re-write a new patch
without cache implementation.
Please give me one or two days to re-write this patch and discribe it
more clearly in commit comment.
thanks,
Bin
On Wed, 2018-07-04 at 09:40 +0200, Thomas Gleixner wrote:
> On Wed, 4 Jul 2018, Yang, Bin wrote:
> > thanks for reviewing my patch. I will update a new patch version
> > based
> > on your feedback soon
>
> Take your time.
>
> > On Tue, 2018-07-03 at 15:57 +0200, Thomas Gleixner wrote:
> > Below is the new commit comment I will use in new patch version
> > soon
> > > Please do not use the output of git show for submitting a patch.
> > > Use
> > > git format-patch(1). >
> >
> > I use "git send-email -1" to submit patch for review. Should I run
> > "git
> > format-patch" first and send the patch as email?
>
> git send-email is fine, but it should not result in the changelog
> being
> indented by a bunch of spaces. That's why I assumed that you used git
> show
> because that's exacty the format. I'm not using it, so I can't give
> you
> advise there.
>
> > ===
> > If cpu supports "pdpe1gb", kernel will try its best to use 1G big
> > page.
> > When changing a 4K page attr inside 1G page range,
> > __change_page_attr()
> > will either consume this 4K page into the 1G page, or it splits 1G
> > page
> > into 2M pages and tries again. The retry will either consume the 4K
> > page into a 2MB page, or it splits 2MB page into 4K pages.
> > try_preserve_large_page() is called by __change_page_attr() to
> > decide
>
> I know what calls try_preserve_large_page(), but you still fail to
> explain
> the full call chain including parameters which I asked for.
>
> > it by checking all 4K pages inside the big page one by one.
>
> After your change this will still happen. You just shortcut the inner
> workings, but you are still not explaining why the shortcut is
> necessary in
> the first place.
>
> The try_preserve_large_page() logic should not need any of this
> unless
> there is a subtle implementation bug. If that's the case, then the
> bug
> needs to be isolated and fixed and not papered over by magic short
> cuts.
>
> > This issue is discovered during kernel boot time optimization.
> > Sometimes, free_initmem() returns after about 600ms on my x86_64
> > board
> > with 4GB memory.
> >
> > Since it is a common issue of x86_64, it can be reproduced by qemu
> > too.
> > We can add some logs in try_preserve_large_page() function to
> > measure
> > the loop count and elapsed time. Please make sure the host CPU has
> > "pdpe1gb" flag and run below qemu command to reproduce it:
> >
> > qemu-system-x86_64 -enable-kvm -cpu host -serial mon:stdio -m 4G
> > -nographic -kernel bzImage -initrd ramdisk.img -append
> > "console=ttyS0"
> >
> > Since default x86_64 kernel enables CONFIG_RANDOMIZE_BASE, it needs
> > to
>
> Huch? What as this to do with randomize base?
>
> > try many times to let init memory be randomized in a 1G page range.
>
> And no, I'm not interested in random qemu commands and adding logs
> into
> something. You already did the investigation, but you fail to provide
> the
> information. And I'm not asking for random timing logs, I ask about a
> proper explanation why this happens even if it's supposed not to
> happen.
>
> > This patch try to cache the last address which had been checked
> > just
>
> See Documentation/process/submitting-patches.rst and search for 'This
> patch'
>
> > now. If the next address is in same big page with same attr, the
> > cache
> > will be used without full range check.
> > > > @@ -552,16 +552,20 @@ static int
> > > > try_preserve_large_page(pte_t *kpte, unsigned long address,
> > > > struct cpa_data *cpa)
> > > > {
> > > > + static unsigned long address_cache;
> > > > + static unsigned long do_split_cache = 1;
> > >
> > > What are the life time and protection rules of these static
> > > variables
> > > and
> > > why are they static in the first place.
> >
> > they will be protected by pgd_lock. They only cache previous
> > "do_split"
> > result and will be refreshed every time.
>
> So why is there no comment explaining this? And I'm still not
> convinced
> about pgd_lock being the real protection. pgd_lock protects against
> concurrent page table manipulations, but it does not protect against
> concurrent calls of the change_page_attr logic at all. That's what
> cpa_lock
> does.
>
> > > > unsigned long nextpage_addr, numpages, pmask, psize,
> > > > addr,
> > > > pfn, old_pfn;
> > > > pte_t new_pte, old_pte, *tmp;
> > > > pgprot_t old_prot, new_prot, req_prot;
> > > > int i, do_split = 1;
> > > > enum pg_level level;
> > > >
> > > > - if (cpa->force_split)
> > > > + spin_lock(&pgd_lock);
> > > > + if (cpa->force_split) {
> > > > + do_split_cache = 1;
> > >
> > >
[PATCH v2 1/2] powernv:opal-sensor-groups: Add support to enable sensor groups
Adds support to enable/disable a sensor group at runtime. This
can be used to select the sensor groups that needs to be copied to
main memory by OCC. Sensor groups like power, temperature, current,
voltage, frequency, utilization can be enabled/disabled at runtime.
Signed-off-by: Shilpasri G Bhat
---
- Rebased on master. No changes from v1.
arch/powerpc/include/asm/opal-api.h| 1 +
arch/powerpc/include/asm/opal.h| 2 ++
.../powerpc/platforms/powernv/opal-sensor-groups.c | 28 ++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
4 files changed, 32 insertions(+)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index 3bab299..56a94a1 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -206,6 +206,7 @@
#define OPAL_NPU_SPA_CLEAR_CACHE 160
#define OPAL_NPU_TL_SET161
#define OPAL_SENSOR_READ_U64 162
+#define OPAL_SENSOR_GROUP_ENABLE 163
#define OPAL_PCI_GET_PBCQ_TUNNEL_BAR 164
#define OPAL_PCI_SET_PBCQ_TUNNEL_BAR 165
#define OPAL_LAST 165
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index e1b2910..fc0550e 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -292,6 +292,7 @@ int64_t opal_imc_counters_init(uint32_t type, uint64_t
address,
int opal_get_power_shift_ratio(u32 handle, int token, u32 *psr);
int opal_set_power_shift_ratio(u32 handle, int token, u32 psr);
int opal_sensor_group_clear(u32 group_hndl, int token);
+int opal_sensor_group_enable(u32 group_hndl, int token, bool enable);
s64 opal_signal_system_reset(s32 cpu);
s64 opal_quiesce(u64 shutdown_type, s32 cpu);
@@ -326,6 +327,7 @@ extern int opal_async_wait_response_interruptible(uint64_t
token,
struct opal_msg *msg);
extern int opal_get_sensor_data(u32 sensor_hndl, u32 *sensor_data);
extern int opal_get_sensor_data_u64(u32 sensor_hndl, u64 *sensor_data);
+extern int sensor_group_enable(u32 grp_hndl, bool enable);
struct rtc_time;
extern time64_t opal_get_boot_time(void);
diff --git a/arch/powerpc/platforms/powernv/opal-sensor-groups.c
b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
index 541c9ea..f7d04b6 100644
--- a/arch/powerpc/platforms/powernv/opal-sensor-groups.c
+++ b/arch/powerpc/platforms/powernv/opal-sensor-groups.c
@@ -32,6 +32,34 @@ struct sg_attr {
struct sg_attr *sgattrs;
} *sgs;
+int sensor_group_enable(u32 handle, bool enable)
+{
+ struct opal_msg msg;
+ int token, ret;
+
+ token = opal_async_get_token_interruptible();
+ if (token < 0)
+ return token;
+
+ ret = opal_sensor_group_enable(handle, token, enable);
+ if (ret == OPAL_ASYNC_COMPLETION) {
+ ret = opal_async_wait_response(token, &msg);
+ if (ret) {
+ pr_devel("Failed to wait for the async response\n");
+ ret = -EIO;
+ goto out;
+ }
+ ret = opal_error_code(opal_get_async_rc(msg));
+ } else {
+ ret = opal_error_code(ret);
+ }
+
+out:
+ opal_async_release_token(token);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(sensor_group_enable);
+
static ssize_t sg_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count)
{
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S
b/arch/powerpc/platforms/powernv/opal-wrappers.S
index a8d9b40..8268a1e 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -327,3 +327,4 @@ OPAL_CALL(opal_npu_tl_set,
OPAL_NPU_TL_SET);
OPAL_CALL(opal_pci_get_pbcq_tunnel_bar,
OPAL_PCI_GET_PBCQ_TUNNEL_BAR);
OPAL_CALL(opal_pci_set_pbcq_tunnel_bar,
OPAL_PCI_SET_PBCQ_TUNNEL_BAR);
OPAL_CALL(opal_sensor_read_u64,OPAL_SENSOR_READ_U64);
+OPAL_CALL(opal_sensor_group_enable,OPAL_SENSOR_GROUP_ENABLE);
--
1.8.3.1
Re: [PATCH] ARM: dts: berlin: switch to earlycon
Hi Thomas,
On Tue, 29 May 2018 11:41:42 -0400 Thomas Hebb wrote:
> The Synopsys DesignWare 8250 UART in Berlin SoCs is now supported by
> 8250_early, so we can use earlycon for early console output instead
> of earlyprintk, which requires an SoC-specific kernel.
IIRC, earlyprintk still works during the decompress progress while the
earlycon doesn't.
>
> Signed-off-by: Thomas Hebb
> ---
> arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts| 2 +-
> arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 2 +-
> arch/arm/boot/dts/berlin2q-marvell-dmp.dts| 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
> b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
> index 1c475796d17f..f98798bb684f 100644
> --- a/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
> +++ b/arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
> @@ -45,7 +45,7 @@
> compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
>
> chosen {
> - bootargs = "earlyprintk";
> + bootargs = "earlycon";
Is there something missing here? example, uart8250,mmio,?
> stdout-path = "serial0:115200n8";
> };
>
> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
> b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
> index ca24def0ce13..20f31cdeaf38 100644
> --- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
> @@ -46,7 +46,7 @@
> compatible = "google,chromecast", "marvell,berlin2cd", "marvell,berlin";
>
> chosen {
> - bootargs = "earlyprintk";
> + bootargs = "earlycon";
> stdout-path = "serial0:115200n8";
> };
>
> diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> index 57aa5f8a7c77..9834e84a0797 100644
> --- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> +++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
> @@ -49,7 +49,7 @@
> };
>
> chosen {
> - bootargs = "earlyprintk";
> + bootargs = "earlycon";
> stdout-path = "serial0:115200n8";
> };
>
[PATCH v2 0/2] hwmon: Add attributes to enable/disable sensors
This patch series adds new attribute to enable or disable a sensor in runtime. v1 : https://lkml.org/lkml/2018/3/22/214 Shilpasri G Bhat (2): powernv:opal-sensor-groups: Add support to enable sensor groups hwmon: ibmpowernv: Add attributes to enable/disable sensor groups Documentation/hwmon/sysfs-interface| 22 ++ arch/powerpc/include/asm/opal-api.h| 1 + arch/powerpc/include/asm/opal.h| 2 + .../powerpc/platforms/powernv/opal-sensor-groups.c | 28 ++ arch/powerpc/platforms/powernv/opal-wrappers.S | 1 + drivers/hwmon/ibmpowernv.c | 281 ++--- 6 files changed, 296 insertions(+), 39 deletions(-) -- 1.8.3.1
Re: ipc/msg: zalloc struct msg_queue when creating a new msq
Hello together,
On 06/25/2018 11:21 AM, Dmitry Vyukov wrote:
On Sun, Jun 24, 2018 at 4:56 AM, Davidlohr Bueso wrote:
The following splat was reported around the msg_queue structure
which can have uninitialized fields left over after newque().
Future syscalls which make use of the msq id (now valid) can thus
make KMSAN complain because not all fields are explicitly initialized
and we have the padding as well. This is internal to the kernel,
hence no bogus leaks.
Hi Davidlohr,
As far as I understand the root problem is that (1) we publish a
not-fully initialized objects and (2) finish it's initialization in a
racy manner when other threads already have access to it. As the
result other threads can act on a wrong object. I am not sure that
zeroing the object really solves these problems. It will sure get rid
of the report at hand (but probably not of KTSAN, data race detector,
report), other threads still can see wrong 0 id and the id is still
initialized in racy way. I would expect that a proper fix would be to
publish a fully initialized object with proper, final id. Am I missing
something?
There are 2 relevant values: kern_ipc_perm.id and kern_ipc_perm.seq.
For kern_ipc_perm.id, it is possible to move the access to the codepath
that hold the lock.
For kern_ipc_perm.seq, there are two options:
1) set it before publication.
2) initialize to an invalid value, and correct that at the end.
I'm in favor of option 2, it avoids that we must think about reducing
the next sequence number or not:
The purpose of the sequence counter is to minimize the risk that e.g. a
semop() will write into a newly created array.
I intentially write "minimize the risk", as it is by design impossible
to guarantee that this cannot happen, e.g. if semop() sleeps at the
instruction before the syscall.
Therefore, we can set seq to ULONG_MAX, then ipc_checkid() will always
fail and the corruption is avoided.
What do you think?
And, obviously:
Just set seq to 0 is dangerous, as the first allocated sequence number
is 0, and if that object is destroyed, then the newly created object has
temporarily sequence number 0 as well.
--
Manfred
>From 4791e604dcb618ed7ea1f42b2f6ca9cfe3c113c3 Mon Sep 17 00:00:00 2001
From: Manfred Spraul
Date: Wed, 4 Jul 2018 10:04:49 +0200
Subject: [PATCH] ipc: fix races with kern_ipc_perm.id and .seq
ipc_addid() initializes kern_ipc_perm.id and kern_ipc_perm.seq after
having called ipc_idr_alloc().
Thus a parallel semop() or msgrcv() that uses ipc_obtain_object_idr()
may see an uninitialized value.
The simple solution cannot be used, as the correct id is only known
after ipc_idr_alloc().
Therefore:
- Initialize kern_ipc_perm.seq to an invalid value, so that
ipc_checkid() is guaranteed to fail.
This fulfills the purpose of the sequence counter: If e.g. semget() and
semop() run in parallel, then the semop() should not write into the
newly created array.
- Move the accesses to kern_ipc_perm.id into the code that is protected
by kern_ipc_perm.lock.
The patch also fixes a use-after free that can be triggered by concurrent
semget() and semctl(IPC_RMID): reading kern_ipc_perm.id must happen
before dropping the locks.
Reported-by: syzbot+2827ef6b3385deb07...@syzkaller.appspotmail.com
Signed-off-by: Manfred Spraul
Cc: Dmitry Vyukov
Cc: Kees Cook
Cc: Davidlohr Bueso
Signed-off-by: Manfred Spraul
---
ipc/msg.c | 23 +--
ipc/sem.c | 23 ---
ipc/shm.c | 19 ++-
ipc/util.c | 8 +++-
4 files changed, 54 insertions(+), 19 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index 724000c15296..551c10be8d06 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -166,10 +166,12 @@ static int newque(struct ipc_namespace *ns, struct ipc_params *params)
return retval;
}
+ retval = msq->q_perm.id;
+
ipc_unlock_object(&msq->q_perm);
rcu_read_unlock();
- return msq->q_perm.id;
+ return retval;
}
static inline bool msg_fits_inqueue(struct msg_queue *msq, size_t msgsz)
@@ -491,7 +493,6 @@ static int msgctl_stat(struct ipc_namespace *ns, int msqid,
int cmd, struct msqid64_ds *p)
{
struct msg_queue *msq;
- int id = 0;
int err;
memset(p, 0, sizeof(*p));
@@ -503,7 +504,6 @@ static int msgctl_stat(struct ipc_namespace *ns, int msqid,
err = PTR_ERR(msq);
goto out_unlock;
}
- id = msq->q_perm.id;
} else { /* IPC_STAT */
msq = msq_obtain_object_check(ns, msqid);
if (IS_ERR(msq)) {
@@ -548,10 +548,21 @@ static int msgctl_stat(struct ipc_namespace *ns, int msqid,
p->msg_lspid = pid_vnr(msq->q_lspid);
p->msg_lrpid = pid_vnr(msq->q_lrpid);
- ipc_unlock_object(&msq->q_perm);
- rcu_read_unlock();
- return id;
+ if (cmd == IPC_STAT) {
+ /*
+ * As defined in SUS:
+ * Return 0 on success
+ */
+ err = 0;
+ } else {
+ /*
+ * MSG_STAT and MSG_STAT_ANY (both Linux specific)
+ * Return the full id, including the sequence counter
+ */
+ err = msq->q_perm.id;
+ }
+ ipc_unlock_object(&msq->q
Re: [PATCH] x86/mm: fix cpu stuck issue in __change_page_attr_set_clr
On Wed, 4 Jul 2018, Yang, Bin wrote: > You are completely right. After considering, I think my patch is like a > workaround but not real fix. I am trying to re-write a new patch > without cache implementation. Care to explain the actual problem coherently _before_ writing yet another patch? Thanks, tglx
Re: [PATCH] mm/memblock: replace u64 with phys_addr_t where appropriate
On (07/04/18 02:04), Joe Perches wrote: > > Sorry, NACK on lib/vsprintf.c part > > > > I definitely didn't want to do this tree-wide pf->ps conversion when > > I introduced my patch set. pf/pF should have never existed, true, > > but I think we must support pf/pF in vsprintf(). Simply because it > > has been around for *far* too long. > > And? checkpatch warns about %p[Ff] uses. > > > People tend to develop "habits", > > you know, I'm quite sure ppc/hppa/etc folks still do [and will] use > > pf/pF occasionally. > > There's this saying about habits made to be broken. > This is one of those habits. > > I'd expect more people probably get the %pS or %ps wrong > than use %pF. > > And most people probably look for examples in code and > copy instead of thinking what's correct, so removing old > and deprecated uses from existing code is a good thing. Well, I don't NACK the patch, I just want to keep pf/pF in vsprintf(), that's it. Yes, checkpatch warns about pf/pF uses, becuase we don't want any new pf/pF in the code - it's rather confusing to have both pf/pF and ps/pS -- but I don't necessarily see why would we want to mess up with parisc/hppa/ia64 people using pf/pF for debugging purposes, etc. I'm not married to pf/pF, if you guys insist on complete removal of pf/pF then so be it. -ss
