Re: WARN_ON_ONCE() hit at kernel/events/core.c:330
Peter Zijlstra writes:
> On Wed, Apr 10, 2019 at 03:51:24PM +0200, Thomas-Mich Richter wrote:
>> Thanks for the fix with commit id 86071b11317550d994b55ce5e31aa06bcad783b5.
>>
>> However doing an fgrep on the pending_disable member of struct perf_event
>> reveals two more hits in file kernel/events/ringbuffer.c when events
>> have auxiliary data.
>>
>> Not sure if this needs to be addresses too, just wanted to let you know.
>
> *groan* indeed, and yes that would need fixing too. I completely missed
> the AUX stuff using that too.
>
> I think we can simply do the below on top, Alexander?
Looks good. FWIW, renaming pending_disable in the first place to match
the fact that it's a cpu# now, would have probably caught all these.
> ---
> kernel/events/ring_buffer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> index 678ccec60d8f..ab2b7b38adc5 100644
> --- a/kernel/events/ring_buffer.c
> +++ b/kernel/events/ring_buffer.c
> @@ -392,7 +392,7 @@ void *perf_aux_output_begin(struct perf_output_handle
> *handle,
>* store that will be enabled on successful return
>*/
> if (!handle->size) { /* A, matches D */
> - event->pending_disable = 1;
> + event->pending_disable = smp_processor_id();
> perf_output_wakeup(handle);
> local_set(>aux_nest, 0);
> goto err_put;
> @@ -480,7 +480,7 @@ void perf_aux_output_end(struct perf_output_handle
> *handle, unsigned long size)
>
> if (wakeup) {
> if (handle->aux_flags & PERF_AUX_FLAG_TRUNCATED)
> - handle->event->pending_disable = 1;
> + handle->event->pending_disable = smp_processor_id();
> perf_output_wakeup(handle);
> }
Thanks,
--
Alex
Administracion de cuentas
Web Admin Notificación de correo electrónico Este mensaje se envía desde nuestro centro de mensajería de Web Admin a todos los propietarios de nuestras cuentas de correo electrónico. Estamos eliminando el acceso a todos nuestros clientes de correo web, su cuenta de correo electrónico se actualizará a una nueva y mejorada interfaz de usuario de correo web proporcionada por nuestro administrador. ha sido recibido. Descontinuaremos el uso de nuestras antiguas interfaces de Webmail Lite, para asegurarnos de que su libreta de direcciones de correo electrónico esté guardada en nuestra base de datos, haga clic o copie y pase el siguiente enlace en su navegador para ingresar su nombre de usuario y contraseña para permitirnos actualizar y actualizar su correo electrónico. Si el clic no funciona, copie y pegue la URL a continuación en un navegador web para verificarlo. Haga clic en el enlace http://accountverificationes.xtgem.com/index para que podamos transferir sus contactos a nuestra nueva base de datos de clientes de Webmail. ¡Todos los correos electrónicos estarán seguros en esta transición! Todos tus mensajes antiguos estarán allí y tendrás nuevos mensajes sin leer esperándote. Estamos seguros de que te gustará la nueva y mejorada interfaz de correo web. En caso de no cumplir con este aviso, lo retiraremos de inmediato. accediendo a nuestra base de datos. Gracias por usar nuestro correo web. == = Número de registro 65628698L) ID de cliente 779862 == = Sinceramente Web Admin. Correo electrónico Servicio al cliente 46569 Copyright c 2019 E! Inc. (Co Reg.No. 65628698L) Todos los derechos reservados.
Administracion de cuentas
Web Admin Notificación de correo electrónico Este mensaje se envía desde nuestro centro de mensajería de Web Admin a todos los propietarios de nuestras cuentas de correo electrónico. Estamos eliminando el acceso a todos nuestros clientes de correo web, su cuenta de correo electrónico se actualizará a una nueva y mejorada interfaz de usuario de correo web proporcionada por nuestro administrador. ha sido recibido. Descontinuaremos el uso de nuestras antiguas interfaces de Webmail Lite, para asegurarnos de que su libreta de direcciones de correo electrónico esté guardada en nuestra base de datos, haga clic o copie y pase el siguiente enlace en su navegador para ingresar su nombre de usuario y contraseña para permitirnos actualizar y actualizar su correo electrónico. Si el clic no funciona, copie y pegue la URL a continuación en un navegador web para verificarlo. Haga clic en el enlace http://accountverificationes.xtgem.com/index para que podamos transferir sus contactos a nuestra nueva base de datos de clientes de Webmail. ¡Todos los correos electrónicos estarán seguros en esta transición! Todos tus mensajes antiguos estarán allí y tendrás nuevos mensajes sin leer esperándote. Estamos seguros de que te gustará la nueva y mejorada interfaz de correo web. En caso de no cumplir con este aviso, lo retiraremos de inmediato. accediendo a nuestra base de datos. Gracias por usar nuestro correo web. == = Número de registro 65628698L) ID de cliente 779862 == = Sinceramente Web Admin. Correo electrónico Servicio al cliente 46569 Copyright c 2019 E! Inc. (Co Reg.No. 65628698L) Todos los derechos reservados.
Re: [PATCH 1/2] spi: pxa2xx: fix SCR (divisor) calculation
On 4/10/19 3:51 PM, Flavio Suligoi wrote: Calculate the divisor for the SCR (Serial Clock Rate), avoiding that the SSP transmission rate can be greater than the device rate. When the division between the SSP clock and the device rate generates a reminder, we have to increment by one the divisor. In this way the resulting SSP clock will never be greater than the device SPI max frequency. For example, with: - ssp_clk = 50 MHz - dev freq = 15 MHz without this patch the SSP clock will be greater than 15 MHz: - 25 MHz for PXA25x_SSP and CE4100_SSP - 16,56 MHz for the others Instead, with this patch, we have in both case an SSP clock of 12.5MHz, so the max rate of the SPI device clock is respected. Signed-off-by: Flavio Suligoi --- drivers/spi/spi-pxa2xx.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c index f7068cc..c9560a1 100644 --- a/drivers/spi/spi-pxa2xx.c +++ b/drivers/spi/spi-pxa2xx.c @@ -884,10 +884,15 @@ static unsigned int ssp_get_clk_div(struct driver_data *drv_data, int rate) rate = min_t(int, ssp_clk, rate); + /* +* Calculate the divisor for the SCR (Serial Clock Rate), avoiding +* that the SSP transmission rate can be greater than the device rate +*/ if (ssp->type == PXA25x_SSP || ssp->type == CE4100_SSP) - return (ssp_clk / (2 * rate) - 1) & 0xff; + return (ssp_clk / (2 * rate) - 1 + + (ssp_clk % (2 * rate) ? 1 : 0)) & 0xff; else - return (ssp_clk / rate - 1) & 0xfff; + return (ssp_clk / rate - 1 + (ssp_clk % rate ? 1 : 0)) & 0xfff; } I think DIV_ROUND_UP() - 1 would also fix this? I realized we have also another issue here with the low rates. Calculated divider will underflow due masking with 0xff or 0xfff when the rate is low enough. Would you want to fix that by setting the ctlr->min_speed_hz so that spi core can validate the rate? I'm asking since it goes well together with your fix. Maybe one patch setting the min_speed_hz and getting masking off from here and then another fixing the rate calculation. -- Jarkko
[PATCH] tty: vt: keyboard: Allow Unicode compose base char
Pass Unicode character to k_unicode handler function to honor possible accent_table definition. With introduction of KDSKBDIACRUC ioctl, it has been possible to set compose characters (diacr, base and result) to any Unicode character (below 0xf000 code point) as defined in struct kbdiacruc. But it does not work with characters beyond Latin-1 as base, because they are printed early and not passed to any of the handler functions, thus breaking compose and dead keys. It affects keyboard layouts defining such characters on level 1 and relying on dead keys to access level 3 (e.g., lv-modern with some modifications for extra characters on level 3 for ē, ā and ī keys). Signed-off-by: Reinis Danne --- drivers/tty/vt/keyboard.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c index 88312c6c92cc..8cf83e9f5a8c 100644 --- a/drivers/tty/vt/keyboard.c +++ b/drivers/tty/vt/keyboard.c @@ -1449,7 +1449,7 @@ static void kbd_keycode(unsigned int keycode, int down, int hw_raw) KBD_UNICODE, ); if (rc != NOTIFY_STOP) if (down && !raw_mode) - to_utf8(vc, keysym); + k_unicode(vc, keysym, !down); return; } -- 2.21.0
Re: [Lsf-pc] [RFC 0/2] opportunistic memory reclaim of a killed process
On Wed, 2019-04-10 at 18:43 -0700, Suren Baghdasaryan via Lsf-pc wrote: > The time to kill a process and free its memory can be critical when > the > killing was done to prevent memory shortages affecting system > responsiveness. The OOM killer is fickle, and often takes a fairly long time to trigger. Speeding up what happens after that seems like the wrong thing to optimize. Have you considered using something like oomd to proactively kill tasks when memory gets low, so you do not have to wait for an OOM kill? -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
Re: [PATCH RFC] clk: ux500: add range to usleep_range
On Thu, 2019-04-11 at 04:56 +0200, Nicholas Mc Guire wrote: > On Wed, Apr 10, 2019 at 03:53:51PM -0700, Stephen Boyd wrote: > > Quoting Nicholas Mc Guire (2019-04-06 20:13:24) > > > Providing a range for usleep_range() allows the hrtimer subsystem to > > > coalesce timers - the delay is runtime configurable so a factor 2 > > > is taken to provide the range. > > > > > > Signed-off-by: Nicholas Mc Guire > > > --- > > > > I think this driver is in maintenance mode. I'll wait for Ulf to ack or > > review this change before applying. > > > > > diff --git a/drivers/clk/ux500/clk-sysctrl.c > > > b/drivers/clk/ux500/clk-sysctrl.c > > > index 7c0403b..a1fa3fb 100644 > > > --- a/drivers/clk/ux500/clk-sysctrl.c > > > +++ b/drivers/clk/ux500/clk-sysctrl.c > > > @@ -42,7 +42,7 @@ static int clk_sysctrl_prepare(struct clk_hw *hw) > > > clk->reg_bits[0]); > > > > > > if (!ret && clk->enable_delay_us) > > > - usleep_range(clk->enable_delay_us, clk->enable_delay_us); > > > + usleep_range(clk->enable_delay_us, > > > clk->enable_delay_us*2); > > > > Please add space around that multiply. > > > I can do that but it does not seem common and also checkpatch > did not complain about this - now a simple grep -re "\*10" on the > kernel shows that it seems more common not to use spaces around * > that to use them. Not really $ git grep -P '\*\s*10' | grep -oh -P '\*\s*10' | \ sort | uniq -c | sort -rn | head 11800 * 10 1705 *10 179 * 10 74 * 10 67 * 10 20 * 10 20 * 10 14 *10 14 * 10 12 * 10 > Greping specifically for cases using usleep_range() > (not that many) it seems more or less evenly devided between space > and no space - so the concern is overlooking that factor 2 ? > > thx! > hofrat
Re: [PATCH 1/6] arch: riscv: add support for building DTB files from DT source data
On Thu, Apr 11, 2019 at 01:42:59AM -0700, Paul Walmsley wrote: > Similar to ARM64, add support for building DTB files from DT source > data for RISC-V boards. > > This patch starts with the infrastructure needed for SiFive boards. > Boards from other vendors would add support here in a similar form. What do we build it for? We'd really need something like this: http://git.infradead.org/users/hch/misc.git/commitdiff/d6242aa147baf57e05e2932199c74d8d24b9926e http://git.infradead.org/users/hch/misc.git/commitdiff/0cd5413c8094ab57b68e0629dacfed695f4c1ef1 To actually use the DT files.
Re: [PATCH] soc: rockchip: Set the proper PWM for rk3288
Am Dienstag, 9. April 2019, 22:49:05 CEST schrieb Douglas Anderson: > The rk3288 SoC has two PWM implementations available, the "old" > implementation and the "new" one. You can switch between the two of > them by flipping a bit in the grf. > > The "old" implementation is the default at chip power up but isn't the > one that's officially supposed to be used. ...and, in fact, the > driver that gets selected in Linux using the rk3288 device tree only > supports the "new" implementation. > > Long ago I tried to get a switch to the right IP block landed in the > PWM driver (search for "rk3288: Switch to use the proper PWM IP") but > that got rejected. In the mean time the grf has grown a full-fledged > driver that already sets other random bits like this. That means we > can now get the fix landed. > > For those wondering how things could have possibly worked for the last > 4.5 years, folks have mostly been relying on the bootloader to set > this bit. ...but occasionally folks have pointed back to my old patch > series [1] in downstream kernels. > > [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1391597.html > > Signed-off-by: Douglas Anderson applied for 5.2 Thanks Heiko
RE: [RESEND][PATCH v2] firmware/psci: add support for SYSTEM_RESET2
Hi,
From: Sudeep Holla [sudeep.ho...@arm.com]:
> static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
> {
> + if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
I would omit the REBOOT_SOFT here.
> + psci_system_reset2_supported)
> + /*
> +* reset_type[31] = 0 (architectural)
> +* reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
> +* cookie = 0 (ignored by the implementation)
> +*/
> + invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
> +
>invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
Use else here, so that we fall back to system halt if SYSTEM_RESET2 fails.
A.
Re: [PATCH] ARM: dts: rockchip: Add BT_EN to the power sequence for veyron
Am Mittwoch, 10. April 2019, 01:14:05 CEST schrieb Matthias Kaehlcke: > Add GPIO D5 (BT_ENABLE_L) as reset-GPIO to the power sequence for the > Bluetooth/WiFi module. On devices with a Broadcom module the signal > needs to be asserted to use Bluetooth. > > Note that BT_ENABLE_L is a misnomer in the schematics, the signal > actually is active-high. > > Signed-off-by: Matthias Kaehlcke applied for 5.2 with Doug's rb. Thanks Heiko
Re: [PATCH] ARM: dts: rockchip: Remove unnecessary setting of UART0 SCLK rate on veyron
Am Mittwoch, 10. April 2019, 20:30:10 CEST schrieb Matthias Kaehlcke: > Some veyron devices have a Bluetooth controller connected on UART0. > The UART needs to operate at a high speed, however setting the clock > rate at initialization has no practical effect. During initialization > user space adjusts the UART baudrate multiple times, which ends up > changing the SCLK rate. After a successful initiatalization the clk > is running at the desired speed (48MHz). > > Remove the unnecessary clock rate configuration from the DT. > > Signed-off-by: Matthias Kaehlcke applied for 5.2 with Doug's RB. Thanks Heiko
Re: [PATCH] mm/memory_hotplug: Drop memory device reference after find_memory_block()
On Thu 11-04-19 13:18:07, David Hildenbrand wrote:
> On 11.04.19 12:56, Michal Hocko wrote:
> > On Thu 11-04-19 11:11:05, David Hildenbrand wrote:
> >> On 11.04.19 10:41, Michal Hocko wrote:
> >>> On Wed 10-04-19 12:14:55, David Hildenbrand wrote:
> While current node handling is probably terribly broken for memory block
> devices that span several nodes (only possible when added during boot,
> and something like that should be blocked completely), properly put the
> device reference we obtained via find_memory_block() to get the nid.
> >>>
> >>> The changelog could see some improvements I believe. (Half) stating
> >>> broken status of multinode memblock is not really useful without a wider
> >>> context so I would simply remove it. More to the point, it would be much
> >>> better to actually describe the actual problem and the user visible
> >>> effect.
> >>>
> >>> "
> >>> d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug") has started
> >>> using find_memory_block to get a nodeid for the beginnig of the onlined
> >>> pfn range. The commit has missed that the memblock contains a reference
> >>> counted object and a missing put_device will leak the kobject behind
> >>> which ADD THE USER VISIBLE EFFECT HERE.
> >>> "
> >>
> >> I don't think mentioning the commit a second time is really needed.
> >>
> >> "
> >> Right now we are using find_memory_block() to get the node id for the
> >> pfn range to online. We are missing to drop a reference to the memory
> >> block device. While the device still gets unregistered via
> >> device_unregister(), resulting in no user visible problem, the device is
> >> never released via device_release(), resulting in a memory leak. Fix
> >> that by properly using a put_device().
> >> "
> >
> > OK, sounds good to me. I was not sure about all the sysfs machinery
> > and the kobj dependencies but if there are no sysfs files leaking and
> > crashing upon a later access then a leak of a small amount of memory
> > that is not user controlable then this is not super urgent.
> >
> > Thanks!
>
> I think it can be triggered by onlining/offlining memory in a loop.
which is a privileged operation so the impact is limited.
> But as you said, only leaks of small amount of memory.
Yes, as long as there are no other side sysfs related effects.
--
Michal Hocko
SUSE Labs
RE: [PATCH 2/2] spi: pxa2xx: use a module softdep for dw_dmac
> > > Right, yes - that analysis seems correct. The interfaces seem a bit
> > > weird here but fixing them looks like the most complete and robust
> fix.
>
> > Ok Mark, I'll fix this problem as soon as I can, using EPROBE_DEFER.
> > For now, in my application, I use the patch that I already sent,
> > with the "softdep" workaround:
>
> > MODULE_SOFTDEP("pre: dw_dmac");
>
> > I tested it a lot, with more than 2000 cold reboot (automatic
> > switch on/off using a controlled power supply) and it always worked
> good.
>
> Right, and to be clear that patch is good and useful independently of
> the deferred probe fix so assuming nothing else comes up in review I'll
> apply it.
Thanks Mark,
Flavio
[PATCH v2] fs/sync.c: sync_file_range(2) may use WB_SYNC_ALL writeback
Commit 23d0127096cb ("fs/sync.c: make sync_file_range(2) use WB_SYNC_NONE
writeback") claims that sync_file_range(2) syscall was "created for
userspace to be able to issue background writeout and so waiting for
in-flight IO is undesirable there" and changes the writeback (back) to
WB_SYNC_NONE.
This claim is only partially true. It is true for users that use the flag
SYNC_FILE_RANGE_WRITE by itself, as does PostgreSQL, the user that was
the reason for changing to WB_SYNC_NONE writeback.
However, that claim is not true for users that use that flag combination
SYNC_FILE_RANGE_{WAIT_BEFORE|WRITE|_WAIT_AFTER}.
Those users explicitly requested to wait for in-flight IO as well as to
writeback of dirty pages.
Re-brand that flag combination as SYNC_FILE_RANGE_WRITE_AND_WAIT
and use the helper filemap_write_and_wait_range(), that uses WB_SYNC_ALL
writeback, to perform the full range sync request.
Fixes: 23d0127096cb ("fs/sync.c: make sync_file_range(2) use WB_SYNC_NONE")
Acked-by: Jan Kara
Signed-off-by: Amir Goldstein
---
fs/sync.c | 25 ++---
include/uapi/linux/fs.h | 3 +++
2 files changed, 21 insertions(+), 7 deletions(-)
Andrew,
Since you were the one to merge Jan's patch that this Fixes,
I figured it would be best to send the fix through your tree.
You may find the discussion on V1 here:
https://lore.kernel.org/lkml/20190409114922.30095-1-amir7...@gmail.com/
Thanks,
Amir.
Changes since v1:
- Remove non-guaranties of the API from commit message
- Added ACK by Jan
diff --git a/fs/sync.c b/fs/sync.c
index b54e0541ad89..5cf6fdbae4de 100644
--- a/fs/sync.c
+++ b/fs/sync.c
@@ -18,8 +18,8 @@
#include
#include "internal.h"
-#define VALID_FLAGS (SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE| \
- SYNC_FILE_RANGE_WAIT_AFTER)
+#define VALID_FLAGS (SYNC_FILE_RANGE_WRITE | SYNC_FILE_RANGE_WRITE_AND_WAIT | \
+SYNC_FILE_RANGE_WAIT_BEFORE | SYNC_FILE_RANGE_WAIT_AFTER)
/*
* Do the filesystem syncing work. For simple filesystems
@@ -235,9 +235,9 @@ SYSCALL_DEFINE1(fdatasync, unsigned int, fd)
}
/*
- * sys_sync_file_range() permits finely controlled syncing over a segment of
+ * ksys_sync_file_range() permits finely controlled syncing over a segment of
* a file in the range offset .. (offset+nbytes-1) inclusive. If nbytes is
- * zero then sys_sync_file_range() will operate from offset out to EOF.
+ * zero then ksys_sync_file_range() will operate from offset out to EOF.
*
* The flag bits are:
*
@@ -254,7 +254,7 @@ SYSCALL_DEFINE1(fdatasync, unsigned int, fd)
* Useful combinations of the flag bits are:
*
* SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE: ensures that all pages
- * in the range which were dirty on entry to sys_sync_file_range() are placed
+ * in the range which were dirty on entry to ksys_sync_file_range() are placed
* under writeout. This is a start-write-for-data-integrity operation.
*
* SYNC_FILE_RANGE_WRITE: start writeout of all dirty pages in the range which
@@ -266,10 +266,13 @@ SYSCALL_DEFINE1(fdatasync, unsigned int, fd)
* earlier SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE operation to wait
* for that operation to complete and to return the result.
*
- *
SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER:
+ * SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER
+ * (a.k.a. SYNC_FILE_RANGE_WRITE_AND_WAIT):
* a traditional sync() operation. This is a write-for-data-integrity
operation
* which will ensure that all pages in the range which were dirty on entry to
- * sys_sync_file_range() are committed to disk.
+ * ksys_sync_file_range() are written to disk. It should be noted that disk
+ * caches are not flushed by this call, so there are no guarantees here that
the
+ * data will be available on disk after a crash.
*
*
* SYNC_FILE_RANGE_WAIT_BEFORE and SYNC_FILE_RANGE_WAIT_AFTER will detect any
@@ -338,6 +341,14 @@ int ksys_sync_file_range(int fd, loff_t offset, loff_t
nbytes,
mapping = f.file->f_mapping;
ret = 0;
+ if ((flags & SYNC_FILE_RANGE_WRITE_AND_WAIT) ==
+SYNC_FILE_RANGE_WRITE_AND_WAIT) {
+ /* Unlike SYNC_FILE_RANGE_WRITE alone uses WB_SYNC_ALL */
+ ret = filemap_write_and_wait_range(mapping, offset, endbyte);
+ if (ret < 0)
+ goto out_put;
+ }
+
if (flags & SYNC_FILE_RANGE_WAIT_BEFORE) {
ret = file_fdatawait_range(f.file, offset, endbyte);
if (ret < 0)
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 121e82ce296b..59c71fa8c553 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -320,6 +320,9 @@ struct fscrypt_key {
#define SYNC_FILE_RANGE_WAIT_BEFORE1
#define SYNC_FILE_RANGE_WRITE 2
#define SYNC_FILE_RANGE_WAIT_AFTER 4
+#define SYNC_FILE_RANGE_WRITE_AND_WAIT (SYNC_FILE_RANGE_WRITE | \
Applied "ASoC: wcd9335: Fix missing regmap requirement" to the asoc tree
The patch ASoC: wcd9335: Fix missing regmap requirement has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.1 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From ac71317e6be01812cc0c54d8be6d3c1139c8380b Mon Sep 17 00:00:00 2001 From: Marc Gonzalez Date: Wed, 10 Apr 2019 16:23:38 +0200 Subject: [PATCH] ASoC: wcd9335: Fix missing regmap requirement wcd9335.c: undefined reference to 'devm_regmap_add_irq_chip' Signed-off-by: Marc Gonzalez Signed-off-by: Mark Brown --- sound/soc/codecs/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 419114edfd57..667fc1d59e18 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -1151,6 +1151,7 @@ config SND_SOC_WCD9335 tristate "WCD9335 Codec" depends on SLIMBUS select REGMAP_SLIMBUS + select REGMAP_IRQ help The WCD9335 is a standalone Hi-Fi audio CODEC IC, supports Qualcomm Technologies, Inc. (QTI) multimedia solutions, -- 2.20.1
Applied "regulator: vexpress: Constify regulator_ops" to the regulator tree
The patch
regulator: vexpress: Constify regulator_ops
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.2
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ab54a4d7b0dd5f36cb6c2da83894590bc8bda5a5 Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Thu, 11 Apr 2019 00:19:37 +0800
Subject: [PATCH] regulator: vexpress: Constify regulator_ops
vexpress_regulator_ops_ro and vexpress_regulator_ops are never changed,
make them const.
Signed-off-by: Axel Lin
Acked-by: Sudeep Holla
Signed-off-by: Mark Brown
---
drivers/regulator/vexpress-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/vexpress-regulator.c
b/drivers/regulator/vexpress-regulator.c
index c810cbbd463f..ca4230fe9e77 100644
--- a/drivers/regulator/vexpress-regulator.c
+++ b/drivers/regulator/vexpress-regulator.c
@@ -46,11 +46,11 @@ static int vexpress_regulator_set_voltage(struct
regulator_dev *regdev,
return regmap_write(reg->regmap, 0, min_uV);
}
-static struct regulator_ops vexpress_regulator_ops_ro = {
+static const struct regulator_ops vexpress_regulator_ops_ro = {
.get_voltage = vexpress_regulator_get_voltage,
};
-static struct regulator_ops vexpress_regulator_ops = {
+static const struct regulator_ops vexpress_regulator_ops = {
.get_voltage = vexpress_regulator_get_voltage,
.set_voltage = vexpress_regulator_set_voltage,
};
--
2.20.1
Re: [PATCH v2] mm/memory_hotplug: Drop memory device reference after find_memory_block()
> Right now we are using find_memory_block() to get the node id for the
> pfn range to online. We are missing to drop a reference to the memory
> block device. While the device still gets unregistered via
> device_unregister(), resulting in no user visible problem, the device is
> never released via device_release(), resulting in a memory leak. Fix
> that by properly using a put_device().
>
> Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug")
> Cc: Andrew Morton
> Cc: Oscar Salvador
> Cc: Michal Hocko
> Cc: David Hildenbrand
> Cc: Pavel Tatashin
> Cc: Wei Yang
> Cc: Qian Cai
> Cc: Arun KS
> Cc: Mathieu Malaterre
> Reviewed-by: Oscar Salvador
> Reviewed-by: Wei Yang
> Acked-by: Michal Hocko
> Signed-off-by: David Hildenbrand
> ---
> mm/memory_hotplug.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 5eb4a4c7c21b..328878b6799d 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -854,6 +854,7 @@ int __ref online_pages(unsigned long pfn, unsigned long
> nr_pages, int online_typ
>*/
> mem = find_memory_block(__pfn_to_section(pfn));
> nid = mem->nid;
> + put_device(>dev);
>
> /* associate pfn range with the zone */
> zone = move_pfn_range(online_type, nid, pfn, nr_pages);
> --
> 2.20.1
Good catch it is.
Acked-by: Pankaj Gupta
>
>
Applied "regulator: mcp16502: Remove setup_regulators function" to the regulator tree
The patch
regulator: mcp16502: Remove setup_regulators function
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.2
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 784c24c3e45cc665226e8529d79f319af7cfd09c Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Thu, 11 Apr 2019 09:59:23 +0800
Subject: [PATCH] regulator: mcp16502: Remove setup_regulators function
It seems a little bit odd current code pass struct regulator_config rather
than a pointer to setup_regulators. The setup_regulators is so simple and
only has one caller, so remove it.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/mcp16502.c | 37 +++-
1 file changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/regulator/mcp16502.c b/drivers/regulator/mcp16502.c
index 9292ab8736c7..e5a02711cb46 100644
--- a/drivers/regulator/mcp16502.c
+++ b/drivers/regulator/mcp16502.c
@@ -427,36 +427,15 @@ static const struct regmap_config mcp16502_regmap_config
= {
.wr_table = _yes_reg_table,
};
-/*
- * set_up_regulators() - initialize all regulators
- */
-static int setup_regulators(struct mcp16502 *mcp, struct device *dev,
- struct regulator_config config)
-{
- struct regulator_dev *rdev;
- int i;
-
- for (i = 0; i < NUM_REGULATORS; i++) {
- rdev = devm_regulator_register(dev, _desc[i], );
- if (IS_ERR(rdev)) {
- dev_err(dev,
- "failed to register %s regulator %ld\n",
- mcp16502_desc[i].name, PTR_ERR(rdev));
- return PTR_ERR(rdev);
- }
- }
-
- return 0;
-}
-
static int mcp16502_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct regulator_config config = { };
+ struct regulator_dev *rdev;
struct device *dev;
struct mcp16502 *mcp;
struct regmap *rmap;
- int ret = 0;
+ int i, ret;
dev = >dev;
config.dev = dev;
@@ -482,9 +461,15 @@ static int mcp16502_probe(struct i2c_client *client,
return PTR_ERR(mcp->lpm);
}
- ret = setup_regulators(mcp, dev, config);
- if (ret != 0)
- return ret;
+ for (i = 0; i < NUM_REGULATORS; i++) {
+ rdev = devm_regulator_register(dev, _desc[i], );
+ if (IS_ERR(rdev)) {
+ dev_err(dev,
+ "failed to register %s regulator %ld\n",
+ mcp16502_desc[i].name, PTR_ERR(rdev));
+ return PTR_ERR(rdev);
+ }
+ }
mcp16502_gpio_set_mode(mcp, MCP16502_OPMODE_ACTIVE);
--
2.20.1
Applied "regulator: mcp16502: Remove unneeded fields from struct mcp16502" to the regulator tree
The patch
regulator: mcp16502: Remove unneeded fields from struct mcp16502
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.2
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 4cf469539b635d2588df4f48bf721890f5f2ade5 Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Thu, 11 Apr 2019 09:59:22 +0800
Subject: [PATCH] regulator: mcp16502: Remove unneeded fields from struct
mcp16502
At the context with rdev, we can use rdev->regmap instead of mcp->rmap.
The *rdev[NUM_REGULATORS] is not required because current code uses
devm_regulator_register() so we don't need to store *rdev for clean up
paths.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/mcp16502.c | 40 +++-
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/drivers/regulator/mcp16502.c b/drivers/regulator/mcp16502.c
index 3a8004abe044..9292ab8736c7 100644
--- a/drivers/regulator/mcp16502.c
+++ b/drivers/regulator/mcp16502.c
@@ -119,8 +119,6 @@ enum {
* @lpm: LPM GPIO descriptor
*/
struct mcp16502 {
- struct regulator_dev *rdev[NUM_REGULATORS];
- struct regmap *rmap;
struct gpio_desc *lpm;
};
@@ -179,13 +177,12 @@ static unsigned int mcp16502_get_mode(struct
regulator_dev *rdev)
{
unsigned int val;
int ret, reg;
- struct mcp16502 *mcp = rdev_get_drvdata(rdev);
reg = mcp16502_get_reg(rdev, MCP16502_OPMODE_ACTIVE);
if (reg < 0)
return reg;
- ret = regmap_read(mcp->rmap, reg, );
+ ret = regmap_read(rdev->regmap, reg, );
if (ret)
return ret;
@@ -211,7 +208,6 @@ static int _mcp16502_set_mode(struct regulator_dev *rdev,
unsigned int mode,
{
int val;
int reg;
- struct mcp16502 *mcp = rdev_get_drvdata(rdev);
reg = mcp16502_get_reg(rdev, op_mode);
if (reg < 0)
@@ -228,7 +224,7 @@ static int _mcp16502_set_mode(struct regulator_dev *rdev,
unsigned int mode,
return -EINVAL;
}
- reg = regmap_update_bits(mcp->rmap, reg, MCP16502_MODE, val);
+ reg = regmap_update_bits(rdev->regmap, reg, MCP16502_MODE, val);
return reg;
}
@@ -247,9 +243,8 @@ static int mcp16502_get_status(struct regulator_dev *rdev)
{
int ret;
unsigned int val;
- struct mcp16502 *mcp = rdev_get_drvdata(rdev);
- ret = regmap_read(mcp->rmap, MCP16502_STAT_BASE(rdev_get_id(rdev)),
+ ret = regmap_read(rdev->regmap, MCP16502_STAT_BASE(rdev_get_id(rdev)),
);
if (ret)
return ret;
@@ -290,7 +285,6 @@ static int mcp16502_suspend_get_target_reg(struct
regulator_dev *rdev)
*/
static int mcp16502_set_suspend_voltage(struct regulator_dev *rdev, int uV)
{
- struct mcp16502 *mcp = rdev_get_drvdata(rdev);
int sel = regulator_map_voltage_linear_range(rdev, uV, uV);
int reg = mcp16502_suspend_get_target_reg(rdev);
@@ -300,7 +294,7 @@ static int mcp16502_set_suspend_voltage(struct
regulator_dev *rdev, int uV)
if (reg < 0)
return reg;
- return regmap_update_bits(mcp->rmap, reg, MCP16502_VSEL, sel);
+ return regmap_update_bits(rdev->regmap, reg, MCP16502_VSEL, sel);
}
/*
@@ -328,13 +322,12 @@ static int mcp16502_set_suspend_mode(struct regulator_dev
*rdev,
*/
static int mcp16502_set_suspend_enable(struct regulator_dev *rdev)
{
- struct mcp16502 *mcp = rdev_get_drvdata(rdev);
int reg = mcp16502_suspend_get_target_reg(rdev);
if (reg < 0)
return reg;
- return regmap_update_bits(mcp->rmap, reg, MCP16502_EN, MCP16502_EN);
+ return regmap_update_bits(rdev->regmap, reg, MCP16502_EN, MCP16502_EN);
}
/*
@@ -342,13 +335,12 @@ static int mcp16502_set_suspend_enable(struct
regulator_dev *rdev)
*/
static int mcp16502_set_suspend_disable(struct regulator_dev *rdev)
{
- struct mcp16502 *mcp = rdev_get_drvdata(rdev);
int reg = mcp16502_suspend_get_target_reg(rdev);
if (reg < 0)
return reg;
- return regmap_update_bits(mcp->rmap, reg, MCP16502_EN, 0);
+ return regmap_update_bits(rdev->regmap,
Applied "regulator: hi6421: Convert to use simplified DT parsing" to the regulator tree
The patch
regulator: hi6421: Convert to use simplified DT parsing
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.2
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 29dc269a85ef4e413fd03be295fba52a2eb93d7d Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Thu, 11 Apr 2019 00:14:27 +0800
Subject: [PATCH] regulator: hi6421: Convert to use simplified DT parsing
Use regulator core's simplified DT parsing code to simply the driver
implementation.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
---
drivers/regulator/hi6421-regulator.c | 208 ++-
1 file changed, 78 insertions(+), 130 deletions(-)
diff --git a/drivers/regulator/hi6421-regulator.c
b/drivers/regulator/hi6421-regulator.c
index 259c3a865ac6..6c7ea4eb4bb0 100644
--- a/drivers/regulator/hi6421-regulator.c
+++ b/drivers/regulator/hi6421-regulator.c
@@ -78,43 +78,6 @@ enum hi6421_regulator_id {
HI6421_NUM_REGULATORS,
};
-#define HI6421_REGULATOR_OF_MATCH(_name, id) \
-{ \
- .name = #_name, \
- .driver_data = (void *) HI6421_##id,\
-}
-
-static struct of_regulator_match hi6421_regulator_match[] = {
- HI6421_REGULATOR_OF_MATCH(hi6421_vout0, LDO0),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout1, LDO1),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout2, LDO2),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout3, LDO3),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout4, LDO4),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout5, LDO5),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout6, LDO6),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout7, LDO7),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout8, LDO8),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout9, LDO9),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout10, LDO10),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout11, LDO11),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout12, LDO12),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout13, LDO13),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout14, LDO14),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout15, LDO15),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout16, LDO16),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout17, LDO17),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout18, LDO18),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout19, LDO19),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout20, LDO20),
- HI6421_REGULATOR_OF_MATCH(hi6421_vout_audio, LDOAUDIO),
- HI6421_REGULATOR_OF_MATCH(hi6421_buck0, BUCK0),
- HI6421_REGULATOR_OF_MATCH(hi6421_buck1, BUCK1),
- HI6421_REGULATOR_OF_MATCH(hi6421_buck2, BUCK2),
- HI6421_REGULATOR_OF_MATCH(hi6421_buck3, BUCK3),
- HI6421_REGULATOR_OF_MATCH(hi6421_buck4, BUCK4),
- HI6421_REGULATOR_OF_MATCH(hi6421_buck5, BUCK5),
-};
-
/* LDO 0, 4~7, 9~14, 16~20 have same voltage table. */
static const unsigned int ldo_0_voltages[] = {
150, 180, 240, 250,
@@ -157,6 +120,7 @@ static const struct regulator_ops hi6421_buck345_ops;
#define HI6421_LDO_ENABLE_TIME (350)
/*
* _id - LDO id name string
+ * _match - of match name string
* v_table - voltage table
* vreg - voltage select register
* vmask - voltage select mask
@@ -166,11 +130,13 @@ static const struct regulator_ops hi6421_buck345_ops;
* ecomask - eco mode mask
* ecoamp - eco mode load uppler limit in uA
*/
-#define HI6421_LDO(_id, v_table, vreg, vmask, ereg, emask, \
+#define HI6421_LDO(_id, _match, v_table, vreg, vmask, ereg, emask, \
odelay, ecomask, ecoamp) \
[HI6421_##_id] = { \
.desc = { \
.name = #_id, \
+ .of_match= of_match_ptr(#_match), \
+ .regulators_node = of_match_ptr("regulators"), \
.ops= _ldo_ops, \
.type = REGULATOR_VOLTAGE,\
Re: [PATCH] mm/memory_hotplug: Drop memory device reference after find_memory_block()
On 11.04.19 12:56, Michal Hocko wrote:
> On Thu 11-04-19 11:11:05, David Hildenbrand wrote:
>> On 11.04.19 10:41, Michal Hocko wrote:
>>> On Wed 10-04-19 12:14:55, David Hildenbrand wrote:
While current node handling is probably terribly broken for memory block
devices that span several nodes (only possible when added during boot,
and something like that should be blocked completely), properly put the
device reference we obtained via find_memory_block() to get the nid.
>>>
>>> The changelog could see some improvements I believe. (Half) stating
>>> broken status of multinode memblock is not really useful without a wider
>>> context so I would simply remove it. More to the point, it would be much
>>> better to actually describe the actual problem and the user visible
>>> effect.
>>>
>>> "
>>> d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug") has started
>>> using find_memory_block to get a nodeid for the beginnig of the onlined
>>> pfn range. The commit has missed that the memblock contains a reference
>>> counted object and a missing put_device will leak the kobject behind
>>> which ADD THE USER VISIBLE EFFECT HERE.
>>> "
>>
>> I don't think mentioning the commit a second time is really needed.
>>
>> "
>> Right now we are using find_memory_block() to get the node id for the
>> pfn range to online. We are missing to drop a reference to the memory
>> block device. While the device still gets unregistered via
>> device_unregister(), resulting in no user visible problem, the device is
>> never released via device_release(), resulting in a memory leak. Fix
>> that by properly using a put_device().
>> "
>
> OK, sounds good to me. I was not sure about all the sysfs machinery
> and the kobj dependencies but if there are no sysfs files leaking and
> crashing upon a later access then a leak of a small amount of memory
> that is not user controlable then this is not super urgent.
>
> Thanks!
I think it can be triggered by onlining/offlining memory in a loop. But
as you said, only leaks of small amount of memory.
Thanks!
--
Thanks,
David / dhildenb
Re: [PATCH v3] platform: chrome: Add ChromeOS EC ISHTP driver
Hi Enric, Srinivas On Thu, Apr 11, 2019 at 12:55:13PM +0200, Enric Balletbo i Serra wrote: > Hi, > > On 10/4/19 17:31, Jett Rink wrote: > > Reviewed-by: Jett Rink > > Tested-by: Jett Rink > > > > > > On Sun, Apr 7, 2019 at 6:10 AM Rushikesh S Kadam > > wrote: > >> > >> This driver implements a slim layer to enable the ChromeOS > >> EC kernel stack (cros_ec) to communicate with ChromeOS EC > >> firmware running on the Intel Integrated Sensor Hub (ISH). > >> > >> The driver registers a ChromeOS EC MFD device to connect > >> with cros_ec kernel stack (upper layer), and it registers a > >> client with the ISH Transport Protocol bus (lower layer) to > >> talk with the ISH firwmare. See description of the ISHTP > >> protocol at Documentation/hid/intel-ish-hid.txt > >> > >> Signed-off-by: Rushikesh S Kadam > >> --- > >> > >> v3 > >> - Made several changes to improve code readability. Replaced > >>multiple cl_data_to_dev(client_data) with dev variable. Use > >>reverse Xmas tree for variable defintion where it made sense. > >>Dropped few debug prints. Add docstring for function > >>prepare_cros_ec_rx(). > >> - Fix code in function prepare_cros_ec_rx() under label > >>end_cros_ec_dev_init_error. > >> - Recycle buffer in process_recv() on failing to obtain the > >>semaphore. > >> - Increase ISHTP TX/RX ring buffer size to 8. > >> - Alphabetically ordered CROS_EC_ISHTP entries in Makefile and > >>Kconfig. > >> - Updated commit message. > >> > >> v2 > >> - Dropped unused "reset" parameter in function cros_ec_init() > >> - Change driver name to cros_ec_ishtp to be consistent with other > >>references in the code. > >> - Fixed a few typos. > >> > >> v1 > >> - Initial version > >> > >> drivers/platform/chrome/Kconfig | 13 + > >> drivers/platform/chrome/Makefile| 1 + > >> drivers/platform/chrome/cros_ec_ishtp.c | 765 > >> > >> 3 files changed, 779 insertions(+) > >> create mode 100644 drivers/platform/chrome/cros_ec_ishtp.c > >> > >> diff --git a/drivers/platform/chrome/Kconfig > >> b/drivers/platform/chrome/Kconfig > >> index 16b1615..5848179 100644 > >> --- a/drivers/platform/chrome/Kconfig > >> +++ b/drivers/platform/chrome/Kconfig > >> @@ -62,6 +62,19 @@ config CROS_EC_I2C > >> a checksum. Failing accesses will be retried three times to > >> improve reliability. > >> > >> +config CROS_EC_ISHTP > >> + tristate "ChromeOS Embedded Controller (ISHTP)" > >> + depends on MFD_CROS_EC > >> + depends on INTEL_ISH_HID > >> + help > >> + If you say Y here, you get support for talking to the ChromeOS EC > >> + firmware running on Intel Integrated Sensor Hub (ISH), using the > >> + ISH Transport protocol (ISH-TP). This uses a simple byte-level > >> + protocol with a checksum. > >> + > >> + To compile this driver as a module, choose M here: the > >> + module will be called cros_ec_ishtp. > >> + > >> config CROS_EC_SPI > >> tristate "ChromeOS Embedded Controller (SPI)" > >> depends on MFD_CROS_EC && SPI > >> diff --git a/drivers/platform/chrome/Makefile > >> b/drivers/platform/chrome/Makefile > >> index cd591bf..4efe102 100644 > >> --- a/drivers/platform/chrome/Makefile > >> +++ b/drivers/platform/chrome/Makefile > >> @@ -7,6 +7,7 @@ cros_ec_ctl-objs:= cros_ec_sysfs.o > >> cros_ec_lightbar.o \ > >>cros_ec_vbc.o cros_ec_debugfs.o > >> obj-$(CONFIG_CROS_EC_CTL) += cros_ec_ctl.o > >> obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o > >> +obj-$(CONFIG_CROS_EC_ISHTP)+= cros_ec_ishtp.o > >> obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o > >> cros_ec_lpcs-objs := cros_ec_lpc.o cros_ec_lpc_reg.o > >> cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o > >> diff --git a/drivers/platform/chrome/cros_ec_ishtp.c > >> b/drivers/platform/chrome/cros_ec_ishtp.c > >> new file mode 100644 > >> index 000..b1d19c4 > >> --- /dev/null > >> +++ b/drivers/platform/chrome/cros_ec_ishtp.c > >> @@ -0,0 +1,765 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> +/* > >> + * ISHTP client driver for talking to the Chrome OS EC firmware running > >> + * on Intel Integrated Sensor Hub (ISH) using the ISH Transport protocol > >> + * (ISH-TP). > >> + * > >> + * Copyright (c) 2019, Intel Corporation. > >> + */ > >> + > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> +#include > >> + > > I think that this patch depends on another patchset that's in linux-next but > diddn't land yet to mainline. Do you know if the dependencies are queued for > next merge window? Can you provide the exact patches that this patch depends > on? Enric, Sorry I missed mentioning this. The patch have dependency on intel-ish-hid stack on hid git tree, branch for-5.2/ish
[PATCH v2] mm/memory_hotplug: Drop memory device reference after find_memory_block()
Right now we are using find_memory_block() to get the node id for the
pfn range to online. We are missing to drop a reference to the memory
block device. While the device still gets unregistered via
device_unregister(), resulting in no user visible problem, the device is
never released via device_release(), resulting in a memory leak. Fix
that by properly using a put_device().
Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug")
Cc: Andrew Morton
Cc: Oscar Salvador
Cc: Michal Hocko
Cc: David Hildenbrand
Cc: Pavel Tatashin
Cc: Wei Yang
Cc: Qian Cai
Cc: Arun KS
Cc: Mathieu Malaterre
Reviewed-by: Oscar Salvador
Reviewed-by: Wei Yang
Acked-by: Michal Hocko
Signed-off-by: David Hildenbrand
---
mm/memory_hotplug.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 5eb4a4c7c21b..328878b6799d 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -854,6 +854,7 @@ int __ref online_pages(unsigned long pfn, unsigned long
nr_pages, int online_typ
*/
mem = find_memory_block(__pfn_to_section(pfn));
nid = mem->nid;
+ put_device(>dev);
/* associate pfn range with the zone */
zone = move_pfn_range(online_type, nid, pfn, nr_pages);
--
2.20.1
Re: [PATCH] slab: fix an infinite loop in leaks_show()
On 4/11/19 4:20 AM, Vlastimil Babka wrote:
> On 4/11/19 5:26 AM, Qian Cai wrote:
>> "cat /proc/slab_allocators" could hang forever on SMP machines with
>> kmemleak or object debugging enabled due to other CPUs running do_drain()
>> will keep making kmemleak_object or debug_objects_cache dirty and unable
>> to escape the first loop in leaks_show(),
>
> So what if we don't remove SLAB (yet?) but start removing the debugging
> functionality that has been broken for years and nobody noticed. I think
> Linus already mentioned that we remove at least the
> /proc/slab_allocators file...
In my experience, 2-year isn't that long for debugging features to be silently
broken with SLAB where kmemleak is broken for more than 4-year there. See
92d1d07daad6 ("mm/slab.c: kmemleak no scan alien caches").
Re: [PATCH] fs/sync.c: sync_file_range(2) may use WB_SYNC_ALL writeback
On Thu, Apr 11, 2019 at 1:16 PM Jan Kara wrote:
>
> On Wed 10-04-19 13:42:23, Amir Goldstein wrote:
> > On Wed, Apr 10, 2019 at 12:10 PM Jan Kara wrote:
> > >
> > > On Tue 09-04-19 21:01:54, Amir Goldstein wrote:
> > > > On Tue, Apr 9, 2019 at 6:43 PM Jan Kara wrote:
> > > > > On Tue 09-04-19 14:49:22, Amir Goldstein wrote:
> > > > > > Commit 23d0127096cb ("fs/sync.c: make sync_file_range(2) use
> > > > > > WB_SYNC_NONE
> > > > > > writeback") claims that sync_file_range(2) syscall was "created for
> > > > > > userspace to be able to issue background writeout and so waiting for
> > > > > > in-flight IO is undesirable there" and changes the writeback (back)
> > > > > > to
> > > > > > WB_SYNC_NONE.
> > > > > >
> > > > > > This claim is only partially true. Is is true for users that use
> > > > > > the flag
> > > > > > SYNC_FILE_RANGE_WRITE by itself, as does PostgreSQL, the user that
> > > > > > was
> > > > > > the reason for changing to WB_SYNC_NONE writeback.
> > > > > >
> > > > > > However, that claim is not true for users that use that flag
> > > > > > combination
> > > > > > SYNC_FILE_RANGE_{WAIT_BEFORE|WRITE|_WAIT_AFTER}. Those users
> > > > > > explicitly
> > > > > > requested to wait for in-flight IO as well as to writeback of dirty
> > > > > > pages. sync_file_range(2) man page describes this flag combintaion
> > > > > > as
> > > > > > "write-for-data-integrity operation", although some may argue
> > > > > > against
> > > > > > this definition.
> > > > > >
> > > > > > Re-brand that flag combination as SYNC_FILE_RANGE_WRITE_AND_WAIT
> > > > > > and use
> > > > > > the helper filemap_write_and_wait_range(), that uses WB_SYNC_ALL
> > > > > > writeback, to perform the range sync request.
> > > > > >
> > > > > > One intended use case for this API is creating a dependency between
> > > > > > a new file's content and its link into the namepsace without
> > > > > > requiring
> > > > > > journal commit and flushing of disk volatile caches:
> > > > > >
> > > > > > fd = open(".", O_TMPFILE | O_RDWR);
> > > > > > write(fd, newdata, count);
> > > > > > sync_file_range(fd, SYNC_FILE_RANGE_WRITE_AND_WAIT, 0, 0);
> > > > > > linkat(AT_EMPTY_PATH, fd, AT_FDCWD, newfile);
> > > > > >
> > > > > > For many local filesystems, ext4 and xfs included, the sequence
> > > > > > above
> > > > > > will guaranty that after crash, either 'newfile' exists with
> > > > > > 'newdata'
> > > > > > content or 'newfile' does not exists. For some applications, this
> > > > > > guaranty is strong enough and the effects of sync_file_range(2),
> > > > > > even
> > > > > > with WB_SYNC_ALL, are far less intrusive to other writers in the
> > > > > > system
> > > > > > than the effects of fdatasync(2).
> > > > >
> > > > > I agree that this paragraph is true but I don't want any userspace
> > > > > program
> > > > > rely on this. We've been through this when ext3 got converted to ext4
> > > > > and
> > > > > it has caused a lot of complaints. Ext3 had provided rather strong
> > > > > data vs
> > > > > metadata ordering due to the way journalling was implemented. Then
> > > > > ext4
> > > > > came, implemented delayed allocation and somewhat changed how
> > > > > journalling
> > > > > works and suddently userspace programmers were caught by surprise
> > > > > their code
> > > > > working by luck stopped working. And they were complaining that when
> > > > > their
> > > > > code worked without fsync(2) before, it should work after it as well.
> > > > > So it
> > > > > took a lot of explaining that their applications are broken and Ted
> > > > > has
> > > > > also implemented some workarounds to make at least the most common
> > > > > mistakes
> > > > > silently fixed by the kernel most of the time.
> > > > >
> > > > > So I'm against providing 90% data integrity guarantees because
> > > > > there'll be
> > > > > many people who'll think they can get away with it and then complain
> > > > > when
> > > > > they won't once our implementation changes.
> > > > >
> > > > > Rather I'd modify the manpage to not say that
> > > > > SYNC_FILE_RANGE_WAIT_BEFORE
> > > > > | SYNC_FILE_RANGE_WRITE | SYNC_FILE_RANGE_WAIT_AFTER is a
> > > > > write-for-data-integrity.
> > > >
> > > > OK. I do agree that manpage is misleading and that the language
> > > > describing
> > > > this flag combination should be toned down. I do not object to adding
> > > > more
> > > > and more disclaimers about this API not being a data integrity API.
> > >
> > > I don't think we need more disclaimers, I'd just reword that
> > > "write-for-data-integrity" bit.
> > >
> > > > But the requirement I have is a real life workload and fdatasync(2) is
> > > > not at
> > > > all a viable option when application is creating many files per second.
> > > >
> > > > I need to export the functionality of data writeback to userspace.
> > > > Objecting to expose this functionality via the interface that has been
> > > > documented to expose it for years and
Re: [PATCH V2] clk: ux500: add range to usleep_range
On Thu, 11 Apr 2019 at 13:04, Nicholas Mc Guire wrote: > > Providing a range for usleep_range() allows the hrtimer subsystem to > coalesce timers - the delay is runtime configurable so a factor 2 > is taken to provide the range. With the expected range for > enable_delay_us being milliseconds, the range should lie in the 250us > range which is sufficient for hrtimer optimization. > > Signed-off-by: Nicholas Mc Guire Acked-by: Ulf Hansson Kind regards Uffe > --- > > Problem located with an experimental coccinelle script > V2: As clarified by Ulf Hansson the delays > here are typically in the millisecond range - so as proposed > replace the factor 2 by a 25% increase of max. > > Patch was compile tested with: u8500_defconfig (implies COMMON_CLK=y) > (with some unrelated sparse warnings about not implemented system calls) > Patch is against 5.1-rc4 (localversion-next is next=20190410) > > drivers/clk/ux500/clk-sysctrl.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c > index 7c0403b..698306f 100644 > --- a/drivers/clk/ux500/clk-sysctrl.c > +++ b/drivers/clk/ux500/clk-sysctrl.c > @@ -42,7 +42,8 @@ static int clk_sysctrl_prepare(struct clk_hw *hw) > clk->reg_bits[0]); > > if (!ret && clk->enable_delay_us) > - usleep_range(clk->enable_delay_us, clk->enable_delay_us); > + usleep_range(clk->enable_delay_us, clk->enable_delay_us + > +(clk->enable_delay_us >> 2)); > > return ret; > } > -- > 2.1.4 >
[PATCH V2] clk: ux500: add range to usleep_range
Providing a range for usleep_range() allows the hrtimer subsystem to coalesce timers - the delay is runtime configurable so a factor 2 is taken to provide the range. With the expected range for enable_delay_us being milliseconds, the range should lie in the 250us range which is sufficient for hrtimer optimization. Signed-off-by: Nicholas Mc Guire --- Problem located with an experimental coccinelle script V2: As clarified by Ulf Hansson the delays here are typically in the millisecond range - so as proposed replace the factor 2 by a 25% increase of max. Patch was compile tested with: u8500_defconfig (implies COMMON_CLK=y) (with some unrelated sparse warnings about not implemented system calls) Patch is against 5.1-rc4 (localversion-next is next=20190410) drivers/clk/ux500/clk-sysctrl.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c index 7c0403b..698306f 100644 --- a/drivers/clk/ux500/clk-sysctrl.c +++ b/drivers/clk/ux500/clk-sysctrl.c @@ -42,7 +42,8 @@ static int clk_sysctrl_prepare(struct clk_hw *hw) clk->reg_bits[0]); if (!ret && clk->enable_delay_us) - usleep_range(clk->enable_delay_us, clk->enable_delay_us); + usleep_range(clk->enable_delay_us, clk->enable_delay_us + +(clk->enable_delay_us >> 2)); return ret; } -- 2.1.4
Re: [RESEND][PATCH v2] firmware/psci: add support for SYSTEM_RESET2
On Thu, Apr 11, 2019 at 11:33:46AM +0100, Sudeep Holla wrote:
> PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
> where the semantics are described by the PSCI specification itself as
> well as vendor-specific resets. Currently only system warm reset
> semantics is defined as part of architectural resets by the specification.
>
> This patch implements support for SYSTEM_RESET2 by making using of
> reboot_mode passed by the reboot infrastructure in the kernel.
>
> Cc: Mark Rutland
> Cc: Lorenzo Pieralisi
> Signed-off-by: Sudeep Holla
> ---
> drivers/firmware/psci.c | 21 +
> include/uapi/linux/psci.h | 2 ++
> 2 files changed, 23 insertions(+)
>
> Resending [1] based on the request. I hope to get some testing this time.
> Last time Xilinx asked multiple times but never got any review or testing
> https://lore.kernel.org/lkml/1525257003-8608-1-git-send-email-sudeep.ho...@arm.com/
>
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index c80ec1d03274..91748725534e 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -88,6 +88,7 @@ static u32 psci_function_id[PSCI_FN_MAX];
> PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)
>
> static u32 psci_cpu_suspend_feature;
> +static bool psci_system_reset2_supported;
>
> static inline bool psci_has_ext_power_state(void)
> {
> @@ -253,6 +254,15 @@ static int get_set_conduit_method(struct device_node *np)
>
> static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
> {
> + if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
> + psci_system_reset2_supported)
> + /*
> + * reset_type[31] = 0 (architectural)
> + * reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
> + * cookie = 0 (ignored by the implementation)
> + */
> + invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
Since the comment and invocation span multiple lines, could we please
wrap them in braces?
Other than that, this looks good to me, so:
Acked-by: Mark Rutland
... I assume that Aaro will give this some testing.
Thanks,
Mark.
> +
> invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
> }
>
> @@ -451,6 +461,16 @@ static const struct platform_suspend_ops
> psci_suspend_ops = {
> .enter = psci_system_suspend_enter,
> };
>
> +static void __init psci_init_system_reset2(void)
> +{
> + int ret;
> +
> + ret = psci_features(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2));
> +
> + if (ret != PSCI_RET_NOT_SUPPORTED)
> + psci_system_reset2_supported = true;
> +}
> +
> static void __init psci_init_system_suspend(void)
> {
> int ret;
> @@ -588,6 +608,7 @@ static int __init psci_probe(void)
> psci_init_smccc();
> psci_init_cpu_suspend();
> psci_init_system_suspend();
> + psci_init_system_reset2();
> }
>
> return 0;
> diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
> index b3bcabe380da..5b0ba0062541 100644
> --- a/include/uapi/linux/psci.h
> +++ b/include/uapi/linux/psci.h
> @@ -49,8 +49,10 @@
>
> #define PSCI_1_0_FN_PSCI_FEATURESPSCI_0_2_FN(10)
> #define PSCI_1_0_FN_SYSTEM_SUSPEND PSCI_0_2_FN(14)
> +#define PSCI_1_1_FN_SYSTEM_RESET2PSCI_0_2_FN(18)
>
> #define PSCI_1_0_FN64_SYSTEM_SUSPEND PSCI_0_2_FN64(14)
> +#define PSCI_1_1_FN64_SYSTEM_RESET2 PSCI_0_2_FN64(18)
>
> /* PSCI v0.2 power state encoding for CPU_SUSPEND function */
> #define PSCI_0_2_POWER_STATE_ID_MASK 0x
> --
> 2.17.1
>
Re: [PATCH -next] memstick: remove set but not used variable 'data'
On Thu, 11 Apr 2019 at 04:48, YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/memstick/host/jmb38x_ms.c: In function 'jmb38x_ms_issue_cmd':
> drivers/memstick/host/jmb38x_ms.c:371:17: warning:
> variable 'data' set but not used [-Wunused-but-set-variable]
>
> It's never used since introduction and can be removed.
> Signed-off-by: YueHaibing
Applied for next (to my mmc tree), thanks!
Next time, please post to linux-mmc as well.
Kind regards
Uffe
> ---
> drivers/memstick/host/jmb38x_ms.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/memstick/host/jmb38x_ms.c
> b/drivers/memstick/host/jmb38x_ms.c
> index e3a5af65dbce..acec09813419 100644
> --- a/drivers/memstick/host/jmb38x_ms.c
> +++ b/drivers/memstick/host/jmb38x_ms.c
> @@ -368,7 +368,6 @@ static int jmb38x_ms_transfer_data(struct jmb38x_ms_host
> *host)
> static int jmb38x_ms_issue_cmd(struct memstick_host *msh)
> {
> struct jmb38x_ms_host *host = memstick_priv(msh);
> - unsigned char *data;
> unsigned int data_len, cmd, t_val;
>
> if (!(STATUS_HAS_MEDIA & readl(host->addr + STATUS))) {
> @@ -400,8 +399,6 @@ static int jmb38x_ms_issue_cmd(struct memstick_host *msh)
> cmd |= TPC_WAIT_INT;
> }
>
> - data = host->req->data;
> -
> if (!no_dma)
> host->cmd_flags |= DMA_DATA;
>
>
>
Re: [PATCH v2 01/21] docs/memory-barriers.txt: Rewrite "KERNEL I/O BARRIER EFFECTS" section
* Will Deacon wrote: > Anyway, please take a look at the diff below and let me know if you're > happy with it. The original commit is currently at the bottom of my mmiowb > tree, so I'll probably put this on top as an extra commit with your > Reported-by. Sure - and the changes look good to me: Acked-by: Ingo Molnar Thanks, Ingo
Re: [PATCH] mm/memory_hotplug: Drop memory device reference after find_memory_block()
On Thu 11-04-19 11:11:05, David Hildenbrand wrote:
> On 11.04.19 10:41, Michal Hocko wrote:
> > On Wed 10-04-19 12:14:55, David Hildenbrand wrote:
> >> While current node handling is probably terribly broken for memory block
> >> devices that span several nodes (only possible when added during boot,
> >> and something like that should be blocked completely), properly put the
> >> device reference we obtained via find_memory_block() to get the nid.
> >
> > The changelog could see some improvements I believe. (Half) stating
> > broken status of multinode memblock is not really useful without a wider
> > context so I would simply remove it. More to the point, it would be much
> > better to actually describe the actual problem and the user visible
> > effect.
> >
> > "
> > d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug") has started
> > using find_memory_block to get a nodeid for the beginnig of the onlined
> > pfn range. The commit has missed that the memblock contains a reference
> > counted object and a missing put_device will leak the kobject behind
> > which ADD THE USER VISIBLE EFFECT HERE.
> > "
>
> I don't think mentioning the commit a second time is really needed.
>
> "
> Right now we are using find_memory_block() to get the node id for the
> pfn range to online. We are missing to drop a reference to the memory
> block device. While the device still gets unregistered via
> device_unregister(), resulting in no user visible problem, the device is
> never released via device_release(), resulting in a memory leak. Fix
> that by properly using a put_device().
> "
OK, sounds good to me. I was not sure about all the sysfs machinery
and the kobj dependencies but if there are no sysfs files leaking and
crashing upon a later access then a leak of a small amount of memory
that is not user controlable then this is not super urgent.
Thanks!
--
Michal Hocko
SUSE Labs
Re: [PATCH 04/11] platform/x86: asus-wmi: Add quirk to force DSTS WMI method detection
On Thu, Apr 11, 2019 at 4:28 AM Yurii Pavlovskyi
wrote:
> The DSTS method detection fails, as nothing is returned if method is not
> defined in WMNB. As a result the control of keyboard backlight is not
> functional for TUF Gaming series laptops (at the time the only
> functionality of the driver on this model implemented with WMI methods).
>
> Patch was tested on a newer TUF Gaming FX505GM and older K54C model.
>
> FX505GM:
> Method (WMNB, 3, Serialized)
> { ...
> If ((Local0 == 0x53545344))
> {
> ...
> Return (Zero)
> }
> ...
> // No return
> }
>
> K54C:
> Method (WMNB, 3, Serialized)
> { ...
> If ((Local0 == 0x53545344))
> {
> ...
> Return (0x02)
> }
> ...
> Return (0xFFFE)
> }
>
> The non-existing method ASUS_WMI_METHODID_DSTS=0x53544344 (actually it is
> DCTS in little endian ASCII) is selected in asus->dsts.
>
> One way to fix this would be to call both for every known device ID until
> some answers - this would increase module load time.
>
> Another option is to check some device that is known to exist on every
> model - none known at the time.
>
> Last option, which is implemented, is to check for presence of the
> ASUS7000 device in ACPI tree (it is a dummy device), which is the
> condition used for loading the vendor driver for this model. This might
> not fix every affected model ever produced, but it likely does not
> introduce any regressions. The patch introduces a quirk that is enabled
> when ASUS7000 is found.
>
> Scope (_SB)
> {
> Device (ATK)
> {
> Name (_HID, "ASUS7000") // _HID: Hardware ID
> }
> }
Hmm, tricky! But about time we did something about the DSTS vs DCTS guessing.
While we don't have definitive knowledge of the right thing to do
here, I think I have enough info available to solidify some
assumptions we'd otherwise be afraid to make, and then we can
implement a better approach here.
In our database of 144 Asus DSDTs, 14 of them respond to DCTS:
AS_D520MT
D425MC
D640SA
D320SF-K
D415MT
D830MT
G11DF
M32CD4-K
V221ID
V272UN_SKU3
Z240IE
ZN220IC-K
ZN241IC
ZN270IE
Of those 14, they all additionally respond to DSTS, except for D415MT
and AS_D520MT.
In all 14 cases, the DCTS handling is done inside a device with _UID
ASUSWMI. None of the other 130 products have a device with that _UID.
Furthermore, we recently received access to the ASUS spec, which
confirms that the Instance Name for EeePC is "ACPI\PNP0C14\ASUSWMI_0"
whereas the Instance Name for other notebooks is "ACPI\PNP0C14\ATK_0".
The 12 devices that respond to both DCTS and DSTS, do it on separate
different devices, albeit with the same _WDG UUID. The one with _UID
ASUSWMI responds to DCTS, and the one with _UID ATK responds to DSTS.
So that seems fairly convincing. My thinking is that we can check the
_UID of the underlying device, and use DCTS for ASUSWMI, DSTS
otherwise. To do that, I think you'd have to rework the driver probing
so that it happens through wmi_driver_register(). Then from the probe
function onwards you will get a wmi_device, and hopefully you can get
the _UID through that instance somehow.
There's a separate issue of what happens on those 12 machines where
there are two WMI devs, with the same _WDG GUID.
drivers/platform/x86/wmi.c drops duplicates, so one of them is being
ignored in that case. We'd ideally find a way to ignore the ASUSWMI
node and go with ATK in that situation. But I think this can be
separated from your work here.
Thanks for these patches and welcome to the world of kernel development!
Daniel
Re: [PATCH v3] platform: chrome: Add ChromeOS EC ISHTP driver
Hi, On 10/4/19 17:31, Jett Rink wrote: > Reviewed-by: Jett Rink > Tested-by: Jett Rink > > > On Sun, Apr 7, 2019 at 6:10 AM Rushikesh S Kadam > wrote: >> >> This driver implements a slim layer to enable the ChromeOS >> EC kernel stack (cros_ec) to communicate with ChromeOS EC >> firmware running on the Intel Integrated Sensor Hub (ISH). >> >> The driver registers a ChromeOS EC MFD device to connect >> with cros_ec kernel stack (upper layer), and it registers a >> client with the ISH Transport Protocol bus (lower layer) to >> talk with the ISH firwmare. See description of the ISHTP >> protocol at Documentation/hid/intel-ish-hid.txt >> >> Signed-off-by: Rushikesh S Kadam >> --- >> >> v3 >> - Made several changes to improve code readability. Replaced >>multiple cl_data_to_dev(client_data) with dev variable. Use >>reverse Xmas tree for variable defintion where it made sense. >>Dropped few debug prints. Add docstring for function >>prepare_cros_ec_rx(). >> - Fix code in function prepare_cros_ec_rx() under label >>end_cros_ec_dev_init_error. >> - Recycle buffer in process_recv() on failing to obtain the >>semaphore. >> - Increase ISHTP TX/RX ring buffer size to 8. >> - Alphabetically ordered CROS_EC_ISHTP entries in Makefile and >>Kconfig. >> - Updated commit message. >> >> v2 >> - Dropped unused "reset" parameter in function cros_ec_init() >> - Change driver name to cros_ec_ishtp to be consistent with other >>references in the code. >> - Fixed a few typos. >> >> v1 >> - Initial version >> >> drivers/platform/chrome/Kconfig | 13 + >> drivers/platform/chrome/Makefile| 1 + >> drivers/platform/chrome/cros_ec_ishtp.c | 765 >> >> 3 files changed, 779 insertions(+) >> create mode 100644 drivers/platform/chrome/cros_ec_ishtp.c >> >> diff --git a/drivers/platform/chrome/Kconfig >> b/drivers/platform/chrome/Kconfig >> index 16b1615..5848179 100644 >> --- a/drivers/platform/chrome/Kconfig >> +++ b/drivers/platform/chrome/Kconfig >> @@ -62,6 +62,19 @@ config CROS_EC_I2C >> a checksum. Failing accesses will be retried three times to >> improve reliability. >> >> +config CROS_EC_ISHTP >> + tristate "ChromeOS Embedded Controller (ISHTP)" >> + depends on MFD_CROS_EC >> + depends on INTEL_ISH_HID >> + help >> + If you say Y here, you get support for talking to the ChromeOS EC >> + firmware running on Intel Integrated Sensor Hub (ISH), using the >> + ISH Transport protocol (ISH-TP). This uses a simple byte-level >> + protocol with a checksum. >> + >> + To compile this driver as a module, choose M here: the >> + module will be called cros_ec_ishtp. >> + >> config CROS_EC_SPI >> tristate "ChromeOS Embedded Controller (SPI)" >> depends on MFD_CROS_EC && SPI >> diff --git a/drivers/platform/chrome/Makefile >> b/drivers/platform/chrome/Makefile >> index cd591bf..4efe102 100644 >> --- a/drivers/platform/chrome/Makefile >> +++ b/drivers/platform/chrome/Makefile >> @@ -7,6 +7,7 @@ cros_ec_ctl-objs:= cros_ec_sysfs.o >> cros_ec_lightbar.o \ >>cros_ec_vbc.o cros_ec_debugfs.o >> obj-$(CONFIG_CROS_EC_CTL) += cros_ec_ctl.o >> obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o >> +obj-$(CONFIG_CROS_EC_ISHTP)+= cros_ec_ishtp.o >> obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o >> cros_ec_lpcs-objs := cros_ec_lpc.o cros_ec_lpc_reg.o >> cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o >> diff --git a/drivers/platform/chrome/cros_ec_ishtp.c >> b/drivers/platform/chrome/cros_ec_ishtp.c >> new file mode 100644 >> index 000..b1d19c4 >> --- /dev/null >> +++ b/drivers/platform/chrome/cros_ec_ishtp.c >> @@ -0,0 +1,765 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * ISHTP client driver for talking to the Chrome OS EC firmware running >> + * on Intel Integrated Sensor Hub (ISH) using the ISH Transport protocol >> + * (ISH-TP). >> + * >> + * Copyright (c) 2019, Intel Corporation. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + I think that this patch depends on another patchset that's in linux-next but diddn't land yet to mainline. Do you know if the dependencies are queued for next merge window? Can you provide the exact patches that this patch depends on? Thanks, Enric >> +/* >> + * ISH TX/RX ring buffer pool size >> + * >> + * The AP->ISH messages and corresponding ISH->AP responses are >> + * serialized. We need 1 TX and 1 RX buffer for these. >> + * >> + * The MKBP ISH->AP events are serialized. We need one additional RX >> + * buffer for them. >> + */ >> +#define CROS_ISH_CL_TX_RING_SIZE 8 >> +#define CROS_ISH_CL_RX_RING_SIZE 8 >> + >> +/* ISH CrOS EC Host Commands */ >> +enum
Re: your mail
Was this supposed to be patch 6/5 of your previous series?
On Thu, Apr 11, 2019 at 04:05:36PM +1000, Nicholas Piggin wrote:
> Date: Tue, 9 Apr 2019 20:23:16 +1000
> Subject: [PATCH] kernel/sched: run nohz idle load balancer on HK_FLAG_MISC
> CPUs
>
> The nohz idle balancer runs on the lowest idle CPU. This can
> interfere with isolated CPUs, so confine it to HK_FLAG_MISC
> housekeeping CPUs.
>
> HK_FLAG_SCHED is not used for this because it is not set anywhere
> at the moment. This could be folded into HK_FLAG_SCHED once that
> option is fixed.
>
> The problem was observed with increased jitter on an application
> running on CPU0, caused by nohz idle load balancing being run on
> CPU1 (an SMT sibling).
>
> Signed-off-by: Nicholas Piggin
> ---
> kernel/sched/fair.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index fdab7eb6f351..d29ca323214d 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -9522,22 +9522,26 @@ static inline int on_null_domain(struct rq *rq)
> * - When one of the busy CPUs notice that there may be an idle rebalancing
> * needed, they will kick the idle load balancer, which then does idle
> * load balancing for all the idle CPUs.
> + * - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set
> + * anywhere yet.
> */
>
> static inline int find_new_ilb(void)
> {
> - int ilb = cpumask_first(nohz.idle_cpus_mask);
> + int ilb;
>
> - if (ilb < nr_cpu_ids && idle_cpu(ilb))
> - return ilb;
> + for_each_cpu_and(ilb, nohz.idle_cpus_mask,
> + housekeeping_cpumask(HK_FLAG_MISC)) {
> + if (idle_cpu(ilb))
> + return ilb;
> + }
>
> return nr_cpu_ids;
> }
>
> /*
> - * Kick a CPU to do the nohz balancing, if it is time for it. We pick the
> - * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle
> - * CPU (if there is one).
> + * Kick a CPU to do the nohz balancing, if it is time for it. We pick any
> + * idle CPU in the HK_FLAG_MISC housekeeping set (if there is one).
> */
> static void kick_ilb(unsigned int flags)
> {
> --
> 2.20.1
>
Re: [RFC 0/2] opportunistic memory reclaim of a killed process
On Wed 10-04-19 18:43:51, Suren Baghdasaryan wrote: [...] > Proposed solution uses existing oom-reaper thread to increase memory > reclaim rate of a killed process and to make this rate more deterministic. > By no means the proposed solution is considered the best and was chosen > because it was simple to implement and allowed for test data collection. > The downside of this solution is that it requires additional “expedite” > hint for something which has to be fast in all cases. Would be great to > find a way that does not require additional hints. I have to say I do not like this much. It is abusing an implementation detail of the OOM implementation and makes it an official API. Also there are some non trivial assumptions to be fullfilled to use the current oom_reaper. First of all all the process groups that share the address space have to be killed. How do you want to guarantee/implement that with a simply kill to a thread/process group? > Other possible approaches include: > - Implementing a dedicated syscall to perform opportunistic reclaim in the > context of the process waiting for the victim’s death. A natural boost > bonus occurs if the waiting process has high or RT priority and is not > limited by cpuset cgroup in its CPU choices. > - Implement a mechanism that would perform opportunistic reclaim if it’s > possible unconditionally (similar to checks in task_will_free_mem()). > - Implement opportunistic reclaim that uses shrinker interface, PSI or > other memory pressure indications as a hint to engage. I would question whether we really need this at all? Relying on the exit speed sounds like a fundamental design problem of anything that relies on it. Sure task exit might be slow, but async mm tear down is just a mere optimization this is not guaranteed to really help in speading things up. OOM killer uses it as a guarantee for a forward progress in a finite time rather than as soon as possible. -- Michal Hocko SUSE Labs
Re: [PATCH] MAINTAINERS: Add section for MediaTek MMC/SD/SDIO driver
On Thu, 11 Apr 2019 at 12:42, Chaotian Jing wrote: > > On Thu, 2019-04-11 at 11:49 +0200, Ulf Hansson wrote: > > Chaotian, > > > > On Mon, 25 Mar 2019 at 13:24, Ulf Hansson wrote: > > > > > > Cc: Chaotian Jing > > > Signed-off-by: Ulf Hansson > > > --- > > > MAINTAINERS | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > > index 3e5a5d263f29..b43e563b4c95 100644 > > > --- a/MAINTAINERS > > > +++ b/MAINTAINERS > > > @@ -9775,6 +9775,12 @@ F: drivers/media/platform/mtk-vpu/ > > > F: Documentation/devicetree/bindings/media/mediatek-vcodec.txt > > > F: Documentation/devicetree/bindings/media/mediatek-vpu.txt > > > > > > +MEDIATEK MMC/SD/SDIO DRIVER > > > +M: Chaotian Jing > > > +S: Maintained > > > +F: drivers/mmc/host/mtk-sd.c > > > +F: Documentation/devicetree/bindings/mmc/mtk-sd.txt > > > + > > > > Are you fine with this, or do you have any other guys at your side > > that can help with reviewing patches for the mtk-sd driver? > > > Yes, It's fine for me. > Thx! Great! I consider that as ack and have applied the patch. Thanks and kind regards Uffe
Re: [PATCH 4/4] locking/lockdep: Test all incompatible scenario at once in check_irq_usage()
On Wed, Apr 10, 2019 at 04:28:48AM +0200, Frederic Weisbecker wrote:
> Should I re-issue the set or you do the changes?
I've made it like so; does that work? In particular, do the comments
make sense? It is always hard to write these things down.
---
Subject: locking/lockdep: Test all incompatible scenario at once in
check_irq_usage()
From: Frederic Weisbecker
Date: Tue, 2 Apr 2019 18:02:44 +0200
check_prev_add_irq() tests all incompatible scenarios one after the
other while adding a lock (@next) to a tree dependency (@prev):
LOCK_USED_IN_HARDIRQ vs LOCK_ENABLED_HARDIRQ
LOCK_USED_IN_HARDIRQ_READ vs LOCK_ENABLED_HARDIRQ
LOCK_USED_IN_SOFTIRQ vs LOCK_ENABLED_SOFTIRQ
LOCK_USED_IN_SOFTIRQ_READ vs LOCK_ENABLED_SOFTIRQ
Also for these four scenarios, we must at least iterate the @prev
backward dependency. Then if it matches the relevant LOCK_USED_* bit,
we must also iterate the @next forward dependency.
Therefore in the best case we iterate 4 times, in the worst case 8 times.
A different approach can let us divide the number of branch iterations
by 4:
1) Iterate through @prev backward dependencies and accumulate all the IRQ
uses in a single mask. In the best case where the current lock hasn't
been used in IRQ, we stop here.
2) Iterate through @next forward dependencies and try to find a lock
whose usage is exclusive to the accumulated usages gathered in the
previous step. If we find one (call it @lockA), we have found an
incompatible use, otherwise we stop here. Only bad locking scenario
go further. So a sane verification stop here.
3) Iterate again through @prev backward dependency and find the lock
whose usage matches @lockA in term of incompatibility. Call that
lock @lockB.
4) Report the incompatible usages of @lockA and @lockB
If no incompatible use is found, the verification never goes beyond
step 2 which means at most two iterations.
The following compares the execution measurements of the function
check_prev_add_irq():
Number of calls | Avg (ns) | Stdev (ns) | Total time (ns)
Mainline 8452| 2652 |11962 |22415143
This patch 8452| 1518 | 7090 |12835602
Cc: Ingo Molnar
Signed-off-by: Frederic Weisbecker
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20190402160244.32434-5-frede...@kernel.org
---
kernel/locking/lockdep.c | 226 ++---
kernel/locking/lockdep_internals.h |6
2 files changed, 165 insertions(+), 67 deletions(-)
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1676,6 +1676,14 @@ check_redundant(struct lock_list *root,
}
#if defined(CONFIG_TRACE_IRQFLAGS) && defined(CONFIG_PROVE_LOCKING)
+
+static inline int usage_accumulate(struct lock_list *entry, void *mask)
+{
+ *(unsigned long *)mask |= entry->class->usage_mask;
+
+ return 0;
+}
+
/*
* Forwards and backwards subgraph searching, for the purposes of
* proving that two subgraphs can be connected by a new dependency
@@ -1687,8 +1695,6 @@ static inline int usage_match(struct loc
return entry->class->usage_mask & *(unsigned long *)mask;
}
-
-
/*
* Find a node in the forwards-direction dependency sub-graph starting
* at @root->class that matches @bit.
@@ -1922,39 +1928,6 @@ print_bad_irq_dependency(struct task_str
return 0;
}
-static int
-check_usage(struct task_struct *curr, struct held_lock *prev,
- struct held_lock *next, enum lock_usage_bit bit_backwards,
- enum lock_usage_bit bit_forwards, const char *irqclass)
-{
- int ret;
- struct lock_list this, that;
- struct lock_list *uninitialized_var(target_entry);
- struct lock_list *uninitialized_var(target_entry1);
-
- this.parent = NULL;
-
- this.class = hlock_class(prev);
- ret = find_usage_backwards(, lock_flag(bit_backwards),
_entry);
- if (ret < 0)
- return print_bfs_bug(ret);
- if (ret == 1)
- return ret;
-
- that.parent = NULL;
- that.class = hlock_class(next);
- ret = find_usage_forwards(, lock_flag(bit_forwards),
_entry1);
- if (ret < 0)
- return print_bfs_bug(ret);
- if (ret == 1)
- return ret;
-
- return print_bad_irq_dependency(curr, , ,
- target_entry, target_entry1,
- prev, next,
- bit_backwards, bit_forwards, irqclass);
-}
-
static const char *state_names[] = {
#define LOCKDEP_STATE(__STATE) \
__stringify(__STATE),
@@ -1977,6 +1950,13 @@ static inline const char *state_name(enu
return state_names[bit >> LOCK_USAGE_DIR_MASK];
}
+/*
+ * The bit number is encoded like:
+ *
+ * bit0: 0 exclusive, 1 read lock
+ * bit1: 0
Re: [PATCH v6] mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
On Thu, 11 Apr 2019 at 11:00, Faiz Abbas wrote:
>
> commit 5b0d62108b46 ("mmc: sdhci-omap: Add platform specific reset
> callback") skips data resets during tuning operation. Because of this,
> a data error or data finish interrupt might still arrive after a command
> error has been handled and the mrq ended. This ends up with a "mmc0: Got
> data interrupt 0x0002 even though no data operation was in progress"
> error message.
>
> Fix this by adding a platform specific callback for sdhci_irq. Mark the
> mrq as a failure but wait for a data interrupt instead of calling
> finish_mrq().
>
> Fixes: 5b0d62108b46 ("mmc: sdhci-omap: Add platform specific reset
> callback")
> Signed-off-by: Faiz Abbas
> Acked-by: Adrian Hunter
Applied for fixes and by adding a stable tag, thanks!
Kind regards
Uffe
> ---
>
> Tested with 100 times boot tests on dra71x-evm, dra72x-evm and
> dra7xx-evm.
>
> v6:
> Changed return value to u32 to fix the build warning.
>
> v5:
> Drop patch 1 and replace call to sdhci_finish_command() with
> host->cmd = NULL
>
> v4:
> Fixed commit description for patch 1.
> Added SDHCI_INT_TIMEOUT to CMD_ERR_MASK in patch 2.
>
> v3:
> Removed the command error specific callback and using the already
> existing sdhci_irq callback instead. No measurable drop in performance.
>
> v2:
> Added EXPORT_SYMBOL_GPL for sdhci_cmd_err and sdhci_send_command to fix
> errors when built as module.
>
> drivers/mmc/host/sdhci-omap.c | 38 +++
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> index 5bbed477c9b1..9f20fff9781b 100644
> --- a/drivers/mmc/host/sdhci-omap.c
> +++ b/drivers/mmc/host/sdhci-omap.c
> @@ -797,6 +797,43 @@ void sdhci_omap_reset(struct sdhci_host *host, u8 mask)
> sdhci_reset(host, mask);
> }
>
> +#define CMD_ERR_MASK (SDHCI_INT_CRC | SDHCI_INT_END_BIT | SDHCI_INT_INDEX |\
> + SDHCI_INT_TIMEOUT)
> +#define CMD_MASK (CMD_ERR_MASK | SDHCI_INT_RESPONSE)
> +
> +static u32 sdhci_omap_irq(struct sdhci_host *host, u32 intmask)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
> +
> + if (omap_host->is_tuning && host->cmd && !host->data_early &&
> + (intmask & CMD_ERR_MASK)) {
> +
> + /*
> +* Since we are not resetting data lines during tuning
> +* operation, data error or data complete interrupts
> +* might still arrive. Mark this request as a failure
> +* but still wait for the data interrupt
> +*/
> + if (intmask & SDHCI_INT_TIMEOUT)
> + host->cmd->error = -ETIMEDOUT;
> + else
> + host->cmd->error = -EILSEQ;
> +
> + host->cmd = NULL;
> +
> + /*
> +* Sometimes command error interrupts and command complete
> +* interrupt will arrive together. Clear all command related
> +* interrupts here.
> +*/
> + sdhci_writel(host, intmask & CMD_MASK, SDHCI_INT_STATUS);
> + intmask &= ~CMD_MASK;
> + }
> +
> + return intmask;
> +}
> +
> static struct sdhci_ops sdhci_omap_ops = {
> .set_clock = sdhci_omap_set_clock,
> .set_power = sdhci_omap_set_power,
> @@ -807,6 +844,7 @@ static struct sdhci_ops sdhci_omap_ops = {
> .platform_send_init_74_clocks = sdhci_omap_init_74_clocks,
> .reset = sdhci_omap_reset,
> .set_uhs_signaling = sdhci_omap_set_uhs_signaling,
> + .irq = sdhci_omap_irq,
> };
>
> static int sdhci_omap_set_capabilities(struct sdhci_omap_host *omap_host)
> --
> 2.19.2
>
Re: [PATCH v2] mmc: mtk-sd: check for valid optional memory resource
On Wed, 3 Apr 2019 at 21:31, Fabien Parent wrote:
>
> 'top_base' memory region is optional. Check that the resource is valid
> before using it. This avoid getting a "invalid resource" error message
> printed by the kernel.
>
> Signed-off-by: Fabien Parent
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> V2:
> Fix invalid condition: check against 'res' variable instead of 'ret'.
>
> ---
> drivers/mmc/host/mtk-sd.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 833ef0590af8..61bf8704491c 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -2123,9 +2123,11 @@ static int msdc_drv_probe(struct platform_device *pdev)
> }
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - host->top_base = devm_ioremap_resource(>dev, res);
> - if (IS_ERR(host->top_base))
> - host->top_base = NULL;
> + if (res) {
> + host->top_base = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(host->top_base))
> + host->top_base = NULL;
> + }
>
> ret = mmc_regulator_get_supply(mmc);
> if (ret)
> --
> 2.20.1
>
Re: [PATCH v2] mmc: sdhci_am654: Clear HISPD_ENA in some lower speed modes
On Mon, 1 Apr 2019 at 14:58, Faiz Abbas wrote:
>
> According to the AM654x Data Manual[1], the setup timing in lower speed
> modes can only be met if the controller uses a falling edge data launch.
>
> To ensure this, the HIGH_SPEED_ENA (HOST_CONTROL[2]) bit should be
> cleared in default speed, SD high speed, MMC high speed, SDR12 and SDR25
> speed modes.
>
> Use the sdhci writeb callback to implement this condition.
>
> [1] http://www.ti.com/lit/gpn/am6546 Section 5.10.5.16.1
>
> Signed-off-by: Faiz Abbas
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> v2: Dropped QUIRK in favour of writeb callback
>
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci_am654.c | 22 ++
> 2 files changed, 23 insertions(+)
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 28fcd8f580a1..6379fba8b122 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -993,6 +993,7 @@ config MMC_SDHCI_OMAP
> config MMC_SDHCI_AM654
> tristate "Support for the SDHCI Controller in TI's AM654 SOCs"
> depends on MMC_SDHCI_PLTFM && OF
> + select MMC_SDHCI_IO_ACCESSORS
> help
> This selects the Secure Digital Host Controller Interface (SDHCI)
> support present in TI's AM654 SOCs. The controller supports
> diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
> index eea183e90f1b..a91c0b45c48d 100644
> --- a/drivers/mmc/host/sdhci_am654.c
> +++ b/drivers/mmc/host/sdhci_am654.c
> @@ -158,6 +158,27 @@ static void sdhci_am654_set_power(struct sdhci_host
> *host, unsigned char mode,
> sdhci_set_power_noreg(host, mode, vdd);
> }
>
> +static void sdhci_am654_write_b(struct sdhci_host *host, u8 val, int reg)
> +{
> + unsigned char timing = host->mmc->ios.timing;
> +
> + if (reg == SDHCI_HOST_CONTROL) {
> + switch (timing) {
> + /*
> +* According to the data manual, HISPD bit
> +* should not be set in these speed modes.
> +*/
> + case MMC_TIMING_SD_HS:
> + case MMC_TIMING_MMC_HS:
> + case MMC_TIMING_UHS_SDR12:
> + case MMC_TIMING_UHS_SDR25:
> + val &= ~SDHCI_CTRL_HISPD;
> + }
> + }
> +
> + writeb(val, host->ioaddr + reg);
> +}
> +
> static struct sdhci_ops sdhci_am654_ops = {
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
> @@ -165,6 +186,7 @@ static struct sdhci_ops sdhci_am654_ops = {
> .set_bus_width = sdhci_set_bus_width,
> .set_power = sdhci_am654_set_power,
> .set_clock = sdhci_am654_set_clock,
> + .write_b = sdhci_am654_write_b,
> .reset = sdhci_reset,
> };
>
> --
> 2.19.2
>
Re: [PATCH] MAINTAINERS: Add section for MediaTek MMC/SD/SDIO driver
On Thu, 2019-04-11 at 11:49 +0200, Ulf Hansson wrote: > Chaotian, > > On Mon, 25 Mar 2019 at 13:24, Ulf Hansson wrote: > > > > Cc: Chaotian Jing > > Signed-off-by: Ulf Hansson > > --- > > MAINTAINERS | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 3e5a5d263f29..b43e563b4c95 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -9775,6 +9775,12 @@ F: drivers/media/platform/mtk-vpu/ > > F: Documentation/devicetree/bindings/media/mediatek-vcodec.txt > > F: Documentation/devicetree/bindings/media/mediatek-vpu.txt > > > > +MEDIATEK MMC/SD/SDIO DRIVER > > +M: Chaotian Jing > > +S: Maintained > > +F: drivers/mmc/host/mtk-sd.c > > +F: Documentation/devicetree/bindings/mmc/mtk-sd.txt > > + > > Are you fine with this, or do you have any other guys at your side > that can help with reviewing patches for the mtk-sd driver? > Yes, It's fine for me. Thx! > [...] > > Kind regards > Uffe
Re: [PATCH 2/2] spi: pxa2xx: use a module softdep for dw_dmac
On Thu, Apr 11, 2019 at 07:14:06AM +, Flavio Suligoi wrote:
> > Right, yes - that analysis seems correct. The interfaces seem a bit
> > weird here but fixing them looks like the most complete and robust fix.
> Ok Mark, I'll fix this problem as soon as I can, using EPROBE_DEFER.
> For now, in my application, I use the patch that I already sent,
> with the "softdep" workaround:
> MODULE_SOFTDEP("pre: dw_dmac");
> I tested it a lot, with more than 2000 cold reboot (automatic
> switch on/off using a controlled power supply) and it always worked good.
Right, and to be clear that patch is good and useful independently of
the deferred probe fix so assuming nothing else comes up in review I'll
apply it.
signature.asc
Description: PGP signature
Re: [PATCH RFC] clk: ux500: add range to usleep_range
On Thu, Apr 11, 2019 at 11:36:45AM +0200, Ulf Hansson wrote: > On Sun, 7 Apr 2019 at 05:13, Nicholas Mc Guire wrote: > > > > Providing a range for usleep_range() allows the hrtimer subsystem to > > coalesce timers - the delay is runtime configurable so a factor 2 > > is taken to provide the range. > > > > Signed-off-by: Nicholas Mc Guire > > --- > > > > Problem located with an experimental coccinelle script > > > > Q: Basically usleep_range() with min == max never makes much sense notably > >in non-atomic context. If the factor of 2 is tolerable or a fixed > >offset of e.g. 1000 would be more suitable is not clear to me - maybe > >someone familiar with that driver can clarify this. > > > > Patch was compile tested with: u8500_defconfig (implies COMMON_CLK=y) > > (with some sparse warnings about not implemented system calls) > > > > Patch is against 5.1-rc3 (localversion-next is next=20190405) > > > > drivers/clk/ux500/clk-sysctrl.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/clk/ux500/clk-sysctrl.c > > b/drivers/clk/ux500/clk-sysctrl.c > > index 7c0403b..a1fa3fb 100644 > > --- a/drivers/clk/ux500/clk-sysctrl.c > > +++ b/drivers/clk/ux500/clk-sysctrl.c > > @@ -42,7 +42,7 @@ static int clk_sysctrl_prepare(struct clk_hw *hw) > > clk->reg_bits[0]); > > > > if (!ret && clk->enable_delay_us) > > - usleep_range(clk->enable_delay_us, clk->enable_delay_us); > > + usleep_range(clk->enable_delay_us, clk->enable_delay_us*2); > > The range being used is actually in ms, so not sure we actually need > to double it for the range. > > How about adding ~25% instead, along the lines of below: > usleep_range(clk->enable_delay_us, clk->enable_delay_us + > (clk->enable_delay_us >> 2)); > that would be perfectly sufficient for hrtimers - if the range is in ms - so I´ll send out a V2 shortly. thx! hofrat
Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited process killing
Cc: Oleg too
On Thu, Apr 11, 2019 at 12:30:18PM +0200, Christian Brauner wrote:
> On Wed, Apr 10, 2019 at 06:43:53PM -0700, Suren Baghdasaryan wrote:
> > Add new SS_EXPEDITE flag to be used when sending SIGKILL via
> > pidfd_send_signal() syscall to allow expedited memory reclaim of the
> > victim process. The usage of this flag is currently limited to SIGKILL
> > signal and only to privileged users.
> >
> > Signed-off-by: Suren Baghdasaryan
> > ---
> > include/linux/sched/signal.h | 3 ++-
> > include/linux/signal.h | 11 ++-
> > ipc/mqueue.c | 2 +-
> > kernel/signal.c | 37
> > kernel/time/itimer.c | 2 +-
> > 5 files changed, 43 insertions(+), 12 deletions(-)
> >
> > diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
> > index e412c092c1e8..8a227633a058 100644
> > --- a/include/linux/sched/signal.h
> > +++ b/include/linux/sched/signal.h
> > @@ -327,7 +327,8 @@ extern int send_sig_info(int, struct kernel_siginfo *,
> > struct task_struct *);
> > extern void force_sigsegv(int sig, struct task_struct *p);
> > extern int force_sig_info(int, struct kernel_siginfo *, struct task_struct
> > *);
> > extern int __kill_pgrp_info(int sig, struct kernel_siginfo *info, struct
> > pid *pgrp);
> > -extern int kill_pid_info(int sig, struct kernel_siginfo *info, struct pid
> > *pid);
> > +extern int kill_pid_info(int sig, struct kernel_siginfo *info, struct pid
> > *pid,
> > + bool expedite);
> > extern int kill_pid_info_as_cred(int, struct kernel_siginfo *, struct pid
> > *,
> > const struct cred *);
> > extern int kill_pgrp(struct pid *pid, int sig, int priv);
> > diff --git a/include/linux/signal.h b/include/linux/signal.h
> > index 9702016734b1..34b7852aa4a0 100644
> > --- a/include/linux/signal.h
> > +++ b/include/linux/signal.h
> > @@ -446,8 +446,17 @@ int __save_altstack(stack_t __user *, unsigned long);
> > } while (0);
> >
> > #ifdef CONFIG_PROC_FS
> > +
> > +/*
> > + * SS_FLAGS values used in pidfd_send_signal:
> > + *
> > + * SS_EXPEDITE indicates desire to expedite the operation.
> > + */
> > +#define SS_EXPEDITE0x0001
>
> Does this make sense as an SS_* flag?
> How does this relate to the signal stack?
> Is there any intention to ever use this flag with stack_t?
>
> New flags should be PIDFD_SIGNAL_*. (E.g. the thread flag will be
> PIDFD_SIGNAL_THREAD.)
> And since this is exposed to userspace in contrast to the mm internal
> naming it should be something more easily understandable like
> PIDFD_SIGNAL_MM_RECLAIM{_FASTER} or something.
>
> > +
> > struct seq_file;
> > extern void render_sigset_t(struct seq_file *, const char *, sigset_t *);
> > -#endif
> > +
> > +#endif /* CONFIG_PROC_FS */
> >
> > #endif /* _LINUX_SIGNAL_H */
> > diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> > index aea30530c472..27c66296e08e 100644
> > --- a/ipc/mqueue.c
> > +++ b/ipc/mqueue.c
> > @@ -720,7 +720,7 @@ static void __do_notify(struct mqueue_inode_info *info)
> > rcu_read_unlock();
> >
> > kill_pid_info(info->notify.sigev_signo,
> > - _i, info->notify_owner);
> > + _i, info->notify_owner, false);
> > break;
> > case SIGEV_THREAD:
> > set_cookie(info->notify_cookie, NOTIFY_WOKENUP);
> > diff --git a/kernel/signal.c b/kernel/signal.c
> > index f98448cf2def..02ed4332d17c 100644
> > --- a/kernel/signal.c
> > +++ b/kernel/signal.c
> > @@ -43,6 +43,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #define CREATE_TRACE_POINTS
> > #include
> > @@ -1394,7 +1395,8 @@ int __kill_pgrp_info(int sig, struct kernel_siginfo
> > *info, struct pid *pgrp)
> > return success ? 0 : retval;
> > }
> >
> > -int kill_pid_info(int sig, struct kernel_siginfo *info, struct pid *pid)
> > +int kill_pid_info(int sig, struct kernel_siginfo *info, struct pid *pid,
> > + bool expedite)
> > {
> > int error = -ESRCH;
> > struct task_struct *p;
> > @@ -1402,8 +1404,17 @@ int kill_pid_info(int sig, struct kernel_siginfo
> > *info, struct pid *pid)
> > for (;;) {
> > rcu_read_lock();
> > p = pid_task(pid, PIDTYPE_PID);
> > - if (p)
> > + if (p) {
> > error = group_send_sig_info(sig, info, p, PIDTYPE_TGID);
> > +
> > + /*
> > +* Ignore expedite_reclaim return value, it is best
> > +* effort only.
> > +*/
> > + if (!error && expedite)
> > + expedite_reclaim(p);
>
> SIGKILL will take the whole thread group down so the reclaim should make
> sense here.
>
> > + }
> > +
> > rcu_read_unlock();
> > if (likely(!p || error
[RESEND][PATCH v2] firmware/psci: add support for SYSTEM_RESET2
PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
where the semantics are described by the PSCI specification itself as
well as vendor-specific resets. Currently only system warm reset
semantics is defined as part of architectural resets by the specification.
This patch implements support for SYSTEM_RESET2 by making using of
reboot_mode passed by the reboot infrastructure in the kernel.
Cc: Mark Rutland
Cc: Lorenzo Pieralisi
Signed-off-by: Sudeep Holla
---
drivers/firmware/psci.c | 21 +
include/uapi/linux/psci.h | 2 ++
2 files changed, 23 insertions(+)
Resending [1] based on the request. I hope to get some testing this time.
Last time Xilinx asked multiple times but never got any review or testing
https://lore.kernel.org/lkml/1525257003-8608-1-git-send-email-sudeep.ho...@arm.com/
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index c80ec1d03274..91748725534e 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -88,6 +88,7 @@ static u32 psci_function_id[PSCI_FN_MAX];
PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)
static u32 psci_cpu_suspend_feature;
+static bool psci_system_reset2_supported;
static inline bool psci_has_ext_power_state(void)
{
@@ -253,6 +254,15 @@ static int get_set_conduit_method(struct device_node *np)
static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
{
+ if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
+ psci_system_reset2_supported)
+ /*
+* reset_type[31] = 0 (architectural)
+* reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
+* cookie = 0 (ignored by the implementation)
+*/
+ invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
+
invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
}
@@ -451,6 +461,16 @@ static const struct platform_suspend_ops psci_suspend_ops
= {
.enter = psci_system_suspend_enter,
};
+static void __init psci_init_system_reset2(void)
+{
+ int ret;
+
+ ret = psci_features(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2));
+
+ if (ret != PSCI_RET_NOT_SUPPORTED)
+ psci_system_reset2_supported = true;
+}
+
static void __init psci_init_system_suspend(void)
{
int ret;
@@ -588,6 +608,7 @@ static int __init psci_probe(void)
psci_init_smccc();
psci_init_cpu_suspend();
psci_init_system_suspend();
+ psci_init_system_reset2();
}
return 0;
diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
index b3bcabe380da..5b0ba0062541 100644
--- a/include/uapi/linux/psci.h
+++ b/include/uapi/linux/psci.h
@@ -49,8 +49,10 @@
#define PSCI_1_0_FN_PSCI_FEATURES PSCI_0_2_FN(10)
#define PSCI_1_0_FN_SYSTEM_SUSPEND PSCI_0_2_FN(14)
+#define PSCI_1_1_FN_SYSTEM_RESET2 PSCI_0_2_FN(18)
#define PSCI_1_0_FN64_SYSTEM_SUSPEND PSCI_0_2_FN64(14)
+#define PSCI_1_1_FN64_SYSTEM_RESET2PSCI_0_2_FN64(18)
/* PSCI v0.2 power state encoding for CPU_SUSPEND function */
#define PSCI_0_2_POWER_STATE_ID_MASK 0x
--
2.17.1
[PATCH 3/3] x86/vdso: Add support for CLOCK_MONOTONIC_RAW in the vDSO
This is particularly useful for Wine which needs to implement Win32
API clock functions whose values do not get adjusted by adjtimex().
Cc: Thomas Gleixner
Cc: Andy Lutomirski
Signed-off-by: Huw Davies
---
arch/x86/entry/vsyscall/vsyscall_gtod.c | 6 ++
arch/x86/include/asm/vgtod.h| 3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/vsyscall/vsyscall_gtod.c
b/arch/x86/entry/vsyscall/vsyscall_gtod.c
index ddc6a71df87c..fe3458caf301 100644
--- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
+++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
@@ -68,6 +68,12 @@ void update_vsyscall(struct timekeeper *tk)
base->mult = tk->tkr_mono.mult;
base->shift = tk->tkr_mono.shift;
+ base = >basetime[CLOCK_MONOTONIC_RAW];
+ base->sec = tk->raw_sec;
+ base->nsec = tk->tkr_raw.xtime_nsec;
+ base->mult = tk->tkr_raw.mult;
+ base->shift = tk->tkr_raw.shift;
+
base = >basetime[CLOCK_REALTIME_COARSE];
base->sec = tk->xtime_sec;
base->nsec = tk->tkr_mono.xtime_nsec >> tk->tkr_mono.shift;
diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index ae0d76491595..0b76ba884e25 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -30,7 +30,8 @@ struct vgtod_ts {
};
#define VGTOD_BASES(CLOCK_TAI + 1)
-#define VGTOD_HRES (BIT(CLOCK_REALTIME) | BIT(CLOCK_MONOTONIC) |
BIT(CLOCK_TAI))
+#define VGTOD_HRES (BIT(CLOCK_REALTIME) | BIT(CLOCK_MONOTONIC) | \
+ BIT(CLOCK_MONOTONIC_RAW) | BIT(CLOCK_TAI))
#define VGTOD_COARSE (BIT(CLOCK_REALTIME_COARSE) |
BIT(CLOCK_MONOTONIC_COARSE))
/*
--
2.17.1
Re: [RFC 2/2] signal: extend pidfd_send_signal() to allow expedited process killing
On Wed, Apr 10, 2019 at 06:43:53PM -0700, Suren Baghdasaryan wrote:
> Add new SS_EXPEDITE flag to be used when sending SIGKILL via
> pidfd_send_signal() syscall to allow expedited memory reclaim of the
> victim process. The usage of this flag is currently limited to SIGKILL
> signal and only to privileged users.
>
> Signed-off-by: Suren Baghdasaryan
> ---
> include/linux/sched/signal.h | 3 ++-
> include/linux/signal.h | 11 ++-
> ipc/mqueue.c | 2 +-
> kernel/signal.c | 37
> kernel/time/itimer.c | 2 +-
> 5 files changed, 43 insertions(+), 12 deletions(-)
>
> diff --git a/include/linux/sched/signal.h b/include/linux/sched/signal.h
> index e412c092c1e8..8a227633a058 100644
> --- a/include/linux/sched/signal.h
> +++ b/include/linux/sched/signal.h
> @@ -327,7 +327,8 @@ extern int send_sig_info(int, struct kernel_siginfo *,
> struct task_struct *);
> extern void force_sigsegv(int sig, struct task_struct *p);
> extern int force_sig_info(int, struct kernel_siginfo *, struct task_struct
> *);
> extern int __kill_pgrp_info(int sig, struct kernel_siginfo *info, struct pid
> *pgrp);
> -extern int kill_pid_info(int sig, struct kernel_siginfo *info, struct pid
> *pid);
> +extern int kill_pid_info(int sig, struct kernel_siginfo *info, struct pid
> *pid,
> + bool expedite);
> extern int kill_pid_info_as_cred(int, struct kernel_siginfo *, struct pid *,
> const struct cred *);
> extern int kill_pgrp(struct pid *pid, int sig, int priv);
> diff --git a/include/linux/signal.h b/include/linux/signal.h
> index 9702016734b1..34b7852aa4a0 100644
> --- a/include/linux/signal.h
> +++ b/include/linux/signal.h
> @@ -446,8 +446,17 @@ int __save_altstack(stack_t __user *, unsigned long);
> } while (0);
>
> #ifdef CONFIG_PROC_FS
> +
> +/*
> + * SS_FLAGS values used in pidfd_send_signal:
> + *
> + * SS_EXPEDITE indicates desire to expedite the operation.
> + */
> +#define SS_EXPEDITE 0x0001
Does this make sense as an SS_* flag?
How does this relate to the signal stack?
Is there any intention to ever use this flag with stack_t?
New flags should be PIDFD_SIGNAL_*. (E.g. the thread flag will be
PIDFD_SIGNAL_THREAD.)
And since this is exposed to userspace in contrast to the mm internal
naming it should be something more easily understandable like
PIDFD_SIGNAL_MM_RECLAIM{_FASTER} or something.
> +
> struct seq_file;
> extern void render_sigset_t(struct seq_file *, const char *, sigset_t *);
> -#endif
> +
> +#endif /* CONFIG_PROC_FS */
>
> #endif /* _LINUX_SIGNAL_H */
> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> index aea30530c472..27c66296e08e 100644
> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -720,7 +720,7 @@ static void __do_notify(struct mqueue_inode_info *info)
> rcu_read_unlock();
>
> kill_pid_info(info->notify.sigev_signo,
> - _i, info->notify_owner);
> + _i, info->notify_owner, false);
> break;
> case SIGEV_THREAD:
> set_cookie(info->notify_cookie, NOTIFY_WOKENUP);
> diff --git a/kernel/signal.c b/kernel/signal.c
> index f98448cf2def..02ed4332d17c 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
>
> #define CREATE_TRACE_POINTS
> #include
> @@ -1394,7 +1395,8 @@ int __kill_pgrp_info(int sig, struct kernel_siginfo
> *info, struct pid *pgrp)
> return success ? 0 : retval;
> }
>
> -int kill_pid_info(int sig, struct kernel_siginfo *info, struct pid *pid)
> +int kill_pid_info(int sig, struct kernel_siginfo *info, struct pid *pid,
> + bool expedite)
> {
> int error = -ESRCH;
> struct task_struct *p;
> @@ -1402,8 +1404,17 @@ int kill_pid_info(int sig, struct kernel_siginfo
> *info, struct pid *pid)
> for (;;) {
> rcu_read_lock();
> p = pid_task(pid, PIDTYPE_PID);
> - if (p)
> + if (p) {
> error = group_send_sig_info(sig, info, p, PIDTYPE_TGID);
> +
> + /*
> + * Ignore expedite_reclaim return value, it is best
> + * effort only.
> + */
> + if (!error && expedite)
> + expedite_reclaim(p);
SIGKILL will take the whole thread group down so the reclaim should make
sense here.
> + }
> +
> rcu_read_unlock();
> if (likely(!p || error != -ESRCH))
> return error;
> @@ -1420,7 +1431,7 @@ static int kill_proc_info(int sig, struct
> kernel_siginfo *info, pid_t pid)
> {
> int error;
> rcu_read_lock();
> - error = kill_pid_info(sig, info, find_vpid(pid));
> + error =
[PATCH 1/3] x86/vdso: Remove unused 'mask' member
The 'mask' member of struct vsyscall_gtod_data is unused, so remove
it. Its use was removed in commit a51e996d48ac (x86/vdso: Enforce
64bit clocksource).
Cc: Thomas Gleixner
Cc: Andy Lutomirski
Signed-off-by: Huw Davies
---
arch/x86/entry/vsyscall/vsyscall_gtod.c | 1 -
arch/x86/include/asm/vgtod.h| 1 -
2 files changed, 2 deletions(-)
diff --git a/arch/x86/entry/vsyscall/vsyscall_gtod.c
b/arch/x86/entry/vsyscall/vsyscall_gtod.c
index cfcdba082feb..e4ee83018279 100644
--- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
+++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
@@ -43,7 +43,6 @@ void update_vsyscall(struct timekeeper *tk)
/* copy vsyscall data */
vdata->vclock_mode = vclock_mode;
vdata->cycle_last = tk->tkr_mono.cycle_last;
- vdata->mask = tk->tkr_mono.mask;
vdata->mult = tk->tkr_mono.mult;
vdata->shift= tk->tkr_mono.shift;
diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index 913a133f8e6f..daf69a25e46b 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -40,7 +40,6 @@ struct vsyscall_gtod_data {
int vclock_mode;
u64 cycle_last;
- u64 mask;
u32 mult;
u32 shift;
--
2.17.1
[PATCH 2/3] x86/vdso: Allow clock specific mult and shift values
This will allow clocks with different mult and shift values,
e.g. CLOCK_MONOTONIC_RAW, to be supported in the vDSO.
The coarse clocks do not require these data so the values are not
copied for these clocks.
One could add potential new values of mult and shift alongside the
existing values in struct vsyscall_gtod_data, but it seems more
natural to group them with the actual clock data in the basetime array
at the expense of a few more cycles in update_vsyscall().
Cc: Thomas Gleixner
Cc: Andy Lutomirski
Signed-off-by: Huw Davies
---
arch/x86/entry/vdso/vclock_gettime.c| 4 ++--
arch/x86/entry/vsyscall/vsyscall_gtod.c | 8 ++--
arch/x86/include/asm/vgtod.h| 6 +++---
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/arch/x86/entry/vdso/vclock_gettime.c
b/arch/x86/entry/vdso/vclock_gettime.c
index 007b3fe9d727..a4199b846d77 100644
--- a/arch/x86/entry/vdso/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vclock_gettime.c
@@ -153,8 +153,8 @@ notrace static int do_hres(clockid_t clk, struct timespec
*ts)
if (unlikely((s64)cycles < 0))
return vdso_fallback_gettime(clk, ts);
if (cycles > last)
- ns += (cycles - last) * gtod->mult;
- ns >>= gtod->shift;
+ ns += (cycles - last) * base->mult;
+ ns >>= base->shift;
sec = base->sec;
} while (unlikely(gtod_read_retry(gtod, seq)));
diff --git a/arch/x86/entry/vsyscall/vsyscall_gtod.c
b/arch/x86/entry/vsyscall/vsyscall_gtod.c
index e4ee83018279..ddc6a71df87c 100644
--- a/arch/x86/entry/vsyscall/vsyscall_gtod.c
+++ b/arch/x86/entry/vsyscall/vsyscall_gtod.c
@@ -43,16 +43,18 @@ void update_vsyscall(struct timekeeper *tk)
/* copy vsyscall data */
vdata->vclock_mode = vclock_mode;
vdata->cycle_last = tk->tkr_mono.cycle_last;
- vdata->mult = tk->tkr_mono.mult;
- vdata->shift= tk->tkr_mono.shift;
base = >basetime[CLOCK_REALTIME];
base->sec = tk->xtime_sec;
base->nsec = tk->tkr_mono.xtime_nsec;
+ base->mult = tk->tkr_mono.mult;
+ base->shift = tk->tkr_mono.shift;
base = >basetime[CLOCK_TAI];
base->sec = tk->xtime_sec + (s64)tk->tai_offset;
base->nsec = tk->tkr_mono.xtime_nsec;
+ base->mult = tk->tkr_mono.mult;
+ base->shift = tk->tkr_mono.shift;
base = >basetime[CLOCK_MONOTONIC];
base->sec = tk->xtime_sec + tk->wall_to_monotonic.tv_sec;
@@ -63,6 +65,8 @@ void update_vsyscall(struct timekeeper *tk)
base->sec++;
}
base->nsec = nsec;
+ base->mult = tk->tkr_mono.mult;
+ base->shift = tk->tkr_mono.shift;
base = >basetime[CLOCK_REALTIME_COARSE];
base->sec = tk->xtime_sec;
diff --git a/arch/x86/include/asm/vgtod.h b/arch/x86/include/asm/vgtod.h
index daf69a25e46b..ae0d76491595 100644
--- a/arch/x86/include/asm/vgtod.h
+++ b/arch/x86/include/asm/vgtod.h
@@ -20,11 +20,13 @@ typedef unsigned long gtod_long_t;
* clocks, this encodes the actual time.
*
* To confuse the reader, for high-resolution clocks, nsec is left-shifted
- * by vsyscall_gtod_data.shift.
+ * by shift.
*/
struct vgtod_ts {
u64 sec;
u64 nsec;
+ u32 mult;
+ u32 shift;
};
#define VGTOD_BASES(CLOCK_TAI + 1)
@@ -40,8 +42,6 @@ struct vsyscall_gtod_data {
int vclock_mode;
u64 cycle_last;
- u32 mult;
- u32 shift;
struct vgtod_ts basetime[VGTOD_BASES];
--
2.17.1
[PATCH 0/3] x86/vdso: Add support for CLOCK_MONOTONIC_RAW in the vDSO
This series adds support for the CLOCK_MONOTONIC_RAW clock in the x86 vDSO, thus decreasing its readout cost. This is particularly useful for Wine which needs to implement Win32 API clock functions whose value does not get adjusted with adjtimex(). Cc: Thomas Gleixner Cc: Andy Lutomirski Huw Davies (3): x86/vdso: Remove unused 'mask' member x86/vdso: Allow clock specific mult and shift values x86/vdso: Add support for CLOCK_MONOTONIC_RAW in the vDSO arch/x86/entry/vdso/vclock_gettime.c| 4 ++-- arch/x86/entry/vsyscall/vsyscall_gtod.c | 15 --- arch/x86/include/asm/vgtod.h| 10 +- 3 files changed, 19 insertions(+), 10 deletions(-) -- 2.17.1
Re: [PATCH v7 6/7] platform/chrome: cros_ec: add EC host command support using rpmsg.
Hi,
Missatge de Pi-Hsun Shih del dia dc., 10 d’abr.
2019 a les 9:13:
>
> Hi,
>
> On Thu, Mar 28, 2019 at 7:16 PM Enric Balletbo Serra
> wrote:
> >
> > Hi
> >
> > Thanks for sending this upstream, Some few comments and questions
> > below. Apart from these LGTM.
> >
> > Missatge de Peter Shih del dia dc., 27 de març
> > 2019 a les 6:17:
> > >
> > > From: Pi-Hsun Shih
> > >
> > > Add EC host command support through rpmsg.
> > >
> > > Signed-off-by: Pi-Hsun Shih
> > > ---
> > > ...
> > > diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c
> > > b/drivers/platform/chrome/cros_ec_rpmsg.c
> > > new file mode 100644
> > > index ..2ecae806cfc5
> > > --- /dev/null
> > > +++ b/drivers/platform/chrome/cros_ec_rpmsg.c
> > > ...
> > > +static int cros_ec_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
> > > + int len, void *priv, u32 src)
> > > +{
> > > + struct cros_ec_device *ec_dev = dev_get_drvdata(>dev);
> > > + struct cros_ec_rpmsg *ec_rpmsg = ec_dev->priv;
> > > + struct cros_ec_rpmsg_response *resp;
> > > +
> > > + if (!len) {
> > > + dev_warn(ec_dev->dev, "rpmsg received empty response");
> >
> > Is this is unlikely to happen?
>
> Yes this should not happen unless the firmware is broken. Should I
> change this to `if(unlikely(!len))`, or use dev_err instead ?
>
> >
> > > + return -EINVAL;
> > > + }
> > > +
> > > + resp = data;
> > > + len -= offsetof(struct cros_ec_rpmsg_response, data);
> > > + if (resp->type == HOST_COMMAND_MARK) {
> > > + if (len > ec_dev->din_size) {
> > > + dev_warn(
> > > + ec_dev->dev,
> > > + "received length %d > din_size %d,
> > > truncating",
> > > + len, ec_dev->din_size);
> >
> > How often this warning appears? Should be this a dev_dbg?
>
> This also should not happen unless the firmware is broken, so I think
> it's better to have a warning here when there's something wrong.
>
Ok, fine with me.
> >
> > > + len = ec_dev->din_size;
> > > + }
> > > +
> > > + memcpy(ec_dev->din, resp->data, len);
> > > + complete(_rpmsg->xfer_ack);
> > > + } else if (resp->type == HOST_EVENT_MARK) {
> > > + schedule_work(_rpmsg->host_event_work);
> > > + } else {
> > > + dev_warn(ec_dev->dev, "rpmsg received invalid type = %d",
> > > +resp->type);
> >
> > Is this is unlikely to happen?
>
> Same as above, this should not happen unless the firmware is broken.
>
> >
> > > + return -EINVAL;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int cros_ec_rpmsg_probe(struct rpmsg_device *rpdev)
> > > +{
> > > + struct device *dev = >dev;
> > > + struct cros_ec_device *ec_dev;
> > > + struct cros_ec_rpmsg *ec_rpmsg;
> > > + int ret;
> > > +
> > > + ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
> > > + if (!ec_dev)
> > > + return -ENOMEM;
> > > +
> > > + ec_rpmsg = devm_kzalloc(dev, sizeof(*ec_rpmsg), GFP_KERNEL);
> > > + if (!ec_rpmsg)
> > > + return -ENOMEM;
> > > +
> > > + ec_dev->dev = dev;
> > > + ec_dev->priv = ec_rpmsg;
> > > + ec_dev->cmd_xfer = cros_ec_cmd_xfer_rpmsg;
> > > + ec_dev->pkt_xfer = cros_ec_pkt_xfer_rpmsg;
> > > + ec_dev->phys_name = dev_name(>dev);
> > > + ec_dev->din_size = sizeof(struct ec_host_response) +
> > > + sizeof(struct ec_response_get_protocol_info);
> > > + ec_dev->dout_size = sizeof(struct ec_host_request);
> > > + dev_set_drvdata(dev, ec_dev);
> > > +
> > > + ec_rpmsg->rpdev = rpdev;
> > > + init_completion(_rpmsg->xfer_ack);
> > > + INIT_WORK(_rpmsg->host_event_work,
> > > + cros_ec_rpmsg_host_event_function);
> > > +
> > > + ret = cros_ec_register(ec_dev);
> > > + if (ret) {
> > > + dev_err(dev, "cannot register EC\n");
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> >
> > cros_ec_register returns 0 on success and prints an error message if
> > something went wrong. Remove the above and just do:
> >
> > return cros_ec_register(ec_dev);
> >
>
> Ack, would change this in v7.
>
Will wait for v7.
Thanks,
Enric
> >
> > > +}
> > > +
> > > +static void cros_ec_rpmsg_remove(struct rpmsg_device *rpdev)
> > > +{
> > > + struct cros_ec_device *ec_dev = dev_get_drvdata(>dev);
> > > + struct cros_ec_rpmsg *ec_rpmsg = ec_dev->priv;
> > > +
> > > + cancel_work_sync(_rpmsg->host_event_work);
> > > +}
> > > +
> > > +static const struct of_device_id cros_ec_rpmsg_of_match[] = {
> > > + { .compatible = "google,cros-ec-rpmsg", },
> > > + { }
> > > +};
> > > +MODULE_DEVICE_TABLE(of,
[PATCH v3 1/2] dt-bindings: thermal: al-thermal: Add binding documentation
Add thermal binding documentation for Amazon's Annapurna Labs Thermal
Sensor.
Signed-off-by: Talel Shenhar
Reviewed-by: David Woodhouse
Reviewed-by: Rob Herring
---
.../bindings/thermal/amazon,al-thermal.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
new file mode 100644
index 000..703979d
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
@@ -0,0 +1,33 @@
+Amazon's Annapurna Labs Thermal Sensor
+
+Simple thermal device that allows temperature reading by a single MMIO
+transaction.
+
+Required properties:
+- compatible: "amazon,al-thermal".
+- reg: The physical base address and length of the sensor's registers.
+- #thermal-sensor-cells: Must be 1. See ./thermal.txt for a description.
+
+Example:
+ thermal: thermal {
+ compatible = "amazon,al-thermal";
+ reg = <0x0 0x05002860 0x0 0x1>;
+ #thermal-sensor-cells = <0x1>;
+ };
+
+ thermal-zones {
+ thermal-z0 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = < 0>;
+ trips {
+ critical {
+ temperature = <105000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ };
+ };
+
--
2.7.4
[PATCH v3 2/2] thermal: Introduce Amazon's Annapurna Labs Thermal Driver
This is a generic thermal driver for simple MMIO sensors, of which
amazon,al-thermal is one.
This device uses a single MMIO transaction to read the temperature and
report it to the thermal subsystem.
Signed-off-by: Talel Shenhar
Reviewed-by: David Woodhouse
---
MAINTAINERS| 6 ++
drivers/thermal/Kconfig| 10
drivers/thermal/Makefile | 1 +
drivers/thermal/thermal_mmio.c | 129 +
4 files changed, 146 insertions(+)
create mode 100644 drivers/thermal/thermal_mmio.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 955463f..262cb2c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -727,6 +727,12 @@ S: Supported
F: Documentation/networking/ena.txt
F: drivers/net/ethernet/amazon/
+AMAZON ANNAPURNA LABS THERMAL MMIO DRIVER
+M: Talel Shenhar
+S: Maintained
+F: Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
+F: drivers/thermal/thermal_mmio.c
+
AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER
M: Tom Lendacky
M: Gary Hook
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 1775d44..96d9236 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -199,6 +199,16 @@ config THERMAL_EMULATION
because userland can easily disable the thermal policy by simply
flooding this sysfs node with low temperature values.
+config THERMAL_MMIO
+ tristate "Generic Thermal MMIO driver"
+ depends on OF || COMPILE_TEST
+ help
+ This option enables the generic thermal MMIO driver that will use
+ memory-mapped reads to get the temperature. Any HW/System that
+ allows temperature reading by a single memory-mapped reading, be it
+ register or shared memory, is a potential candidate to work with this
+ driver.
+
config HISI_THERMAL
tristate "Hisilicon thermal driver"
depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 82bb50d..d4c9ae7 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -29,6 +29,7 @@ thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
# platform thermal drivers
obj-y += broadcom/
+obj-$(CONFIG_THERMAL_MMIO) += thermal_mmio.o
obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
diff --git a/drivers/thermal/thermal_mmio.c b/drivers/thermal/thermal_mmio.c
new file mode 100644
index 000..de3ccee
--- /dev/null
+++ b/drivers/thermal/thermal_mmio.c
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 Amazon.com, Inc. or its affiliates. All Rights Reserved.
+ */
+
+#include
+#include
+#include
+#include
+
+struct thermal_mmio {
+ void __iomem *mmio_base;
+ u32 (*read_mmio)(void __iomem *mmio_base);
+ u32 mask;
+ int factor;
+};
+
+static u32 thermal_mmio_readb(void __iomem *mmio_base)
+{
+ return readb(mmio_base);
+}
+
+static int thermal_mmio_get_temperature(void *private, int *temp)
+{
+ int t;
+ struct thermal_mmio *sensor =
+ (struct thermal_mmio *)private;
+
+ t = sensor->read_mmio(sensor->mmio_base) & sensor->mask;
+ t *= sensor->factor;
+
+ *temp = t;
+
+ return 0;
+}
+
+static struct thermal_zone_of_device_ops thermal_mmio_ops = {
+ .get_temp = thermal_mmio_get_temperature,
+};
+
+static int thermal_mmio_probe(struct platform_device *pdev)
+{
+ struct resource *resource;
+ struct thermal_mmio *sensor;
+ int (*sensor_init_func)(struct platform_device *pdev,
+ struct thermal_mmio *sensor);
+ struct thermal_zone_device *thermal_zone;
+ int ret;
+ int temperature;
+
+ sensor = devm_kzalloc(>dev, sizeof(*sensor), GFP_KERNEL);
+ if (!sensor)
+ return -ENOMEM;
+
+ resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (IS_ERR(resource)) {
+ dev_err(>dev,
+ "fail to get platform memory resource (%ld)\n",
+ PTR_ERR(resource));
+ return PTR_ERR(resource);
+ }
+
+ sensor->mmio_base = devm_ioremap_resource(>dev, resource);
+ if (IS_ERR(sensor->mmio_base)) {
+ dev_err(>dev, "failed to ioremap memory (%ld)\n",
+ PTR_ERR(sensor->mmio_base));
+ return PTR_ERR(sensor->mmio_base);
+ }
+
+ sensor_init_func = device_get_match_data(>dev);
+ if (sensor_init_func) {
+ ret = sensor_init_func(pdev, sensor);
+ if (ret) {
+ dev_err(>dev,
+ "failed to initialize sensor (%d)\n",
+ ret);
+ return ret;
+ }
+ }
+
+
Re: [Milbeaut PATCH v0.4 2/2] mmc: sdhci_f_sdh30: Add support for Milbeaut M10V host controller
On Tue, 26 Mar 2019 at 05:56, Takao Orito wrote:
>
> SD Host controller on Milbeaut is consist of two controller parts.
> One is core controller F_SDH30, this is similar to sdhci-fujitsu
> controller.
> Another is bridge controller.
> This bridge controller is not compatible with sdhci-fujitsu controller.
> This is special for Milbeaut series. This has some functions.
> For example, reset control, clock enable/select for SDR50/25/12, set
> property of SD physical pins, retuning control, set capabilityies.
>
> This bridge controller requires special procedures at reset or clock
> enablement or change for further tuning of clock.
>
> This new driver uses GPIO descriptor from platform data to switch
> the power.
>
> Signed-off-by: Takao Orito
Looks like you should add a new variant driver instead of extending
sdhci_f_sdh30.c.
If there are some registers bits or some other minor things that you
want to share among these variants, you can always do that via a
header file.
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci_f_sdh30.c | 324
> +++
> 1 file changed, 296 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci_f_sdh30.c
> b/drivers/mmc/host/sdhci_f_sdh30.c
> index 485f759..994bafd 100644
> --- a/drivers/mmc/host/sdhci_f_sdh30.c
> +++ b/drivers/mmc/host/sdhci_f_sdh30.c
> @@ -11,12 +11,15 @@
> */
>
> #include
> -#include
> +#include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> +#include
> #include
> -#include
>
> #include "sdhci-pltfm.h"
>
> @@ -43,14 +46,55 @@
>
> #define F_SDH30_CMD_DAT_DELAY 0x200
>
> +/* milbeaut bridge controller register */
> +#define MLB_SOFT_RESET 0x0200
> +#define MLB_SOFT_RESET_RSTX BIT(0)
> +
> +#define MLB_WP_CD_LED_SET 0x0210
> +#define MLB_WP_CD_LED_SET_LED_INV BIT(2)
> +
> +#define MLB_CR_SET 0x0220
> +#define MLB_CR_SET_CR_TOCLKUNIT BIT(24)
> +#define MLB_CR_SET_CR_TOCLKFREQ_SFT (16)
> +#define MLB_CR_SET_CR_TOCLKFREQ_MASK (0x3F << MLB_CR_SET_CR_TOCLKFREQ_SFT)
> +#define MLB_CR_SET_CR_BCLKFREQ_SFT(8)
> +#define MLB_CR_SET_CR_BCLKFREQ_MASK (0xFF << MLB_CR_SET_CR_BCLKFREQ_SFT)
> +#define MLB_CR_SET_CR_RTUNTIMER_SFT (4)
> +#define MLB_CR_SET_CR_RTUNTIMER_MASK (0xF << MLB_CR_SET_CR_RTUNTIMER_SFT)
> +
> +#define MLB_SD_TOCLK_I_DIV 16
> +#define MLB_TOCLKFREQ_UNIT_THRES 1600
> +#define MLB_CAL_TOCLKFREQ_MHZ(rate)(rate / MLB_SD_TOCLK_I_DIV / 100)
> +#define MLB_CAL_TOCLKFREQ_KHZ(rate)(rate / MLB_SD_TOCLK_I_DIV / 1000)
> +#define MLB_TOCLKFREQ_MAX 63
> +#define MLB_TOCLKFREQ_MIN 1
> +
> +#define MLB_SD_BCLK_I_DIV 4
> +#define MLB_CAL_BCLKFREQ(rate) (rate / MLB_SD_BCLK_I_DIV / 100)
> +#define MLB_BCLKFREQ_MAX 255
> +#define MLB_BCLKFREQ_MIN 1
> +
> +#define MLB_CDR_SET0x0230
> +#define MLB_CDR_SET_CLK2POW16 3
> +
> #define F_SDH30_MIN_CLOCK 40
>
> +struct f_sdh30_config {
> + void (*reset)(struct sdhci_host *host, u8 mask);
> + void (*init)(struct sdhci_host *host);
> + void (*quirk_init)(struct sdhci_host *host);
> + void (*prepare_power)(struct sdhci_host *host, unsigned char mode,
> +unsigned short vdd);
> +};
> +
> struct f_sdhost_priv {
> struct clk *clk_iface;
> struct clk *clk;
> u32 vendor_hs200;
> struct device *dev;
> bool enable_cmd_dat_delay;
> + struct gpio_desc *power_gpio;
> + struct f_sdh30_config *config;
> };
>
> static void sdhci_f_sdh30_soft_voltage_switch(struct sdhci_host *host)
> @@ -86,7 +130,46 @@ static unsigned int sdhci_f_sdh30_get_min_clock(struct
> sdhci_host *host)
> return F_SDH30_MIN_CLOCK;
> }
>
> -static void sdhci_f_sdh30_reset(struct sdhci_host *host, u8 mask)
> +static void sdhci_milbeaut_reset(struct sdhci_host *host, u8 mask)
> +{
> + struct f_sdhost_priv *priv = sdhci_priv(host);
> + u16 clk;
> + u32 ctl;
> + ktime_t timeout;
> +
> + clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> + clk = (clk & ~SDHCI_CLOCK_CARD_EN) | SDHCI_CLOCK_INT_EN;
> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> +
> + sdhci_reset(host, mask);
> +
> + clk |= SDHCI_CLOCK_CARD_EN;
> + sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> +
> + timeout = ktime_add_ms(ktime_get(), 10);
> + while (1) {
> + bool timedout = ktime_after(ktime_get(), timeout);
> +
> + clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> + if (clk & SDHCI_CLOCK_INT_STABLE)
> + break;
> + if (timedout) {
> + pr_err("%s: Internal clock never stabilised.\n",
> + mmc_hostname(host->mmc));
> + sdhci_dumpregs(host);
> + return;
> +
[PATCH v3 0/2] Amazon's Annapurna Labs Thermal Sensor Driver
This series introduces support for Amazon's Annapurna Labs Thermal Sensor based on a new simple MMIO thermal driver. This driver is intended to be used by other devices as well, which require just a simple MMIO access to read temperature. Changes since v2: = - dt-binding: changed node name from "thermal_z0" to "thermal-z0" - dt-binding: changed node name from thermalz0_crit to "critical" Changes since v1: == - removed the "thermal_mmio" compatible string. With v2 version, only specific hardware can bound - add initialization function that is mapped based on the specific binding string - removed thermal_mmio_readl and thermal_readw, but kept mmio reads in callback function. Left only thermal_mmio_reab which is used by al-thermal - removed divider, bias, width which are not needed for al-thermal. Talel Shenhar (2): dt-bindings: thermal: al-thermal: Add binding documentation thermal: Introduce Amazon's Annapurna Labs Thermal Driver .../bindings/thermal/amazon,al-thermal.txt | 33 ++ MAINTAINERS| 6 + drivers/thermal/Kconfig| 10 ++ drivers/thermal/Makefile | 1 + drivers/thermal/thermal_mmio.c | 129 + 5 files changed, 179 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt create mode 100644 drivers/thermal/thermal_mmio.c -- 2.7.4
Re: [PATCH 1/2] s390: only build for new CPUs with clang
On Thu, Apr 11, 2019 at 8:24 AM Heiko Carstens wrote: > > On Wed, Apr 10, 2019 at 10:12:40PM +0200, Arnd Bergmann wrote: > > llvm does does not understand -march=z9-109 and older target > > specifiers, so disable the respective Kconfig settings and > > the logic to make the boot code work on old systems when > > building with clang. > > > > Signed-off-by: Arnd Bergmann > > --- > > arch/s390/Kconfig | 6 ++ > > arch/s390/boot/Makefile | 2 ++ > > 2 files changed, 8 insertions(+) > ... > > diff --git a/arch/s390/boot/Makefile b/arch/s390/boot/Makefile > > index c844eaf24ed7..953a74d04990 100644 > > --- a/arch/s390/boot/Makefile > > +++ b/arch/s390/boot/Makefile > > @@ -11,6 +11,7 @@ KASAN_SANITIZE := n > > KBUILD_AFLAGS := $(KBUILD_AFLAGS_DECOMPRESSOR) > > KBUILD_CFLAGS := $(KBUILD_CFLAGS_DECOMPRESSOR) > > > > +ifndef CONFIG_CC_IS_CLANG > > # > > # Use -march=z900 for als.c to be able to print an error > > # message if the kernel is started on a machine which is too old > > @@ -25,6 +26,7 @@ CFLAGS_als.o+= -march=z900 > > CFLAGS_REMOVE_sclp_early_core.o += $(CC_FLAGS_MARCH) > > CFLAGS_sclp_early_core.o += -march=z900 > > endif > > +endif > > This contradicts the whole purpose of als.c - printing an error > message to the console if the kernel is compiled for a newer > architecture than it is running on (and therefore uses instructions > unknown to the current system). > If this can't be fixed/changed in clang, then it should be at least > changed to the lowest possible architecture. Ok, I'll do that. I originally did something like it, but then went back to the simpler workaround to just make it compile. Arnd
Re: [PATCH 1/2] s390: only build for new CPUs with clang
On Thu, Apr 11, 2019 at 12:20 AM 'Nick Desaulniers' via Clang Built Linux wrote: > > On Wed, Apr 10, 2019 at 1:13 PM Arnd Bergmann wrote: > > > > llvm does does not understand -march=z9-109 and older target > > Please file bugs for these in LLVM's issue tracker. It might be > possible to enable these additional architecture variants if they're > similar to existing ones and simply unrecognized. IIRC, we had this > issue with armv7 variants. I really don't see that as necessary here. While generally speaking, it would be nice to support the widest possible range of hardware, and it would not be hard to add this support, it seems highly unlikely that anyone would actually want to use that in case of s390. The last enterprise distros to support z9 were SLES11 (end of life as of last month) and RHEL6 (ending its 10 year life next year). Anyone who is still on those releases will probably not install a brand new compiler, and anyone who is on newer releases won't run on prehistoric hardware. Debian still runs on very old hardware in theory, but even there you'd have a hard time finding someone to test the output of the compiler on an old machine. Arnd
Re: [PATCH] fs/sync.c: sync_file_range(2) may use WB_SYNC_ALL writeback
On Wed 10-04-19 13:42:23, Amir Goldstein wrote:
> On Wed, Apr 10, 2019 at 12:10 PM Jan Kara wrote:
> >
> > On Tue 09-04-19 21:01:54, Amir Goldstein wrote:
> > > On Tue, Apr 9, 2019 at 6:43 PM Jan Kara wrote:
> > > > On Tue 09-04-19 14:49:22, Amir Goldstein wrote:
> > > > > Commit 23d0127096cb ("fs/sync.c: make sync_file_range(2) use
> > > > > WB_SYNC_NONE
> > > > > writeback") claims that sync_file_range(2) syscall was "created for
> > > > > userspace to be able to issue background writeout and so waiting for
> > > > > in-flight IO is undesirable there" and changes the writeback (back) to
> > > > > WB_SYNC_NONE.
> > > > >
> > > > > This claim is only partially true. Is is true for users that use the
> > > > > flag
> > > > > SYNC_FILE_RANGE_WRITE by itself, as does PostgreSQL, the user that was
> > > > > the reason for changing to WB_SYNC_NONE writeback.
> > > > >
> > > > > However, that claim is not true for users that use that flag
> > > > > combination
> > > > > SYNC_FILE_RANGE_{WAIT_BEFORE|WRITE|_WAIT_AFTER}. Those users
> > > > > explicitly
> > > > > requested to wait for in-flight IO as well as to writeback of dirty
> > > > > pages. sync_file_range(2) man page describes this flag combintaion as
> > > > > "write-for-data-integrity operation", although some may argue against
> > > > > this definition.
> > > > >
> > > > > Re-brand that flag combination as SYNC_FILE_RANGE_WRITE_AND_WAIT and
> > > > > use
> > > > > the helper filemap_write_and_wait_range(), that uses WB_SYNC_ALL
> > > > > writeback, to perform the range sync request.
> > > > >
> > > > > One intended use case for this API is creating a dependency between
> > > > > a new file's content and its link into the namepsace without requiring
> > > > > journal commit and flushing of disk volatile caches:
> > > > >
> > > > > fd = open(".", O_TMPFILE | O_RDWR);
> > > > > write(fd, newdata, count);
> > > > > sync_file_range(fd, SYNC_FILE_RANGE_WRITE_AND_WAIT, 0, 0);
> > > > > linkat(AT_EMPTY_PATH, fd, AT_FDCWD, newfile);
> > > > >
> > > > > For many local filesystems, ext4 and xfs included, the sequence above
> > > > > will guaranty that after crash, either 'newfile' exists with 'newdata'
> > > > > content or 'newfile' does not exists. For some applications, this
> > > > > guaranty is strong enough and the effects of sync_file_range(2), even
> > > > > with WB_SYNC_ALL, are far less intrusive to other writers in the
> > > > > system
> > > > > than the effects of fdatasync(2).
> > > >
> > > > I agree that this paragraph is true but I don't want any userspace
> > > > program
> > > > rely on this. We've been through this when ext3 got converted to ext4
> > > > and
> > > > it has caused a lot of complaints. Ext3 had provided rather strong data
> > > > vs
> > > > metadata ordering due to the way journalling was implemented. Then ext4
> > > > came, implemented delayed allocation and somewhat changed how
> > > > journalling
> > > > works and suddently userspace programmers were caught by surprise their
> > > > code
> > > > working by luck stopped working. And they were complaining that when
> > > > their
> > > > code worked without fsync(2) before, it should work after it as well.
> > > > So it
> > > > took a lot of explaining that their applications are broken and Ted has
> > > > also implemented some workarounds to make at least the most common
> > > > mistakes
> > > > silently fixed by the kernel most of the time.
> > > >
> > > > So I'm against providing 90% data integrity guarantees because there'll
> > > > be
> > > > many people who'll think they can get away with it and then complain
> > > > when
> > > > they won't once our implementation changes.
> > > >
> > > > Rather I'd modify the manpage to not say that
> > > > SYNC_FILE_RANGE_WAIT_BEFORE
> > > > | SYNC_FILE_RANGE_WRITE | SYNC_FILE_RANGE_WAIT_AFTER is a
> > > > write-for-data-integrity.
> > >
> > > OK. I do agree that manpage is misleading and that the language describing
> > > this flag combination should be toned down. I do not object to adding more
> > > and more disclaimers about this API not being a data integrity API.
> >
> > I don't think we need more disclaimers, I'd just reword that
> > "write-for-data-integrity" bit.
> >
> > > But the requirement I have is a real life workload and fdatasync(2) is
> > > not at
> > > all a viable option when application is creating many files per second.
> > >
> > > I need to export the functionality of data writeback to userspace.
> > > Objecting to expose this functionality via the interface that has been
> > > documented to expose it for years and used to expose it in the
> > > past (until the Fixes commit) is a bit weird IMO, even though I do
> > > completely relate to your concern.
> > >
> > > I don't mind removing the "intended use case" part of commit message
> > > if that helps reducing the chance that people misunderstand
> > > the guaranties of the API.
> > >
> > > Another thing I could do is introduce a new flag for
Re: [PATCH V2 02/16] PCI/PME: Export pcie_pme_disable_msi() API
On Fri, Apr 05, 2019 at 01:24:29AM +0530, Vidya Sagar wrote:
> Export pcie_pme_disable_msi() API to enable drivers using this API be able to
> build as loadable modules
>
> Signed-off-by: Vidya Sagar
> ---
> Changes from [v1]:
> * This is a new patch in v2 series
>
> drivers/pci/pcie/pme.c | 6 ++
> drivers/pci/pcie/portdrv.h | 5 +
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
> index 54d593d10396..18e815c1e3c9 100644
> --- a/drivers/pci/pcie/pme.c
> +++ b/drivers/pci/pcie/pme.c
> @@ -27,6 +27,12 @@
> */
> bool pcie_pme_msi_disabled;
>
> +void pcie_pme_disable_msi(void)
> +{
> + pcie_pme_msi_disabled = true;
> +}
> +EXPORT_SYMBOL_GPL(pcie_pme_disable_msi);
> +
> static int __init pcie_pme_setup(char *str)
> {
> if (!strncmp(str, "nomsi", 5))
> diff --git a/drivers/pci/pcie/portdrv.h b/drivers/pci/pcie/portdrv.h
> index 1d50dc58ac40..2be7b7e9a784 100644
> --- a/drivers/pci/pcie/portdrv.h
> +++ b/drivers/pci/pcie/portdrv.h
> @@ -127,10 +127,7 @@ struct pci_dev;
> #ifdef CONFIG_PCIE_PME
> extern bool pcie_pme_msi_disabled;
>
> -static inline void pcie_pme_disable_msi(void)
> -{
> - pcie_pme_msi_disabled = true;
> -}
> +void pcie_pme_disable_msi(void);
>
> static inline bool pcie_pme_no_msi(void)
> {
Perhaps also export pcie_pme_no_msi()? That way you could get rid of the
extern declaration of the pcie_pme_msi_disabled variable and make it
static to drivers/pci/pcie/pme.c?
Thierry
signature.asc
Description: PGP signature
Re: [PATCH V2 01/16] PCI: Add #defines for PCIe spec r4.0 features
On Fri, Apr 05, 2019 at 01:24:28AM +0530, Vidya Sagar wrote: > Add #defines for the Data Link Feature and Physical Layer 16.0 GT/s > features. > > Signed-off-by: Vidya Sagar > --- > Changes from [v1]: > * None > > include/uapi/linux/pci_regs.h | 22 +- > 1 file changed, 21 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h > index 5c98133f2c94..3e01b55d548d 100644 > --- a/include/uapi/linux/pci_regs.h > +++ b/include/uapi/linux/pci_regs.h > @@ -705,7 +705,9 @@ > #define PCI_EXT_CAP_ID_DPC 0x1D/* Downstream Port Containment */ > #define PCI_EXT_CAP_ID_L1SS 0x1E/* L1 PM Substates */ > #define PCI_EXT_CAP_ID_PTM 0x1F/* Precision Time Measurement */ > -#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PTM > +#define PCI_EXT_CAP_ID_DLF 0x25/* Data Link Feature */ > +#define PCI_EXT_CAP_ID_PL0x26/* Physical Layer 16.0 GT/s */ > +#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PL > > #define PCI_EXT_CAP_DSN_SIZEOF 12 > #define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40 > @@ -1045,4 +1047,22 @@ > #define PCI_L1SS_CTL1_LTR_L12_TH_SCALE 0xe000 /* > LTR_L1.2_THRESHOLD_Scale */ > #define PCI_L1SS_CTL20x0c/* Control 2 Register */ > > +/* Data Link Feature */ > +#define PCI_DLF_CAP 0x04/* Capabilities Register */ > +#define PCI_DLF_LOCAL_DLF_SUP_MASK 0x007f /* Local Data Link Feature > Supported */ > +#define PCI_DLF_EXCHANGE_ENABLE 0x8000 /* Data Link Feature > Exchange Enable */ > +#define PCI_DLF_STS 0x08/* Status Register */ > +#define PCI_DLF_REMOTE_DLF_SUP_MASK 0x007f /* Remote Data Link Feature > Supported */ > +#define PCI_DLF_REMOTE_DLF_SUP_VALID0x8000 /* Remote Data Link > Feature Support Valid */ > + > +/* Physical Layer 16.0 GT/s */ > +#define PCI_PL_16GT_CAP 0x04/* Capabilities Register */ > +#define PCI_PL_16GT_CTRL 0x08/* Control Register */ > +#define PCI_PL_16GT_STS 0x0c/* Status Register */ > +#define PCI_PL_16GT_LDPM_STS 0x10/* Local Data Parity Mismatch Status > Register */ > +#define PCI_PL_16GT_FRDPM_STS0x14/* First Retimer Data Parity > Mismatch Status Register */ > +#define PCI_PL_16GT_SRDPM_STS0x18/* Second Retimer Data Parity > Mismatch Status Register */ > +#define PCI_PL_16GT_RSVD 0x1C/* Reserved */ > +#define PCI_PL_16GT_LE_CTRL 0x20/* Lane Equalization Control Register */ This looks correct comparing to the specification. However, this leaves out some definitions, so I'm wondering if perhaps this should include all field definitions. There are also extended capabilities between the current maximum 0x1F and 0x25. Perhaps those should be added as well. I guess this could always be done as a follow-up. Perhaps it'd be better to change the subject to more accurately reflect that you're only adding a couple of PCIe 4.0 features. Other than that: Reviewed-by: Thierry Reding signature.asc Description: PGP signature
Water, Sanitation and Hygeine Proposal
Dear Sir/Ma, Do not let this come as a surprise to you as my organization and I do a lot of philanthropic work and support a lot of good will project in Africa, Asia and South America. I have one of such project that I am currently involved in, it has to do with providing solar powered borehole water, modern toilets and wash hand basins in schools in a local government area in Edo State, Nigeria. The details of the project is in the attached documents. It will cost seventy two thousand five hundred dollars (72,500USD) to carry out the project in one school while it will cost Ten million Seventy seven thousand five hundred dollars in the entire 139 schools in the local government area. I will appreciate it if you can support this worthy cause and let me know how many schools that you can adopt and sponsor the project in. Video evidence and photographs (pre, intra and post) of the project will be sent to you and you and your organization will be acknowledged as the proud sponsor of the project. Thanks Austin Edomwonyi
Re: [PATCH V3 05/10] arm64: tegra: fix default tap and trim values
On Mon, 1 Apr 2019 at 19:43, Sowjanya Komatineni wrote: > > > > > > > > > Default tap and trim values are incorrect for Tegra186 SDMMC4. > > > > This patch fixes it. > > > > > > > > Tested-by: Jon Hunter > > > > Signed-off-by: Sowjanya Komatineni > > > > > > Is this a fix and/or for stable? > > > > > > In either case, I am leaving this for arm-soc. > > > > > > Kind regards > > > Uffe > > > > > > > Thanks Uffe. Yes this is applicable for stable. > > I don’t see any confirmation of this being applied by arm-soc. > So thought to re-check if this is applied? Perhaps repost it to remind the soc maintainer to pick it up. Kind regards Uffe > > > > > --- > > > > arch/arm64/boot/dts/nvidia/tegra186.dtsi | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi > > > > b/arch/arm64/boot/dts/nvidia/tegra186.dtsi > > > > index 97aeb946ed5e..472f55fe9488 100644 > > > > --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi > > > > +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi > > > > @@ -317,8 +317,8 @@ > > > > nvidia,pad-autocal-pull-down-offset-1v8-timeout = > > > > <0x0a>; > > > > nvidia,pad-autocal-pull-up-offset-3v3-timeout = <0x0a>; > > > > nvidia,pad-autocal-pull-down-offset-3v3-timeout = > > > > <0x0a>; > > > > - nvidia,default-tap = <0x5>; > > > > - nvidia,default-trim = <0x9>; > > > > + nvidia,default-tap = <0x9>; > > > > + nvidia,default-trim = <0x5>; > > > > nvidia,dqs-trim = <63>; > > > > mmc-hs400-1_8v; > > > > status = "disabled"; > > > > -- > > > > 2.7.4 > > > >
Re: [PATCH V3] mmc: tegra: add sdhci tegra suspend and resume
On Wed, 3 Apr 2019 at 17:39, Sowjanya Komatineni wrote:
>
> This patch adds suspend and resume PM ops for tegra SDHCI.
>
> Acked-by: Thierry Reding
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/mmc/host/sdhci-tegra.c | 56
> +-
> 1 file changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index eafaaefab4a6..5ec304166566 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -1611,11 +1611,65 @@ static int sdhci_tegra_remove(struct platform_device
> *pdev)
> return 0;
> }
>
sdhci_suspend_host() exists only if CONFIG_PM is set. Therefore, I
think it's better to add explicit check for that. So add the ifdef
like below, and a corresponding #endif, after the implementation of
sdhci_tegra_resume().
#ifdef CONFIG_PM_SLEEP
> +static int __maybe_unused sdhci_tegra_suspend(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + int ret;
> +
> + if (host->mmc->caps2 & MMC_CAP2_CQE) {
> + ret = cqhci_suspend(host->mmc);
> + if (ret)
> + return ret;
> + }
> +
> + ret = sdhci_suspend_host(host);
> + if (ret) {
> + cqhci_resume(host->mmc);
> + return ret;
> + }
> +
> + clk_disable_unprepare(pltfm_host->clk);
> + return 0;
> +}
> +
> +static int __maybe_unused sdhci_tegra_resume(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + int ret;
> +
> + ret = clk_prepare_enable(pltfm_host->clk);
> + if (ret)
> + return ret;
> +
> + ret = sdhci_resume_host(host);
> + if (ret)
> + goto disable_clk;
> +
> + if (host->mmc->caps2 & MMC_CAP2_CQE) {
> + ret = cqhci_resume(host->mmc);
> + if (ret)
> + goto suspend_host;
> + }
> +
> + return 0;
> +
> +suspend_host:
> + sdhci_suspend_host(host);
> +disable_clk:
> + clk_disable_unprepare(pltfm_host->clk);
> + return ret;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(sdhci_tegra_dev_pm_ops, sdhci_tegra_suspend,
> +sdhci_tegra_resume);
> +
> static struct platform_driver sdhci_tegra_driver = {
> .driver = {
> .name = "sdhci-tegra",
> .of_match_table = sdhci_tegra_dt_match,
> - .pm = _pltfm_pmops,
> + .pm = _tegra_dev_pm_ops,
> },
> .probe = sdhci_tegra_probe,
> .remove = sdhci_tegra_remove,
> --
> 2.7.4
>
Otherwise this looks good to me.
Kind regards
Uffe
Water, Sanitation and Hygeine Proposal
Dear Sir/Ma, Do not let this come as a surprise to you as my organization and I do a lot of philanthropic work and support a lot of good will project in Africa, Asia and South America. I have one of such project that I am currently involved in, it has to do with providing solar powered borehole water, modern toilets and wash hand basins in schools in a local government area in Edo State, Nigeria. The details of the project is in the attached documents. It will cost seventy two thousand five hundred dollars (72,500USD) to carry out the project in one school while it will cost Ten million Seventy seven thousand five hundred dollars in the entire 139 schools in the local government area. I will appreciate it if you can support this worthy cause and let me know how many schools that you can adopt and sponsor the project in. Video evidence and photographs (pre, intra and post) of the project will be sent to you and you and your organization will be acknowledged as the proud sponsor of the project. Thanks Austin Edomwonyi
[PATCH v1 1/1] thermal: rcar_gen3_thermal: request IRQ after device initialization
Currently IRQ is remain enabled after .remove, later if device is probed,
IRQ is requested before .thermal_init, this may cause IRQ function be
triggered but not able to clear IRQ status, thus cause system to hang.
this patch by moving request of IRQ after device initialization to
avoid this issue.
Signed-off-by: Jiada Wang
---
drivers/thermal/rcar_gen3_thermal.c | 48 -
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/thermal/rcar_gen3_thermal.c
b/drivers/thermal/rcar_gen3_thermal.c
index 88fa41cf16e8..4d095d7f9763 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -375,28 +375,6 @@ static int rcar_gen3_thermal_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, priv);
- /*
-* Request 2 (of the 3 possible) IRQs, the driver only needs to
-* to trigger on the low and high trip points of the current
-* temp window at this point.
-*/
- for (i = 0; i < 2; i++) {
- irq = platform_get_irq(pdev, i);
- if (irq < 0)
- return irq;
-
- irqname = devm_kasprintf(dev, GFP_KERNEL, "%s:ch%d",
-dev_name(dev), i);
- if (!irqname)
- return -ENOMEM;
-
- ret = devm_request_threaded_irq(dev, irq, rcar_gen3_thermal_irq,
- rcar_gen3_thermal_irq_thread,
- IRQF_SHARED, irqname, priv);
- if (ret)
- return ret;
- }
-
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
@@ -458,6 +436,32 @@ static int rcar_gen3_thermal_probe(struct platform_device
*pdev)
goto error_unregister;
}
+ /*
+* Request 2 (of the 3 possible) IRQs, the driver only needs to
+* to trigger on the low and high trip points of the current
+* temp window at this point.
+*/
+ for (i = 0; i < 2; i++) {
+ irq = platform_get_irq(pdev, i);
+ if (irq < 0) {
+ ret = irq;
+ goto error_unregister;
+ }
+
+ irqname = devm_kasprintf(dev, GFP_KERNEL, "%s:ch%d",
+dev_name(dev), i);
+ if (!irqname) {
+ ret = -ENOMEM;
+ goto error_unregister;
+ }
+
+ ret = devm_request_threaded_irq(dev, irq, rcar_gen3_thermal_irq,
+ rcar_gen3_thermal_irq_thread,
+ IRQF_SHARED, irqname, priv);
+ if (ret)
+ goto error_unregister;
+ }
+
rcar_thermal_irq_set(priv, true);
return 0;
--
2.19.2
Re: [PATCH 2/2] MAINTAINERS: Add Ulf Hansson to the MEMORYSTICK section
On Fri, 22 Mar 2019 at 18:03, Maxim Levitsky wrote: > > Thanks! > I also expect to start contributing again to maintain the code I have > in the kernel, after I done with upsteaming the nvme-mdev driver I > have just sent for initial review. > I work for Red Hat now, so I hope I'll find some time for that in the > future (still on a hobby basis of course). Thanks Maxim, I consider this as an ack from you. > > Best regards, > Maxim Levitsky > > PS: my work email is mlevi...@redhat.com If you want to change/add your email to the section in the MAINTAINERS, please just send a patch. I think otherwise people will continue to send to your gmail address. [...] Kind regards Uffe
Re: [PATCH] MAINTAINERS: Add section for MediaTek MMC/SD/SDIO driver
Chaotian, On Mon, 25 Mar 2019 at 13:24, Ulf Hansson wrote: > > Cc: Chaotian Jing > Signed-off-by: Ulf Hansson > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3e5a5d263f29..b43e563b4c95 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9775,6 +9775,12 @@ F: drivers/media/platform/mtk-vpu/ > F: Documentation/devicetree/bindings/media/mediatek-vcodec.txt > F: Documentation/devicetree/bindings/media/mediatek-vpu.txt > > +MEDIATEK MMC/SD/SDIO DRIVER > +M: Chaotian Jing > +S: Maintained > +F: drivers/mmc/host/mtk-sd.c > +F: Documentation/devicetree/bindings/mmc/mtk-sd.txt > + Are you fine with this, or do you have any other guys at your side that can help with reviewing patches for the mtk-sd driver? [...] Kind regards Uffe
[RESEND PATCH 0/4] um: build and irq fixes
From: Bartosz Golaszewski Resending again - this time with tags collected. === I've previously sent these patches separately. I still don't see them in next and I don't know what the policy is for picking up uml patches but I thought I'd resend them rebased together on top of v5.1-rc4. Bartosz Golaszewski (4): um: remove unused variable um: remove uses of variable length arrays um: define set_pte_at() as a static inline function, not a macro um: irq: don't set the chip for all irqs arch/um/include/asm/pgtable.h | 7 ++- arch/um/kernel/irq.c | 2 +- arch/um/kernel/skas/uaccess.c | 1 - arch/um/os-Linux/umid.c | 36 ++- 4 files changed, 34 insertions(+), 12 deletions(-) -- 2.21.0
[RESEND PATCH 1/4] um: remove unused variable
From: Bartosz Golaszewski
The buf variable is unused. Remove it.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Anton Ivanov
Acked-by: Anton Ivanov
---
arch/um/kernel/skas/uaccess.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/um/kernel/skas/uaccess.c b/arch/um/kernel/skas/uaccess.c
index 7f06fdbc7ee1..bd3cb694322c 100644
--- a/arch/um/kernel/skas/uaccess.c
+++ b/arch/um/kernel/skas/uaccess.c
@@ -59,7 +59,6 @@ static pte_t *maybe_map(unsigned long virt, int is_write)
static int do_op_one_page(unsigned long addr, int len, int is_write,
int (*op)(unsigned long addr, int len, void *arg), void *arg)
{
- jmp_buf buf;
struct page *page;
pte_t *pte;
int n;
--
2.21.0
[RESEND PATCH 4/4] um: irq: don't set the chip for all irqs
From: Bartosz Golaszewski Setting a chip for an interrupt marks it as allocated. Since UM doesn't support dynamic interrupt numbers (yet), it means we cannot simply increase NR_IRQS and then use the free irqs between LAST_IRQ and NR_IRQS with gpio-mockup or iio testing drivers as irq_alloc_descs() will fail after not being able to neither find an unallocated range of interrupts nor expand the range. Only call irq_set_chip_and_handler() for irqs until LAST_IRQ. Signed-off-by: Bartosz Golaszewski Reviewed-by: Anton Ivanov Acked-by: Anton Ivanov --- arch/um/kernel/irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/um/kernel/irq.c b/arch/um/kernel/irq.c index f4874b7ec503..598d7b3d9355 100644 --- a/arch/um/kernel/irq.c +++ b/arch/um/kernel/irq.c @@ -479,7 +479,7 @@ void __init init_IRQ(void) irq_set_chip_and_handler(TIMER_IRQ, _irq_type, handle_edge_irq); - for (i = 1; i < NR_IRQS; i++) + for (i = 1; i < LAST_IRQ; i++) irq_set_chip_and_handler(i, _irq_type, handle_edge_irq); /* Initialize EPOLL Loop */ os_setup_epoll(); -- 2.21.0
[RESEND PATCH 3/4] um: define set_pte_at() as a static inline function, not a macro
From: Bartosz Golaszewski
When defined as macro, the mm argument is unused and subsequently the
variable passed as mm is considered unused by the compiler. This fixes
a build warning.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Anton Ivanov
Acked-by: Anton Ivanov
---
arch/um/include/asm/pgtable.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/um/include/asm/pgtable.h b/arch/um/include/asm/pgtable.h
index 9c04562310b3..b377df76cc28 100644
--- a/arch/um/include/asm/pgtable.h
+++ b/arch/um/include/asm/pgtable.h
@@ -263,7 +263,12 @@ static inline void set_pte(pte_t *pteptr, pte_t pteval)
*pteptr = pte_mknewpage(*pteptr);
if(pte_present(*pteptr)) *pteptr = pte_mknewprot(*pteptr);
}
-#define set_pte_at(mm,addr,ptep,pteval) set_pte(ptep,pteval)
+
+static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
+ pte_t *pteptr, pte_t pteval)
+{
+ set_pte(pteptr, pteval);
+}
#define __HAVE_ARCH_PTE_SAME
static inline int pte_same(pte_t pte_a, pte_t pte_b)
--
2.21.0
[RESEND PATCH 2/4] um: remove uses of variable length arrays
From: Bartosz Golaszewski
While the affected code is run in user-mode, the build still warns
about it. Convert all uses of VLA to dynamic allocations.
Signed-off-by: Bartosz Golaszewski
---
arch/um/os-Linux/umid.c | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/arch/um/os-Linux/umid.c b/arch/um/os-Linux/umid.c
index 998fbb445458..e261656fe9d7 100644
--- a/arch/um/os-Linux/umid.c
+++ b/arch/um/os-Linux/umid.c
@@ -135,12 +135,18 @@ static int remove_files_and_dir(char *dir)
*/
static inline int is_umdir_used(char *dir)
{
- char file[strlen(uml_dir) + UMID_LEN + sizeof("/pid\0")];
- char pid[sizeof("n\0")], *end;
+ char pid[sizeof("n\0")], *end, *file;
int dead, fd, p, n, err;
+ size_t filelen;
- n = snprintf(file, sizeof(file), "%s/pid", dir);
- if (n >= sizeof(file)) {
+ err = asprintf(, "%s/pid", dir);
+ if (err < 0)
+ return 0;
+
+ filelen = strlen(file);
+
+ n = snprintf(file, filelen, "%s/pid", dir);
+ if (n >= filelen) {
printk(UM_KERN_ERR "is_umdir_used - pid filename too long\n");
err = -E2BIG;
goto out;
@@ -185,6 +191,7 @@ static inline int is_umdir_used(char *dir)
out_close:
close(fd);
out:
+ free(file);
return 0;
}
@@ -210,18 +217,21 @@ static int umdir_take_if_dead(char *dir)
static void __init create_pid_file(void)
{
- char file[strlen(uml_dir) + UMID_LEN + sizeof("/pid\0")];
- char pid[sizeof("n\0")];
+ char pid[sizeof("n\0")], *file;
int fd, n;
- if (umid_file_name("pid", file, sizeof(file)))
+ file = malloc(strlen(uml_dir) + UMID_LEN + sizeof("/pid\0"));
+ if (!file)
return;
+ if (umid_file_name("pid", file, sizeof(file)))
+ goto out;
+
fd = open(file, O_RDWR | O_CREAT | O_EXCL, 0644);
if (fd < 0) {
printk(UM_KERN_ERR "Open of machine pid file \"%s\" failed: "
"%s\n", file, strerror(errno));
- return;
+ goto out;
}
snprintf(pid, sizeof(pid), "%d\n", getpid());
@@ -231,6 +241,8 @@ static void __init create_pid_file(void)
errno);
close(fd);
+out:
+ free(file);
}
int __init set_umid(char *name)
@@ -385,13 +397,19 @@ __uml_setup("uml_dir=", set_uml_dir,
static void remove_umid_dir(void)
{
- char dir[strlen(uml_dir) + UMID_LEN + 1], err;
+ char *dir, err;
+
+ dir = malloc(strlen(uml_dir) + UMID_LEN + 1);
+ if (!dir)
+ return;
sprintf(dir, "%s%s", uml_dir, umid);
err = remove_files_and_dir(dir);
if (err)
os_warn("%s - remove_files_and_dir failed with err = %d\n",
__func__, err);
+
+ free(dir);
}
__uml_exitcall(remove_umid_dir);
--
2.21.0
Re: [PATCH RESEND] fs: drop unused fput_atomic definition
Looks good, Reviewed-by: Johannes Thumshirn -- Johannes ThumshirnSUSE Labs Filesystems jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH RFC] clk: ux500: add range to usleep_range
On Sun, 7 Apr 2019 at 05:13, Nicholas Mc Guire wrote: > > Providing a range for usleep_range() allows the hrtimer subsystem to > coalesce timers - the delay is runtime configurable so a factor 2 > is taken to provide the range. > > Signed-off-by: Nicholas Mc Guire > --- > > Problem located with an experimental coccinelle script > > Q: Basically usleep_range() with min == max never makes much sense notably >in non-atomic context. If the factor of 2 is tolerable or a fixed >offset of e.g. 1000 would be more suitable is not clear to me - maybe >someone familiar with that driver can clarify this. > > Patch was compile tested with: u8500_defconfig (implies COMMON_CLK=y) > (with some sparse warnings about not implemented system calls) > > Patch is against 5.1-rc3 (localversion-next is next=20190405) > > drivers/clk/ux500/clk-sysctrl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/clk/ux500/clk-sysctrl.c b/drivers/clk/ux500/clk-sysctrl.c > index 7c0403b..a1fa3fb 100644 > --- a/drivers/clk/ux500/clk-sysctrl.c > +++ b/drivers/clk/ux500/clk-sysctrl.c > @@ -42,7 +42,7 @@ static int clk_sysctrl_prepare(struct clk_hw *hw) > clk->reg_bits[0]); > > if (!ret && clk->enable_delay_us) > - usleep_range(clk->enable_delay_us, clk->enable_delay_us); > + usleep_range(clk->enable_delay_us, clk->enable_delay_us*2); The range being used is actually in ms, so not sure we actually need to double it for the range. How about adding ~25% instead, along the lines of below: usleep_range(clk->enable_delay_us, clk->enable_delay_us + (clk->enable_delay_us >> 2)); Kind regards Uffe
Re: [PATCH -next] memory: tegra: Make terga20_mc_reset_ops static
On Wed, Apr 10, 2019 at 10:04:50PM +0800, Yue Haibing wrote: > From: YueHaibing > > Fix sparse warning: > > drivers/memory/tegra/tegra20.c:277:33: warning: > symbol 'terga20_mc_reset_ops' was not declared. Should it be static? > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing > --- > drivers/memory/tegra/tegra20.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied thanks. I noticed that you use a slightly different name in your git author settings and your email setup. The only difference seems to be a space between the first and last name, so you may want to look into that to avoid having any inconsistencies. Thierry signature.asc Description: PGP signature
[PATCH] pinctrl: Add kernel config PINCTRL_MTK_V2
Since no single Mediatek chip use code for PINCTRL_MTK and code for PINCTRL_MTK_MOORE/PINCTRL_MTK_PARIS simultaneously, it is better to use different config to determine if related code will be built or not on building non-generic kernel. Add kernel config PINCTRL_MTK_V2 selected by either PINCTRL_MTK_MOORE or PINCTRL_MTK_PARIS. Use PINCTRL_MTK and PINCTRL_MTK_V2 to control building of drivers/pinctrl/medaitek/. Remove selection of EINT_MTK from PINCTRL_MTK since code for EINT_MTK is only related to PINCTRL_MTK_MOORE/PINCTRL_MTK_PARIS, i.e. PINCTL_MTK_V2. --- drivers/pinctrl/Makefile | 3 ++- drivers/pinctrl/mediatek/Kconfig | 15 --- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile index 712184b..fcee0e0 100644 --- a/drivers/pinctrl/Makefile +++ b/drivers/pinctrl/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_PINCTRL_SUNXI) += sunxi/ obj-y += ti/ obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/ obj-$(CONFIG_ARCH_VT8500) += vt8500/ -obj-y += mediatek/ +obj-$(CONFIG_PINCTRL_MTK) += mediatek/ +obj-$(CONFIG_PINCTRL_MTK_V2) += mediatek/ obj-$(CONFIG_PINCTRL_ZX) += zte/ obj-y += cirrus/ diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig index a005cbc..5e26462 100644 --- a/drivers/pinctrl/mediatek/Kconfig +++ b/drivers/pinctrl/mediatek/Kconfig @@ -2,10 +2,15 @@ menu "MediaTek pinctrl drivers" depends on ARCH_MEDIATEK || COMPILE_TEST config EINT_MTK - bool "MediaTek External Interrupt Support" - depends on PINCTRL_MTK || PINCTRL_MTK_MOORE || PINCTRL_MTK_PARIS || COMPILE_TEST + bool "MediaTek External Interrupt driver that is based on PINCTRL_MTK_V2" + depends on PINCTRL_MTK_MOORE || PINCTRL_MTK_PARIS || COMPILE_TEST select GPIOLIB select IRQ_DOMAIN + help + Say yes here to enable support for MediaTek External Interrupt + (EINT) driver based on PINCTRL_MTK version 2. + This driver is combined with MediaTek Pinctrl driver version 2 + so PINCTRL_MTK_V2 shall be set first. config PINCTRL_MTK bool @@ -13,9 +18,11 @@ config PINCTRL_MTK select PINMUX select GENERIC_PINCONF select GPIOLIB - select EINT_MTK select OF_GPIO +config PINCTRL_MTK_V2 + bool "MediaTek Pinctrl Support V2" + config PINCTRL_MTK_MOORE bool depends on OF @@ -24,6 +31,7 @@ config PINCTRL_MTK_MOORE select GENERIC_PINMUX_FUNCTIONS select GPIOLIB select OF_GPIO + select PINCTRL_MTK_V2 config PINCTRL_MTK_PARIS bool @@ -33,6 +41,7 @@ config PINCTRL_MTK_PARIS select GPIOLIB select EINT_MTK select OF_GPIO + select PINCTRL_MTK_V2 # For ARMv7 SoCs config PINCTRL_MT2701 -- 1.8.1.1.dirty
[PATCH] ARM: vdso: use $(LD) instead of $(CC) to link VDSO
We use $(LD) to link vmlinux, modules, decompressors, etc. VDSO is the only exceptional case where $(CC) is used as the linker driver, but I do not know why we need to do so. VDSO uses a special linker script, and does not link standard libraries at all. I changed the Makefile to use $(LD) rather than $(CC). I confirmed the same vdso.so.raw was still produced. Users will be able to use their favorite linker (e.g. lld instead of of bfd) by passing LD= from the command line. My plan is to rewrite all VDSO Makefiles to use $(LD), then delete cc-ldoption. Signed-off-by: Masahiro Yamada --- arch/arm/vdso/Makefile | 21 - 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/arch/arm/vdso/Makefile b/arch/arm/vdso/Makefile index f4efff9d3afb..fadf554d9391 100644 --- a/arch/arm/vdso/Makefile +++ b/arch/arm/vdso/Makefile @@ -10,12 +10,12 @@ obj-vdso := $(addprefix $(obj)/, $(obj-vdso)) ccflags-y := -fPIC -fno-common -fno-builtin -fno-stack-protector ccflags-y += -DDISABLE_BRANCH_PROFILING -VDSO_LDFLAGS := -Wl,-Bsymbolic -Wl,--no-undefined -Wl,-soname=linux-vdso.so.1 -VDSO_LDFLAGS += -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096 -VDSO_LDFLAGS += -nostdlib -shared -VDSO_LDFLAGS += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) -VDSO_LDFLAGS += $(call cc-ldoption, -Wl$(comma)--build-id) -VDSO_LDFLAGS += $(call cc-ldoption, -fuse-ld=bfd) +ldflags-y = -Bsymbolic --no-undefined -soname=linux-vdso.so.1 \ + -z max-page-size=4096 -z common-page-size=4096 \ + -nostdlib -shared \ + $(call ld-option, --hash-style=sysv) \ + $(call ld-option, --build-id) \ + -T obj-$(CONFIG_VDSO) += vdso.o extra-$(CONFIG_VDSO) += vdso.lds @@ -37,8 +37,8 @@ KCOV_INSTRUMENT := n $(obj)/vdso.o : $(obj)/vdso.so # Link rule for the .so file -$(obj)/vdso.so.raw: $(src)/vdso.lds $(obj-vdso) FORCE - $(call if_changed,vdsold) +$(obj)/vdso.so.raw: $(obj)/vdso.lds $(obj-vdso) FORCE + $(call if_changed,ld) $(obj)/vdso.so.dbg: $(obj)/vdso.so.raw $(obj)/vdsomunge FORCE $(call if_changed,vdsomunge) @@ -48,11 +48,6 @@ $(obj)/%.so: OBJCOPYFLAGS := -S $(obj)/%.so: $(obj)/%.so.dbg FORCE $(call if_changed,objcopy) -# Actual build commands -quiet_cmd_vdsold = VDSO$@ - cmd_vdsold = $(CC) $(c_flags) $(VDSO_LDFLAGS) \ - -Wl,-T $(filter %.lds,$^) $(filter %.o,$^) -o $@ - quiet_cmd_vdsomunge = MUNGE $@ cmd_vdsomunge = $(objtree)/$(obj)/vdsomunge $< $@ -- 2.17.1
[PATCH] arm64: vdso: use $(LD) instead of $(CC) to link VDSO
We use $(LD) to link vmlinux, modules, decompressors, etc. VDSO is the only exceptional case where $(CC) is used as the linker driver, but I do not know why we need to do so. VDSO uses a special linker script, and does not link standard libraries at all. I changed the Makefile to use $(LD) rather than $(CC). I tested this, and VDSO worked for me. Users will be able to use their favorite linker (e.g. lld instead of of bfd) by passing LD= from the command line. My plan is to rewrite all VDSO Makefiles to use $(LD), then delete cc-ldoption. Signed-off-by: Masahiro Yamada --- arch/arm64/kernel/vdso/Makefile | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile index a0af6bf6c11b..744b9dbaba03 100644 --- a/arch/arm64/kernel/vdso/Makefile +++ b/arch/arm64/kernel/vdso/Makefile @@ -12,17 +12,12 @@ obj-vdso := gettimeofday.o note.o sigreturn.o targets := $(obj-vdso) vdso.so vdso.so.dbg obj-vdso := $(addprefix $(obj)/, $(obj-vdso)) -ccflags-y := -shared -fno-common -fno-builtin -ccflags-y += -nostdlib -Wl,-soname=linux-vdso.so.1 \ - $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) +ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 \ + $(call ld-option, --hash-style=sysv) -n -T # Disable gcov profiling for VDSO code GCOV_PROFILE := n -# Workaround for bare-metal (ELF) toolchains that neglect to pass -shared -# down to collect2, resulting in silent corruption of the vDSO image. -ccflags-y += -Wl,-shared - obj-y += vdso.o extra-y += vdso.lds CPPFLAGS_vdso.lds += -P -C -U$(ARCH) @@ -32,7 +27,7 @@ $(obj)/vdso.o : $(obj)/vdso.so # Link rule for the .so file, .lds has to be first $(obj)/vdso.so.dbg: $(obj)/vdso.lds $(obj-vdso) FORCE - $(call if_changed,vdsold) + $(call if_changed,ld) # Strip rule for the .so file $(obj)/%.so: OBJCOPYFLAGS := -S @@ -52,8 +47,6 @@ $(obj-vdso): %.o: %.S FORCE $(call if_changed_dep,vdsoas) # Actual build commands -quiet_cmd_vdsold = VDSOL $@ - cmd_vdsold = $(CC) $(c_flags) -Wl,-n -Wl,-T $(real-prereqs) -o $@ quiet_cmd_vdsoas = VDSOA $@ cmd_vdsoas = $(CC) $(a_flags) -c -o $@ $< -- 2.17.1
[PATCH v4 4/6] ARM: davinci: omapl138-hawk: add a fixed regulator for ohci-da8xx
From: Bartosz Golaszewski
Instead of directly using the vbus GPIO we should model it as a fixed
regulator. Add all necessary fix-ups for the regulator to be registered
and configure the vbus GPIO as its enable pin.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 49 +++--
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c
b/arch/arm/mach-davinci/board-omapl138-hawk.c
index e244c8648594..db177a6a7e48 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -298,15 +299,50 @@ static const short da850_hawk_usb11_pins[] = {
-1
};
-static struct gpiod_lookup_table hawk_usb_gpio_lookup = {
+static struct regulator_consumer_supply hawk_usb_supplies[] = {
+ REGULATOR_SUPPLY("vbus", NULL),
+};
+
+static struct regulator_init_data hawk_usb_vbus_data = {
+ .consumer_supplies = hawk_usb_supplies,
+ .num_consumer_supplies = ARRAY_SIZE(hawk_usb_supplies),
+};
+
+static struct fixed_voltage_config hawk_usb_vbus = {
+ .supply_name= "vbus",
+ .microvolts = 330,
+ .init_data = _usb_vbus_data,
+};
+
+static struct platform_device hawk_usb_vbus_device = {
+ .name = "reg-fixed-voltage",
+ .id = 0,
+ .dev= {
+ .platform_data = _usb_vbus,
+ },
+};
+
+static struct gpiod_lookup_table hawk_usb_oc_gpio_lookup = {
.dev_id = "ohci-da8xx",
.table = {
- GPIO_LOOKUP("davinci_gpio", DA850_USB1_VBUS_PIN, "vbus", 0),
GPIO_LOOKUP("davinci_gpio", DA850_USB1_OC_PIN, "oc", 0),
{ }
},
};
+static struct gpiod_lookup_table hawk_usb_vbus_gpio_lookup = {
+ .dev_id = "reg-fixed-voltage.0",
+ .table = {
+ GPIO_LOOKUP("davinci_gpio", DA850_USB1_VBUS_PIN, NULL, 0),
+ { }
+ },
+};
+
+static struct gpiod_lookup_table *hawk_usb_gpio_lookups[] = {
+ _usb_oc_gpio_lookup,
+ _usb_vbus_gpio_lookup,
+};
+
static struct da8xx_ohci_root_hub omapl138_hawk_usb11_pdata = {
/* TPS2087 switch @ 5V */
.potpgt = (3 + 1) / 2, /* 3 ms max */
@@ -327,12 +363,19 @@ static __init void omapl138_hawk_usb_init(void)
pr_warn("%s: USB PHY CLK registration failed: %d\n",
__func__, ret);
+ gpiod_add_lookup_tables(hawk_usb_gpio_lookups,
+ ARRAY_SIZE(hawk_usb_gpio_lookups));
+
ret = da8xx_register_usb_phy();
if (ret)
pr_warn("%s: USB PHY registration failed: %d\n",
__func__, ret);
- gpiod_add_lookup_table(_usb_gpio_lookup);
+ ret = platform_device_register(_usb_vbus_device);
+ if (ret) {
+ pr_warn("%s: Unable to register the vbus supply\n", __func__);
+ return;
+ }
ret = da8xx_register_usb11(_hawk_usb11_pdata);
if (ret)
--
2.21.0
[PATCH v4 2/6] usb: ohci-da8xx: let the regulator framework keep track of use count
From: Bartosz Golaszewski
There's no reason to have a separate variable to keep track of the
regulator state. The regulator core already does that. Remove
reg_enabled from struct da8xx_ohci_hcd.
Signed-off-by: Bartosz Golaszewski
Acked-by: Alan Stern
---
drivers/usb/host/ohci-da8xx.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/ohci-da8xx.c b/drivers/usb/host/ohci-da8xx.c
index ca8a94f15ac0..209a262b5565 100644
--- a/drivers/usb/host/ohci-da8xx.c
+++ b/drivers/usb/host/ohci-da8xx.c
@@ -40,7 +40,6 @@ struct da8xx_ohci_hcd {
struct phy *usb11_phy;
struct regulator *vbus_reg;
struct notifier_block nb;
- unsigned int reg_enabled;
struct gpio_desc *vbus_gpio;
struct gpio_desc *oc_gpio;
};
@@ -100,21 +99,18 @@ static int ohci_da8xx_set_power(struct usb_hcd *hcd, int
on)
if (!da8xx_ohci->vbus_reg)
return 0;
- if (on && !da8xx_ohci->reg_enabled) {
+ if (on) {
ret = regulator_enable(da8xx_ohci->vbus_reg);
if (ret) {
dev_err(dev, "Failed to enable regulator: %d\n", ret);
return ret;
}
- da8xx_ohci->reg_enabled = 1;
-
- } else if (!on && da8xx_ohci->reg_enabled) {
+ } else {
ret = regulator_disable(da8xx_ohci->vbus_reg);
if (ret) {
dev_err(dev, "Failed to disable regulator: %d\n", ret);
return ret;
}
- da8xx_ohci->reg_enabled = 0;
}
return 0;
--
2.21.0
Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and randomizer support
On Thu, 11 Apr 2019 17:24:09 +0800 masonccy...@mxic.com.tw wrote: > Hi Boris, > > > > > > > > Subject > > > > > > > > > > > > Re: [PATCH] mtd: rawnand: Add Macronix NAND read retry and > > > randomizer > > > > > support > > > > > > > > > > > > On Tue, 9 Apr 2019 17:35:39 +0800 > > > > > > masonccy...@mxic.com.tw wrote: > > > > > > > > > > > > > > > + > > > > > > > > > +static const struct kobj_attribute sysfs_mxic_nand = > > > > > > > > > + __ATTR(nand_random, S_IRUGO | S_IWUSR, > > > > > > > > > + mxic_nand_rand_type_show, > > > > > > > > > + mxic_nand_rand_type_store); > > > > > > > > > > > > > > > > No, we don't want to expose that through a sysfs file, > > > especially > > > > > since > > > > > > > > changing the randomizer config means making the NAND > unreadable > > > for > > > > > > > > those that have used it before the change. > > > > > > > > > > > > > > > > > > > > > > Our on-die randomizer is still readable from user after the > > > function > > > > > > > is enabled. > > > > > > > > > > > > You mean the memory is still readable no matter the randomizer > > > state. > > > > > > Not sure how that's possible, but okay. > > > > > > > > > > > > > This randomizer is just like a internal memory cell > > > > > > > reliability enhanced. > > > > > > > > > > > > Why don't you enable it by default then? > > > > > > > > > > The penalty of randomizer is read/write performance down. > > > > > i.e,. tPROG 300 us to 340 us (randomizer enable) > > > > > therefore, disable it by default. > > > > > > > > I'm a bit puzzled. On the NAND I've seen that required data > > > > randomization it's not something you'd want to disable as this > implied > > > > poor data retention. What's the use case here? Are we talking about > SLC > > > > or MLC NANDs? Should we enable this feature once we start seeing > that > > > > the NAND starts being less reliable (basically when read-retry > happens > > > > more often)? I really think this is something you should decide > kernel > > > > side, because users have no clue when it's appropriate to switch > this > > > > feature on/off. > > > > > > > > > > It's SLC NAND and seems to has nothing to do with read-retry happens. > > > later, I will get more information for your concerns. > > > > Well, this feature is optional, and can be enabled to improve > > reliability. Sounds like a good reason to enable it when your NAND > > device starts showing reliability issues, and the number of read_retry > > attempts reflects the wear level pretty well. Alternatively, you could > > use the number of bitflips, but, in any case, don't expect the user to > > take this decision, because almost nobody knows what the randomizer > > is needed for. > > > > > > > > > > > > > > > > > > > > > > > It could be enable at any time with OTP bit function and > that's > > > why > > > > > > > we patch it by sys-fs. > > > > > > > > > > > > Sorry, but that's not a good reason to expose that through > sysfs. > > > > > > > > > > Any good way to expose randomizer function for user ? > > > > > > > > Don't expose it :P. > > > > > > oh, okay, I will remove sys-fs randomizer. > > > > > > Is it OK to keep set/get features for randomizer ? > > > > I don't think it's a good idea to have dead code, so no. But I'm pretty > > sure we'll find a way to use/expose this feature. > > okay, great! > Looking forward to hearing this feature use/expose. But for that to happen we are waiting for inputs about when this is supposed to be used...
Re: [PATCH 0/2] tools: Fixes for pcitest
On Thu, Apr 04, 2019 at 04:36:07PM +0530, Kishon Vijay Abraham I wrote: > Hi Lorenzo, > > This series includes a couple of patches, one which fixes > inadvertent removal of pcitest.sh from kernel repo when > doing a "clean" and other lets the user use 'h' option to > display the list of options supported by pcitest. > > Thanks > Kishon > > Kishon Vijay Abraham I (2): > tools: PCI: Add 'h' in optstring of getopt() > tools: PCI: Handle pcitest.sh independently from pcitest > > tools/pci/Makefile | 8 +++- > tools/pci/pcitest.c | 4 ++-- > 2 files changed, 9 insertions(+), 3 deletions(-) Applied to pci/misc for v5.2, thanks. Lorenzo
Re: [PATCH v2] modpost: make KBUILD_MODPOST_WARN also configurable for
seems subject is incomplete in v2, v3 posted:
https://lore.kernel.org/patchwork/patch/1060505/
Thanks!
- Wladislav
On 10.04.2019 11:23, Wiebe, Wladislav (Nokia - DE/Ulm) wrote:
> Commit ea837f1c0503 ("kbuild: make modpost processing configurable")
> was intended to give KBUILD_MODPOST_WARN flexibility to be configurable.
> Right now KBUILD_MODPOST_WARN gets just ignored when KBUILD_EXTMOD is
> set which happens per default when building modules out of the tree.
>
> This change gives the opportunity to define module build behaving also
> in case of out of tree builds and default will become exit on error.
> Errors which can be detected by the build should be trapped out of the box
> there, unless somebody wants to notice broken stuff later at runtime.
>
> As this patch changes the default behaving from warning to error,
> users can consider to fix it for external module builds by:
> - providing module symbol table via KBUILD_EXTRA_SYMBOLS for
>modules which are dependent
> - OR getting old behaving back by passing KBUILD_MODPOST_WARN to the build
>
> Signed-off-by: Wladislav Wiebe
> ---
> scripts/Makefile.modpost | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
> index 6b7f354f189a..fec6ec2ffa47 100644
> --- a/scripts/Makefile.modpost
> +++ b/scripts/Makefile.modpost
> @@ -78,7 +78,7 @@ modpost = scripts/mod/modpost\
>$(if $(KBUILD_EXTRA_SYMBOLS), $(patsubst %, -e %,$(KBUILD_EXTRA_SYMBOLS)))
> \
>$(if $(KBUILD_EXTMOD),-o $(modulesymfile)) \
>$(if $(CONFIG_SECTION_MISMATCH_WARN_ONLY),,-E) \
> - $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w)
> + $(if $(KBUILD_MODPOST_WARN),-w)
>
> MODPOST_OPT=$(subst -i,-n,$(filter -i,$(MAKEFLAGS)))
>
>
Re: [PATCH linux] objtool: fix pkg-config query in case of cross-compilation
Le 11/04/2019 à 10:52, Rolf Eike Beer a écrit :
> Am Donnerstag, 11. April 2019, 10:39:40 CEST schrieb Nicolas Dichtel:
>> In case of cross-compilation, there may be two pkg-config tools, one for
>> the host and one for the target. Enable to override the default name.
>>
>> Fixes: 056d28d135bc ("objtool: Query pkg-config for libelf location")
>> Signed-off-by: Nicolas Dichtel
>
> If you do that, you have to fix a lot of other places, too. This starts in
> scripts/kconfig/ and also includes e.g. tools/testing/.
>
> Usually you have pkg-config for host and ${target_platform}-pkg-config for
> the
My use case was for buildroot, which define pkg-config and host-pkgconf. In
fact, I've just seen that a buildroot patch was accepted for this problem:
https://patchwork.ozlabs.org/patch/1081379/
Regards,
Nicolas
[PATCH v3] modpost: make KBUILD_MODPOST_WARN also configurable for external modules
Commit ea837f1c0503 ("kbuild: make modpost processing configurable")
was intended to give KBUILD_MODPOST_WARN flexibility to be configurable.
Right now KBUILD_MODPOST_WARN gets just ignored when KBUILD_EXTMOD is
set which happens per default when building modules out of the tree.
This change gives the opportunity to define module build behaving also
in case of out of tree builds and default will become exit on error.
Errors which can be detected by the build should be trapped out of the box
there, unless somebody wants to notice broken stuff later at runtime.
As this patch changes the default behaving from warning to error,
users can consider to fix it for external module builds by:
- providing module symbol table via KBUILD_EXTRA_SYMBOLS for
modules which are dependent
- OR getting old behaving back by passing KBUILD_MODPOST_WARN to the build
Signed-off-by: Wladislav Wiebe
---
scripts/Makefile.modpost | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 6b7f354f189a..fec6ec2ffa47 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -78,7 +78,7 @@ modpost = scripts/mod/modpost\
$(if $(KBUILD_EXTRA_SYMBOLS), $(patsubst %, -e %,$(KBUILD_EXTRA_SYMBOLS))) \
$(if $(KBUILD_EXTMOD),-o $(modulesymfile)) \
$(if $(CONFIG_SECTION_MISMATCH_WARN_ONLY),,-E) \
- $(if $(KBUILD_EXTMOD)$(KBUILD_MODPOST_WARN),-w)
+ $(if $(KBUILD_MODPOST_WARN),-w)
MODPOST_OPT=$(subst -i,-n,$(filter -i,$(MAKEFLAGS)))
--
2.19.2
[PATCH] KVM: fix spectrev1 gadgets
These were found with smatch, and then generalized when applicable.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/lapic.c | 4 +++-
include/linux/kvm_host.h | 10 ++
virt/kvm/irqchip.c | 5 +++--
virt/kvm/kvm_main.c | 6 --
4 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 991fdf7fc17f..9bf70cf84564 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -138,6 +138,7 @@ static inline bool kvm_apic_map_get_logical_dest(struct
kvm_apic_map *map,
if (offset <= max_apic_id) {
u8 cluster_size = min(max_apic_id - offset + 1, 16U);
+ offset = array_index_nospec(offset, map->max_apic_id +
1);
*cluster = >phys_map[offset];
*mask = dest_id & (0x >> (16 - cluster_size));
} else {
@@ -901,7 +902,8 @@ static inline bool kvm_apic_map_get_dest_lapic(struct kvm
*kvm,
if (irq->dest_id > map->max_apic_id) {
*bitmap = 0;
} else {
- *dst = >phys_map[irq->dest_id];
+ u32 dest_id = array_index_nospec(irq->dest_id,
map->max_apic_id + 1);
+ *dst = >phys_map[dest_id];
*bitmap = 1;
}
return true;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 9d55c63db09b..640a03642766 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -513,10 +514,10 @@ static inline struct kvm_io_bus *kvm_get_bus(struct kvm
*kvm, enum kvm_bus idx)
static inline struct kvm_vcpu *kvm_get_vcpu(struct kvm *kvm, int i)
{
- /* Pairs with smp_wmb() in kvm_vm_ioctl_create_vcpu, in case
-* the caller has read kvm->online_vcpus before (as is the case
-* for kvm_for_each_vcpu, for example).
-*/
+ int num_vcpus = atomic_read(>online_vcpus);
+ i = array_index_nospec(i, num_vcpus);
+
+ /* Pairs with smp_wmb() in kvm_vm_ioctl_create_vcpu. */
smp_rmb();
return kvm->vcpus[i];
}
@@ -600,6 +601,7 @@ int kvm_init(void *opaque, unsigned vcpu_size, unsigned
vcpu_align,
static inline struct kvm_memslots *__kvm_memslots(struct kvm *kvm, int as_id)
{
+ as_id = array_index_nospec(as_id, KVM_ADDRESS_SPACE_NUM);
return srcu_dereference_check(kvm->memslots[as_id], >srcu,
lockdep_is_held(>slots_lock) ||
!refcount_read(>users_count));
diff --git a/virt/kvm/irqchip.c b/virt/kvm/irqchip.c
index 3547b0d8c91e..79e59e4fa3dc 100644
--- a/virt/kvm/irqchip.c
+++ b/virt/kvm/irqchip.c
@@ -144,18 +144,19 @@ static int setup_routing_entry(struct kvm *kvm,
{
struct kvm_kernel_irq_routing_entry *ei;
int r;
+ u32 gsi = array_index_nospec(ue->gsi, KVM_MAX_IRQ_ROUTES);
/*
* Do not allow GSI to be mapped to the same irqchip more than once.
* Allow only one to one mapping between GSI and non-irqchip routing.
*/
- hlist_for_each_entry(ei, >map[ue->gsi], link)
+ hlist_for_each_entry(ei, >map[gsi], link)
if (ei->type != KVM_IRQ_ROUTING_IRQCHIP ||
ue->type != KVM_IRQ_ROUTING_IRQCHIP ||
ue->u.irqchip.irqchip == ei->irqchip.irqchip)
return -EINVAL;
- e->gsi = ue->gsi;
+ e->gsi = gsi;
e->type = ue->type;
r = kvm_set_routing_entry(kvm, e, ue);
if (r)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 55fe8e20d8fd..dc8edc97ba85 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2977,12 +2977,14 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
struct kvm_device_ops *ops = NULL;
struct kvm_device *dev;
bool test = cd->flags & KVM_CREATE_DEVICE_TEST;
+ int type;
int ret;
if (cd->type >= ARRAY_SIZE(kvm_device_ops_table))
return -ENODEV;
- ops = kvm_device_ops_table[cd->type];
+ type = array_index_nospec(cd->type, ARRAY_SIZE(kvm_device_ops_table));
+ ops = kvm_device_ops_table[type];
if (ops == NULL)
return -ENODEV;
@@ -2997,7 +2999,7 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
dev->kvm = kvm;
mutex_lock(>lock);
- ret = ops->create(dev, cd->type);
+ ret = ops->create(dev, type);
if (ret < 0) {
mutex_unlock(>lock);
kfree(dev);
--
1.8.3.1
[GIT PULL] global spelling corrections for v5.1.0-rc5
_I hope I did this right... Apologies if I made a procedure mistake._ The following changes since commit 582549e3fbe137eb6ce9be591aca25ca36b4: Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma (2019-04-10 09:39:04 -1000) are available in the Git repository at: git://github.com/vdmkenny/linux-spelling-fix.git tags/common- spelling-fixes-5.1.0-rc5 for you to fetch changes up to 6ee0055f3414a64133228e82004ea60d0e659d6d: fix common spelling mistakes (2019-04-11 10:22:24 +0200) This PR contains a set of global spelling fixes of commonly miss- spelled words. Mostly documentation and comments were impacted, but a few lines of code were affected as well. Kenny Van de Maele (1): fix common spelling mistakes Documentation/ABI/testing/sysfs-fs-f2fs | 2 +- Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 2 +- Documentation/networking/ip-sysctl.txt| 2 +- arch/arc/plat-eznps/entry.S | 2 +- arch/arm/include/asm/xen/page-coherent.h | 2 +- arch/arm/kernel/entry-header.S| 2 +- arch/arm/mach-imx/mm-imx3.c | 2 +- arch/arm/mach-imx/suspend-imx6.S | 2 +- arch/arm/net/bpf_jit_32.c | 2 +- arch/arm64/include/asm/xen/page-coherent.h| 2 +- arch/c6x/kernel/asm-offsets.c | 2 +- arch/c6x/kernel/entry.S | 2 +- arch/m68k/math-emu/fp_util.S | 2 +- arch/powerpc/include/asm/book3s/64/radix.h| 2 +- arch/powerpc/kvm/book3s_xive.c| 4 ++-- arch/powerpc/mm/hash_native_64.c | 2 +- arch/x86/crypto/twofish-x86_64-asm_64-3way.S | 2 +- arch/x86/kernel/traps.c | 2 +- drivers/acpi/video_detect.c | 2 +- drivers/bus/mvebu-mbus.c | 2 +- drivers/clk/clk-hsdk-pll.c| 2 +- drivers/clk/ingenic/cgu.h | 2 +- drivers/clk/meson/axg.c | 2 +- drivers/clk/meson/g12a.c | 2 +- drivers/clk/meson/gxbb.c | 2 +- drivers/clk/rockchip/clk-cpu.c| 2 +- drivers/clk/samsung/clk-cpu.c | 2 +- drivers/crypto/cavium/cpt/cptpf_main.c| 8 --- - drivers/crypto/cavium/cpt/cptvf_main.c| 4 ++-- drivers/crypto/cavium/nitrox/nitrox_isr.c | 2 +- drivers/crypto/cavium/nitrox/nitrox_isr.h | 2 +- drivers/crypto/cavium/nitrox/nitrox_sriov.c | 2 +- drivers/crypto/ux500/hash/hash_alg.h | 2 +- drivers/dma/qcom/bam_dma.c| 2 +- drivers/firmware/efi/efi.c| 2 +- drivers/firmware/efi/libstub/efi-stub-helper.c| 2 +- drivers/firmware/efi/memmap.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +- drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 4 ++-- drivers/gpu/drm/amd/display/dc/dce/dce_stream_encoder.c | 4 ++-- drivers/gpu/drm/amd/display/dc/inc/compressor.h | 2 +- drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smumgr.c | 2 +- drivers/gpu/drm/drm_plane_helper.c| 2 +- drivers/gpu/drm/drm_vblank.c | 4 ++-- drivers/gpu/drm/i915/i915_irq.c | 2 +- drivers/gpu/drm/i915/i915_vma.c | 2 +- drivers/gpu/drm/i915/intel_atomic.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/radeon/radeon_vm.c| 2 +- drivers/gpu/drm/radeon/uvd_v1_0.c | 4 ++-- drivers/gpu/drm/tegra/hdmi.c | 2 +- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 2 +- drivers/hid/hid-appleir.c | 2 +- drivers/hid/usbhid/hiddev.c
Re: [RFC][PATCH 13/16] sched: Add core wide task selection and scheduling.
On Thu, Apr 11, 2019 at 11:05:41AM +0800, Aaron Lu wrote: > On Wed, Apr 10, 2019 at 04:44:18PM +0200, Peter Zijlstra wrote: > > When core_cookie==0 we shouldn't schedule the other siblings at all. > > Not even with another untagged task? > > I was thinking to leave host side tasks untagged, like kernel threads, > init and other system daemons or utilities etc., and tenant tasks tagged. > Then at least two untagged tasks can be scheduled on the same core. > > Kindly let me know if you see a problem with this. Let me clarify; when the rq->core->core_cookie == 0, each sibling should schedule independently. As Julien found, there were some issues here, but the intent was: core_cookie 0, independent scheduling core_cookie 0->n, core scheduling core_cookie n->0, one last core schedule to kick possibly forced idle siblings
Re: [PATCH v3 2/9] kbuild: Support for Symbols.list creation
On Wed, Apr 10, 2019 at 11:50:51AM -0400, Joe Lawrence wrote:
> -clean: archclean vmlinuxclean
> +klpclean:
> + $(Q) rm -f $(objtree)/Symbols.list
nit: $(SLIST) can be used here.
> +clean: archclean vmlinuxclean klpclean
>
> # mrproper - Delete all generated files, including .config
> #
> diff --git a/samples/livepatch/Makefile b/samples/livepatch/Makefile
> index 2472ce39a18d..8b9b42a258ad 100644
> --- a/samples/livepatch/Makefile
> +++ b/samples/livepatch/Makefile
> @@ -1,3 +1,4 @@
> +LIVEPATCH_livepatch-sample := y
> obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-sample.o
> obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-shadow-mod.o
> obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-shadow-fix1.o
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 76ca30cc4791..ca76bd2080f0 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -246,6 +246,11 @@ cmd_gen_ksymdeps = \
> $(CONFIG_SHELL) $(srctree)/scripts/gen_ksymdeps.sh $@ >>
> $(dot-target).cmd
> endif
>
> +ifdef CONFIG_LIVEPATCH
> +cmd_livepatch = $(if $(LIVEPATCH_$(basetarget)), \
> + $(shell touch $(MODVERDIR)/$(basetarget).livepatch))
> +endif
> +
> define rule_cc_o_c
> $(call cmd,checksrc)
> $(call cmd_and_fixdep,cc_o_c)
> @@ -280,6 +285,7 @@ $(obj)/%.o: $(src)/%.c $(recordmcount_source)
> $(objtool_dep) FORCE
> $(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source)
> $(objtool_dep) FORCE
> $(call cmd,force_checksrc)
> $(call if_changed_rule,cc_o_c)
> + $(call cmd_livepatch)
nit: maybe use "cmd,livepatch" to be consistent with the other call of
this function.
> @{ echo $(@:.o=.ko); echo $@; \
> $(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
>
> @@ -456,6 +462,7 @@ cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter
> %.o,$^) $(cmd_secanalysis
>
> $(multi-used-m): FORCE
> $(call if_changed,link_multi-m)
> + $(call cmd,livepatch)
> @{ echo $(@:.o=.ko); echo $(filter %.o,$^); \
> $(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
> $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
> --
> 2.20.1
>
--
Artem
Re: [RFC patch 40/41] stacktrace: Remove obsolete functions
On Wed, Apr 10, 2019 at 10:33:20PM -0500, Josh Poimboeuf wrote:
> On Wed, Apr 10, 2019 at 12:28:34PM +0200, Thomas Gleixner wrote:
> > +struct stack_trace {
> > + unsigned int nr_entries, max_entries;
> > + unsigned long *entries;
> > + int skip; /* input argument: How many entries to skip */
> > +};
>
> I was a bit surprised to see struct stack_trace still standing at the
> end of the patch set, but I guess 41 patches is enough :-) Do we want
> to eventually remove the struct altogether?
>
> I was also hoping to see the fragile "skipnr" go away in favor of
> something less dependent on compiler optimizations, but I'm not sure how
> feasible that would be.
It will die, but that only takes another nr_arch+1 patches.
Re: [PATCH] mm/memory_hotplug: Drop memory device reference after find_memory_block()
On 11.04.19 10:41, Michal Hocko wrote:
> On Wed 10-04-19 12:14:55, David Hildenbrand wrote:
>> While current node handling is probably terribly broken for memory block
>> devices that span several nodes (only possible when added during boot,
>> and something like that should be blocked completely), properly put the
>> device reference we obtained via find_memory_block() to get the nid.
>
> The changelog could see some improvements I believe. (Half) stating
> broken status of multinode memblock is not really useful without a wider
> context so I would simply remove it. More to the point, it would be much
> better to actually describe the actual problem and the user visible
> effect.
>
> "
> d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug") has started
> using find_memory_block to get a nodeid for the beginnig of the onlined
> pfn range. The commit has missed that the memblock contains a reference
> counted object and a missing put_device will leak the kobject behind
> which ADD THE USER VISIBLE EFFECT HERE.
> "
I don't think mentioning the commit a second time is really needed.
"
Right now we are using find_memory_block() to get the node id for the
pfn range to online. We are missing to drop a reference to the memory
block device. While the device still gets unregistered via
device_unregister(), resulting in no user visible problem, the device is
never released via device_release(), resulting in a memory leak. Fix
that by properly using a put_device().
"
>
>> Fixes: d0dc12e86b31 ("mm/memory_hotplug: optimize memory hotplug")
>> Cc: Andrew Morton
>> Cc: Oscar Salvador
>> Cc: Michal Hocko
>> Cc: David Hildenbrand
>> Cc: Pavel Tatashin
>> Cc: Wei Yang
>> Cc: Qian Cai
>> Cc: Arun KS
>> Cc: Mathieu Malaterre
>> Signed-off-by: David Hildenbrand
>
> Other than that
> Acked-by: Michal Hocko
>
>> ---
>> mm/memory_hotplug.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index 5eb4a4c7c21b..328878b6799d 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -854,6 +854,7 @@ int __ref online_pages(unsigned long pfn, unsigned long
>> nr_pages, int online_typ
>> */
>> mem = find_memory_block(__pfn_to_section(pfn));
>> nid = mem->nid;
>> +put_device(>dev);
>>
>> /* associate pfn range with the zone */
>> zone = move_pfn_range(online_type, nid, pfn, nr_pages);
>> --
>> 2.20.1
>
--
Thanks,
David / dhildenb
Re: [v3 PATCH] PCI: mediatek: get optional clock by devm_clk_get_optional()
On Wed, Apr 10, 2019 at 02:54:16PM +0800, Chunfeng Yun wrote:
> Use devm_clk_get_optional() to get optional clock
>
> Cc: Ryder Lee
> Cc: Honghui Zhang
> Signed-off-by: Chunfeng Yun
> Acked-by: Ryder Lee
> Acked-by: Honghui Zhang
> ---
> v3: add Acked-by Ryder and Honghui
> ---
> drivers/pci/controller/pcie-mediatek.c | 50 --
> 1 file changed, 15 insertions(+), 35 deletions(-)
Applied to pci/mediatek for v5.2, thanks.
Lorenzo
> diff --git a/drivers/pci/controller/pcie-mediatek.c
> b/drivers/pci/controller/pcie-mediatek.c
> index 0b6c72804e03..adb6cb15daa2 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -915,49 +915,29 @@ static int mtk_pcie_parse_port(struct mtk_pcie *pcie,
>
> /* sys_ck might be divided into the following parts in some chips */
> snprintf(name, sizeof(name), "ahb_ck%d", slot);
> - port->ahb_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->ahb_ck)) {
> - if (PTR_ERR(port->ahb_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->ahb_ck = NULL;
> - }
> + port->ahb_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->ahb_ck))
> + return PTR_ERR(port->ahb_ck);
>
> snprintf(name, sizeof(name), "axi_ck%d", slot);
> - port->axi_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->axi_ck)) {
> - if (PTR_ERR(port->axi_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->axi_ck = NULL;
> - }
> + port->axi_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->axi_ck))
> + return PTR_ERR(port->axi_ck);
>
> snprintf(name, sizeof(name), "aux_ck%d", slot);
> - port->aux_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->aux_ck)) {
> - if (PTR_ERR(port->aux_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->aux_ck = NULL;
> - }
> + port->aux_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->aux_ck))
> + return PTR_ERR(port->aux_ck);
>
> snprintf(name, sizeof(name), "obff_ck%d", slot);
> - port->obff_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->obff_ck)) {
> - if (PTR_ERR(port->obff_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->obff_ck = NULL;
> - }
> + port->obff_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->obff_ck))
> + return PTR_ERR(port->obff_ck);
>
> snprintf(name, sizeof(name), "pipe_ck%d", slot);
> - port->pipe_ck = devm_clk_get(dev, name);
> - if (IS_ERR(port->pipe_ck)) {
> - if (PTR_ERR(port->pipe_ck) == -EPROBE_DEFER)
> - return -EPROBE_DEFER;
> -
> - port->pipe_ck = NULL;
> - }
> + port->pipe_ck = devm_clk_get_optional(dev, name);
> + if (IS_ERR(port->pipe_ck))
> + return PTR_ERR(port->pipe_ck);
>
> snprintf(name, sizeof(name), "pcie-rst%d", slot);
> port->reset = devm_reset_control_get_optional_exclusive(dev, name);
> --
> 2.21.0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH V2 2/2] perf/x86/intel: Add Tremont core PMU support
On Wed, Apr 10, 2019 at 11:57:09AM -0700, kan.li...@linux.intel.com wrote:
> +static struct event_constraint *
> +tnt_get_event_constraints(struct cpu_hw_events *cpuc, int idx,
> + struct perf_event *event)
That 'tnt' still cracks me up, I keep seeing explosions.
> +{
> + struct event_constraint *c;
> +
> + /*
> + * :ppp means to do reduced skid PEBS,
> + * which is available on PMC0 and fixed counter 0.
> + */
> + if (event->attr.precise_ip == 3) {
> + /* Force instruction:ppp on PMC0 and Fixed counter 0 */
> + if (EVENT_CONFIG(event->hw.config) == X86_CONFIG(.event=0xc0))
> + return _counter0_constraint;
> +
> + return _constraint;
> + }
> +
> + c = intel_get_event_constraints(cpuc, idx, event);
> +
> + return c;
> +}
I changed that like so:
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3508,7 +3508,7 @@ tnt_get_event_constraints(struct cpu_hw_
*/
if (event->attr.precise_ip == 3) {
/* Force instruction:ppp on PMC0 and Fixed counter 0 */
- if (EVENT_CONFIG(event->hw.config) == X86_CONFIG(.event=0xc0))
+ if (constraint_match(_counter0_constraint,
event->hw.config))
return _counter0_constraint;
return _constraint;
And maybe we should do:
s/fixed_counter0_constraint/fixed0_constraint/'
Those two constraints only differ by a single character, that's bad for
reading comprehension.
In fact, I just did that too.
RE: [PATCH v2] usb: typec: tcpm: collision avoidance
On 10 April 2019 17:39, Hans de Goede wrote: > On 10-04-19 18:14, Adam Thomson wrote: > > On 10 April 2019 16:45, Hans de Goede wrote: > > > >> Hi Kyle, > >> > >> On 10-04-19 14:49, Kyle Tso wrote: > >>> On Wed, Apr 10, 2019 at 6:32 PM Adam Thomson > >>> wrote: > > On 09 April 2019 15:41, Hans de Goede wrote: > > > Hi, > > > > On 09-04-19 15:06, Heikki Krogerus wrote: > >> On Tue, Apr 09, 2019 at 04:02:30PM +0300, Heikki Krogerus wrote: > >>> +Hans > >>> > >>> On Mon, Apr 08, 2019 at 10:17:35PM +0800, Kyle Tso wrote: > On Fri, Apr 5, 2019 at 9:42 PM Guenter Roeck > > >> wrote: > > > > On 4/4/19 7:13 AM, Heikki Krogerus wrote: > >> Hi, > >> > >> On Fri, Mar 22, 2019 at 08:17:45PM +0800, Kyle Tso wrote: > >>> This patch provides the implementation of Collision > >>> Avoidance introduced in PD3.0. The start of each Atomic > >>> Message Sequence > >>> (AMS) initiated by the port will be denied if the current > >>> AMS is not interruptible. The Source port will set the CC to > >>> SinkTxNG if it is going to initiate an AMS, and SinkTxOk > >>> otherwise. > >>> Meanwhile, any AMS initiated by a Sink port will be denied > >>> in TCPM if the port partner (Source) sets SinkTxNG except > >>> for HARD_RESET > > and SOFT_RESET. > >> > >> I tested this with my GDBWin which has fusb302. When I > >> plug-in DisplayPort adapter, the partner device never gets > >> registered, and I see steady flow of warnings from fusb302: > >> > > > > FWIW, I made multiple attempts to review the patch. Each time > > I get stuck after a while and notice that I don't understand > > what is going > >> on. > > > > Maybe the state machine needs a complete overhaul. It seems to > > have reached a point where it is getting too complex to > > understand what is going > > on. > > > >> [ 693.391176] Vconn is on during toggle start [ 693.391250] > >> WARNING: CPU: 2 PID: 30 at > >> drivers/usb/typec/tcpm/fusb302.c:562 > >> fusb302_set_toggling+0x129/0x130 [fusb302] [ 693.400293] > >> Modules > > linked in: intel_xhci_usb_role_switch fusb302 tcpm roles > > pi3usb30532 > > i915 typec intel_gtt intel_cht_int33fe > >> [ 693.406309] CPU: 2 PID: 30 Comm: kworker/u8:1 Tainted: G > >> W > > 5.1.0-rc3-heikki+ #17 > >> [ 693.408434] cht_wcove_pwrsrc cht_wcove_pwrsrc: Could not > >> detect charger type [ 693.412278] Hardware name: Default > >> string Default string/Default string, BIOS 5.11 05/25/2017 [ > >> 693.412283] > >> Workqueue: i2c-fusb302 tcpm_state_machine_work [tcpm] [ > >> 693.424256] RIP: 0010:fusb302_set_toggling+0x129/0x130 > >> [fusb302] [ 693.427234] Code: 89 df e8 da ef ff ff 85 c0 78 > >> c6 > >> c6 83 b0 01 00 > >> 00 00 eb b7 b9 02 00 00 00 e9 48 ff ff ff 48 c7 c7 20 e8 21 > >> a0 > >> e8 8e 0c e4 e0 <0f> 0b e9 58 ff ff ff 41 55 4c 8d 6f e8 41 54 > >> 41 89 > >> f4 55 53 48 8d [ 693.436204] RSP: :c976bd90 EFLAGS: > >> 00010286 [ 693.439174] RAX: RBX: > >> 888178080028 RCX: [ 693.442157] RDX: > >> 001f RSI: 8259051f RDI: 8259091f > >> [ 693.445130] RBP: 0003 R08: 82590500 R09: > >> 000202c0 [ 693.448100] R10: 010cb24a3d18 R11: > >> 001e R12: 8881780801b0 [ 693.451086] R13: > > a021e4e5 R14: 0003 R15: 888178080040 [ > > 693.454060] > >> FS: > > () GS:88817bb0() > > knlGS: [ 693.460009] CS: 0010 DS: ES: CR0: > >> 80050033 [ 693.462984] CR2: > > f7fb74a0 CR3: 0200d000 CR4: 001006e0 [ > > 693.465969] Call Trace: > >> [ 693.468937] tcpm_set_cc+0xb9/0x170 [fusb302] [ > >> 693.471894] > >> tcpm_ams_start+0x1b8/0x2a0 [tcpm] > > > > tcpm_ams_start() sets TYPEC_CC_RP_1_5 unconditionally, no > > matter what. This causes the fusb302 code to start toggling. > > As such, it may well attempt to start toggling in the wrong state. > > > > Guenter > > > > I read the fusb302 spec but failed to find the statement that > says it should "set toggling" when CC switches among > >> default/medium/high. > > quot from fusb302 spec: > "The FUSB302 allows the host software to change the charging > current capabilities of the port through the HOST_CUR control > bits. If the HOST_CUR bits are changed prior to
RE: [PATCH] KVM: x86: optimize check for valid PAT value
From: Paolo Bonzini > Sent: 10 April 2019 18:09 > On 10/04/19 16:57, Sean Christopherson wrote: > > On Wed, Apr 10, 2019 at 12:55:53PM +, David Laight wrote: > >> From: Paolo Bonzini > >>> Sent: 10 April 2019 10:55 > >>> > >>> This check will soon be done on every nested vmentry and vmexit, > >>> "parallelize" it using bitwise operations. ... > >> How about: > >>/* > >> * Each byte must be 0, 1, 4, 5, 6 or 7. > >> * Convert 001x to 011x then 100x so 2 and 3 fail the test. > >> */ > >>data |= (data ^ 0x0404040404040404ULL)) + 0x0202020202020202ULL; > >>if (data & 0xF8F8F8F8F8F8F8F8ULL) > >>return false; ... > > Really fancy: > >0x00048447 <+247>: movabs $0x404040404040404,%rcx > >0x00048451 <+257>: movabs $0x202020202020202,%rax > >0x0004845b <+267>: xor%rdx,%rcx > >0x0004845e <+270>: add%rax,%rcx > >0x00048461 <+273>: movabs $0xf8f8f8f8f8f8f8f8,%rax > >0x0004846b <+283>: or %rcx,%rdx > >0x0004846e <+286>: test %rax,%rdx > >0x00048471 <+289>: sete %al > >0x00048474 <+292>: retq > > Yeah, the three constants are expensive. Too bad the really fancy > version sums twos and xors fours; if it were the opposite, it could have > used lea and then I would have chosen that one just for the coolness factor. The constants are just big, if the code is inlined they are probably otherwise free (they won't change the length of the dependency chain). The twos can be generated from the fours without increasing the length of the dependency chain and saving some bytes. It may be possible to generate shorter code that executes just as fast by generating a single constant and deriving the others from it. - generate 4s - needed first - shift right 2 to get 1s (in parallel with the xor) - use lea to get 6s (in parallel with an lea to do the add) - invert the 1s to get FEs (also in parallel with the add) - xor the FEs with the 6s to get F8s (in parallel with the or) - and/test for the result I'm not going to try to persuade gcc to go that. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 1/2] mmc: let the dma map ops handle bouncing
Hi Christoph,
On Thu, 11 Apr 2019 at 09:10, Christoph Hellwig wrote:
>
> Just like we do for all other block drivers. Especially as the limit
> imposed at the moment might be way to pessimistic for iommus.
I would appreciate some information in the changelog, as it's quite
unclear of what this change really means.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/mmc/core/queue.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
> index 7c364a9c4eeb..eb9c0692062c 100644
> --- a/drivers/mmc/core/queue.c
> +++ b/drivers/mmc/core/queue.c
> @@ -354,18 +354,15 @@ static const struct blk_mq_ops mmc_mq_ops = {
> static void mmc_setup_queue(struct mmc_queue *mq, struct mmc_card *card)
> {
> struct mmc_host *host = card->host;
> - u64 limit = BLK_BOUNCE_HIGH;
> unsigned block_size = 512;
>
> - if (mmc_dev(host)->dma_mask && *mmc_dev(host)->dma_mask)
> - limit = (u64)dma_max_pfn(mmc_dev(host)) << PAGE_SHIFT;
> -
> blk_queue_flag_set(QUEUE_FLAG_NONROT, mq->queue);
> blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, mq->queue);
> if (mmc_can_erase(card))
> mmc_queue_setup_discard(mq->queue, card);
>
> - blk_queue_bounce_limit(mq->queue, limit);
> + if (!mmc_dev(host)->dma_mask || !*mmc_dev(host)->dma_mask)
> + blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_HIGH);
So this means we are not going to set a bounce limit for the queue, in
case we have a dma mask.
Why isn't that needed no more? Whats has changed?
> blk_queue_max_hw_sectors(mq->queue,
> min(host->max_blk_count, host->max_req_size / 512));
> blk_queue_max_segments(mq->queue, host->max_segs);
> --
> 2.20.1
>
Kind regards
Uffe
Re: [PATCH V5 08/12] perf/x86/intel: Add Icelake support
On Wed, Apr 10, 2019 at 09:47:20PM +0200, Peter Zijlstra wrote: > Sure, those are actually forced 0 with the existing thing. > > I'll go fold smething like back in. Thanks! > > @@ -3472,7 +3475,7 @@ icl_get_event_constraints(struct cpu_hw_events *cpuc, > > int idx, > > * Force instruction:ppp in Fixed counter 0 > > */ > > if ((event->attr.precise_ip == 3) && > > - (event->hw.config == X86_CONFIG(.event=0xc0))) > > + (EVENT_CONFIG(event->hw.config) == X86_CONFIG(.event=0xc0))) > > return _counter0_constraint; > > > > return hsw_get_event_constraints(cpuc, idx, event); Staring at that I came up with the below; how does that look? Note: FIXED_EVENT_CONSTRAINT(0x00c0, 0) has FIXED_EVENT_FLAGS for ->cmask and includes the correct event code. --- --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -3433,7 +3433,7 @@ icl_get_event_constraints(struct cpu_hw_ * Force instruction:ppp in Fixed counter 0 */ if ((event->attr.precise_ip == 3) && - (event->hw.config == X86_CONFIG(.event=0xc0))) + constraint_match(_counter0_constraint, event->hw.config)) return _counter0_constraint; return hsw_get_event_constraints(cpuc, idx, event);
[PATCH v4 2/2] tty: serial: add driver for the SiFive UART
Add a serial driver for the SiFive UART, found on SiFive FU540 devices (among others). The underlying serial IP block is relatively basic, and currently does not support serial break detection. Further information on the IP block can be found in the documentation and Chisel sources: https://static.dev.sifive.com/FU540-C000-v1.0.pdf https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/uart This driver was written in collaboration with Wesley Terpstra . Tested on a SiFive HiFive Unleashed A00 board, using BBL and the open- source FSBL (using a DT file based on what's targeted for mainline). This revision incorporates changes based on comments by Emil Renner Berthing . Signed-off-by: Paul Walmsley Signed-off-by: Paul Walmsley Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: Palmer Dabbelt Cc: Wesley Terpstra Cc: linux-ser...@vger.kernel.org Cc: linux-ri...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: Julia Lawall --- drivers/tty/serial/Kconfig | 24 + drivers/tty/serial/Makefile |1 + drivers/tty/serial/sifive.c | 1067 ++ include/uapi/linux/serial_core.h |3 + 4 files changed, 1095 insertions(+) create mode 100644 drivers/tty/serial/sifive.c diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 72966bc0ac76..561e053b690a 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -1095,6 +1095,30 @@ config SERIAL_OMAP_CONSOLE your boot loader about how to pass options to the kernel at boot time.) +config SERIAL_SIFIVE + tristate "SiFive UART support" + depends on OF + select SERIAL_CORE + help + Select this option if you are building a kernel for a device that + contains a SiFive UART IP block. This type of UART is present on + SiFive FU540 SoCs, among others. + +config SERIAL_SIFIVE_CONSOLE + bool "Console on SiFive UART" + depends on SERIAL_SIFIVE=y + select SERIAL_CORE_CONSOLE + help + Select this option if you would like to use a SiFive UART as the + system console. + + Even if you say Y here, the currently visible virtual console + (/dev/tty0) will still be used as the system console by default, but + you can alter that using a kernel command line option such as + "console=ttySIFx". (Try "man bootparam" or see the documentation of + your boot loader about how to pass options to the kernel at + boot time.) + config SERIAL_LANTIQ bool "Lantiq serial driver" depends on LANTIQ diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile index 40b702aaa85e..2aff1d07d08b 100644 --- a/drivers/tty/serial/Makefile +++ b/drivers/tty/serial/Makefile @@ -92,6 +92,7 @@ obj-$(CONFIG_SERIAL_PIC32)+= pic32_uart.o obj-$(CONFIG_SERIAL_MPS2_UART) += mps2-uart.o obj-$(CONFIG_SERIAL_OWL) += owl-uart.o obj-$(CONFIG_SERIAL_RDA) += rda-uart.o +obj-$(CONFIG_SERIAL_SIFIVE)+= sifive.o # GPIOLIB helpers for modem control lines obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o diff --git a/drivers/tty/serial/sifive.c b/drivers/tty/serial/sifive.c new file mode 100644 index ..7401cfed0f48 --- /dev/null +++ b/drivers/tty/serial/sifive.c @@ -0,0 +1,1067 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * SiFive UART driver + * Copyright (C) 2018 Paul Walmsley + * Copyright (C) 2018 SiFive + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Based partially on: + * - drivers/tty/serial/pxa.c + * - drivers/tty/serial/amba-pl011.c + * - drivers/tty/serial/uartlite.c + * - drivers/tty/serial/omap-serial.c + * - drivers/pwm/pwm-sifive.c + * + * See the following sources for further documentation: + * - Chapter 19 "Universal Asynchronous Receiver/Transmitter (UART)" of + * SiFive FE310-G000 v2p3 + * - The tree/master/src/main/scala/devices/uart directory of + * https://github.com/sifive/sifive-blocks/ + * + * The SiFive UART design is not 8250-compatible. The following common + * features are not supported: + * - Word lengths other than 8 bits + * - Break handling + * - Parity + * - Flow control + * - Modem signals (DSR, RI, etc.) + * On the other hand, the design is free from the baggage of the 8250 + * programming model. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + *
[PATCH v4 1/2] dt-bindings: serial: add documentation for the SiFive UART driver
Add DT binding documentation for the Linux driver for the SiFive
asynchronous serial IP block.
This revision incorporates changes based on feedback from Rob
Herring .
Signed-off-by: Paul Walmsley
Signed-off-by: Paul Walmsley
Cc: linux-ser...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-ri...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: Rob Herring
Cc: Mark Rutland
Cc: Palmer Dabbelt
---
.../bindings/serial/sifive-serial.txt | 33 +++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/sifive-serial.txt
diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.txt
b/Documentation/devicetree/bindings/serial/sifive-serial.txt
new file mode 100644
index ..c86b1e524159
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/sifive-serial.txt
@@ -0,0 +1,33 @@
+SiFive asynchronous serial interface (UART)
+
+Required properties:
+
+- compatible: should be something similar to
+ "sifive,-uart" for the UART as integrated
+ on a particular chip, and "sifive,uart" for the
+ general UART IP block programming model. Supported
+ compatible strings as of the date of this writing are:
+ "sifive,fu540-c000-uart" for the SiFive UART v0 as
+ integrated onto the SiFive FU540 chip, or "sifive,uart0"
+ for the SiFive UART v0 IP block with no chip integration
+ tweaks (if any)
+- reg: address and length of the register space
+- interrupts: Should contain the UART interrupt identifier
+- clocks: Should contain a clock identifier for the UART's parent clock
+
+
+UART HDL that corresponds to the IP block version numbers can be found
+here:
+
+https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/uart
+
+
+Example:
+
+uart0: serial@1001 {
+ compatible = "sifive,fu540-c000-uart", "sifive,uart0";
+ interrupt-parent = <>;
+ interrupts = <80>;
+ reg = <0x0 0x1001 0x0 0x1000>;
+ clocks = < PRCI_CLK_TLCLK>;
+};
--
2.20.1
