RE: [PATCH 3/6] ASoC: amd: SND_SOC_RT5682_I2C does not build rt5682
[AMD Official Use Only - Internal Distribution Only] So Actually for rt5682 codec Now in 5.8 there are three flags : SND_SOC_RT5682 SND_SOC_RT5682_I2C SND_SOC_RT5682_SDW But till 5.7.8 we have SND_SOC_RT5682 SND_SOC_RT5682_SDW So in our design we were using SND_SOC_RT5682 which build snd_soc_rt5682.ko Creates the respective codec_dais as defined in that .ko If we use SND_SOC_RT5682_I2C we get snd_soc_rt5682_I2c.ko , it is not creating the expected codec_dai links. As there are three flags defined in codecs, I expect that previous one which we were using(SND_SOC_RT5682) is not a wrong flag and I expect to use SND_SOC_RT5682 as it is still available. Thanks, Vishnu -Original Message- From: Mark Brown Sent: Monday, July 27, 2020 9:40 PM To: Pierre-Louis Bossart Cc: RAVULAPATI, VISHNU VARDHAN RAO ; moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM... ; Arnd Bergmann ; open list ; YueHaibing ; Takashi Iwai ; Enric Balletbo i Serra ; Liam Girdwood ; Mukunda, Vijendar ; Deucher, Alexander ; Agrawal, Akshu Subject: Re: [PATCH 3/6] ASoC: amd: SND_SOC_RT5682_I2C does not build rt5682 On Mon, Jul 27, 2020 at 10:31:24AM -0500, Pierre-Louis Bossart wrote: > On 7/27/20 9:58 AM, Ravulapati Vishnu vardhan rao wrote: > > changing SND_SOC_RT5682_I2C to SND_SOC_RT5682 because, This flag > > which was previously set as SND_SOC_RT5682 used to build rt5682 > > codec driver but by changing into SND_SOC_RT5682_I2C is preventing > > to build rt5682 codec driver and machine driver fails to probe.So > > Reverting the changes. > The split between I2C and SoundWire means you have to choose the I2C > or SDW mode. Selecting the common part looks very strange. Right, and I can't understand the commit message at all. What's the actual issue here and how could this fix it - in what situation wouldn't you need one of the bus modules?
Re: [PATCH] drivers/net/wan/lapbether: Use needed_headroom instead of hard_header_len
Hi Brian Norris, I'm wishing to change a driver from using "hard_header_len" to using "needed_headroom" to declare its needed headroom. I submitted a patch and it is decided it needs to be reviewed. I see you submitted a similar patch in the past. So I think you might be able to help review my patch. Can you help review my patch? Thanks! The patch is at: http://patchwork.ozlabs.org/project/netdev/patch/20200726110524.151957-1-xie.he.0...@gmail.com/ As you have noted in the commit message of your patch, hard_header_len has special meaning in AF_PACKET so we need to use needed_headroom instead when we just need to reserve some header space. I believe the value of hard_header_len should be the same as the length of the header created by dev_hard_header.
[PATCH] sched: Make select_idle_sibling search domain configurable
The scope of select_idle_sibling idle cpu search is LLC. This
becomes a problem for the AMD CCX architecture, as the sd_llc is only
4 cores. On a many core machine, the range of search is too small to
reach a satisfactory level of statistical multiplexing / efficient
utilization of short idle time slices.
With this patch idle sibling search is detached from LLC and it
becomes run time configurable. To reduce search and migration
overheads, a presearch domain is added. The presearch domain will be
searched first before the "main search" domain, e.g.:
sysctl_sched_wake_idle_domain == 2 ("MC" domain)
sysctl_sched_wake_idle_presearch_domain == 1 ("DIE" domain)
Presearch will go through 4 cores of a CCX. If no idle cpu is found
during presearch, full search will go through the remaining cores of
a cpu socket.
Heuristics including sd->avg_scan_cost and sds->have_idle_cores
are only active for the main search.
On a 128 core (2 socket * 64 core, 256 hw threads) AMD machine ran
hackbench as
hackbench -g 20 -f 20 --loops 1
A snapshot of run time was
Baseline: 11.8
With the patch: 7.6(configured as in the example above)
Signed-off-by: Xi Wang
---
block/blk-mq.c | 2 +-
block/blk-softirq.c| 2 +-
include/linux/cpuset.h | 10 +-
include/linux/sched/topology.h | 11 +-
kernel/cgroup/cpuset.c | 32 --
kernel/sched/core.c| 10 +-
kernel/sched/fair.c| 191 +
kernel/sched/sched.h | 9 +-
kernel/sched/topology.c| 87 ++-
kernel/sysctl.c| 25 +
10 files changed, 256 insertions(+), 123 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 4e0d173beaa3..20aee9f047e2 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -626,7 +626,7 @@ void blk_mq_force_complete_rq(struct request *rq)
cpu = get_cpu();
if (!test_bit(QUEUE_FLAG_SAME_FORCE, &q->queue_flags))
- shared = cpus_share_cache(cpu, ctx->cpu);
+ shared = cpus_share_sis(cpu, ctx->cpu);
if (cpu != ctx->cpu && !shared && cpu_online(ctx->cpu)) {
rq->csd.func = __blk_mq_complete_request_remote;
diff --git a/block/blk-softirq.c b/block/blk-softirq.c
index 6e7ec87d49fa..dd38ac0e1f2e 100644
--- a/block/blk-softirq.c
+++ b/block/blk-softirq.c
@@ -108,7 +108,7 @@ void __blk_complete_request(struct request *req)
*/
if (test_bit(QUEUE_FLAG_SAME_COMP, &q->queue_flags) && ccpu != -1) {
if (!test_bit(QUEUE_FLAG_SAME_FORCE, &q->queue_flags))
- shared = cpus_share_cache(cpu, ccpu);
+ shared = cpus_share_sis(cpu, ccpu);
} else
ccpu = cpu;
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 04c20de66afc..8b243aa8462e 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -117,6 +117,7 @@ static inline int cpuset_do_slab_mem_spread(void)
extern bool current_cpuset_is_being_rebound(void);
extern void rebuild_sched_domains(void);
+extern void rebuild_sched_domains_force(void);
extern void cpuset_print_current_mems_allowed(void);
@@ -173,7 +174,7 @@ static inline void cpuset_force_rebuild(void) { }
static inline void cpuset_update_active_cpus(void)
{
- partition_sched_domains(1, NULL, NULL);
+ partition_sched_domains(1, NULL, NULL, 0);
}
static inline void cpuset_wait_for_hotplug(void) { }
@@ -259,7 +260,12 @@ static inline bool current_cpuset_is_being_rebound(void)
static inline void rebuild_sched_domains(void)
{
- partition_sched_domains(1, NULL, NULL);
+ partition_sched_domains(1, NULL, NULL, 0);
+}
+
+static inline void rebuild_sched_domains_force(void)
+{
+ partition_sched_domains(1, NULL, NULL, 1);
}
static inline void cpuset_print_current_mems_allowed(void)
diff --git a/include/linux/sched/topology.h b/include/linux/sched/topology.h
index fb11091129b3..aff9739cf516 100644
--- a/include/linux/sched/topology.h
+++ b/include/linux/sched/topology.h
@@ -151,16 +151,17 @@ static inline struct cpumask *sched_domain_span(struct
sched_domain *sd)
extern void partition_sched_domains_locked(int ndoms_new,
cpumask_var_t doms_new[],
- struct sched_domain_attr *dattr_new);
+ struct sched_domain_attr *dattr_new,
+ int force_update);
extern void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[],
- struct sched_domain_attr *dattr_new);
+ struct sched_domain_attr *dattr_new, int
force_update);
/* Allocate an array of sched domains, for partition_sched_domains(). */
cpumask_var_t *alloc_sched_domains(unsigned int ndoms);
void free_sched_domains(cpumask_var_t doms[], unsigned int ndoms);
-bool cpus_share_ca
Re: [PATCH] scsi: sd: add runtime pm to open / release
On 06.07.20 18:41, Alan Stern wrote: > On Tue, Jun 30, 2020 at 20:49:58PM -0400, Alan Stern wrote: >> On Tue, Jun 30, 2020 at 04:31:58PM -0700, Bart Van Assche wrote: >>> On 2020-06-30 12:38, Alan Stern wrote: Assume that BLK_MQ_REQ_PREEMPT is set in flags. Then where exactly does blk_queue_enter(q, flags) call blk_pm_request_resume(q)? >>> >>> Please take a look at how the *current* implementation of runtime power >>> management works. Your question is relevant for the old implementation >>> of runtime power management but not for the current implementation. >> >> What do you mean by "current"? I have been looking at the implementation >> in 5.8-rc3 from Linus's tree. Should I look somewhere else? > > Any reply to this, or further concerns about the proposed patch? > > I'd like to fix up this API, and it appears that you are the only > person to have worked on it significantly in the last two years. > > Alan Stern > Hi Alan, Any API cleanup is of course welcome. I just wanted to remind you that the underlying problem: broken block device runtime pm. Your initial proposed fix "almost" did it and mounting works but during file access, it still just looks like a runtime_resume is missing somewhere. As we need to have that working at some point, I might look into it, but someone who has experience in the block layer can surely do it more efficiently. to test, turn off polling: echo 0 > /sys/module/block/parameters/events_dfl_poll_msecs and enable runtime pm in your (scsi) device: power/autosuspend_delay_ms and of course power/control (set to auto). thanks, martin
Re: [PATCH] Bluetooth: Fix suspend notifier race
Hi Abhishek, > Unregister from suspend notifications and cancel suspend preparations > before running hci_dev_do_close. Otherwise, the suspend notifier may > race with unregister and cause cmd_timeout even after hdev has been > freed. > > Signed-off-by: Abhishek Pandit-Subedi > Reviewed-by: Miao-chen Chou > --- > Hi Marcel, > > This fixes a race between hci_unregister_dev and the suspend notifier. > Without these changes, we encountered the following kernel panic when > a USB disconnect (with btusb) occurred on resume: > > [ 832.578518] Bluetooth: hci_core.c:hci_cmd_timeout() hci0: command 0x0c05 > tx timeout > [ 832.586200] BUG: kernel NULL pointer dereference, address: > [ 832.586203] #PF: supervisor read access in kernel mode > [ 832.586205] #PF: error_code(0x) - not-present page > [ 832.586206] PGD 0 P4D 0 > [ 832.586210] PM: suspend exit > [ 832.608870] Oops: [#1] PREEMPT SMP NOPTI > [ 832.613232] CPU: 3 PID: 10755 Comm: kworker/3:7 Not tainted > 5.4.44-04894-g1e9dbb96a161 #1 > [ 832.630036] Workqueue: events hci_cmd_timeout [bluetooth] > [ 832.630046] RIP: 0010:__queue_work+0xf0/0x374 > [ 832.630051] RSP: 0018:9b5285f1fdf8 EFLAGS: 00010046 > [ 832.674033] RAX: 8a97681bac00 RBX: RCX: > 8a976a000600 > [ 832.681162] RDX: RSI: 0009 RDI: > 8a976a000748 > [ 832.688289] RBP: 9b5285f1fe38 R08: R09: > 8a97681bac00 > [ 832.695418] R10: 0002 R11: 8a976a0006d8 R12: > 8a9745107600 > [ 832.698045] usb 1-6: new full-speed USB device number 119 using xhci_hcd > [ 832.702547] R13: 8a9673658850 R14: 0040 R15: > 001e > [ 832.702549] FS: () GS:8a976af8() > knlGS: > [ 832.702550] CS: 0010 DS: ES: CR0: 80050033 > [ 832.702550] CR2: CR3: 00010415a000 CR4: > 003406e0 > [ 832.702551] Call Trace: > [ 832.702558] queue_work_on+0x3f/0x68 > [ 832.702562] process_one_work+0x1db/0x396 > [ 832.747397] worker_thread+0x216/0x375 > [ 832.751147] kthread+0x138/0x140 > [ 832.754377] ? pr_cont_work+0x58/0x58 > [ 832.758037] ? kthread_blkcg+0x2e/0x2e > [ 832.761787] ret_from_fork+0x22/0x40 > [ 832.846191] ---[ end trace fa93f466da517212 ]--- > > The suspend notifier handler seemed to be scheduling commands even after > it was cleaned up and this was resulting in a panic in cmd_timeout (when > it tries to requeue the cmd_timer). > > This was tested on 5.4 kernel with a suspend+resume stress test for 500+ > iterations. I also confirmed that after a usb disconnect, the suspend > notifier times out before the USB device is probed again (fixing the > original race between the usb_disconnect + probe and the notifier). Can you please structure the commit message so that the oops is included. It is valuable information Everything after --- is a personal note to the maintainer. And we might want to include a Fixes tag as well. Regards Marcel
Re: [PATCH] mfd: dm355evm_msp: Convert LEDs to GPIO descriptor table
On Mon, 27 Jul 2020, Linus Walleij wrote:
> This converts the DaVinci DM355EVM LEDs to use GPIO
> descriptor look-ups.
>
> Cc: Sekhar Nori
> Cc: Bartosz Golaszewski
> Signed-off-by: Linus Walleij
> ---
> drivers/mfd/dm355evm_msp.c | 49 --
> 1 file changed, 37 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mfd/dm355evm_msp.c b/drivers/mfd/dm355evm_msp.c
> index 151c36ce7343..af24712d605e 100644
> --- a/drivers/mfd/dm355evm_msp.c
> +++ b/drivers/mfd/dm355evm_msp.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -260,31 +261,55 @@ static int add_children(struct i2c_client *client)
>
> /* LED output */
> if (msp_has_leds()) {
> -#define GPIO_LED(l) .name = l, .active_low = true
> static struct gpio_led evm_leds[] = {
> - { GPIO_LED("dm355evm::ds14"),
> + { .name = "dm355evm::ds14",
> .default_trigger = "heartbeat", },
> - { GPIO_LED("dm355evm::ds15"),
> + { .name = "dm355evm::ds15",
> .default_trigger = "mmc0", },
> - { GPIO_LED("dm355evm::ds16"),
> + { .name = "dm355evm::ds16",
> /* could also be a CE-ATA drive */
> .default_trigger = "mmc1", },
> - { GPIO_LED("dm355evm::ds17"),
> + { .name = "dm355evm::ds17",
> .default_trigger = "nand-disk", },
> - { GPIO_LED("dm355evm::ds18"), },
> - { GPIO_LED("dm355evm::ds19"), },
> - { GPIO_LED("dm355evm::ds20"), },
> - { GPIO_LED("dm355evm::ds21"), },
> + { .name = "dm355evm::ds18", },
> + { .name = "dm355evm::ds19", },
> + { .name = "dm355evm::ds20", },
> + { .name = "dm355evm::ds21", },
> };
> -#undef GPIO_LED
>
> struct gpio_led_platform_data evm_led_data = {
> .num_leds = ARRAY_SIZE(evm_leds),
> .leds = evm_leds,
> };
>
> - for (i = 0; i < ARRAY_SIZE(evm_leds); i++)
> - evm_leds[i].gpio = i + dm355evm_msp_gpio.base;
> + static struct gpiod_lookup_table evm_leds_gpio_table = {
> + .dev_id = "leds-gpio",
> + .table = {
> + /*
> + * These GPIOs are on the dm355evm_msp
> + * GPIO chip at index 0..7
> + */
> + GPIO_LOOKUP_IDX("dm355evm_msp", 0, NULL,
> + 0, GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP_IDX("dm355evm_msp", 1, NULL,
> + 1, GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP_IDX("dm355evm_msp", 2, NULL,
> + 2, GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP_IDX("dm355evm_msp", 3, NULL,
> + 3, GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP_IDX("dm355evm_msp", 4, NULL,
> + 4, GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP_IDX("dm355evm_msp", 5, NULL,
> + 5, GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP_IDX("dm355evm_msp", 6, NULL,
> + 6, GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP_IDX("dm355evm_msp", 7, NULL,
> + 7, GPIO_ACTIVE_LOW),
> + { },
> + },
> + };
Horrible.
Can this (and the table above) be placed somewhere else and simply
referenced from here? Tables are usually placed globally at the top
of the file to prevent this kind of formatting craziness from
appearing inside functions.
> + gpiod_add_lookup_table(&evm_leds_gpio_table);
>
> /* NOTE: these are the only fully programmable LEDs
>* on the board, since GPIO-61/ds22 (and many signals
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH RFC 3/6] pwm: pwm-qti-lpg: Add PWM driver for QTI LPG module
Hello Martin,
On Mon, Jul 27, 2020 at 11:16:57PM +0200, Martin Botka wrote:
> Mo 27. 7. 2020 at 22:10 Uwe Kleine-König
> wrote:
> >
> > On Fri, Jul 24, 2020 at 11:36:53PM +0200, Martin Botka wrote:
> > > From: Fenglin Wu
> > >
> > > Add pwm_chip to support QTI LPG module and export LPG channels as
> > > PWM devices for consumer drivers' usage.
> > >
> > > Signed-off-by: Fenglin Wu
> > > [martin.bot...@gmail.com: Fast-forward the driver from kernel 4.14 to 5.8]
> > > Signed-off-by: Martin Botka
> > > ---
> > > drivers/pwm/Kconfig | 10 +
> > > drivers/pwm/Makefile |1 +
> > > drivers/pwm/pwm-qti-lpg.c | 1284 +
> > > 3 files changed, 1295 insertions(+)
> > > create mode 100644 drivers/pwm/pwm-qti-lpg.c
> > >
> > > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> > > index cb8d739067d2..8a52d6884a9a 100644
> > > --- a/drivers/pwm/Kconfig
> > > +++ b/drivers/pwm/Kconfig
> > > @@ -399,6 +399,16 @@ config PWM_RCAR
> > > To compile this driver as a module, choose M here: the module
> > > will be called pwm-rcar.
> > >
> > > +config PWM_QTI_LPG
> > > + tristate "Qualcomm Technologies, Inc. LPG driver"
> > > + depends on MFD_SPMI_PMIC && OF
> > > + help
> > > + This driver supports the LPG (Light Pulse Generator) module found
> > > in
> > > + Qualcomm Technologies, Inc. PMIC chips. Each LPG channel can be
> > > + configured to operate in PWM mode to output a fixed amplitude with
> > > + variable duty cycle or in LUT (Look up table) mode to output PWM
> > > + signal with a modulated amplitude.
> > > +
> > > config PWM_RENESAS_TPU
> > > tristate "Renesas TPU PWM support"
> > > depends on ARCH_RENESAS || COMPILE_TEST
> > > diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> > > index a59c710e98c7..3555a6aa3f33 100644
> > > --- a/drivers/pwm/Makefile
> > > +++ b/drivers/pwm/Makefile
> > > @@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
> > > obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
> > > obj-$(CONFIG_PWM_PXA)+= pwm-pxa.o
> > > obj-$(CONFIG_PWM_RCAR) += pwm-rcar.o
> > > +obj-$(CONFIG_PWM_QTI_LPG)+= pwm-qti-lpg.o
> >
> > Please keep this list alphabetically sorted.
>
> OK
>
> >
> > > obj-$(CONFIG_PWM_RENESAS_TPU)+= pwm-renesas-tpu.o
> > > obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
> > > obj-$(CONFIG_PWM_SAMSUNG)+= pwm-samsung.o
> > > diff --git a/drivers/pwm/pwm-qti-lpg.c b/drivers/pwm/pwm-qti-lpg.c
> > > new file mode 100644
> > > index ..d24c3b3a3d8c
> > > --- /dev/null
> > > +++ b/drivers/pwm/pwm-qti-lpg.c
> > > @@ -0,0 +1,1284 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> > > + */
> > > +
> > > +#define pr_fmt(fmt) "%s: " fmt, __func__
> >
> > This smells like debug stuff. Please drop this.
>
> What do you mean ?
> The #define pr_fmt(fmt) or the tons of REG definitions ?
Either drop pr_fmt or at least don't have __func__ in it. This doesn't
belong into the kernel log (in the non-debug case at least).
(For debugging I like:
#define pr_fmt(fmt) "%s:%d: " fmt, __func__, __LINE__
which helps finding the right printk line in the code from a given
output in functions with many printks.)
I don't mind the REG definitions, though aligning the values vertically
is common.
> > > +static const struct pwm_ops qpnp_lpg_pwm_ops = {
> > > + .config = qpnp_lpg_pwm_config,
> > > + .config_extend = qpnp_lpg_pwm_config_extend,
> > > + .get_output_type_supported = qpnp_lpg_pwm_output_types_supported,
> > > + .set_output_type = qpnp_lpg_pwm_set_output_type,
> > > + .set_output_pattern = qpnp_lpg_pwm_set_output_pattern,
> > > + .enable = qpnp_lpg_pwm_enable,
> > > + .disable = qpnp_lpg_pwm_disable,
> >
> > As already noted in the former patch: Please implement .apply() and
> > .get_state().
>
> So drop:
> .get_output_type_supported = qpnp_lpg_pwm_output_types_supported,
> .set_output_type = qpnp_lpg_pwm_set_output_type,
> .set_output_pattern = qpnp_lpg_pwm_set_output_pattern,
>
> Ad implement implement .apply and .get_state if i understood you correctly.
> Right ?
ack
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH v3 0/3] Few bug fixes and Convert to pin_user_pages*()
Hi Boris, On Sun, Jul 12, 2020 at 9:01 AM Souptick Joarder wrote: > > This series contains few clean up, minor bug fixes and > Convert get_user_pages() to pin_user_pages(). > > I'm compile tested this, but unable to run-time test, > so any testing help is much appriciated. > > v2: > Addressed few review comments and compile issue. > Patch[1/2] from v1 split into 2 in v2. > v3: > Address review comment. Add review tag. > > Cc: John Hubbard > Cc: Boris Ostrovsky > Cc: Paul Durrant > > Souptick Joarder (3): > xen/privcmd: Corrected error handling path > xen/privcmd: Mark pages as dirty > xen/privcmd: Convert get_user_pages*() to pin_user_pages*() Does this series looks good to go for 5.9 ? > > drivers/xen/privcmd.c | 32 ++-- > 1 file changed, 14 insertions(+), 18 deletions(-) > > -- > 1.9.1 >
Re: [PATCH] usb: hso: check for return value in hso_serial_common_create()
On Mon, Jul 27, 2020 at 11:42:17PM -0700, Rustam Kovhaev wrote: > in case of an error tty_register_device_attr() returns ERR_PTR(), > add IS_ERR() check > > Reported-and-tested-by: syzbot+67b2bd0e34f952d03...@syzkaller.appspotmail.com > Link: https://syzkaller.appspot.com/bug?extid=67b2bd0e34f952d0321e > Signed-off-by: Rustam Kovhaev Looks good, thanks! Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 1/2] Bluetooth: hci_h5: Set HCI_UART_RESET_ON_INIT to correct flags
Hi Nicolas,
> HCI_UART_RESET_ON_INIT belongs in hdev_flags, not flags.
>
> Fixes: ce945552fde4a09 ("Bluetooth: hci_h5: Add support for serdev enumerated
> devices")
> Signed-off-by: Nicolas Boichat
>
> ---
>
> drivers/bluetooth/hci_h5.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
Re: [PATCH] Bluetooth: Return NOTIFY_DONE for hci_suspend_notifier
Hi Max, > The original return is NOTIFY_STOP, but notifier_call_chain would stop > the future call for register_pm_notifier even registered on other Kernel > modules with the same priority which value is zero. > > Signed-off-by: Max Chou > --- > net/bluetooth/hci_core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) patch has been applied to bluetooth-next tree. Regards Marcel
Re: [PATCH] tty/synclink: remove leftover bits of non-PCI card support
On Tue, Jul 28, 2020 at 08:40:25AM +0200, Jiri Slaby wrote:
> On 28. 07. 20, 8:20, Christoph Hellwig wrote:
> > On Tue, Jul 28, 2020 at 08:05:36AM +0200, Jiri Slaby wrote:
> >> On 27. 07. 20, 15:05, Christoph Hellwig wrote:
> >>> Since commit 1355cba9c3ba ("tty/synclink: remove ISA support"), the
> >>> synlink driver only supports PCI card. Remove any leftover dead code
> >>> to support other cards.
> >>
> >> So now you can remove also the defines and bus_type completely:
> >> $ git grep -E 'MGSL_BUS_TYPE_(E?ISA|PCI)'
> >> drivers/tty/synclink_gt.c: info->bus_type = MGSL_BUS_TYPE_PCI;
> >> drivers/tty/synclinkmp.c: info->bus_type = MGSL_BUS_TYPE_PCI;
> >> include/uapi/linux/synclink.h:#define MGSL_BUS_TYPE_ISA 1
> >> include/uapi/linux/synclink.h:#define MGSL_BUS_TYPE_EISA2
> >> include/uapi/linux/synclink.h:#define MGSL_BUS_TYPE_PCI 5
> >
> > This is in a uapi header, so I didn't dare to touch it.
>
> Ah, sure. Then OK.
>
> Just wondering, who would place this into a uapi header?
People didn't realize they were uapi headers a long time ago, when
everything was in the same directory/files :(
thanks,
greg k-h
Re: [PATCH v17 17/21] mm/lru: replace pgdat lru_lock with lruvec lock
在 2020/7/28 上午7:34, Alexander Duyck 写道:
>> @@ -847,11 +847,21 @@ static bool too_many_isolated(pg_data_t *pgdat)
>> * contention, to give chance to IRQs. Abort completely if
>> * a fatal signal is pending.
>> */
>> - if (!(low_pfn % SWAP_CLUSTER_MAX)
>> - && compact_unlock_should_abort(&pgdat->lru_lock,
>> - flags, &locked, cc)) {
>> - low_pfn = 0;
>> - goto fatal_pending;
>> + if (!(low_pfn % SWAP_CLUSTER_MAX)) {
>> + if (locked_lruvec) {
>> + unlock_page_lruvec_irqrestore(locked_lruvec,
>> +
>> flags);
>> + locked_lruvec = NULL;
>> + }
>> +
>> + if (fatal_signal_pending(current)) {
>> + cc->contended = true;
>> +
>> + low_pfn = 0;
>> + goto fatal_pending;
>> + }
>> +
>> + cond_resched();
>> }
>>
>> if (!pfn_valid_within(low_pfn))
>
> I'm noticing this patch introduces a bunch of noise. What is the
> reason for getting rid of compact_unlock_should_abort? It seems like
> you just open coded it here. If there is some sort of issue with it
> then it might be better to replace it as part of a preparatory patch
> before you introduce this one as changes like this make it harder to
> review.
Thanks for comments, Alex.
the func compact_unlock_should_abort should be removed since one of parameters
changed from 'bool *locked' to 'struct lruvec *lruvec'. So it's not applicable
now. I have to open it here instead of adding a only one user func.
>
> It might make more sense to look at modifying
> compact_unlock_should_abort and compact_lock_irqsave (which always
> returns true so should probably be a void) to address the deficiencies
> they have that make them unusable for you.
I am wondering if people like a patch which just open
compact_unlock_should_abort
func and move bool to void as a preparation patch, do you like this?
>> @@ -966,10 +975,20 @@ static bool too_many_isolated(pg_data_t *pgdat)
>> if (!TestClearPageLRU(page))
>> goto isolate_fail_put;
>>
>> + rcu_read_lock();
>> + lruvec = mem_cgroup_page_lruvec(page, pgdat);
>> +
>> /* If we already hold the lock, we can skip some rechecking
>> */
>> - if (!locked) {
>> - locked = compact_lock_irqsave(&pgdat->lru_lock,
>> - &flags, cc);
>> + if (lruvec != locked_lruvec) {
>> + if (locked_lruvec)
>> + unlock_page_lruvec_irqrestore(locked_lruvec,
>> +
>> flags);
>> +
>> + compact_lock_irqsave(&lruvec->lru_lock, &flags, cc);
>> + locked_lruvec = lruvec;
>> + rcu_read_unlock();
>> +
>> + lruvec_memcg_debug(lruvec, page);
>>
>> /* Try get exclusive access under lock */
>> if (!skip_updated) {
>
> So this bit makes things a bit complicated. From what I can can tell
> the comment about exclusive access under the lock is supposed to apply
> to the pageblock via the lru_lock. However you are having to retest
> the lock for each page because it is possible the page was moved to
> another memory cgroup while the lru_lock was released correct? So in
The pageblock is aligned by pfn, so pages in them maynot on same memcg
originally. and yes, page may be changed memcg also.
> this case is the lru vector lock really providing any protection for
> the skip_updated portion of this code block if the lock isn't
> exclusive to the pageblock? In theory this would probably make more
> sense to have protected the skip bits under the zone lock, but I
> imagine that was avoided due to the additional overhead.
when we change to lruvec->lru_lock, it does the same thing as pgdat->lru_lock.
just may get a bit more chance to here, and find out this is a skipable
pageblock and quit.
Yes, logically, pgdat lru_lock seems better, but since we are holding lru_lock.
It's fine to not bother more locks.
>
>> @@ -1876,6 +1876,12 @@ static unsigned noinline_for_stack
>> move_pages_to_lru(struct lruvec *lruvec,
>> *
>> list_add(&page->lru,)
>> * list_add(&page->lru,) //corrupt
>> */
>> + new_lruvec = mem_cgroup_page_lruvec(page, page_pgdat(page));
>> + if (new_lruvec != lruvec) {
Re: [PATCH 2/2] Bluetooth: hci_serdev: Only unregister device if it was registered
Hi Nicolas,
> We should not call hci_unregister_dev if the device was not
> successfully registered.
>
> Fixes: c34dc3bfa7642fd ("Bluetooth: hci_serdev: Introduce
> hci_uart_unregister_device()")
> Signed-off-by: Nicolas Boichat
>
> ---
>
> drivers/bluetooth/hci_serdev.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
Re: [PATCH v6 01/13] mfd: add simple regmap based I2C driver
On Sun, 26 Jul 2020, Michael Walle wrote:
> There are I2C devices which contain several different functions but
> doesn't require any special access functions. For these kind of drivers
> an I2C regmap should be enough.
>
> Create an I2C driver which creates an I2C regmap and enumerates its
> children. If a device wants to use this as its MFD core driver, it has
> to add an individual compatible string. It may provide its own regmap
> configuration.
>
> Subdevices can use dev_get_regmap() on the parent to get their regmap
> instance.
>
> Signed-off-by: Michael Walle
> ---
> Changes since v5:
> - removed "select MFD_CORE" in Kconfig
> - removed help text in Kconfig, we assume that the users of this
That's the opposite of what I asked for.
>driver will have a "select MFD_SIMPLE_MFD_I2C". Instead added
>a small description to the driver itself.
> - removed "struct simple_mfd_i2c_config" and use regmap_config
>directly
> - changed builtin_i2c_driver() to module_i2c_driver(), added
>MODULE_ boilerplate
> - cleaned up the included files
>
> Changes since v4:
> - new patch. Lee, please bear with me. I didn't want to delay the
>new version (where a lot of remarks on the other patches were
>addressed) even more, just because we haven't figured out how
>to deal with the MFD part. So for now, I've included this one.
>
> drivers/mfd/Kconfig | 5
> drivers/mfd/Makefile | 1 +
> drivers/mfd/simple-mfd-i2c.c | 55
> 3 files changed, 61 insertions(+)
> create mode 100644 drivers/mfd/simple-mfd-i2c.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 33df0837ab41..c08539c7a166 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1162,6 +1162,11 @@ config MFD_SI476X_CORE
> To compile this driver as a module, choose M here: the
> module will be called si476x-core.
>
> +config MFD_SIMPLE_MFD_I2C
> + tristate
> + depends on I2C
> + select REGMAP_I2C
Please provide a full help.
> config MFD_SM501
> tristate "Silicon Motion SM501"
> depends on HAS_DMA
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index a60e5f835283..78d24a3e7c9e 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -264,3 +264,4 @@ obj-$(CONFIG_MFD_STMFX) += stmfx.o
> obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
>
> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
> +obj-$(CONFIG_MFD_SIMPLE_MFD_I2C) += simple-mfd-i2c.o
> diff --git a/drivers/mfd/simple-mfd-i2c.c b/drivers/mfd/simple-mfd-i2c.c
> new file mode 100644
> index ..45090ddad104
> --- /dev/null
> +++ b/drivers/mfd/simple-mfd-i2c.c
> @@ -0,0 +1,55 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * A very simple I2C MFD driver
Simple MFD - I2C
> + * The driver enumerates its children and registers a common regmap. Use
> + * dev_get_regmap(pdev->dev.parent, NULL) in the child nodes to fetch that
> + * regmap instance.
This driver creates a single register map with the intention for it to
be shared by all sub-devices. Children can use their parent's device
structure (dev.parent) in order reference it.
> + * In the future this driver might be extended to support also other
> interfaces
> + * like SPI etc.
Remove this please.
> + */
'\n' here.
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const struct regmap_config simple_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> +};
> +
> +static int simple_mfd_i2c_probe(struct i2c_client *i2c)
> +{
> + const struct regmap_config *config;
> + struct regmap *regmap;
> +
> + config = device_get_match_data(&i2c->dev);
> + if (!config)
> + config = &simple_regmap_config;
> +
> + regmap = devm_regmap_init_i2c(i2c, config);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + return devm_of_platform_populate(&i2c->dev);
> +}
> +
> +static const struct of_device_id simple_mfd_i2c_of_match[] = {
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, simple_mfd_i2c_of_match);
> +
> +static struct i2c_driver simple_mfd_i2c_driver = {
> + .probe_new = simple_mfd_i2c_probe,
> + .driver = {
> + .name = "simple-mfd-i2c",
> + .of_match_table = simple_mfd_i2c_of_match,
> + },
> +};
> +module_i2c_driver(simple_mfd_i2c_driver);
> +
> +MODULE_AUTHOR("Michael Walle ");
> +MODULE_DESCRIPTION("Simple I2C MFD driver");
Simple MFD - I2C driver
> +MODULE_LICENSE("GPL v2");
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/4] arm64: dts: qcom: sc7180: Add iommus property to ETR
On 2020-07-28 11:58, Bjorn Andersson wrote: On Mon 27 Jul 21:40 PDT 2020, Sai Prakash Ranjan wrote: On 2020-07-28 02:28, Bjorn Andersson wrote: > On Tue 23 Jun 23:56 PDT 2020, Sai Prakash Ranjan wrote: > > > Hi Bjorn, > > > > On 2020-06-21 13:39, Sai Prakash Ranjan wrote: > > > Hi Bjorn, > > > > > > On 2020-06-21 12:52, Bjorn Andersson wrote: > > > > On Tue 09 Jun 06:30 PDT 2020, Sai Prakash Ranjan wrote: > > > > > > > > > Define iommus property for Coresight ETR component in > > > > > SC7180 SoC with the SID and mask to enable SMMU > > > > > translation for this master. > > > > > > > > > > > > > We don't have &apps_smmu in linux-next, as we've yet to figure out how > > > > to disable the boot splash or support the stream mapping handover. > > > > > > > > So I'm not able to apply this. > > > > > > > > > > This is for SC7180 which has apps_smmu not SM8150. > > > > > > > Please let me know if this needs further explanation. > > > > I must have commented on the wrong patch, sorry about that. The SM8150 > patch in this series does not compile due to the lack of &apps_smmu. > > I've picked the other 3 patches. > Thanks Bjorn, I can resend SM8150 coresight change when SMMU support lands for it since coresight ETR won't work without it on android bootloaders. As for the other 3 patches, Patch 1 and Patch 2 will apply cleanly to the right coresight nodes but due to the missing unique context in Patch 3, it could be applied to some other node. We had to upload this change 3 times in chromium tree to get it applied to the right replicator node :) and this property in Patch 3 is important to fix a hard lockup. I'm not sure why this patch is missing the proper context :/ I couldn't find the changes yet in qcom/for-next or other branches to see if it is applied to right replicator node. In case you haven't applied it yet, Patch 3 change should be applied to "replicator@6b06000" node. Thanks for pointing that out, I've fixed up the incorrectly applied change. (Still not published the branch) For the future I believe you can pass -U to git format-patch to get number of lines of context. Making that bigger than the default 3 should help for the coresight patches. Thanks Bjorn, will use this option going forward. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 03/10] remoteproc: imx: use devm_ioremap
On Mon, Jul 27, 2020 at 08:11:09AM +, Peng Fan wrote:
> > Subject: Re: [PATCH 03/10] remoteproc: imx: use devm_ioremap
> >
> > On Mon, Jul 27, 2020 at 06:51:00AM +, Peng Fan wrote:
> > > > Subject: Re: [PATCH 03/10] remoteproc: imx: use devm_ioremap
> > > >
> > > > On Mon, Jul 27, 2020 at 06:28:20AM +, Peng Fan wrote:
> > > > > Hi Oleksij,
> > > > >
> > > > > > Subject: Re: [PATCH 03/10] remoteproc: imx: use devm_ioremap
> > > > > >
> > > > > > On Fri, Jul 24, 2020 at 04:08:06PM +0800, Peng Fan wrote:
> > > > > > > We might need to map an region multiple times, becaue the
> > > > > > > region might be shared between remote processors, such i.MX8QM
> > > > > > > with dual
> > > > M4 cores.
> > > > > > > So use devm_ioremap, not devm_ioremap_resource.
> > > > > >
> > > > > > Can you please give an example of this kind of shared resources
> > > > > > and how they should be handled by two separate devices?
> > > > >
> > > > > This is to share vdevbuffer space, there is a vdevbuffer in device
> > > > > tree, it will be shared between M4_0 and M4_1.
> > > > >
> > > > > For the buffer, it is Linux DMA API will handle the space.
> > > >
> > > > Why remoteproc need to care about it? If I see it correctly, from
> > > > the linux perspective, it is one buffer and one driver is
> > > > responsible for it. Or do I missing some thing?
> > >
> > > We not have the vdev buffer in resource table, so I added in device tree,
> > > see
> > below:
> >
> > Hm.. if vdev is not in resource table and should not be controlled by
> > remoteproc, why do we need remoteproc?
>
> I use same approach as stm32 rproc driver.
>
> The resource table here only publish vring address.
>
> >
> > > imx8qm_cm40: imx8qm_cm4@0 {
> > > compatible = "fsl,imx8qm-cm4";
> > > rsc-da = <0x9000>;
> > > mbox-names = "tx", "rx", "rxdb";
> > > mboxes = <&lsio_mu5 0 1
> > > &lsio_mu5 1 1
> > > &lsio_mu5 3 1>;
> > > mub-partition = <3>;
> > > memory-region = <&vdev0vring0>, <&vdev0vring1>,
> > <&vdevbuffer>,
> > > <&vdev1vring0>, <&vdev1vring1>;
> > > core-index = <0>;
> > > core-id = ;
> > > status = "okay";
> > > power-domains = <&pd IMX_SC_R_M4_0_PID0>,
> > > <&pd IMX_SC_R_M4_0_MU_1A>;
> > > };
> > >
> > > imx8qm_cm41: imx8x_cm4@1 {
> > > compatible = "fsl,imx8qm-cm4";
> > > rsc-da = <0x9010>;
> > > mbox-names = "tx", "rx", "rxdb";
> > > mboxes = <&lsio_mu6 0 1
> > > &lsio_mu6 1 1
> > > &lsio_mu6 3 1>;
> > > mub-partition = <4>;
> > > memory-region = <&vdev2vring0>, <&vdev2vring1>,
> > <&vdevbuffer>,
> > > <&vdev3vring0>, <&vdev3vring1>;
> > > core-index = <1>;
> > > core-id = ;
> > > status = "okay";
> > > power-domains = <&pd IMX_SC_R_M4_1_PID0>,
> > > <&pd IMX_SC_R_M4_1_MU_1A>;
> > > };
> > >
> > > vdevbuffer: vdevbuffer {
> > > compatible = "shared-dma-pool";
> > > reg = <0 0x9040 0 0x10>;
> > > no-map;
> > > };
> > >
> > > I have the upper vdevbuffer node shared between M40 and M41 node.
> > > The vdevbuffer will be used as virtio data buffer.
> > >
> > > And I have the following in rproc_add_virtio_dev to share vdevbuffer:
> > > /* Try to find dedicated vdev buffer carveout */
> > > mem = rproc_find_carveout_by_name(rproc, "vdev%dbuffer",
> > rvdev->index);
> > > if (!mem)
> > > mem = rproc_find_carveout_by_name(rproc,
> > > "vdevbuffer");
> >
> > With kernel v5.8-rc7 i get following call chain:
>
> Please use Linux-next which has support of M4 booted before Linux in
> in remoteproc.
>
> > rproc_boot()
> > rproc_fw_boot()
> > rproc_handle_vdev
> > rproc_vdev_do_start()
> > rproc_add_virtio_dev()
> >
> >
> > So, at the end, we will call rproc_add_virtio_dev() only if we boot
> > firmware by
> > linux, or if we get at least the resource table.
>
>
> Resource table could be got from elf file if it is booted by Linux, or got
> from
> an address if M4 is booted before Linux.
Ok, i see now. Thank you!
Reviewed-by: Oleksij Rempel
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
[PATCH] [v2] Staging: rtl8188eu: rtw_mlme: Fix uninitialized variable authmode
The variable authmode can be uninitialized. The danger would be if
it equals to _WPA_IE_ID_ (0xdd) or _WPA2_IE_ID_ (0x33). We can avoid
this by setting it to zero instead. This is the approach that was
used in the rtl8723bs driver.
Fixes: 7b464c9fa5cc ("staging: r8188eu: Add files for new driver - part 4")
Co-developed-by: Dan Carpenter
Signed-off-by: Dan Carpenter
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Move the initialization after 'else' statement.
Refine commit message.
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index 9de2d421f6b1..4f2abe1e14d5 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -1729,9 +1729,11 @@ int rtw_restruct_sec_ie(struct adapter *adapter, u8
*in_ie, u8 *out_ie, uint in_
if ((ndisauthmode == Ndis802_11AuthModeWPA) ||
(ndisauthmode == Ndis802_11AuthModeWPAPSK))
authmode = _WPA_IE_ID_;
- if ((ndisauthmode == Ndis802_11AuthModeWPA2) ||
+ else if ((ndisauthmode == Ndis802_11AuthModeWPA2) ||
(ndisauthmode == Ndis802_11AuthModeWPA2PSK))
authmode = _WPA2_IE_ID_;
+ else
+ authmode = 0x0;
if (check_fwstate(pmlmepriv, WIFI_UNDER_WPS)) {
memcpy(out_ie + ielength, psecuritypriv->wps_ie,
psecuritypriv->wps_ie_len);
--
2.17.1
Re: [PATCH v6 02/13] dt-bindings: mfd: Add bindings for sl28cpld
On Sun, 26 Jul 2020, Michael Walle wrote: > Add a device tree bindings for the board management controller found on > the Kontron SMARC-sAL28 board. > > Signed-off-by: Michael Walle > Reviewed-by: Rob Herring > --- > Changes since v5: > - none > > Changes since v4: > - fix the regex of the unit-address > > Changes since v3: > - see cover letter > > .../bindings/gpio/kontron,sl28cpld-gpio.yaml | 54 +++ > .../hwmon/kontron,sl28cpld-hwmon.yaml | 27 > .../kontron,sl28cpld-intc.yaml| 54 +++ > .../bindings/mfd/kontron,sl28cpld.yaml| 153 ++ > .../bindings/pwm/kontron,sl28cpld-pwm.yaml| 35 > .../watchdog/kontron,sl28cpld-wdt.yaml| 35 > 6 files changed, 358 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > create mode 100644 > Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml > create mode 100644 > Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml > create mode 100644 > Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml > create mode 100644 > Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml > > diff --git > a/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > new file mode 100644 > index ..9a63a158a796 > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > @@ -0,0 +1,54 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/gpio/kontron,sl28cpld-gpio.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: GPIO driver for the sl28cpld board management controller > + > +maintainers: > + - Michael Walle > + > +description: | > + This module is part of the sl28cpld multi-function device. For more > + details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml. Paths are normally relative. > + There are three flavors of the GPIO controller, one full featured > + input/output with interrupt support (kontron,sl28cpld-gpio), one > + output-only (kontron,sl28-gpo) and one input-only (kontron,sl28-gpi). > + > + Each controller supports 8 GPIO lines. > + > +properties: > + compatible: > +enum: > + - kontron,sl28cpld-gpio > + - kontron,sl28cpld-gpi > + - kontron,sl28cpld-gpo > + > + reg: > +maxItems: 1 > + > + interrupts: > +maxItems: 1 > + > + "#interrupt-cells": > +const: 2 > + > + interrupt-controller: true > + > + "#gpio-cells": > +const: 2 > + > + gpio-controller: true > + > + gpio-line-names: > + minItems: 1 > + maxItems: 8 > + > +required: > + - compatible > + - "#gpio-cells" > + - gpio-controller > + > +additionalProperties: false > diff --git > a/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml > b/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml > new file mode 100644 > index ..1cebd61c6c32 > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml > @@ -0,0 +1,27 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/hwmon/kontron,sl28cpld-hwmon.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Hardware monitoring driver for the sl28cpld board management > controller > + > +maintainers: > + - Michael Walle > + > +description: | > + This module is part of the sl28cpld multi-function device. For more > + details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml. > + > +properties: > + compatible: > +enum: > + - kontron,sl28cpld-fan > + > + reg: > +maxItems: 1 > + > +required: > + - compatible > + > +additionalProperties: false > diff --git > a/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml > > b/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml > new file mode 100644 > index ..4c39e9ff9aea > --- /dev/null > +++ > b/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml > @@ -0,0 +1,54 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: > http://devicetree.org/schemas/interrupt-controller/kontron,sl28cpld-intc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Interrupt controller driver for the sl28cpld board management > controller > + > +maintainers: > + - Michael Walle > + > +description: | > + This module is part of the sl28cpld multi-function device. For more > + details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml. > + > + The following interrupts are available. All typ
Re: [PATCH v6 03/13] mfd: simple-mfd-i2c: add sl28cpld support
On Sun, 26 Jul 2020, Michael Walle wrote: > Add the core support for the board management controller found on the > SMARC-sAL28 board. > > At the moment, this controller is used on the Kontron SMARC-sAL28 board. > > Signed-off-by: Michael Walle > --- > Changes since v5: > - none > > Changes since v4: > - new patch > > drivers/mfd/simple-mfd-i2c.c | 1 + > 1 file changed, 1 insertion(+) For my own reference (apply this as-is to your sign-off block): Acked-for-MFD-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v4 1/6] fs: introduce FMODE_ZONE_APPEND and IOCB_ZONE_APPEND
On Tue, Jul 28, 2020 at 02:49:59AM +0100, Matthew Wilcox wrote: > On Sun, Jul 26, 2020 at 04:18:10PM +0100, Christoph Hellwig wrote: > > Zone append is a protocol context that ha not business showing up > > in a file system interface. The right interface is a generic way > > to report the written offset for an append write for any kind of file. > > So we should pick a better name like FMODE_REPORT_APPEND_OFFSET > > (not that I particularly like that name, but it is the best I could > > quickly come up with). > > Is it necessarily *append*? There were a spate of papers about ten > years ago for APIs that were "write anywhere and I'll tell you where it > ended up". So FMODE_ANONYMOUS_WRITE perhaps? But that really is not the semantics I had in mind - both the semantics for the proposed Linux file API and the NVMe Zone Append command say write exactly at the write pointer (NVMe) or end of the file (file API).
Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early boot
On Mon, Jul 27, 2020 at 09:18:31AM +, Peng Fan wrote: > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > > boot > > > > On Mon, Jul 27, 2020 at 06:44:32AM +, Peng Fan wrote: > > > Hi Oleksij, > > > > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and > > > > early boot > > > > > > > > Hi, > > > > > > > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > > > > This patchset is to support i.MX8MQ/M coproc booted before linux. > > > > > Since i.MX8MQ/M was not supported, several patches are needed to > > > > > first support the platform, then support early boot case. > > > > > > > > > > I intended to included i.MX8QM/QXP, but that would introduce a > > > > > large patchset, so not included. But the clk/syscon optional patch > > > > > for i.MX8QM/QXP was still kept here to avoid rebase error. > > > > > > > > Thank you for your work. > > > > > > > > Can you please provide more information about big picture of this work. > > > > > > > > If I see it correctly, we have here support for i.MX8MM, which seems > > > > to be able to fully control Cortex M4 (enable CPU core, etc...). > > > > > > Yes. > > > > In this case, I would recommend to mainline the i.MX8MM part > > first/separately. > > Only the last patch is to support earlyboot, all others is imx8mm part. ok > > > > > > > > > > And other case, where remoteproc is running on application processor > > > > and can't or should not touch M4 (i.MX7ULP, i.MX8QM/QXP..). Since M4 > > > > provides some functionality, you are trying to reuse remoteproc > > > > framework to get resource table present in ELF header and to > > > > dynamically load things. For some reasons this header provides more > > > > information then needed, so you are changing the ELF parser in the > > > > kernel > > to workaround it. > > > > > > Not exactly. > > > > > > For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 kicked by > > Linux remoteproc. > > > For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but we will > > > also add M4 kicked by Linux remoteproc. > > > For i.MX7ULP, I would only support M4 dual boot case, M4 control > > everything. > > > > From current state of discussion, i'm not sure what role plays remoteproc in > > the scenario where M4 is started before linux. Especially if we are not > > using > > resource table. > > We are using resource table from an address, not in elf file. > This is the new feature in Linux-next to support coproc booted early. > > > > > > The reason the change the elf parser is that when M4 elf is loaded by > > > Linux remoteproc, It use memset to clear area. > > > > The use of memset, depends on ELF format. Fix/change the linker script on > > your firmware and memset will be never called. > > > > > However we use ioremap, memset on ARM64 will report crash to device > > > nGnRE memory. And we could not use ioremap_wc to TCM area, since it > > > could have data correctly written into TCM. > > > > I have strong feeling, that we are talking about badly or not properly > > formatted ELF binary. I would prefer to double check it, before we will > > apply > > fixes on wrong place. > > > > > Maintainer not wanna to drop memset in common code, and TI guys > > > suggest add i.MX specific elf stuff. So I add elf handler in i.MX code. > > > > I think, removing memset may damage current users of imx_rproc driver. > > Since, like I said: the use of memset depends on ELF format. > > In my elf file, the last PT_LOAD contains data/bss/heap/stack. I'll check > with our MCU guys, we only need the specific data loaded. > > Elf file type is EXEC (Executable file) > Entry point 0x1ffe0355 > There are 3 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x01 0x1ffe 0x1ffe 0x00240 0x00240 R 0x1 > LOAD 0x010240 0x1ffe0240 0x1ffe0240 0x03e90 0x03e90 RWE 0x1 > LOAD 0x02 0x2000 0x1ffe40d0 0x00068 0x0ad00 RW 0x1 > > Section to Segment mapping: > Segment Sections... >00 .interrupts >01 .resource_table .text .ARM .init_array .fini_array >02 .data .bss .heap .stack Here is an example of formatting ELF for remoteproc: https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/local_src/remoteproc-elf/linker.ld https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/local_src/remoteproc-elf/imx7m4.S In this example I pack linux in to remoteproc elf image and start linux on imx7d-m4 part. Will be interesting if you can do the same on imx8* SoCs ;) Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v4 3/3] usb: dwc2: don't use ID/Vbus detection if usb-role-switch on STM32MP15 SoCs
Hi, On 7/27/20 9:44 PM, Andy Shevchenko wrote: On Mon, Jul 27, 2020 at 10:04 PM Martin Blumenstingl wrote: On Mon, Jul 27, 2020 at 11:23 AM Amelie Delaunay wrote: > - p->activate_stm_id_vb_detection = true; > + p->activate_stm_id_vb_detection = > + !of_property_read_bool(np, "usb-role-switch"); the rest of params.c uses device_property_read_* instead of of_read_property_* I thought I'd mention it so you can decide yourself whether this is fine or needs to be changed Better to change and leave all on one line. Thank you both for your review. I'll change it in upcoming v5. I'm still not used to exceed the 80 columns :) Regards, Amelie -- With Best Regards, Andy Shevchenko
Re: [PATCH v3] usb: dwc3: Add support for VBUS power control
Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Products B.V. Materiaalweg 4, 5681 RJ Best The Netherlands T: +31 (0) 499 33 69 69 E: mike.looijm...@topicproducts.com W: www.topicproducts.com Please consider the environment before printing this e-mail On 27-07-2020 13:53, Mark Brown wrote: On Mon, Jul 27, 2020 at 01:50:26PM +0200, Mike Looijmans wrote: Met vriendelijke groet / kind regards, Mike Looijmans System Expert You probably want to remove your signature when replying to the list... On 27-07-2020 12:23, Mark Brown wrote: On Sun, Jul 26, 2020 at 09:10:39AM +0200, Mike Looijmans wrote: It's the 5V VBUS power for the USB "plug" that's being controlled here. It must turned on when the controller is in "host" mode. Some boards arrange this in hardware through the PHY, and some just don't have any control at all and have it permanently on or off. On a board where the 5V is controlled using a GPIO line or an I2C chip, this patch is required to make it work. That sounds like the driver should not be using _get_optional() then. Making it mandatory would break most (read: all except Topic's) existing boards as they won't have it in their devicetree. I'm perfectly okay with that, but others might disagree. No, it wouldn't break them at all - they'd get a dummy regulator provided. Ah, so *not* using _get_optional will yield the behaviour that I'd want. I'll test and make a v4 patch.
Re: [PATCH 5.4 000/138] 5.4.54-rc1 review
On Mon, 27 Jul 2020 at 19:48, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.4.54 release. > There are 138 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 29 Jul 2020 13:48:51 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.54-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.4.54-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.4.y git commit: 7a4613493cc30754cf5159b126623d26314454bd git describe: v5.4.53-139-g7a4613493cc3 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.53-139-g7a4613493cc3 No regressions (compared to build v5.4.53) No fixes (compared to build v5.4.53) Ran 35091 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-io-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * v4l2-compliance * kselftest * kselftest/drivers * kselftest/filesystems * ltp-containers-tests * ltp-controllers-tests * ltp-hugetlb-tests * ltp-ipc-tests * ltp-mm-tests * network-basic-tests * kselftest/net * ltp-fs-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net * ssuite -- Linaro LKFT https://lkft.linaro.org
[PATCH] selftests: more general make nesting support
selftests can be built from the toplevel kernel makefile (e.g. make
kselftest-all) or directly (make -C tools/testing/selftests all).
The toplevel kernel makefile explicitly disables implicit rules with
"MAKEFLAGS += -rR", which is passed to tools/testing/selftests. Some
selftest makefiles require implicit make rules, which is why
commit 67d8712dcc70 ("selftests: Fix build failures when invoked from
kselftest target") reenables implicit rules by clearing MAKEFLAGS if
MAKELEVEL=1.
So far so good. However, if the toplevel makefile is called from an
outer makefile then MAKELEVEL will be elevated, which breaks the
MAKELEVEL equality test.
Example wrapped makefile error:
$ cat ~/Makefile
all:
$(MAKE) defconfig
$(MAKE) kselftest-all
$ make -sf ~/Makefile
futex_wait_timeout.c /src/tools/testing/selftests/kselftest_harness.h
/src/tools/testing/selftests/kselftest.h ../include/futextest.h
../include/atomic.h ../include/logging.h -lpthread -lrt -o
/src/tools/testing/selftests/futex/functional/futex_wait_timeout
make[4]: futex_wait_timeout.c: Command not found
Rather than checking $(MAKELEVEL), check for $(LINK.c), which is a more
direct side effect of "make -R". This enables arbitrary makefile
nesting.
Signed-off-by: Greg Thelen
---
tools/testing/selftests/Makefile | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 1195bd85af38..289a2e4b3f6f 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -84,10 +84,10 @@ endif
# of the targets gets built.
FORCE_TARGETS ?=
-# Clear LDFLAGS and MAKEFLAGS if called from main
-# Makefile to avoid test build failures when test
-# Makefile doesn't have explicit build rules.
-ifeq (1,$(MAKELEVEL))
+# Clear LDFLAGS and MAKEFLAGS when implicit rules are missing. This provides
+# implicit rules to sub-test Makefiles which avoids build failures in test
+# Makefile that don't have explicit build rules.
+ifeq (,$(LINK.c))
override LDFLAGS =
override MAKEFLAGS =
endif
--
2.28.0.rc0.142.g3c755180ce-goog
Re: [PATCH 5.7 000/179] 5.7.11-rc1 review
On Mon, 27 Jul 2020 at 19:49, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.7.11 release. > There are 179 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 29 Jul 2020 13:48:51 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.11-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.7.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 5.7.11-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.7.y git commit: 17edbab45dbfdee306397509538f3f12251f23b3 git describe: v5.7.10-180-g17edbab45dbf Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.7-oe/build/v5.7.10-180-g17edbab45dbf No regressions (compared to build v5.7.10) No fixes (compared to build v5.7.10) Ran 37112 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - juno-r2-compat - juno-r2-kasan - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 - x86-kasan Test Suites --- * build * install-android-platform-tools-r2600 * install-android-platform-tools-r2800 * kselftest * kselftest/drivers * kselftest/filesystems * kselftest/net * linux-log-parser * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-syscalls-tests * perf * v4l2-compliance * kvm-unit-tests * libhugetlbfs * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-sched-tests * ltp-open-posix-tests * network-basic-tests * igt-gpu-tools * ssuite * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-native/drivers * kselftest-vsyscall-mode-native/filesystems * kselftest-vsyscall-mode-native/net * kselftest-vsyscall-mode-none * kselftest-vsyscall-mode-none/drivers * kselftest-vsyscall-mode-none/filesystems * kselftest-vsyscall-mode-none/net -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] ARM: dts: berlin: Align L2 cache-controller nodename with dtschema
On Tue, Jul 28, 2020 at 8:37 AM Jisheng Zhang wrote: > > Hi arm-soc, > > > On Fri, 26 Jun 2020 10:06:41 +0200 Krzysztof Kozlowski wrote: > > > > > > > Fix dtschema validator warnings like: > > l2-cache-controller@ac: $nodename:0: > > 'l2-cache-controller@ac' does not match > > '^(cache-controller|cpu)(@[0-9a-f,]+)*$' > > > > Signed-off-by: Krzysztof Kozlowski > > Reviewed-by: Jisheng Zhang > > As for berlin linux-5.9, we only have this one patch, could you please > directly take this patch? Applied now. To ensure we actually see the patch, it's better if you can just send a new copy with your added Signed-off-by to s...@kernel.org than to reply to the original email. Thanks, Arnd
Re: linux-next: build failure after merge of the char-misc tree
Hi Greg,
On Mon, 27 Jul 2020 11:24:48 +0200 Greg KH wrote:
>
> On Mon, Jul 27, 2020 at 06:08:31PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the char-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from drivers/misc/habanalabs/goya/goya.c:8:
> > drivers/misc/habanalabs/goya/goyaP.h:12:10: fatal error: habanalabs.h: No
> > such file or directory
> >12 | #include "habanalabs.h"
> > | ^~
> > In file included from drivers/misc/habanalabs/goya/goya_security.c:8:
> > drivers/misc/habanalabs/goya/goyaP.h:12:10: fatal error: habanalabs.h: No
> > such file or directory
> >12 | #include "habanalabs.h"
> > | ^~
> >
> > Presumably caused by commit
> >
> > 70b2f993ea4a ("habanalabs: create common folder")
> >
> > I have used the char-misc tree from next-20200724 for today.
>
> Ugh, this is a mess of a merge with this driver.
>
> Oded, I'll take Stephen's merge resolutions here and push out a new
> version, and try to resolve this error, but if you could verify I got it
> correct, that would be great.
The conflicts are gone, but I still get these errors.
--
Cheers,
Stephen Rothwell
pgpRa6uHWZval.pgp
Description: OpenPGP digital signature
Re: [PATCH v5 1/6] kprobes: Remove dependency to the module_mutex
On Sat, 25 Jul 2020 12:21:10 +0200
Ingo Molnar wrote:
>
> * Jarkko Sakkinen wrote:
>
> > On Fri, Jul 24, 2020 at 11:17:11AM +0200, Ingo Molnar wrote:
> > >
> > > * Jarkko Sakkinen wrote:
> > >
> > > > --- a/kernel/kprobes.c
> > > > +++ b/kernel/kprobes.c
> > > > @@ -564,7 +564,7 @@ static void kprobe_optimizer(struct work_struct
> > > > *work)
> > > > cpus_read_lock();
> > > > mutex_lock(&text_mutex);
> > > > /* Lock modules while optimizing kprobes */
> > > > - mutex_lock(&module_mutex);
> > > > + lock_modules();
> > > >
> > > > /*
> > > > * Step 1: Unoptimize kprobes and collect cleaned (unused and
> > > > disarmed)
> > > > @@ -589,7 +589,7 @@ static void kprobe_optimizer(struct work_struct
> > > > *work)
> > > > /* Step 4: Free cleaned kprobes after quiesence period */
> > > > do_free_cleaned_kprobes();
> > > >
> > > > - mutex_unlock(&module_mutex);
> > > > + unlock_modules();
> > > > mutex_unlock(&text_mutex);
> > > > cpus_read_unlock();
> > >
> > > BTW., it would be nice to expand on the comments above - exactly which
> > > parts of the modules code is being serialized against and why?
> > >
> > > We already hold the text_mutex here, which should protect against most
> > > kprobes related activities interfering - and it's unclear (to me)
> > > which part of the modules code is being serialized with here, and the
> > > 'lock modules while optimizing kprobes' comments is unhelpful. :-)
> > >
> > > Thanks,
> > >
> > > Ingo
> >
> > AFAIK, only if you need to call find_module(), you ever need to acquire
> > this mutex. 99% of time it is internally taken care by kernel/module.c.
> >
> > I cannot make up any obvious reason to acquire it here.
>
> If it's unnecessary, then it needs to be removed.
>
> If it's necessary, then it needs to be documented better.
Good catch! This is not needed anymore.
It has been introduced to avoid conflict with text modification, at that
point we didn't get text_mutex. But after commit f1c6ece23729 ("kprobes: Fix
potential deadlock in kprobe_optimizer()") moved the text_mutex in the current
position, we don't need it. (and anyway, keeping kprobe_mutex locked means
any module unloading will be stopped inside kprobes_module_callback())
This may help?
>From 2355ecd941c3234b12a6de7443592848ed4e2087 Mon Sep 17 00:00:00 2001
From: Masami Hiramatsu
Date: Tue, 28 Jul 2020 16:32:34 +0900
Subject: [PATCH] kprobes: Remove unneeded module_mutex lock from the optimizer
Remove unneeded module_mutex locking from the optimizer. Since
we already locks both kprobe_mutex and text_mutex in the optimizer,
text will not be changed and the module unloading will be stopped
inside kprobes_module_callback().
Suggested-by: Ingo Molnar
Signed-off-by: Masami Hiramatsu
---
kernel/kprobes.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 4a904cc56d68..d1b02e890793 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -563,8 +563,6 @@ static void kprobe_optimizer(struct work_struct *work)
mutex_lock(&kprobe_mutex);
cpus_read_lock();
mutex_lock(&text_mutex);
- /* Lock modules while optimizing kprobes */
- mutex_lock(&module_mutex);
/*
* Step 1: Unoptimize kprobes and collect cleaned (unused and disarmed)
@@ -589,7 +587,6 @@ static void kprobe_optimizer(struct work_struct *work)
/* Step 4: Free cleaned kprobes after quiesence period */
do_free_cleaned_kprobes();
- mutex_unlock(&module_mutex);
mutex_unlock(&text_mutex);
cpus_read_unlock();
--
2.25.1
--
Masami Hiramatsu
Re: [Linux-kernel-mentees] [PATCH net v2] xdp: Prevent kernel-infoleak in xsk_getsockopt()
On Tue, Jul 28, 2020 at 7:37 AM Peilin Ye wrote:
>
> xsk_getsockopt() is copying uninitialized stack memory to userspace when
> `extra_stats` is `false`. Fix it.
>
> Fixes: 8aa5a33578e9 ("xsk: Add new statistics")
> Suggested-by: Dan Carpenter
> Signed-off-by: Peilin Ye
Acked-by: Arnd Bergmann
Re: [PATCH] Staging : media : atomisp : fixed a brace coding sytle issue
On Tue, Jul 28, 2020 at 03:00:10AM +0530, Ankit wrote: > From: Ankit Baluni You need a ' ' before the '<' character. > > Fixed a coding style issue. Be more descriptive of what you are doing, this is vague. > > Signed-off-by: Ankit Baluni Same here with the ' '. thanks, greg k-h
Re: [PATCH v3 0/3] Few bug fixes and Convert to pin_user_pages*()
On 28.07.20 09:10, Souptick Joarder wrote: Hi Boris, On Sun, Jul 12, 2020 at 9:01 AM Souptick Joarder wrote: This series contains few clean up, minor bug fixes and Convert get_user_pages() to pin_user_pages(). I'm compile tested this, but unable to run-time test, so any testing help is much appriciated. v2: Addressed few review comments and compile issue. Patch[1/2] from v1 split into 2 in v2. v3: Address review comment. Add review tag. Cc: John Hubbard Cc: Boris Ostrovsky Cc: Paul Durrant Souptick Joarder (3): xen/privcmd: Corrected error handling path xen/privcmd: Mark pages as dirty xen/privcmd: Convert get_user_pages*() to pin_user_pages*() Does this series looks good to go for 5.9 ? Yes. I already have it in my queue. Juergen
Re: [RESEND PATCH] drivers: arm arch timer: Correct fault programming of CNTKCTL_EL1.EVNTI
Friendly ping.
Is this an effective bugfix?
On 2020/7/17 17:21, Keqian Zhu wrote:
> ARM virtual counter supports event stream. It can only trigger an event
> when the trigger bit of CNTVCT_EL0 changes from 0 to 1 (or from 1 to 0),
> so the actual period of event stream is 2 ^ (cntkctl_evnti + 1). For
> example, when the trigger bit is 0, then it triggers an event for every
> two cycles.
>
> Signed-off-by: Keqian Zhu
> ---
> drivers/clocksource/arm_arch_timer.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index ecf7b7db2d05..06d99a4b1b9b 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -799,10 +799,20 @@ static void __arch_timer_setup(unsigned type,
> static void arch_timer_evtstrm_enable(int divider)
> {
> u32 cntkctl = arch_timer_get_cntkctl();
> + int cntkctl_evnti;
> +
> + /*
> + * Note that it can only trigger an event when the trigger bit
> + * of CNTVCT_EL0 changes from 1 to 0 (or from 0 to 1), so the
> + * actual period of event stream is 2 ^ (cntkctl_evnti + 1).
> + */
> + cntkctl_evnti = divider - 1;
> + cntkctl_evnti = min(cntkctl_evnti, 15);
> + cntkctl_evnti = max(cntkctl_evnti, 0);
>
> cntkctl &= ~ARCH_TIMER_EVT_TRIGGER_MASK;
> /* Set the divider and enable virtual event stream */
> - cntkctl |= (divider << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> + cntkctl |= (cntkctl_evnti << ARCH_TIMER_EVT_TRIGGER_SHIFT)
> | ARCH_TIMER_VIRT_EVT_EN;
> arch_timer_set_cntkctl(cntkctl);
> arch_timer_set_evtstrm_feature();
> @@ -816,10 +826,11 @@ static void arch_timer_configure_evtstream(void)
> /* Find the closest power of two to the divisor */
> evt_stream_div = arch_timer_rate / ARCH_TIMER_EVT_STREAM_FREQ;
> pos = fls(evt_stream_div);
> - if (pos > 1 && !(evt_stream_div & (1 << (pos - 2
> + if ((pos == 1) || (pos > 1 && !(evt_stream_div & (1 << (pos - 2)
> pos--;
> +
> /* enable event stream */
> - arch_timer_evtstrm_enable(min(pos, 15));
> + arch_timer_evtstrm_enable(pos);
> }
>
> static void arch_counter_set_user_access(void)
>
Re: [PATCH] ARM: dts: berlin: Align L2 cache-controller nodename with dtschema
On Tue, 28 Jul 2020 09:33:05 +0200 Arnd Bergmann wrote: > > > On Tue, Jul 28, 2020 at 8:37 AM Jisheng Zhang > wrote: > > > > Hi arm-soc, > > > > > > On Fri, 26 Jun 2020 10:06:41 +0200 Krzysztof Kozlowski wrote: > > > > > > > > > > > Fix dtschema validator warnings like: > > > l2-cache-controller@ac: $nodename:0: > > > 'l2-cache-controller@ac' does not match > > > '^(cache-controller|cpu)(@[0-9a-f,]+)*$' > > > > > > Signed-off-by: Krzysztof Kozlowski > > > > Reviewed-by: Jisheng Zhang > > > > As for berlin linux-5.9, we only have this one patch, could you please > > directly take this patch? > > Applied now. To ensure we actually see the patch, it's better if you can just > send a new copy with your added Signed-off-by to s...@kernel.org than to > reply to the original email. > Got it. Thanks for the your kind reminding
Re: [PATCH v6 01/13] mfd: add simple regmap based I2C driver
Am 2020-07-28 09:19, schrieb Lee Jones: On Sun, 26 Jul 2020, Michael Walle wrote: There are I2C devices which contain several different functions but doesn't require any special access functions. For these kind of drivers an I2C regmap should be enough. Create an I2C driver which creates an I2C regmap and enumerates its children. If a device wants to use this as its MFD core driver, it has to add an individual compatible string. It may provide its own regmap configuration. Subdevices can use dev_get_regmap() on the parent to get their regmap instance. Signed-off-by: Michael Walle --- Changes since v5: - removed "select MFD_CORE" in Kconfig - removed help text in Kconfig, we assume that the users of this That's the opposite of what I asked for. What is the use to describe the symbol, if it is not user selectable? I'm not aware this is done anywhere in the kernel, am I missing something? driver will have a "select MFD_SIMPLE_MFD_I2C". Instead added a small description to the driver itself. - removed "struct simple_mfd_i2c_config" and use regmap_config directly - changed builtin_i2c_driver() to module_i2c_driver(), added MODULE_ boilerplate - cleaned up the included files Changes since v4: - new patch. Lee, please bear with me. I didn't want to delay the new version (where a lot of remarks on the other patches were addressed) even more, just because we haven't figured out how to deal with the MFD part. So for now, I've included this one. drivers/mfd/Kconfig | 5 drivers/mfd/Makefile | 1 + drivers/mfd/simple-mfd-i2c.c | 55 3 files changed, 61 insertions(+) create mode 100644 drivers/mfd/simple-mfd-i2c.c diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 33df0837ab41..c08539c7a166 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1162,6 +1162,11 @@ config MFD_SI476X_CORE To compile this driver as a module, choose M here: the module will be called si476x-core. +config MFD_SIMPLE_MFD_I2C + tristate + depends on I2C + select REGMAP_I2C Please provide a full help. See above. config MFD_SM501 tristate "Silicon Motion SM501" depends on HAS_DMA diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index a60e5f835283..78d24a3e7c9e 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -264,3 +264,4 @@ obj-$(CONFIG_MFD_STMFX) += stmfx.o obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o +obj-$(CONFIG_MFD_SIMPLE_MFD_I2C) += simple-mfd-i2c.o diff --git a/drivers/mfd/simple-mfd-i2c.c b/drivers/mfd/simple-mfd-i2c.c new file mode 100644 index ..45090ddad104 --- /dev/null +++ b/drivers/mfd/simple-mfd-i2c.c @@ -0,0 +1,55 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * A very simple I2C MFD driver Simple MFD - I2C ok. + * The driver enumerates its children and registers a common regmap. Use + * dev_get_regmap(pdev->dev.parent, NULL) in the child nodes to fetch that + * regmap instance. This driver creates a single register map with the intention for it to be shared by all sub-devices. Children can use their parent's device structure (dev.parent) in order reference it. Should this be appended or should it replace my paragraph? If its the latter, the "enumeration of the children" is missing. + * In the future this driver might be extended to support also other interfaces + * like SPI etc. Remove this please. Why would you remove information about the intention of this driver? If someone looks for a place to implement its SPI/I3C/Slimbus MFD driver this might come in handy. -michael
Re: [PATCH v6 06/13] pwm: add support for sl28cpld PWM controller
Hello,
just a few minor issues left:
On Sun, Jul 26, 2020 at 01:18:27AM +0200, Michael Walle wrote:
> diff --git a/drivers/pwm/pwm-sl28cpld.c b/drivers/pwm/pwm-sl28cpld.c
> new file mode 100644
> index ..956fa09f3aba
> --- /dev/null
> +++ b/drivers/pwm/pwm-sl28cpld.c
> @@ -0,0 +1,223 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * sl28cpld PWM driver
> + *
> + * Copyright (c) 2020 Michael Walle
> + *
> + * There is no public datasheet available for this PWM core. But it is easy
> + * enough to be briefly explained. It consists of one 8-bit counter. The PWM
> + * supports four distinct frequencies by selecting when to reset the counter.
> + * With the prescaler setting you can select which bit of the counter is used
> + * to reset it. This implies that the higher the frequency the less remaining
> + * bits are available for the actual counter.
> + *
> + * Let cnt[7:0] be the counter, clocked at 32kHz:
> + * +---++--+---+
> + * | prescaler | reset | counter bits | frequency |
> + * +---++--+---+
> + * | 0 | cnt[7] | cnt[6:0] | 250Hz |
> + * | 1 | cnt[6] | cnt[5:0] | 500Hz |
> + * | 2 | cnt[5] | cnt[4:0] | 1kHz |
> + * | 3 | cnt[4] | cnt[3:0] | 2kHz |
> + * +---++--+---+
Very nice. I'd add a "period length" column, as this is what the PWM
core uses.
For your convenience (and as I created that table anyhow for further
checking of the formulas below):
* +---++--+---++
* | prescaler | reset | counter bits | frequency | period |
* | || | | length |
* +---++--+---++
* | 0 | cnt[7] | cnt[6:0] | 250Hz | 4000ns |
* | 1 | cnt[6] | cnt[5:0] | 500Hz | 2000ns |
* | 2 | cnt[5] | cnt[4:0] | 1kHz | 1000ns |
* | 3 | cnt[4] | cnt[3:0] | 2kHz | 500ns |
* +---++--+---++
> + *
> + * Limitations:
> + * - The hardware cannot generate a 100% duty cycle if the prescaler is 0.
> + * - The hardware cannot atomically set the prescaler and the counter value,
> + * which might lead to glitches and inconsistent states if a write fails.
> + * - The counter is not reset if you switch the prescaler which leads
> + * to glitches, too.
> + * - The duty cycle will switch immediately and not after a complete cycle.
> + * - Depending on the actual implementation, disabling the PWM might have
> + * side effects. For example, if the output pin is shared with a GPIO pin
> + * it will automatically switch back to GPIO mode.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * PWM timer block registers.
> + */
> +#define SL28CPLD_PWM_CTRL0x00
> +#define SL28CPLD_PWM_CTRL_ENABLE BIT(7)
> +#define SL28CPLD_PWM_CTRL_PRESCALER_MASK GENMASK(1, 0)
> +#define SL28CPLD_PWM_CYCLE 0x01
> +#define SL28CPLD_PWM_CYCLE_MAX GENMASK(6, 0)
> +
> +#define SL28CPLD_PWM_CLK 32000 /* 32 kHz */
> +#define SL28CPLD_PWM_MAX_DUTY_CYCLE(prescaler) (1 << (7 - (prescaler)))
> +#define SL28CPLD_PWM_PERIOD(prescaler) \
> + (NSEC_PER_SEC / SL28CPLD_PWM_CLK *
> SL28CPLD_PWM_MAX_DUTY_CYCLE(prescaler))
> +
> +/*
> + * We calculate the duty cycle like this:
> + * duty_cycle_ns = pwm_cycle_reg * max_period_ns / max_duty_cycle
> + *
> + * With
> + * max_period_ns = (1 << 7 - prescaler) / pwm_clk * NSEC_PER_SEC
> + * max_duty_cycle = 1 << (7 - prescaler)
If you don't need parenthesis in the max_period_ns around 7 - prescaler,
you don't need them either in the max_duty_cycle line.
> + * this then simplifies to:
> + * duty_cycle_ns = pwm_cycle_reg / pwm_clk * NSEC_PER_SEC
> + */
> +#define SL28CPLD_PWM_TO_DUTY_CYCLE(reg) \
> + (NSEC_PER_SEC / SL28CPLD_PWM_CLK * (reg))
For those who copy from your driver maybe add a comment like:
* NSEC_PER_SEC / SL28CPLD_PWM_CLK is integer here, so we're not loosing
* precision by doing the division first.
> +#define SL28CPLD_PWM_FROM_DUTY_CYCLE(duty_cycle) \
> + (DIV_ROUND_DOWN_ULL((duty_cycle), NSEC_PER_SEC / SL28CPLD_PWM_CLK))
> +
> +struct sl28cpld_pwm {
> + struct pwm_chip pwm_chip;
> + struct regmap *regmap;
> + u32 offset;
> +};
> +
> +static void sl28cpld_pwm_get_state(struct pwm_chip *chip,
> +struct pwm_device *pwm,
> +struct pwm_state *state)
> +{
> + struct sl28cpld_pwm *priv = dev_get_drvdata(chip->dev);
> + unsigned int reg;
> + int prescaler;
> +
> + regmap_read(priv->regmap, priv->offset + SL28CPLD_PWM_CTRL, ®);
Would it make sense to hide this using e.g.:
#define sl28cpkd_pwm_read(priv, reg, val)
Re: [RESEND PATCH v2] mfd: syscon: Use a unique name with regmap_config
On Mon, Jul 27, 2020 at 11:10 PM Suman Anna wrote: > > The DT node full name is currently being used in regmap_config > which in turn is used to create the regmap debugfs directories. > This name however is not guaranteed to be unique and the regmap > debugfs registration can fail in the cases where the syscon nodes > have the same unit-address but are present in different DT node > hierarchies. Replace this logic using the syscon reg resource > address instead (inspired from logic used while creating platform > devices) to ensure a unique name is given for each syscon. > > Signed-off-by: Suman Anna > --- > Hi Arnd, > Lee is looking for your review on this patch. Can you please > review and provide your comments. Sorry for missing this earlier. I think this makes sense, and I don't expect the name change to cause problems, so Reviewed-by: Arnd Bergmann > --- a/drivers/mfd/syscon.c > +++ b/drivers/mfd/syscon.c > @@ -101,12 +101,14 @@ static struct syscon *of_syscon_register(struct > device_node *np, bool check_clk) > } > } > > - syscon_config.name = of_node_full_name(np); > + syscon_config.name = kasprintf(GFP_KERNEL, "%pOFn@%llx", np, > + (u64)res.start); Note that you could avoid the cast by using "%pOFn@%pa", and passing res.start by reference. Not important though, the result should be similar, and you might not like the '0x' that this adds. Arnd
[PATCH v5 0/3] Add USB role switch support to DWC2
When using usb-c connector (but it can also be the case with a micro-b connector), iddig, avalid, bvalid, vbusvalid input signals may not be connected to the DWC2 OTG controller. DWC2 OTG controller features an overriding control of the PHY voltage valid and ID input signals. So, missing signals can be forced using usb role from usb role switch and this override feature. This series adds support for usb role switch to dwc2, by using overriding control of the PHY voltage valid and ID input signals. It has been tested on stm32mp157c-dk2 [1], which has a Type-C connector managed by a Type-C port controller, and connected to USB OTG controller. [1] https://www.st.com/en/evaluation-tools/stm32mp157c-dk2.html Amelie Delaunay (3): dt-bindings: usb: dwc2: add optional usb-role-switch property usb: dwc2: override PHY input signals with usb role switch support usb: dwc2: don't use ID/Vbus detection if usb-role-switch on STM32MP15 SoCs --- Changes in v5: - Use device_property_read_bool instead of of_read_property_bool in params.c Changes in v4: - Simplify call to dwc2_force_mode in drd.c - Add error_drd label in probe error path in platform.c Changes in v3: - Fix build issue reported by kernel test robot in drd.c Changes in v2: - Previous DT patch already in stm32-next branch so removed from v2 patchset "ARM: dts: stm32: enable usb-role-switch on USB OTG on stm32mp15xx-dkx" - DWC2 DT bindings update added - Build issue reported by kernel test robot fixed - Martin's comments taken into account --- .../devicetree/bindings/usb/dwc2.yaml | 4 + drivers/usb/dwc2/Kconfig | 1 + drivers/usb/dwc2/Makefile | 2 +- drivers/usb/dwc2/core.h | 9 + drivers/usb/dwc2/drd.c| 180 ++ drivers/usb/dwc2/gadget.c | 2 +- drivers/usb/dwc2/params.c | 2 +- drivers/usb/dwc2/platform.c | 20 +- 8 files changed, 215 insertions(+), 5 deletions(-) create mode 100644 drivers/usb/dwc2/drd.c -- 2.17.1
[PATCH v5 1/3] dt-bindings: usb: dwc2: add optional usb-role-switch property
This patch documents the usb-role-switch property in dwc2 bindings, now that usb-role-switch support is available in dwc2 driver. Reviewed-by: Martin Blumenstingl Signed-off-by: Amelie Delaunay --- Documentation/devicetree/bindings/usb/dwc2.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 9352a8ef60a6..7b226eeffe82 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -100,6 +100,10 @@ properties: dr_mode: enum: [host, peripheral, otg] + usb-role-switch: +$ref: /schemas/types.yaml#/definitions/flag +description: Support role switch. + g-rx-fifo-size: $ref: /schemas/types.yaml#/definitions/uint32 description: size of rx fifo size in gadget mode. -- 2.17.1
[PATCH v5 3/3] usb: dwc2: don't use ID/Vbus detection if usb-role-switch on STM32MP15 SoCs
If usb-role-switch is present in the device tree, it means that ID and Vbus signals are not connected to the OTG controller but to an external component (GPIOs, Type-C controller). In this configuration, usb role switch is used to force valid sessions on STM32MP15 SoCs. Signed-off-by: Amelie Delaunay --- Changes in v5: - Use device_property_read_bool instead of of_read_property_bool --- drivers/usb/dwc2/params.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c index a3611cdd1dea..50df72f32b4c 100644 --- a/drivers/usb/dwc2/params.c +++ b/drivers/usb/dwc2/params.c @@ -185,7 +185,7 @@ static void dwc2_set_stm32mp15_hsotg_params(struct dwc2_hsotg *hsotg) struct dwc2_core_params *p = &hsotg->params; p->otg_cap = DWC2_CAP_PARAM_NO_HNP_SRP_CAPABLE; - p->activate_stm_id_vb_detection = true; + p->activate_stm_id_vb_detection = !device_property_read_bool(hsotg->dev, "usb-role-switch"); p->host_rx_fifo_size = 440; p->host_nperio_tx_fifo_size = 256; p->host_perio_tx_fifo_size = 256; -- 2.17.1
[PATCH v5 2/3] usb: dwc2: override PHY input signals with usb role switch support
This patch adds support for usb role switch to dwc2, by using overriding
control of the PHY voltage valid and ID input signals.
iddig signal (ID) can be overridden:
- when setting GUSBCFG_FORCEHOSTMODE, iddig input pin is overridden with 1;
- when setting GUSBCFG_FORCEDEVMODE, iddig input pin is overridden with 0.
avalid/bvalid/vbusvalid signals can be overridden respectively with:
- GOTGCTL_AVALOEN + GOTGCTL_AVALOVAL
- GOTGCTL_BVALOEN + GOTGCTL_BVALOVAL
- GOTGCTL_VBVALEN + GOTGCTL_VBVALOVAL
It is possible to determine valid sessions thanks to usb role switch:
- if USB_ROLE_NONE then !avalid && !bvalid && !vbusvalid
- if USB_ROLE_DEVICE then !avalid && bvalid && vbusvalid
- if USB_ROLE_HOST then avalid && !bvalid && vbusvalid
Acked-by: Martin Blumenstingl
Signed-off-by: Amelie Delaunay
---
No changes in v5.
Changes in v4:
- Simplify call to dwc2_force_mode in drd.c
- Add error_drd label in probe error path in platform.c
Changes in v3:
- Fix build issue reported by kernel test robot in drd.c
Changes in v2:
- Fix build issue reported by kernel test robot
- Move call to dwc2_force_mode outside spinlock context
- Add dwc2_drd_exit call in probe error path
---
drivers/usb/dwc2/Kconfig| 1 +
drivers/usb/dwc2/Makefile | 2 +-
drivers/usb/dwc2/core.h | 9 ++
drivers/usb/dwc2/drd.c | 180
drivers/usb/dwc2/gadget.c | 2 +-
drivers/usb/dwc2/platform.c | 20 +++-
6 files changed, 210 insertions(+), 4 deletions(-)
create mode 100644 drivers/usb/dwc2/drd.c
diff --git a/drivers/usb/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig
index 16e1aa304edc..dceb8f32414e 100644
--- a/drivers/usb/dwc2/Kconfig
+++ b/drivers/usb/dwc2/Kconfig
@@ -47,6 +47,7 @@ config USB_DWC2_PERIPHERAL
config USB_DWC2_DUAL_ROLE
bool "Dual Role mode"
depends on (USB=y && USB_GADGET=y) || (USB_DWC2=m && USB && USB_GADGET)
+ select USB_ROLE_SWITCH
help
Select this option if you want the driver to work in a dual-role
mode. In this mode both host and gadget features are enabled, and
diff --git a/drivers/usb/dwc2/Makefile b/drivers/usb/dwc2/Makefile
index 440320cc20a4..2bcd6945df46 100644
--- a/drivers/usb/dwc2/Makefile
+++ b/drivers/usb/dwc2/Makefile
@@ -3,7 +3,7 @@ ccflags-$(CONFIG_USB_DWC2_DEBUG)+= -DDEBUG
ccflags-$(CONFIG_USB_DWC2_VERBOSE) += -DVERBOSE_DEBUG
obj-$(CONFIG_USB_DWC2) += dwc2.o
-dwc2-y := core.o core_intr.o platform.o
+dwc2-y := core.o core_intr.o platform.o drd.o
dwc2-y += params.o
ifneq ($(filter y,$(CONFIG_USB_DWC2_HOST) $(CONFIG_USB_DWC2_DUAL_ROLE)),)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9deff0400a92..7161344c6522 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -860,6 +860,7 @@ struct dwc2_hregs_backup {
* - USB_DR_MODE_PERIPHERAL
* - USB_DR_MODE_HOST
* - USB_DR_MODE_OTG
+ * @role_sw: usb_role_switch handle
* @hcd_enabled: Host mode sub-driver initialization indicator.
* @gadget_enabled:Peripheral mode sub-driver initialization indicator.
* @ll_hw_enabled: Status of low-level hardware resources.
@@ -1054,6 +1055,7 @@ struct dwc2_hsotg {
struct dwc2_core_params params;
enum usb_otg_state op_state;
enum usb_dr_mode dr_mode;
+ struct usb_role_switch *role_sw;
unsigned int hcd_enabled:1;
unsigned int gadget_enabled:1;
unsigned int ll_hw_enabled:1;
@@ -1376,6 +1378,11 @@ static inline int dwc2_is_device_mode(struct dwc2_hsotg
*hsotg)
return (dwc2_readl(hsotg, GINTSTS) & GINTSTS_CURMODE_HOST) == 0;
}
+int dwc2_drd_init(struct dwc2_hsotg *hsotg);
+void dwc2_drd_suspend(struct dwc2_hsotg *hsotg);
+void dwc2_drd_resume(struct dwc2_hsotg *hsotg);
+void dwc2_drd_exit(struct dwc2_hsotg *hsotg);
+
/*
* Dump core registers and SPRAM
*/
@@ -1392,6 +1399,7 @@ int dwc2_hsotg_resume(struct dwc2_hsotg *dwc2);
int dwc2_gadget_init(struct dwc2_hsotg *hsotg);
void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg *dwc2,
bool reset);
+void dwc2_hsotg_core_disconnect(struct dwc2_hsotg *hsotg);
void dwc2_hsotg_core_connect(struct dwc2_hsotg *hsotg);
void dwc2_hsotg_disconnect(struct dwc2_hsotg *dwc2);
int dwc2_hsotg_set_test_mode(struct dwc2_hsotg *hsotg, int testmode);
@@ -1417,6 +1425,7 @@ static inline int dwc2_gadget_init(struct dwc2_hsotg
*hsotg)
{ return 0; }
static inline void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg *dwc2,
bool reset) {}
+static inline void dwc2_hsotg_core_disconnect(struct dwc2_hsotg *hsotg) {}
static inline void dwc2_hsotg_core_connect(struct dwc2_hsotg *hsotg) {}
static inline void dwc2_hsotg_disconnect(struct dwc2_hsotg *dwc2) {}
static inline int dwc2_hso
Re: [PATCH 1/2] media: stm32-dcmi: create video dev within notifier bound
Reviewed-by: Hugues Fruchet
On 7/28/20 8:37 AM, Alain Volmat wrote:
> In case of an error during the initialization of the sensor,
> the video device is still available since created at the
> probe of the dcmi driver. Moreover the device wouldn't
> be released even when removing the module since the release
> is performed as part of the notifier unbind callback
> (not called if no sensor is properly initialized).
>
> This patch move the video device creation with the v4l2 notifier
> bound handler in order to avoid having a video device created when
> an error happen during the pipe (dcmi - sensor) initialization.
>
> This also makes the video device creation symmetric with the
> release which is already done within the notifier unbind handler.
>
> Fixes: 37404f91ef8b ("[media] stm32-dcmi: STM32 DCMI camera interface driver")
> Signed-off-by: Alain Volmat
> ---
> drivers/media/platform/stm32/stm32-dcmi.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c
> b/drivers/media/platform/stm32/stm32-dcmi.c
> index b8931490b83b..5e60d4c6eeeb 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -1747,6 +1747,15 @@ static int dcmi_graph_notify_bound(struct
> v4l2_async_notifier *notifier,
>
> dev_dbg(dcmi->dev, "Subdev \"%s\" bound\n", subdev->name);
>
> + ret = video_register_device(dcmi->vdev, VFL_TYPE_VIDEO, -1);
> + if (ret) {
> + dev_err(dcmi->dev, "Failed to register video device\n");
> + return ret;
> + }
> +
> + dev_dbg(dcmi->dev, "Device registered as %s\n",
> + video_device_node_name(dcmi->vdev));
> +
> /*
>* Link this sub-device to DCMI, it could be
>* a parallel camera sensor or a bridge
> @@ -1759,10 +1768,11 @@ static int dcmi_graph_notify_bound(struct
> v4l2_async_notifier *notifier,
> &dcmi->vdev->entity, 0,
> MEDIA_LNK_FL_IMMUTABLE |
> MEDIA_LNK_FL_ENABLED);
> - if (ret)
> + if (ret) {
> dev_err(dcmi->dev, "Failed to create media pad link with subdev
> \"%s\"\n",
> subdev->name);
> - else
> + video_unregister_device(dcmi->vdev);
> + } else
> dev_dbg(dcmi->dev, "DCMI is now linked to \"%s\"\n",
> subdev->name);
>
> @@ -1974,15 +1984,6 @@ static int dcmi_probe(struct platform_device *pdev)
> }
> dcmi->vdev->entity.flags |= MEDIA_ENT_FL_DEFAULT;
>
> - ret = video_register_device(dcmi->vdev, VFL_TYPE_VIDEO, -1);
> - if (ret) {
> - dev_err(dcmi->dev, "Failed to register video device\n");
> - goto err_media_entity_cleanup;
> - }
> -
> - dev_dbg(dcmi->dev, "Device registered as %s\n",
> - video_device_node_name(dcmi->vdev));
> -
> /* Buffer queue */
> q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> q->io_modes = VB2_MMAP | VB2_READ | VB2_DMABUF;
>
Re: [PATCH] hwrng: imx-rngc - setup default RNG quality
Hi Christian,
On 20-07-27 14:45, Christian Eggers wrote:
> When hw_random device's quality is non-zero, it will automatically fill
> the kernel's entropy pool at boot. For this purpose, one conservative
> quality value is being picked up as the default value.
IMHO your value is not conservative enough and the commit message should
explain why we should use 900. Unfortunately I had not enough time to
send my patch addressing this. However please check my commit message
why 900 is not good:
8<
>From 9f047eee5e4ce8353c9b764a47e7f584b2013347 Mon Sep 17 00:00:00 2001
From: Marco Felsch
Date: Thu, 7 May 2020 12:01:28 +0200
Subject: [PATCH] hwrng: imx-rngc - add quality to use it as kernel entropy
pool
The RM describes the RNGB as follow:
8<
The RNGB uses the True Random Number Generator (TRNG) and a
Pseudo-Random Number Generator (PRNG) to achieve a true randomness and
cryptographic strength.
8<
The RNGB has 3 operation modes: self-test, seed-generation and the final
'random number generation' mode. Befor we can retrieve random numbers
from the RNGB we need to generate the seed pool:
8<
During the seed generation, the RNGB adds the entropy generated in the
TRNG to the 256-bit XKEY register. The PRNG algorithm executes 20.000
entropy samples from the TRNG to create an initial seed for the random
number generation.
8<
The RNGB can generate 2^20 words (4byte) of 'random' data after the
seed pool was initialized. The pool needs to be reseeded if more words
are required. The reseeding is done automatically since
commit 3acd9ea9331c ("hwrng: imx-rngc - use automatic seeding").
We can't retrieve the TRNG values directly so we need a other way to get
the quality level. We know that the PRNG uses 20.000 entropy samples
from the TRNG to generate 2^20 words (1MiB) and the quality level is
defined as (in bits of entropy per 1024 bits of input). So the quality
level can be calculated by:
20.000 * 1024
- = ~ 19.5
2^20
Signed-off-by: Marco Felsch
---
drivers/char/hw_random/imx-rngc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/char/hw_random/imx-rngc.c
b/drivers/char/hw_random/imx-rngc.c
index 9c47e431ce90..61c844baf26e 100644
--- a/drivers/char/hw_random/imx-rngc.c
+++ b/drivers/char/hw_random/imx-rngc.c
@@ -285,6 +285,7 @@ static int imx_rngc_probe(struct platform_device *pdev)
rngc->rng.init = imx_rngc_init;
rngc->rng.read = imx_rngc_read;
rngc->rng.cleanup = imx_rngc_cleanup;
+ rngc->rng.quality = 19;
rngc->dev = &pdev->dev;
platform_set_drvdata(pdev, rngc);
Re: [PATCH 2/2] media: stm32-dcmi: fix probe error path & module remove
Reviewed-by: Hugues Fruchet
On 7/28/20 8:37 AM, Alain Volmat wrote:
> This commit add missing vb2_queue_release calls with the
> probe error path and module remove.
> Missing v4l2_async_notifier_unregister is also added within
> the probe error path
>
> Fixes: 37404f91ef8b ("[media] stm32-dcmi: STM32 DCMI camera interface driver")
> Signed-off-by: Alain Volmat
> ---
> drivers/media/platform/stm32/stm32-dcmi.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c
> b/drivers/media/platform/stm32/stm32-dcmi.c
> index 5e60d4c6eeeb..57830ee691be 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -2004,7 +2004,7 @@ static int dcmi_probe(struct platform_device *pdev)
>
> ret = dcmi_graph_init(dcmi);
> if (ret < 0)
> - goto err_media_entity_cleanup;
> + goto err_vb2_queue_release;
>
> /* Reset device */
> ret = reset_control_assert(dcmi->rstc);
> @@ -2030,7 +2030,10 @@ static int dcmi_probe(struct platform_device *pdev)
> return 0;
>
> err_cleanup:
> + v4l2_async_notifier_unregister(&dcmi->notifier);
> v4l2_async_notifier_cleanup(&dcmi->notifier);
> +err_vb2_queue_release:
> + vb2_queue_release(q);
> err_media_entity_cleanup:
> media_entity_cleanup(&dcmi->vdev->entity);
> err_device_release:
> @@ -2052,6 +2055,7 @@ static int dcmi_remove(struct platform_device *pdev)
>
> v4l2_async_notifier_unregister(&dcmi->notifier);
> v4l2_async_notifier_cleanup(&dcmi->notifier);
> + vb2_queue_release(&dcmi->queue);
> media_entity_cleanup(&dcmi->vdev->entity);
> v4l2_device_unregister(&dcmi->v4l2_dev);
> media_device_cleanup(&dcmi->mdev);
>
Re: [PATCH] thermal: core: Add thermal zone enable/disable notification
On Tue, 2020-07-28 at 01:10 +0200, Daniel Lezcano wrote: > Now the calls to enable/disable a thermal zone are centralized in a > call to a function, we can add in these the corresponding netlink > notifications. > > Signed-off-by: Daniel Lezcano Acked-by: Zhang Rui > --- > drivers/thermal/thermal_core.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/thermal/thermal_core.c > b/drivers/thermal/thermal_core.c > index 9748fbb9a3a1..72bf159bcecc 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -509,6 +509,11 @@ static int thermal_zone_device_set_mode(struct > thermal_zone_device *tz, > > thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED); > > + if (mode == THERMAL_DEVICE_ENABLED) > + thermal_notify_tz_enable(tz->id); > + else > + thermal_notify_tz_disable(tz->id); > + > return ret; > } >
RE: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early boot
> Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > boot > > On Mon, Jul 27, 2020 at 09:18:31AM +, Peng Fan wrote: > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and > > > early boot > > > > > > On Mon, Jul 27, 2020 at 06:44:32AM +, Peng Fan wrote: > > > > Hi Oleksij, > > > > > > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M > > > > > and early boot > > > > > > > > > > Hi, > > > > > > > > > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > > > > > This patchset is to support i.MX8MQ/M coproc booted before linux. > > > > > > Since i.MX8MQ/M was not supported, several patches are needed > > > > > > to first support the platform, then support early boot case. > > > > > > > > > > > > I intended to included i.MX8QM/QXP, but that would introduce a > > > > > > large patchset, so not included. But the clk/syscon optional > > > > > > patch for i.MX8QM/QXP was still kept here to avoid rebase error. > > > > > > > > > > Thank you for your work. > > > > > > > > > > Can you please provide more information about big picture of this > work. > > > > > > > > > > If I see it correctly, we have here support for i.MX8MM, which > > > > > seems to be able to fully control Cortex M4 (enable CPU core, etc...). > > > > > > > > Yes. > > > > > > In this case, I would recommend to mainline the i.MX8MM part > > > first/separately. > > > > Only the last patch is to support earlyboot, all others is imx8mm part. > > ok > > > > > > > > > > > > > > And other case, where remoteproc is running on application > > > > > processor and can't or should not touch M4 (i.MX7ULP, > > > > > i.MX8QM/QXP..). Since M4 provides some functionality, you are > > > > > trying to reuse remoteproc framework to get resource table > > > > > present in ELF header and to dynamically load things. For some > > > > > reasons this header provides more information then needed, so > > > > > you are changing the ELF parser in the kernel > > > to workaround it. > > > > > > > > Not exactly. > > > > > > > > For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 kicked > > > > by > > > Linux remoteproc. > > > > For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but we > > > > will also add M4 kicked by Linux remoteproc. > > > > For i.MX7ULP, I would only support M4 dual boot case, M4 control > > > everything. > > > > > > From current state of discussion, i'm not sure what role plays > > > remoteproc in the scenario where M4 is started before linux. > > > Especially if we are not using resource table. > > > > We are using resource table from an address, not in elf file. > > This is the new feature in Linux-next to support coproc booted early. > > > > > > > > > The reason the change the elf parser is that when M4 elf is loaded > > > > by Linux remoteproc, It use memset to clear area. > > > > > > The use of memset, depends on ELF format. Fix/change the linker > > > script on your firmware and memset will be never called. > > > > > > > However we use ioremap, memset on ARM64 will report crash to > > > > device nGnRE memory. And we could not use ioremap_wc to TCM area, > > > > since it could have data correctly written into TCM. > > > > > > I have strong feeling, that we are talking about badly or not > > > properly formatted ELF binary. I would prefer to double check it, > > > before we will apply fixes on wrong place. > > > > > > > Maintainer not wanna to drop memset in common code, and TI guys > > > > suggest add i.MX specific elf stuff. So I add elf handler in i.MX code. > > > > > > I think, removing memset may damage current users of imx_rproc driver. > > > Since, like I said: the use of memset depends on ELF format. > > > > In my elf file, the last PT_LOAD contains data/bss/heap/stack. I'll > > check with our MCU guys, we only need the specific data loaded. > > > > Elf file type is EXEC (Executable file) Entry point 0x1ffe0355 There > > are 3 program headers, starting at offset 52 > > > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz MemSiz > Flg Align > > LOAD 0x01 0x1ffe 0x1ffe 0x00240 0x00240 > R 0x1 > > LOAD 0x010240 0x1ffe0240 0x1ffe0240 0x03e90 0x03e90 > RWE 0x1 > > LOAD 0x02 0x2000 0x1ffe40d0 0x00068 0x0ad00 > RW 0x1 > > > > Section to Segment mapping: > > Segment Sections... > >00 .interrupts > >01 .resource_table .text .ARM .init_array .fini_array > >02 .data .bss .heap .stack > > Here is an example of formatting ELF for remoteproc: > https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/loc > al_src/remoteproc-elf/linker.ld > https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/loc > al_src/remoteproc-elf/imx7m4.S > > In this example I pack linux in to remoteproc elf image and start linux on > imx7d-m4 part. > Will be interesting if you can do the same on imx8* SoCs ;) In NXP release, the m4
[PATCHv2] coresight: etm4x: Fix etm4_count race by moving cpuhp callbacks to init
etm4_count keeps track of number of ETMv4 registered and on some systems,
a race is observed on etm4_count variable which can lead to multiple calls
to cpuhp_setup_state_nocalls_cpuslocked(). This function internally calls
cpuhp_store_callbacks() which prevents multiple registrations of callbacks
for a given state and due to this race, it returns -EBUSY leading to ETM
probe failures like below.
coresight-etm4x: probe of 704.etm failed with error -16
This race can easily be triggered with async probe by setting probe type
as PROBE_PREFER_ASYNCHRONOUS and with ETM power management property
"arm,coresight-loses-context-with-cpu".
Prevent this race by moving cpuhp callbacks to etm driver init since the
cpuhp callbacks doesn't have to depend on the etm4_count and can be once
setup during driver init. Similarly we move cpu_pm notifier registration
to driver init and completely remove etm4_count usage.
Fixes: 9b6a3f3633a5 ("coresight: etmv4: Fix CPU power management setup in
probe() function")
Fixes: 58eb457be028 ("hwtracing/coresight-etm4x: Convert to hotplug state
machine")
Suggested-by: Suzuki K Poulose
Signed-off-by: Sai Prakash Ranjan
---
Changes in v2:
* Rearrange cpuhp callbacks and move them to driver init (Suzuki K Poulose)
---
drivers/hwtracing/coresight/coresight-etm4x.c | 51 ++-
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
b/drivers/hwtracing/coresight/coresight-etm4x.c
index 6d7d2169bfb2..adb71987a1e3 100644
--- a/drivers/hwtracing/coresight/coresight-etm4x.c
+++ b/drivers/hwtracing/coresight/coresight-etm4x.c
@@ -48,8 +48,6 @@ module_param(pm_save_enable, int, 0444);
MODULE_PARM_DESC(pm_save_enable,
"Save/restore state on power down: 1 = never, 2 = self-hosted");
-/* The number of ETMv4 currently registered */
-static int etm4_count;
static struct etmv4_drvdata *etmdrvdata[NR_CPUS];
static void etm4_set_default_config(struct etmv4_config *config);
static int etm4_set_event_filters(struct etmv4_drvdata *drvdata,
@@ -1403,12 +1401,9 @@ static int etm4_pm_setup_cpuslocked(void)
{
int ret;
- if (etm4_count++)
- return 0;
-
ret = cpu_pm_register_notifier(&etm4_cpu_pm_nb);
if (ret)
- goto reduce_count;
+ return ret;
ret =
cpuhp_setup_state_nocalls_cpuslocked(CPUHP_AP_ARM_CORESIGHT_STARTING,
"arm/coresight4:starting",
@@ -1432,17 +1427,11 @@ static int etm4_pm_setup_cpuslocked(void)
unregister_notifier:
cpu_pm_unregister_notifier(&etm4_cpu_pm_nb);
-
-reduce_count:
- --etm4_count;
return ret;
}
static void etm4_pm_clear(void)
{
- if (--etm4_count != 0)
- return;
-
cpu_pm_unregister_notifier(&etm4_cpu_pm_nb);
cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
if (hp_online) {
@@ -1498,22 +1487,12 @@ static int etm4_probe(struct amba_device *adev, const
struct amba_id *id)
if (!desc.name)
return -ENOMEM;
- cpus_read_lock();
etmdrvdata[drvdata->cpu] = drvdata;
if (smp_call_function_single(drvdata->cpu,
etm4_init_arch_data, drvdata, 1))
dev_err(dev, "ETM arch init failed\n");
- ret = etm4_pm_setup_cpuslocked();
- cpus_read_unlock();
-
- /* etm4_pm_setup_cpuslocked() does its own cleanup - exit on error */
- if (ret) {
- etmdrvdata[drvdata->cpu] = NULL;
- return ret;
- }
-
if (etm4_arch_supported(drvdata->arch) == false) {
ret = -EINVAL;
goto err_arch_supported;
@@ -1560,7 +1539,6 @@ static int etm4_probe(struct amba_device *adev, const
struct amba_id *id)
err_arch_supported:
etmdrvdata[drvdata->cpu] = NULL;
- etm4_pm_clear();
return ret;
}
@@ -1598,4 +1576,29 @@ static struct amba_driver etm4x_driver = {
.probe = etm4_probe,
.id_table = etm4_ids,
};
-builtin_amba_driver(etm4x_driver);
+
+static int __init etm4x_init(void)
+{
+ int ret;
+
+ cpus_read_lock();
+ ret = etm4_pm_setup_cpuslocked();
+ cpus_read_unlock();
+
+ /* etm4_pm_setup_cpuslocked() does its own cleanup - exit on error */
+ if (ret)
+ return ret;
+
+ ret = amba_driver_register(&etm4x_driver);
+ if (ret) {
+ pr_info("Error registering etm4x driver\n");
+ goto err_init;
+ }
+
+ return ret;
+
+err_init:
+ etm4_pm_clear();
+ return ret;
+}
+module_init(etm4x_init);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH RCC 1/6] pwm: Add different PWM output types support
Hello Martin,
On Mon, Jul 27, 2020 at 10:56:31PM +0200, Martin Botka wrote:
> Mo 27. 7. 2020 at 22:10 Uwe Kleine-König
> wrote:
> > On Fri, Jul 24, 2020 at 11:36:51PM +0200, Martin Botka wrote:
> > > +/*
> > > + * pwm_output_type_support()
> > > + * @pwm: PWM device
> > > + *
> > > + * Returns: output types supported by the PWM device
> > > + */
> > > +static inline int pwm_get_output_type_supported(struct pwm_device *pwm)
> > > +{
> > > + if (pwm->chip->ops->get_output_type_supported != NULL)
> > > + return pwm->chip->ops->get_output_type_supported(pwm->chip,
> > > pwm);
> > > + else
> > > + return PWM_OUTPUT_FIXED;
> > > +}
> >
> > I don't like this "advertising" for specific functions. I'd prefer to
> > handle this in .apply(), fix all drivers to return -ESOMETHING when the
> > request cannot be fulfilled.
>
> I will have to disagree on this one. As the functions are called in
> multiple places it would just make mess in the driver.
Note this is something where (I think) I don't agree with Thierry
either. This popped up just yesterday, see
https://www.spinics.net/lists/linux-pwm/msg13290.html
For sure I want at most one such function per driver, so if we really
want to go this path and introduce a capability indicator, this should
be named differently and have a different prototype.
> As the driver is even now not exactly the definition of clean driver i
> would not like to make it even more messy.
> > Having said that I wonder if this output pattern is a common enough
> > property to add support for it in the PWM framework.
> >
>
> I have gotten an email from Guru Das Srinagesh regarding this exact
> issue you are pointing to. Yes the output pattern will be dropped in
> V2.
That's good.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [PATCH 4/7] net/mlx5: drop unnecessary list_empty
On Mon, 2020-07-27 at 10:10 -0700, David Miller wrote: > From: Julia Lawall > Date: Sun, 26 Jul 2020 12:58:29 +0200 > > > list_for_each_entry is able to handle an empty list. > > The only effect of avoiding the loop is not initializing the > > index variable. > > Drop list_empty tests in cases where these variables are not > > used. > > > > Note that list_for_each_entry is defined in terms of > list_first_entry, > > which indicates that it should not be used on an empty list. But > in > > list_for_each_entry, the element obtained by list_first_entry is > not > > really accessed, only the address of its list_head field is > compared > > to the address of the list head, so the list_first_entry is safe. > > > > The semantic patch that makes this change is as follows (with > another > > variant for the no brace case): (http://coccinelle.lip6.fr/) > ... > > Signed-off-by: Julia Lawall > > Saeed, please pick this up. > > Thank you. Applied to net-next-mlx5. Thanks !
Re: [PATCH linux-next] clk: sparx5: Review changes
Stephen Boyd writes: > Quoting Arnd Bergmann (2020-07-27 13:11:49) >> On Mon, Jul 27, 2020 at 9:39 PM Stephen Boyd wrote: >> > >> > Why was the clk driver merged to linux-next outside of the clk tree? Was >> > there some sort of dependency? >> >> I merged the entire series of the base platform support along with >> a few core drivers. I had asked for the series to be submitted to >> s...@kernel.org after all parts had been reviewed, but I missed that >> the clk driver was still missing maintainer review (I saw you had >> reviewed some patches, but apparently that was just the binding, >> not the driver). >> >> I rebased the 'arm/newsoc' branch the other day to fix another mistake, >> so if you prefer, I can rebase it again and drop the clk driver or >> all the sparx5 patches. >> > > Yes, please just drop the clk driver and I can pick it up for the next > merge window from the list and all the fixes can be rolled into one > patch. Sorry for all the commotion! With Stephen's comments I assume I don't have to submit anything new, at least not right now. Otherwise, please let me know. Cheers, -- Lars Povlsen, Microchip
Re: linux-next: build failure after merge of the char-misc tree
On Tue, Jul 28, 2020 at 05:33:31PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> On Mon, 27 Jul 2020 11:24:48 +0200 Greg KH wrote:
> >
> > On Mon, Jul 27, 2020 at 06:08:31PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the char-misc tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > In file included from drivers/misc/habanalabs/goya/goya.c:8:
> > > drivers/misc/habanalabs/goya/goyaP.h:12:10: fatal error: habanalabs.h: No
> > > such file or directory
> > >12 | #include "habanalabs.h"
> > > | ^~
> > > In file included from drivers/misc/habanalabs/goya/goya_security.c:8:
> > > drivers/misc/habanalabs/goya/goyaP.h:12:10: fatal error: habanalabs.h: No
> > > such file or directory
> > >12 | #include "habanalabs.h"
> > > | ^~
> > >
> > > Presumably caused by commit
> > >
> > > 70b2f993ea4a ("habanalabs: create common folder")
> > >
> > > I have used the char-misc tree from next-20200724 for today.
> >
> > Ugh, this is a mess of a merge with this driver.
> >
> > Oded, I'll take Stephen's merge resolutions here and push out a new
> > version, and try to resolve this error, but if you could verify I got it
> > correct, that would be great.
>
> The conflicts are gone, but I still get these errors.
Very odd, I can not duplicate this at all here. I just did a clean
checkout of the char-misc-next branch and a full 'make allmodconfig' for
x86_64, and it worked just fine.
Are you sure it's not coming from some other tree?
thanks,
greg k-h
Re: [PATCH][next] net/mlx5: Use fallthrough pseudo-keyword
On Mon, 2020-07-27 at 13:24 -0700, David Miller wrote: > From: "Gustavo A. R. Silva" > Date: Mon, 27 Jul 2020 13:03:56 -0500 > > > Replace the existing /* fall through */ comments and its variants > with > > the new pseudo-keyword macro fallthrough[1]. Also, remove > unnecessary > > fall-through markings when it is the case. > > > > [1] > https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through > > > > Signed-off-by: Gustavo A. R. Silva > > Saeed, please pick this up. > > Thank you. Applied to net-next-mlx5. Thanks.
RE: [PATCH v7 3/8] scsi: ufs-qcom: Remove testbus dump in ufs_qcom_dump_dbg_regs
> > Dumping testbus registers is heavy enough to cause stability issues > sometime, just remove them as of now. > > Signed-off-by: Can Guo Reviewed-by: Avri Altman
Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early boot
On Tue, Jul 28, 2020 at 07:50:04AM +, Peng Fan wrote: > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and early > > boot > > > > On Mon, Jul 27, 2020 at 09:18:31AM +, Peng Fan wrote: > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M and > > > > early boot > > > > > > > > On Mon, Jul 27, 2020 at 06:44:32AM +, Peng Fan wrote: > > > > > Hi Oleksij, > > > > > > > > > > > Subject: Re: [PATCH 00/10] remoteproc: imx_rproc: support iMX8M > > > > > > and early boot > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Fri, Jul 24, 2020 at 04:08:03PM +0800, Peng Fan wrote: > > > > > > > This patchset is to support i.MX8MQ/M coproc booted before linux. > > > > > > > Since i.MX8MQ/M was not supported, several patches are needed > > > > > > > to first support the platform, then support early boot case. > > > > > > > > > > > > > > I intended to included i.MX8QM/QXP, but that would introduce a > > > > > > > large patchset, so not included. But the clk/syscon optional > > > > > > > patch for i.MX8QM/QXP was still kept here to avoid rebase error. > > > > > > > > > > > > Thank you for your work. > > > > > > > > > > > > Can you please provide more information about big picture of this > > work. > > > > > > > > > > > > If I see it correctly, we have here support for i.MX8MM, which > > > > > > seems to be able to fully control Cortex M4 (enable CPU core, > > > > > > etc...). > > > > > > > > > > Yes. > > > > > > > > In this case, I would recommend to mainline the i.MX8MM part > > > > first/separately. > > > > > > Only the last patch is to support earlyboot, all others is imx8mm part. > > > > ok > > > > > > > > > > > > > > > > > > And other case, where remoteproc is running on application > > > > > > processor and can't or should not touch M4 (i.MX7ULP, > > > > > > i.MX8QM/QXP..). Since M4 provides some functionality, you are > > > > > > trying to reuse remoteproc framework to get resource table > > > > > > present in ELF header and to dynamically load things. For some > > > > > > reasons this header provides more information then needed, so > > > > > > you are changing the ELF parser in the kernel > > > > to workaround it. > > > > > > > > > > Not exactly. > > > > > > > > > > For i.MX8MM, we support two cases. M4 kicked by U-Boot, M4 kicked > > > > > by > > > > Linux remoteproc. > > > > > For i.MX8QM/QXP, the typical usecase is M4 kicked by SCFW, but we > > > > > will also add M4 kicked by Linux remoteproc. > > > > > For i.MX7ULP, I would only support M4 dual boot case, M4 control > > > > everything. > > > > > > > > From current state of discussion, i'm not sure what role plays > > > > remoteproc in the scenario where M4 is started before linux. > > > > Especially if we are not using resource table. > > > > > > We are using resource table from an address, not in elf file. > > > This is the new feature in Linux-next to support coproc booted early. > > > > > > > > > > > > The reason the change the elf parser is that when M4 elf is loaded > > > > > by Linux remoteproc, It use memset to clear area. > > > > > > > > The use of memset, depends on ELF format. Fix/change the linker > > > > script on your firmware and memset will be never called. > > > > > > > > > However we use ioremap, memset on ARM64 will report crash to > > > > > device nGnRE memory. And we could not use ioremap_wc to TCM area, > > > > > since it could have data correctly written into TCM. > > > > > > > > I have strong feeling, that we are talking about badly or not > > > > properly formatted ELF binary. I would prefer to double check it, > > > > before we will apply fixes on wrong place. > > > > > > > > > Maintainer not wanna to drop memset in common code, and TI guys > > > > > suggest add i.MX specific elf stuff. So I add elf handler in i.MX > > > > > code. > > > > > > > > I think, removing memset may damage current users of imx_rproc driver. > > > > Since, like I said: the use of memset depends on ELF format. > > > > > > In my elf file, the last PT_LOAD contains data/bss/heap/stack. I'll > > > check with our MCU guys, we only need the specific data loaded. > > > > > > Elf file type is EXEC (Executable file) Entry point 0x1ffe0355 There > > > are 3 program headers, starting at offset 52 > > > > > > Program Headers: > > > Type Offset VirtAddr PhysAddr FileSiz MemSiz > > Flg Align > > > LOAD 0x01 0x1ffe 0x1ffe 0x00240 0x00240 > > R 0x1 > > > LOAD 0x010240 0x1ffe0240 0x1ffe0240 0x03e90 0x03e90 > > RWE 0x1 > > > LOAD 0x02 0x2000 0x1ffe40d0 0x00068 0x0ad00 > > RW 0x1 > > > > > > Section to Segment mapping: > > > Segment Sections... > > >00 .interrupts > > >01 .resource_table .text .ARM .init_array .fini_array > > >02 .data .bss .heap .stack > > > > Here is an example of formatting ELF for remoteproc: > > https://git.pengutronix.de/cgit/ore/OSELAS.BSP-Pengutronix-DualKit/tree/loc > > al_src/remotep
Re: [PATCH v2] drm/hisilicon: Fixed the warning: Assignment of 0/1 to bool variable
Hi
Am 07.07.20 um 04:58 schrieb Tian Tao:
> fixed the following warning:
> hibmc_drm_drv.c:296:1-18:WARNING: Assignment of 0/1 to bool variable.
> hibmc_drm_drv.c:301:2-19: WARNING: Assignment of 0/1 to bool variable.
>
> v2:
> using the pci_dev.msi_enabled instead of priv->msi_enabled.
>
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +++---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 -
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index 249c298..83c7bb5 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -254,7 +254,7 @@ static int hibmc_unload(struct drm_device *dev)
>
> if (dev->irq_enabled)
> drm_irq_uninstall(dev);
> - if (priv->msi_enabled)
> + if (dev->pdev->msi_enabled)
You don't need these tests and you don't have to set
dev->pdev->msi_enabled by yourself. Just call pci_enable_msi() and
pci_disable_msi() and they should do the right thing.
Best regards
Thomas
> pci_disable_msi(dev->pdev);
>
> hibmc_kms_fini(priv);
> @@ -294,12 +294,12 @@ static int hibmc_load(struct drm_device *dev)
> goto err;
> }
>
> - priv->msi_enabled = 0;
> + dev->pdev->msi_enabled = 0;
> ret = pci_enable_msi(dev->pdev);
> if (ret) {
> DRM_WARN("enabling MSI failed: %d\n", ret);
> } else {
> - priv->msi_enabled = 1;
> + dev->pdev->msi_enabled = 1;
> ret = drm_irq_install(dev, dev->pdev->irq);
> if (ret)
> DRM_WARN("install irq failed: %d\n", ret);
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index 6097687..a683763 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -25,7 +25,6 @@ struct hibmc_drm_private {
> void __iomem *fb_map;
> unsigned long fb_base;
> unsigned long fb_size;
> - bool msi_enabled;
>
> /* drm */
> struct drm_device *dev;
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v6 02/13] dt-bindings: mfd: Add bindings for sl28cpld
Am 2020-07-28 09:24, schrieb Lee Jones: On Sun, 26 Jul 2020, Michael Walle wrote: Add a device tree bindings for the board management controller found on the Kontron SMARC-sAL28 board. Signed-off-by: Michael Walle Reviewed-by: Rob Herring --- Changes since v5: - none Changes since v4: - fix the regex of the unit-address Changes since v3: - see cover letter .../bindings/gpio/kontron,sl28cpld-gpio.yaml | 54 +++ .../hwmon/kontron,sl28cpld-hwmon.yaml | 27 .../kontron,sl28cpld-intc.yaml| 54 +++ .../bindings/mfd/kontron,sl28cpld.yaml| 153 ++ .../bindings/pwm/kontron,sl28cpld-pwm.yaml| 35 .../watchdog/kontron,sl28cpld-wdt.yaml| 35 6 files changed, 358 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml create mode 100644 Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml create mode 100644 Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml create mode 100644 Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml create mode 100644 Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml create mode 100644 Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml diff --git a/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml new file mode 100644 index ..9a63a158a796 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/kontron,sl28cpld-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO driver for the sl28cpld board management controller + +maintainers: + - Michael Walle + +description: | + This module is part of the sl28cpld multi-function device. For more + details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml. Paths are normally relative. grep Documentation/ Documentation I know there are a lot false positives (esp in the first one).. $ grep -r "\.\./" Documentation | wc -l 1826 $ grep -r "Documentation/" Documentation|wc -l 2862 + There are three flavors of the GPIO controller, one full featured + input/output with interrupt support (kontron,sl28cpld-gpio), one + output-only (kontron,sl28-gpo) and one input-only (kontron,sl28-gpi). + + Each controller supports 8 GPIO lines. + +properties: + compatible: +enum: + - kontron,sl28cpld-gpio + - kontron,sl28cpld-gpi + - kontron,sl28cpld-gpo + + reg: +maxItems: 1 + + interrupts: +maxItems: 1 + + "#interrupt-cells": +const: 2 + + interrupt-controller: true + + "#gpio-cells": +const: 2 + + gpio-controller: true + + gpio-line-names: + minItems: 1 + maxItems: 8 + +required: + - compatible + - "#gpio-cells" + - gpio-controller + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml new file mode 100644 index ..1cebd61c6c32 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/kontron,sl28cpld-hwmon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hardware monitoring driver for the sl28cpld board management controller + +maintainers: + - Michael Walle + +description: | + This module is part of the sl28cpld multi-function device. For more + details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml. + +properties: + compatible: +enum: + - kontron,sl28cpld-fan + + reg: +maxItems: 1 + +required: + - compatible + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml new file mode 100644 index ..4c39e9ff9aea --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/kontron,sl28cpld-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Interrupt controller driver for the sl28cpld board management controller + +maintainers: + - Michael Walle + +description: | + This module is part of the sl28cpld multi-function device. For more + details see Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml. + + The following interrupts are available. All types and levels are fixed + and handled by the board
Re: [PATCH V4 2/3] mfd: Intel Platform Monitoring Technology support
On Fri, 17 Jul 2020, David E. Box wrote:
> Intel Platform Monitoring Technology (PMT) is an architecture for
> enumerating and accessing hardware monitoring facilities. PMT supports
> multiple types of monitoring capabilities. This driver creates platform
> devices for each type so that they may be managed by capability specific
> drivers (to be introduced). Capabilities are discovered using PCIe DVSEC
> ids. Support is included for the 3 current capability types, Telemetry,
> Watcher, and Crashlog. The features are available on new Intel platforms
> starting from Tiger Lake for which support is added.
>
> Also add a quirk mechanism for several early hardware differences and bugs.
> For Tiger Lake, do not support Watcher and Crashlog capabilities since they
> will not be compatible with future product. Also, fix use a quirk to fix
> the discovery table offset.
>
> Reviewed-by: Andy Shevchenko
> Co-developed-by: Alexander Duyck
> Signed-off-by: Alexander Duyck
> Signed-off-by: David E. Box
This should be in chronological order.
> ---
> MAINTAINERS | 5 +
> drivers/mfd/Kconfig | 10 ++
> drivers/mfd/Makefile| 1 +
> drivers/mfd/intel_pmt.c | 215
> 4 files changed, 231 insertions(+)
> create mode 100644 drivers/mfd/intel_pmt.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b4a43a9e7fbc..2e42bf0c41ab 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8845,6 +8845,11 @@ F: drivers/mfd/intel_soc_pmic*
> F: include/linux/mfd/intel_msic.h
> F: include/linux/mfd/intel_soc_pmic*
>
> +INTEL PMT DRIVER
> +M: "David E. Box"
> +S: Maintained
> +F: drivers/mfd/intel_pmt.c
> +
> INTEL PRO/WIRELESS 2100, 2200BG, 2915ABG NETWORK CONNECTION SUPPORT
> M: Stanislav Yakovlev
> L: linux-wirel...@vger.kernel.org
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index a37d7d171382..1a62ce2c68d9 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -670,6 +670,16 @@ config MFD_INTEL_PMC_BXT
> Register and P-unit access. In addition this creates devices
> for iTCO watchdog and telemetry that are part of the PMC.
>
> +config MFD_INTEL_PMT
> + tristate "Intel Platform Monitoring Technology support"
Nit: "Intel Platform Monitoring Technology (PMT) support"
> + depends on PCI
> + select MFD_CORE
> + help
> + The Intel Platform Monitoring Technology (PMT) is an interface that
> + provides access to hardware monitor registers. This driver supports
> + Telemetry, Watcher, and Crashlog PMT capabilities/devices for
> + platforms starting from Tiger Lake.
> +
> config MFD_IPAQ_MICRO
> bool "Atmel Micro ASIC (iPAQ h3100/h3600/h3700) Support"
> depends on SA1100_H3100 || SA1100_H3600
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 9367a92f795a..1961b4737985 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -216,6 +216,7 @@ obj-$(CONFIG_MFD_INTEL_LPSS_PCI) += intel-lpss-pci.o
> obj-$(CONFIG_MFD_INTEL_LPSS_ACPI)+= intel-lpss-acpi.o
> obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
> obj-$(CONFIG_MFD_INTEL_PMC_BXT) += intel_pmc_bxt.o
> +obj-$(CONFIG_MFD_INTEL_PMT) += intel_pmt.o
> obj-$(CONFIG_MFD_PALMAS) += palmas.o
> obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
> obj-$(CONFIG_MFD_RC5T583)+= rc5t583.o rc5t583-irq.o
> diff --git a/drivers/mfd/intel_pmt.c b/drivers/mfd/intel_pmt.c
> new file mode 100644
> index ..6857eaf4ff86
> --- /dev/null
> +++ b/drivers/mfd/intel_pmt.c
> @@ -0,0 +1,215 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Intel Platform Monitoring Technology MFD driver
s/MFD/(PMT)/
> + * Copyright (c) 2020, Intel Corporation.
> + * All Rights Reserved.
> + *
> + * Authors: David E. Box
Looks odd to use a plural for a single author.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Alphabetical please.
> +/* Intel DVSEC capability vendor space offsets */
> +#define INTEL_DVSEC_ENTRIES 0xA
> +#define INTEL_DVSEC_SIZE 0xB
> +#define INTEL_DVSEC_TABLE0xC
> +#define INTEL_DVSEC_TABLE_BAR(x) ((x) & GENMASK(2, 0))
> +#define INTEL_DVSEC_TABLE_OFFSET(x) ((x) & GENMASK(31, 3))
> +#define INTEL_DVSEC_ENTRY_SIZE 4
> +
> +/* PMT capabilities */
> +#define DVSEC_INTEL_ID_TELEMETRY 2
> +#define DVSEC_INTEL_ID_WATCHER 3
> +#define DVSEC_INTEL_ID_CRASHLOG 4
> +
> +#define TELEMETRY_DEV_NAME "pmt_telemetry"
> +#define WATCHER_DEV_NAME "pmt_watcher"
> +#define CRASHLOG_DEV_NAME"pmt_crashlog"
Please don't define names of things. It makes grepping a pain, at the
very least. Just use the 'raw' string in-place.
> +struct intel_dvsec_header {
> + u16 length;
> + u16 id;
> + u8 num_entries;
> + u8 entry_size;
> + u8 tbir;
> +
Re: [PATCH V2 1/4] gpio: mxc: Support module build
On Mon, Jul 27, 2020 at 12:44 PM Arnd Bergmann wrote: > On Mon, Jul 27, 2020 at 10:18 AM Anson Huang wrote: > > > Why is this driver using syscore_ops rather than > > > SIMPLE_DEV_PM_OPS() or similar? > > > > Below is the original patch of using syscore_ops, it has explanation: > > > > commit 1a5287a3dbc34cd0c02c8f64c9131bd23cdfe2bb > > Author: Anson Huang > > Date: Fri Nov 9 04:56:56 2018 + > > > > gpio: mxc: move gpio noirq suspend/resume to syscore phase > > > > During noirq suspend/resume phase, GPIO irq could arrive > > and its registers like IMR will be changed by irq handle > > process, to make the GPIO registers exactly when it is > > powered ON after resume, move the GPIO noirq suspend/resume > > callback to syscore suspend/resume phase, local irq is > > disabled at this phase so GPIO registers are atomic. This looks like it would have been easier to use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS as pointed out later... > The description makes sense, but this must be a problem that > other gpio/pinctrl irqchip drivers have as well. > > Linus, could you have a look? I see these other pinctrl drivers > using SIMPLE_DEV_PM_OPS: > > drivers/pinctrl/nomadik/pinctrl-nomadik.c:static > SIMPLE_DEV_PM_OPS(nmk_pinctrl_pm_ops, This one does not involve IRQs rather calls pinctrl_force_sleep/default which sets up hogged pins for energy saving while sleeping. > drivers/pinctrl/pinctrl-rockchip.c:static > SIMPLE_DEV_PM_OPS(rockchip_pinctrl_dev_pm_ops, > rockchip_pinctrl_suspend, Pretty much the same as Nomadik, with some extra register (also not IRQ-related). > drivers/pinctrl/pinctrl-stmfx.c:static > SIMPLE_DEV_PM_OPS(stmfx_pinctrl_dev_pm_ops, This one is problematic. However this is on an I2C expander meaning the slow bus traffic needs to be working and if IRQs are off at syscore suspend/resume time, I2C will not work. I think Amelie has tested this thing pretty thoroughly, and that expanders are less sensitive to this. > drivers/pinctrl/qcom/pinctrl-msm.c:SIMPLE_DEV_PM_OPS(msm_pinctrl_dev_pm_ops, > msm_pinctrl_suspend, This one is like the Nomadik: just forcing some hogs to go into low power mode. > drivers/pinctrl/spear/pinctrl-plgpio.c:static > SIMPLE_DEV_PM_OPS(plgpio_dev_pm_ops, plgpio_suspend, plgpio_resume); This one is affected by the same problem, I don't know if anyone really has this hardware anymore, but there are some SPEAr products deployed so the users should be notified that they may need to move this to syscore ops. Viresh? > It seems that some drivers use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() > instead, which looks like it is meant to address the same problem, but > as I have not used that myself, I may be misunderstanding the problem > or what this one does. IIUC that callback is for exactly this, and occurs after IRQs are disabled and before IRQs are re-enabled. Again the same problem if you need slow bus traffic in your callback (I2C/SPI devices): it is not going to work. Yours, Linus Walleij
Re: [RESEND PATCH v2] mfd: syscon: Use a unique name with regmap_config
On Mon, 27 Jul 2020, Suman Anna wrote: > The DT node full name is currently being used in regmap_config > which in turn is used to create the regmap debugfs directories. > This name however is not guaranteed to be unique and the regmap > debugfs registration can fail in the cases where the syscon nodes > have the same unit-address but are present in different DT node > hierarchies. Replace this logic using the syscon reg resource > address instead (inspired from logic used while creating platform > devices) to ensure a unique name is given for each syscon. > > Signed-off-by: Suman Anna > --- > Hi Arnd, > Lee is looking for your review on this patch. Can you please > review and provide your comments. > > This is a resend of the patch that was posted previously, rebased > now onto latest kernel. > > v2: https://patchwork.kernel.org/patch/11353355/ > - Fix build warning reported by kbuild test bot > v1: https://patchwork.kernel.org/patch/11346363/ > > drivers/mfd/syscon.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 2/2] media: bt8xx: avoid a useless memset
Le 27/07/2020 à 18:09, Joe Perches a écrit :
On Mon, 2020-07-27 at 15:51 +0200, Christophe JAILLET wrote:
Avoid a memset after a call to 'dma_alloc_coherent()'.
This is useless since
commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*")
[]
diff --git a/drivers/media/pci/bt8xx/btcx-risc.c
b/drivers/media/pci/bt8xx/btcx-risc.c
[]
@@ -73,7 +73,6 @@ int btcx_riscmem_alloc(struct pci_dev *pci,
dprintk("btcx: riscmem alloc [%d] dma=%lx cpu=%p size=%d\n",
memcnt, (unsigned long)dma, cpu, size);
}
- memset(risc->cpu,0,risc->size);
return 0;
}
Likely NAK.
This is not useless as risc->cpu may be reused
and the alloc may not have been done.
Agreed.
This 2/2 patch should be NAK'ed.
I've been a bit too fast on this one.
Thanks for the review Joe.
CJ
Re: [PATCH 2/2] media: bt8xx: avoid a useless memset
Le 27/07/2020 à 18:16, Joe Perches a écrit :
On Mon, 2020-07-27 at 09:09 -0700, Joe Perches wrote:
On Mon, 2020-07-27 at 15:51 +0200, Christophe JAILLET wrote:
Avoid a memset after a call to 'dma_alloc_coherent()'.
This is useless since
commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*")
[]
diff --git a/drivers/media/pci/bt8xx/btcx-risc.c
b/drivers/media/pci/bt8xx/btcx-risc.c
[]
@@ -73,7 +73,6 @@ int btcx_riscmem_alloc(struct pci_dev *pci,
dprintk("btcx: riscmem alloc [%d] dma=%lx cpu=%p size=%d\n",
memcnt, (unsigned long)dma, cpu, size);
}
- memset(risc->cpu,0,risc->size);
return 0;
}
Likely NAK.
This is not useless as risc->cpu may be reused
and the alloc may not have been done.
Perhaps a little rewrite for clarity:
---
drivers/media/pci/bt8xx/btcx-risc.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/pci/bt8xx/btcx-risc.c
b/drivers/media/pci/bt8xx/btcx-risc.c
index 51257980f539..311f4ca2a108 100644
--- a/drivers/media/pci/bt8xx/btcx-risc.c
+++ b/drivers/media/pci/bt8xx/btcx-risc.c
@@ -56,24 +56,26 @@ int btcx_riscmem_alloc(struct pci_dev *pci,
struct btcx_riscmem *risc,
unsigned int size)
{
- __le32 *cpu;
- dma_addr_t dma = 0;
-
- if (NULL != risc->cpu && risc->size < size)
- btcx_riscmem_free(pci,risc);
- if (NULL == risc->cpu) {
- cpu = pci_alloc_consistent(pci, size, &dma);
- if (NULL == cpu)
+ if (risc->cpu && risc->size < size)
+ btcx_riscmem_free(pci, risc);
+
+ if (risc->cpu) {
+ memset(risc->cpu, 0, risc->size);
+ } else {
+ dma_addr_t dma = 0;
+
+ risc->cpu = pci_alloc_consistent(pci, size, &dma);
+ if (!risc->cpu)
return -ENOMEM;
- risc->cpu = cpu;
+
risc->dma = dma;
risc->size = size;
memcnt++;
dprintk("btcx: riscmem alloc [%d] dma=%lx cpu=%p size=%d\n",
- memcnt, (unsigned long)dma, cpu, size);
+ memcnt, (unsigned long)dma, risc->cpu, size);
}
- memset(risc->cpu,0,risc->size);
+
return 0;
}
Looks good to me.
Just note, that this will not apply after patch 1/2 is applied, because
it turns pci_alloc_consistent() into dma_alloc_coherent().
CJ
RE: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t
From: Christoph Hellwig > Sent: 27 July 2020 17:24 > > On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote: > > Maybe sockptr_advance should have some safety checks and sometimes > > return -EFAULT? Or you should always use the implementation where > > being a kernel address is an explicit bit of sockptr_t, rather than > > being implicit? > > I already have a patch to use access_ok to check the whole range in > init_user_sockptr. That doesn't make (much) difference to the code paths that ignore the user-supplied length. OTOH doing the user/kernel check on the base address (not an incremented one) means that the correct copy function is always selected. Perhaps the functions should all be passed a 'const sockptr_t'. The typedef could be made 'const' - requiring non-const items explicitly use the union/struct itself. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: [PATCH 03/15] arm, xtensa: simplify initialization of high memory pages
On Mon, Jul 27, 2020 at 10:12 PM Mike Rapoport wrote: > > From: Mike Rapoport > > The function free_highpages() in both arm and xtensa essentially open-code > for_each_free_mem_range() loop to detect high memory pages that were not > reserved and that should be initialized and passed to the buddy allocator. > > Replace open-coded implementation of for_each_free_mem_range() with usage > of memblock API to simplify the code. > > Signed-off-by: Mike Rapoport > --- > arch/arm/mm/init.c| 48 +++-- > arch/xtensa/mm/init.c | 55 --- > 2 files changed, 18 insertions(+), 85 deletions(-) For the xtensa part: Reviewed-by: Max Filippov Tested-by: Max Filippov -- Thanks. -- Max
Re: [PATCH V2 1/4] gpio: mxc: Support module build
On Mon, Jul 27, 2020 at 1:57 PM Arnd Bergmann wrote: > Overall, my feeling is that making sure all drivers that depend on the pinctrl > driver can deal with deferred probing is a prerequisite before this can be > made a loadable module itself (same for clk, irqchip, etc drivers that others > may rely on). > > I understand that your primary motivation is to fit into Google's GKI > framework, > but I think that doing the conversion only partially would neither serve to > improve the kernel nor actually meet the GKI requirements. This has been my worry as well when it comes to these GKI-initiated patches that are flying right now. > Most pinctrl drivers are currently always built-in to work around the > load order dependencies. This of course is a bit of a hack and we'd be > better off if all drivers managed to avoid the dependencies, but this > can also require a lot of work. Several people have argued that it is reasonable to cut corners to achieve the "greater good" of GKI. I try to handle it on a "does the kernel look better after than before" basis, while pushing gently for at least trying to properly modularize the whole thing. It can become pretty hard to test I think. If it is things like GPIO expanders on I2C that can be used by several SoCs I would be more hard on this, on a single SoC not as much. One discussion thread got inflamed because of ARM vs x86 discussions "x86 is better modularized" which is something I want to avoid, it is easy to be modularized when your irqs, clocks, regulators and pins are handled by the BIOS. This is a SoC problem and x86 SoCs with no BIOS, RISCV, ARM and whatever doesn't have a fix-it-all-BIOS have this problem. :/ Yours, Linus Walleij
Re: [PATCH v4 4/6] dt-bindings: snps,dw-apb-ssi: Add sparx5 support, plus rx-sample-delay-ns property
Rob Herring writes:
> On Fri, Jul 24, 2020 at 01:14:02PM +0200, Lars Povlsen wrote:
>> This has the following changes for the snps,dw-apb-ss DT bindings:
>>
>> - Add "microchip,sparx5-spi" as the compatible for the Sparx5 SoC
>> controller
>>
>> - Add the property "rx-sample-delay-ns"
>>
>> Signed-off-by: Lars Povlsen
>> ---
>> .../bindings/spi/snps,dw-apb-ssi.yaml | 21 +++
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> index c62cbe79f00dd..c0adaad1aa695 100644
>> --- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> +++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
>> @@ -36,6 +36,8 @@ properties:
>>- mscc,ocelot-spi
>>- mscc,jaguar2-spi
>>- const: snps,dw-apb-ssi
>> + - description: Microchip Sparx5 SoC SPI Controller
>> +const: microchip,sparx5-spi
>>- description: Amazon Alpine SPI Controller
>> const: amazon,alpine-dw-apb-ssi
>>- description: Renesas RZ/N1 SPI Controller
>> @@ -93,6 +95,12 @@ properties:
>>- const: tx
>>- const: rx
>>
>> + rx-sample-delay-ns:
>> +description: Default value of the rx-sample-delay-ns property.
>> + This value will be used if the property is not explicitly defined
>> + for a SPI slave device. Default value is 0. See below.
>> +$ref: /schemas/types.yaml#/definitions/uint32
>
> Don't need a type for properties with unit suffixes.
>
> Also, add:
>
> 'default: 0'
>
Hi Rob!
Thank you for your input, all duly noted.
---Lars
>> +
>> patternProperties:
>>"^.*@[0-9a-f]+$":
>> type: object
>> @@ -107,6 +115,13 @@ patternProperties:
>>spi-tx-bus-width:
>> const: 1
>>
>> + rx-sample-delay-ns:
>> +description: SPI Rx sample delay offset, unit is nanoseconds.
>> + The delay from the default sample time before the actual
>> + sample of the rxd input signal occurs. The "rx_sample_delay"
>> + is an optional feature of the designware controller, and the
>> + upper limit is also subject to controller configuration.
>> +
>> unevaluatedProperties: false
>>
>> required:
>> @@ -129,5 +144,11 @@ examples:
>>num-cs = <2>;
>>cs-gpios = <&gpio0 13 0>,
>> <&gpio0 14 0>;
>> + rx-sample-delay-ns = <3>;
>> + spi-flash@1 {
>> +compatible = "spi-nand";
>> +reg = <1>;
>> +rx-sample-delay-ns = <7>;
>> + };
>> };
>> ...
>> --
>> 2.27.0
>>
--
Lars Povlsen,
Microchip
linux-next: build failure after merge of the vhost tree
Hi all,
After merging the vhost tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/virtio/virtio_vdpa.c:17:
include/linux/vdpa.h:43:21: error: expected ':', ',', ';', '}' or
'__attribute__' before '.' token
43 | bool features_valid.
| ^
Caused by commit
fee8fe6bd8cc ("vdpa: make sure set_features in invoked for legacy")
I have used the vhost tree from next-20200727 for today.
--
Cheers,
Stephen Rothwell
pgpi_SWfqzRkv.pgp
Description: OpenPGP digital signature
Re: [Linux-kernel-mentees] [PATCH] drm/bufs: Prevent kernel-infoleak in copy_one_buf()
On Tue, Jul 28, 2020 at 3:45 AM Peilin Ye wrote:
>
> copy_one_buf() is copying uninitialized stack memory to userspace due to
> the compiler not initializing holes in statically allocated structures.
> Fix it by initializing `v` with memset().
I would add 'potentially' somewhere in that description: it is architecture
dependent whether there are holes in this structure as 'enum' types
and 'long' are both dependent on the ABI, and even if there is a hole,
it is undefined behavior whether the hold gets initialized.
Other than that, the patch looks good.
> Cc: sta...@vger.kernel.org
> Fixes: 5c7640ab6258 ("switch compat_drm_infobufs() to drm_ioctl_kernel()")
> Suggested-by: Dan Carpenter
> Signed-off-by: Peilin Ye
Acked-by: Arnd Bergmann
> ---
> drivers/gpu/drm/drm_bufs.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index a0735fbc144b..f99cd4a3f951 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -1349,10 +1349,14 @@ static int copy_one_buf(void *data, int count, struct
> drm_buf_entry *from)
> {
> struct drm_buf_info *request = data;
> struct drm_buf_desc __user *to = &request->list[count];
> - struct drm_buf_desc v = {.count = from->buf_count,
> -.size = from->buf_size,
> -.low_mark = from->low_mark,
> -.high_mark = from->high_mark};
> + struct drm_buf_desc v;
> +
> + memset(&v, 0, sizeof(v));
> +
> + v.count = from->buf_count;
> + v.size = from->buf_size;
> + v.low_mark = from->low_mark;
> + v.high_mark = from->high_mark;
>
> if (copy_to_user(to, &v, offsetof(struct drm_buf_desc, flags)))
> return -EFAULT;
> --
> 2.25.1
>
Re: [PATCH v6 01/13] mfd: add simple regmap based I2C driver
On Tue, 28 Jul 2020, Michael Walle wrote: > Am 2020-07-28 09:19, schrieb Lee Jones: > > On Sun, 26 Jul 2020, Michael Walle wrote: > > > > > There are I2C devices which contain several different functions but > > > doesn't require any special access functions. For these kind of > > > drivers > > > an I2C regmap should be enough. > > > > > > Create an I2C driver which creates an I2C regmap and enumerates its > > > children. If a device wants to use this as its MFD core driver, it has > > > to add an individual compatible string. It may provide its own regmap > > > configuration. > > > > > > Subdevices can use dev_get_regmap() on the parent to get their regmap > > > instance. > > > > > > Signed-off-by: Michael Walle > > > --- > > > Changes since v5: > > > - removed "select MFD_CORE" in Kconfig > > > - removed help text in Kconfig, we assume that the users of this > > > > That's the opposite of what I asked for. > > What is the use to describe the symbol, if it is not user selectable? > I'm not aware this is done anywhere in the kernel, am I missing > something? You mean in menuconfig? I find 'help's helpful even outside of menuconfig. Surely I'm not the only one who reads them 'raw'? > > >driver will have a "select MFD_SIMPLE_MFD_I2C". Instead added > > >a small description to the driver itself. > > > - removed "struct simple_mfd_i2c_config" and use regmap_config > > >directly > > > - changed builtin_i2c_driver() to module_i2c_driver(), added > > >MODULE_ boilerplate > > > - cleaned up the included files > > > > > > Changes since v4: > > > - new patch. Lee, please bear with me. I didn't want to delay the > > >new version (where a lot of remarks on the other patches were > > >addressed) even more, just because we haven't figured out how > > >to deal with the MFD part. So for now, I've included this one. > > > > > > drivers/mfd/Kconfig | 5 > > > drivers/mfd/Makefile | 1 + > > > drivers/mfd/simple-mfd-i2c.c | 55 > > > > > > 3 files changed, 61 insertions(+) > > > create mode 100644 drivers/mfd/simple-mfd-i2c.c > > > > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > > > index 33df0837ab41..c08539c7a166 100644 > > > --- a/drivers/mfd/Kconfig > > > +++ b/drivers/mfd/Kconfig > > > @@ -1162,6 +1162,11 @@ config MFD_SI476X_CORE > > > To compile this driver as a module, choose M here: the > > > module will be called si476x-core. > > > > > > +config MFD_SIMPLE_MFD_I2C > > > + tristate > > > + depends on I2C > > > + select REGMAP_I2C > > > > Please provide a full help. > > See above. > > > > > > config MFD_SM501 > > > tristate "Silicon Motion SM501" > > > depends on HAS_DMA > > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > > index a60e5f835283..78d24a3e7c9e 100644 > > > --- a/drivers/mfd/Makefile > > > +++ b/drivers/mfd/Makefile > > > @@ -264,3 +264,4 @@ obj-$(CONFIG_MFD_STMFX) += stmfx.o > > > obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o > > > > > > obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o > > > +obj-$(CONFIG_MFD_SIMPLE_MFD_I2C) += simple-mfd-i2c.o > > > diff --git a/drivers/mfd/simple-mfd-i2c.c > > > b/drivers/mfd/simple-mfd-i2c.c > > > new file mode 100644 > > > index ..45090ddad104 > > > --- /dev/null > > > +++ b/drivers/mfd/simple-mfd-i2c.c > > > @@ -0,0 +1,55 @@ > > > +// SPDX-License-Identifier: GPL-2.0-only > > > +/* > > > + * A very simple I2C MFD driver > > > > Simple MFD - I2C > > ok. > > > > + * The driver enumerates its children and registers a common > > > regmap. Use > > > + * dev_get_regmap(pdev->dev.parent, NULL) in the child nodes to > > > fetch that > > > + * regmap instance. > > > > This driver creates a single register map with the intention for it to > > be shared by all sub-devices. Children can use their parent's device > > structure (dev.parent) in order reference it. > > Should this be appended or should it replace my paragraph? If its the > latter, > the "enumeration of the children" is missing. If you want to keep that part, try: This driver creates a single register map with the intention for it to be shared by all sub-devices. Children can use their parent's device structure (dev.parent) in order reference it. Once the register map has been successfully initialised, any sub-devices represented by child nodes in Device Tree will be subsequently registered. > > > + * In the future this driver might be extended to support also > > > other interfaces > > > + * like SPI etc. > > > > Remove this please. > > Why would you remove information about the intention of this driver? If > someone > looks for a place to implement its SPI/I3C/Slimbus MFD driver this might > come > in handy. By all means put something similar in the commit log, but it has no place in the driver itself. Besides, if we were to add support for SPI, it is likely to be a completely separate/unrelated driver. -- Lee Jones [李琼斯]
Re: [PATCH] KVM: x86: Deflect unknown MSR accesses to user space
Alexander Graf writes:
> MSRs are weird. Some of them are normal control registers, such as EFER.
> Some however are registers that really are model specific, not very
> interesting to virtualization workloads, and not performance critical.
> Others again are really just windows into package configuration.
>
> Out of these MSRs, only the first category is necessary to implement in
> kernel space. Rarely accessed MSRs, MSRs that should be fine tunes against
> certain CPU models and MSRs that contain information on the package level
> are much better suited for user space to process. However, over time we have
> accumulated a lot of MSRs that are not the first category, but still handled
> by in-kernel KVM code.
>
> This patch adds a generic interface to handle WRMSR and RDMSR from user
> space. With this, any future MSR that is part of the latter categories can
> be handled in user space.
>
> Furthermore, it allows us to replace the existing "ignore_msrs" logic with
> something that applies per-VM rather than on the full system. That way you
> can run productive VMs in parallel to experimental ones where you don't care
> about proper MSR handling.
>
In theory, we can go further: userspace will give KVM the list of MSRs
it is interested in. This list may even contain MSRs which are normally
handled by KVM, in this case userspace gets an option to mangle KVM's
reply (RDMSR) or do something extra (WRMSR). I'm not sure if there is a
real need behind this, just an idea.
The problem with this approach is: if currently some MSR is not
implemented in KVM you will get an exit. When later someone comes with a
patch to implement this MSR your userspace handling will immediately get
broken so the list of not implemented MSRs effectively becomes an API :-)
> Signed-off-by: Alexander Graf
>
> ---
>
> As a quick example to show what this does, I implemented handling for MSR 0x35
> (MSR_CORE_THREAD_COUNT) in QEMU on top of this patch set:
>
> https://github.com/agraf/qemu/commits/user-space-msr
> ---
> Documentation/virt/kvm/api.rst | 60 ++
> arch/x86/include/asm/kvm_host.h | 6 +++
> arch/x86/kvm/emulate.c | 18 +++--
> arch/x86/kvm/x86.c | 65 -
> include/trace/events/kvm.h | 2 +-
> include/uapi/linux/kvm.h| 11 ++
> 6 files changed, 155 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 320788f81a05..7dfcc8e09dad 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -5155,6 +5155,34 @@ Note that KVM does not skip the faulting instruction
> as it does for
> KVM_EXIT_MMIO, but userspace has to emulate any change to the processing
> state
> if it decides to decode and emulate the instruction.
>
> +::
> +
> + /* KVM_EXIT_RDMSR / KVM_EXIT_WRMSR */
> + struct {
> + __u8 reply;
> + __u8 error;
> + __u8 pad[2];
> + __u32 index;
> + __u64 data;
> + } msr;
(Personal taste most likely)
This layout is perfect but it makes my brain explode :-) Naturally, I
expect index and data to be the most significant members and I expect
them to be the first two members, something like
struct {
__u32 index;
__u32 pad32;
__u64 data;
__u8 reply;
__u8 error;
__u8 pad8[6];
} msr;
> +
> +Used on x86 systems. When the VM capability KVM_CAP_X86_USER_SPACE_MSR is
> +enabled, MSR accesses to registers that are not known by KVM kernel code will
> +trigger a KVM_EXIT_RDMSR exit for reads and KVM_EXIT_WRMSR exit for writes.
> +
> +For KVM_EXIT_RDMSR, the "index" field tells user space which MSR the guest
> +wants to read. To respond to this request with a successful read, user space
> +writes a 1 into the "reply" field and the respective data into the "data"
> field.
> +
> +If the RDMSR request was unsuccessful, user space indicates that with a "1"
> +in the "reply" field and a "1" in the "error" field. This will inject a #GP
> +into the guest when the VCPU is executed again.
> +
> +For KVM_EXIT_WRMSR, the "index" field tells user space which MSR the guest
> +wants to write. Once finished processing the event, user space sets the
> "reply"
> +field to "1". If the MSR write was unsuccessful, user space also sets the
> +"error" field to "1".
> +
> ::
>
> /* Fix the size of the union. */
> @@ -5844,6 +5872,27 @@ controlled by the kvm module parameter halt_poll_ns.
> This capability allows
> the maximum halt time to specified on a per-VM basis, effectively overriding
> the module parameter for the target VM.
>
> +7.21 KVM_CAP_X86_USER_SPACE_MSR
> +--
> +
> +:Architectures: x86
> +:Targ
Re: [PATCH v5 5/6] kprobes: Use text_alloc() and text_free()
On Sun, 26 Jul 2020 19:06:20 +0300
Ard Biesheuvel wrote:
> On Sun, 26 Jul 2020 at 11:14, Mike Rapoport wrote:
> >
> > On Sat, Jul 25, 2020 at 06:16:48AM +0300, Jarkko Sakkinen wrote:
> > > On Fri, Jul 24, 2020 at 11:27:46AM +0200, Ingo Molnar wrote:
> > > >
> > > > * Jarkko Sakkinen wrote:
> > > >
> > > > > Use text_alloc() and text_free() instead of module_alloc() and
> > > > > module_memfree() when an arch provides them.
> > > > >
> > > > > Cc: linux...@kvack.org
> > > > > Cc: Andi Kleen
> > > > > Cc: Masami Hiramatsu
> > > > > Cc: Peter Zijlstra
> > > > > Signed-off-by: Jarkko Sakkinen
> > > > > ---
> > > > > kernel/kprobes.c | 9 +
> > > > > 1 file changed, 9 insertions(+)
> > > > >
> > > > > diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> > > > > index 4e46d96d4e16..611fcda9f6bf 100644
> > > > > --- a/kernel/kprobes.c
> > > > > +++ b/kernel/kprobes.c
> > > > > @@ -40,6 +40,7 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > >
> > > > > #define KPROBE_HASH_BITS 6
> > > > > #define KPROBE_TABLE_SIZE (1 << KPROBE_HASH_BITS)
> > > > > @@ -111,12 +112,20 @@ enum kprobe_slot_state {
> > > > >
> > > > > void __weak *alloc_insn_page(void)
> > > > > {
> > > > > +#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC
> > > > > + return text_alloc(PAGE_SIZE);
> > > > > +#else
> > > > > return module_alloc(PAGE_SIZE);
> > > > > +#endif
> > > > > }
> > > > >
> > > > > void __weak free_insn_page(void *page)
> > > > > {
> > > > > +#ifdef CONFIG_ARCH_HAS_TEXT_ALLOC
> > > > > + text_free(page);
> > > > > +#else
> > > > > module_memfree(page);
> > > > > +#endif
> > > > > }
> > > >
> > > > I've read the observations in the other threads, but this #ifdef
> > > > jungle is silly, it's a de-facto open coded text_alloc() with a
> > > > module_alloc() fallback...
> > >
> > > In the previous version I had:
> > >
> > >
> > > https://lore.kernel.org/lkml/20200717030422.679972-4-jarkko.sakki...@linux.intel.com/
> > >
> > > and I had just calls to text_alloc() and text_free() in corresponding
> > > snippet to the above.
> > >
> > > I got this feedback from Mike:
> > >
> > > https://lore.kernel.org/lkml/20200718162359.ga2919...@kernel.org/
> > >
> > > I'm not still sure that I fully understand this feedback as I don't see
> > > any inherent and obvious difference to the v4. In that version fallbacks
> > > are to module_alloc() and module_memfree() and text_alloc() and
> > > text_memfree() can be overridden by arch.
> >
> > Let me try to elaborate.
> >
> > There are several subsystems that need to allocate memory for executable
> > text. As it happens, they use module_alloc() with some abilities for
> > architectures to override this behaviour.
> >
> > For many architectures, it would be enough to rename modules_alloc() to
> > text_alloc(), make it built-in and this way allow removing dependency on
> > MODULES.
> >
> > Yet, some architectures have different restrictions for code allocation
> > for different subsystems so it would make sense to have more than one
> > variant of text_alloc() and a single config option ARCH_HAS_TEXT_ALLOC
> > won't be sufficient.
> >
> > I liked Mark's suggestion to have text_alloc_() and proposed
> > a way to introduce text_alloc_kprobes() along with
> > HAVE_KPROBES_TEXT_ALLOC to enable arch overrides of this function.
> >
> > The major difference between your v4 and my suggestion is that I'm not
> > trying to impose a single ARCH_HAS_TEXT_ALLOC as an alternative to
> > MODULES but rather to use per subsystem config option, e.g.
> > HAVE_KPROBES_TEXT_ALLOC.
> >
> > Another thing, which might be worth doing regardless of the outcome of
> > this discussion is to rename alloc_insn_pages() to text_alloc_kprobes()
> > because the former is way too generic and does not emphasize that the
> > instruction page is actually used by kprobes only.
The name of the insn_pages came from the struct kprobe_insn_page, so
if there is a text_alloc_kprobe(), I'm OK to rename it. (anyway, that
is an allocation operator, we don't call it directly.)
> Masami or Peter should correct me if I am wrong, but it seems to me
> that the way kprobes uses these pages does not require them to be in
> relative branching range of the core kernel on any architecture, given
> that they are populated with individual instruction opcodes that are
> executed in single step mode, and relative branches are emulated (when
> needed)
Actually, x86 and arm has the "relative branching range" requirements
for the jump optimized kprobes. For the other architectures, I think
we don't need it. Only executable text buffer is needed.
Thank you,
> So for kprobes in particular, we should be able to come up with a
> generic sequence that does not involve module_alloc(), and therefore
> removes the kprobes dependency on module support entirely (with the
> exception of power which maps the vmalloc space nx when module support
> is disabled). Renaming alloc_insn_page() to something more descript
Re: [PATCH 12/26] netfilter: switch nf_setsockopt to sockptr_t
On Tue, Jul 28, 2020 at 10:07 AM David Laight wrote: > > From: Christoph Hellwig > > Sent: 27 July 2020 17:24 > > > > On Mon, Jul 27, 2020 at 06:16:32PM +0200, Jason A. Donenfeld wrote: > > > Maybe sockptr_advance should have some safety checks and sometimes > > > return -EFAULT? Or you should always use the implementation where > > > being a kernel address is an explicit bit of sockptr_t, rather than > > > being implicit? > > > > I already have a patch to use access_ok to check the whole range in > > init_user_sockptr. > > That doesn't make (much) difference to the code paths that ignore > the user-supplied length. > OTOH doing the user/kernel check on the base address (not an > incremented one) means that the correct copy function is always > selected. Right, I had the same reaction in reading this, but actually, his code gets rid of the sockptr_advance stuff entirely and never mutates, so even though my point about attacking those pointers was missed, the code does the better thing now -- checking the base address and never mutating the pointer. So I think we're good. > > Perhaps the functions should all be passed a 'const sockptr_t'. > The typedef could be made 'const' - requiring non-const items > explicitly use the union/struct itself. I was thinking the same, but just by making the pointers inside the struct const. However, making the whole struct const via the typedef is a much better idea. That'd probably require changing the signature of init_user_sockptr a bit, which would be fine, but indeed I think this would be a very positive change. Jason
Re: [PATCH 4/7] gpio: dwapb: Convert driver to using the GPIO-lib-based IRQ-chip
On Mon, Jul 27, 2020 at 11:50 PM Serge Semin wrote: > It turns out my "mostly" was wrong in this matter. It's 4 out of 17 patches, > which make the initialization in the same order as mine: I'll think about fixing them up to all look the same at some point if noone beats me to it. Sorry for the mess, I was just hacking along to get this work item finalized. Yours, Linus Walleij
Re: [PATCH] staging/speakup: Update TODO list
On Sun, Jul 26, 2020 at 06:54:52PM +0200, Samuel Thibault wrote:
> Thanks to Okash's latest work, the TODO list is essentially empty, so
> the way out from staging now seems open.
>
> The status of the remaining issue mentioned in TODO is not clear, we
> asked the speakup user mailing list for reproducer cases, but didn't get
> a really specific scenario. One serious bug was fixed by 9d32c0cde4e2
> ("staging/speakup: fix get_word non-space look-ahead"), which does not
> seem to really be related to the bug mentioned in TODO. Possibly the bug
> mentioned in TODO has been fixed long ago and people have been thinking
> that it was not because they can not distinguish the symptoms mentioned
> in TODO from the symptoms of the bug fixed by 9d32c0cde4e2.
I think it's time we move speakup out of staging. Care to submit a
patch series that does this?
thanks,
greg k-h
[PATCH] dt-bindings: regulator: Convert sy8824x to json-schema
Convert the sy8824x binding to DT schema format using json-schema.
Signed-off-by: Jisheng Zhang
---
.../bindings/regulator/silergy,sy8824x.yaml | 40 +++
.../devicetree/bindings/regulator/sy8824x.txt | 24 ---
2 files changed, 40 insertions(+), 24 deletions(-)
create mode 100644
Documentation/devicetree/bindings/regulator/silergy,sy8824x.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/sy8824x.txt
diff --git a/Documentation/devicetree/bindings/regulator/silergy,sy8824x.yaml
b/Documentation/devicetree/bindings/regulator/silergy,sy8824x.yaml
new file mode 100644
index ..62a476c94111
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/silergy,sy8824x.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/silergy,sy8824x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: silergy sy8824c,sy8824e,sy20276 and sy20278 PMIC
+
+maintainers:
+ - Jisheng Zhang
+
+properties:
+ compatible:
+enum:
+ - silergy,sy8824c
+ - silergy,sy8824e
+ - silergy,sy20276
+ - silergy,sy20278
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+regulator@60 {
+ compatible = "silergy,sy8824c";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <115>;
+ reg = <0x60>;
+};
+};
+
+...
diff --git a/Documentation/devicetree/bindings/regulator/sy8824x.txt
b/Documentation/devicetree/bindings/regulator/sy8824x.txt
deleted file mode 100644
index c5e95850c427..
--- a/Documentation/devicetree/bindings/regulator/sy8824x.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-SY8824C/SY8824E/SY20276 Voltage regulator
-
-Required properties:
-- compatible: Must be one of the following.
- "silergy,sy8824c"
- "silergy,sy8824e"
- "silergy,sy20276"
- "silergy,sy20278"
-- reg: I2C slave address
-
-Any property defined as part of the core regulator binding, defined in
-./regulator.txt, can also be used.
-
-Example:
-
- vcore: regulator@00 {
- compatible = "silergy,sy8824c";
- reg = <0x66>;
- regulator-name = "vcore";
- regulator-min-microvolt = <80>;
- regulator-max-microvolt = <115>;
- regulator-boot-on;
- regulator-always-on;
- };
--
2.28.0.rc0
Re: [PATCH -mmotm] pinctrl: mediatek: fix build for tristate changes
On Tue, Jul 28, 2020 at 7:55 AM Randy Dunlap wrote: > From: Randy Dunlap > > Export mtk_is_virt_gpio() for the case when > CONFIG_PINCTRL_MTK=y > CONFIG_PINCTRL_MTK_V2=y > CONFIG_PINCTRL_MTK_MOORE=y > CONFIG_PINCTRL_MTK_PARIS=m > > to fix this build error: > > ERROR: modpost: "mtk_is_virt_gpio" > [drivers/pinctrl/mediatek/pinctrl-paris.ko] undefined! > > Signed-off-by: Randy Dunlap > Cc: Sean Wang > Cc: linux-media...@lists.infradead.org Good catch! Thanks Randy, patch applied. Yours, Linus Walleij
Re: [PATCH v6 06/13] pwm: add support for sl28cpld PWM controller
Hi,
Am 2020-07-28 09:43, schrieb Uwe Kleine-König:
Hello,
just a few minor issues left:
thanks for the review.
On Sun, Jul 26, 2020 at 01:18:27AM +0200, Michael Walle wrote:
diff --git a/drivers/pwm/pwm-sl28cpld.c b/drivers/pwm/pwm-sl28cpld.c
new file mode 100644
index ..956fa09f3aba
--- /dev/null
+++ b/drivers/pwm/pwm-sl28cpld.c
@@ -0,0 +1,223 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * sl28cpld PWM driver
+ *
+ * Copyright (c) 2020 Michael Walle
+ *
+ * There is no public datasheet available for this PWM core. But it
is easy
+ * enough to be briefly explained. It consists of one 8-bit counter.
The PWM
+ * supports four distinct frequencies by selecting when to reset the
counter.
+ * With the prescaler setting you can select which bit of the counter
is used
+ * to reset it. This implies that the higher the frequency the less
remaining
+ * bits are available for the actual counter.
+ *
+ * Let cnt[7:0] be the counter, clocked at 32kHz:
+ * +---++--+---+
+ * | prescaler | reset | counter bits | frequency |
+ * +---++--+---+
+ * | 0 | cnt[7] | cnt[6:0] | 250Hz |
+ * | 1 | cnt[6] | cnt[5:0] | 500Hz |
+ * | 2 | cnt[5] | cnt[4:0] | 1kHz |
+ * | 3 | cnt[4] | cnt[3:0] | 2kHz |
+ * +---++--+---+
Very nice. I'd add a "period length" column, as this is what the PWM
core uses.
For your convenience (and as I created that table anyhow for further
checking of the formulas below):
* +---++--+---++
* | prescaler | reset | counter bits | frequency | period |
* | || | | length |
* +---++--+---++
* | 0 | cnt[7] | cnt[6:0] | 250Hz | 4000ns |
* | 1 | cnt[6] | cnt[5:0] | 500Hz | 2000ns |
* | 2 | cnt[5] | cnt[4:0] | 1kHz | 1000ns |
* | 3 | cnt[4] | cnt[3:0] | 2kHz | 500ns |
* +---++--+---++
sure :)
+ *
+ * Limitations:
+ * - The hardware cannot generate a 100% duty cycle if the prescaler
is 0.
+ * - The hardware cannot atomically set the prescaler and the counter
value,
+ * which might lead to glitches and inconsistent states if a write
fails.
+ * - The counter is not reset if you switch the prescaler which leads
+ * to glitches, too.
+ * - The duty cycle will switch immediately and not after a complete
cycle.
+ * - Depending on the actual implementation, disabling the PWM might
have
+ * side effects. For example, if the output pin is shared with a
GPIO pin
+ * it will automatically switch back to GPIO mode.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * PWM timer block registers.
+ */
+#define SL28CPLD_PWM_CTRL 0x00
+#define SL28CPLD_PWM_CTRL_ENABLE BIT(7)
+#define SL28CPLD_PWM_CTRL_PRESCALER_MASK GENMASK(1, 0)
+#define SL28CPLD_PWM_CYCLE 0x01
+#define SL28CPLD_PWM_CYCLE_MAX GENMASK(6, 0)
+
+#define SL28CPLD_PWM_CLK 32000 /* 32 kHz */
+#define SL28CPLD_PWM_MAX_DUTY_CYCLE(prescaler) (1 << (7 -
(prescaler)))
+#define SL28CPLD_PWM_PERIOD(prescaler) \
+ (NSEC_PER_SEC / SL28CPLD_PWM_CLK *
SL28CPLD_PWM_MAX_DUTY_CYCLE(prescaler))
+
+/*
+ * We calculate the duty cycle like this:
+ * duty_cycle_ns = pwm_cycle_reg * max_period_ns / max_duty_cycle
+ *
+ * With
+ * max_period_ns = (1 << 7 - prescaler) / pwm_clk * NSEC_PER_SEC
+ * max_duty_cycle = 1 << (7 - prescaler)
If you don't need parenthesis in the max_period_ns around 7 -
prescaler,
you don't need them either in the max_duty_cycle line.
mhh this should be "1 << (7 - prescaler)" in both cases. So
max_period_ns is wrong:
max_period_ns = 1 << (7 - prescaler) / pwm_clk * NSEC_PER_SEC
+ * this then simplifies to:
+ * duty_cycle_ns = pwm_cycle_reg / pwm_clk * NSEC_PER_SEC
+ */
+#define SL28CPLD_PWM_TO_DUTY_CYCLE(reg) \
+ (NSEC_PER_SEC / SL28CPLD_PWM_CLK * (reg))
For those who copy from your driver maybe add a comment like:
* NSEC_PER_SEC / SL28CPLD_PWM_CLK is integer here, so we're not
loosing
* precision by doing the division first.
ok.
+#define SL28CPLD_PWM_FROM_DUTY_CYCLE(duty_cycle) \
+ (DIV_ROUND_DOWN_ULL((duty_cycle), NSEC_PER_SEC / SL28CPLD_PWM_CLK))
+
+struct sl28cpld_pwm {
+ struct pwm_chip pwm_chip;
+ struct regmap *regmap;
+ u32 offset;
+};
+
+static void sl28cpld_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct sl28cpld_pwm *priv = dev_get_drvdata(chip->dev);
+ unsigned int reg;
+ int prescaler;
+
+ regmap_read(priv->regmap, priv->offset + SL28CPLD_PWM
Re: Kernel panic - not syncing: IO-APIC + timer doesn't work!
Scott, Scott Branden writes: > Bios now updated to latest. Same kernel panic issue. Log below. > > I think it is related to power cycling quickly. > Should APIC work if PC power cycled in a few seconds or is that the > problem? Yes, emphasis on should. Just to clarify, if you reboot it works and cold start works as well if power was off long enough? > [ 0.00] Linux version 5.8.0-rc6 (oe-user@oe-host) > (x86_64-poky-linux-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34.0.20200220) > #1 SMP Sat Jul 25 03:55:25 UTC 2020 > [ 0.00] Command line: BOOT_IMAGE=/bzImage ima_policy=tcb > apic=debug ip=dhcp raid=noautodetect console=ttyS0,115200 > root=/dev/nfs nfsroot=192.168.1.100:/nfs/vxc,hard,tcp,intr,v3 rootwait > nfsrootdebug The working dmesg and the failing console log are hard to compare because the latter does not contain debug level printks. Please add 'ignore_loglevel' to the command line parameters. Thanks, tglx
Re: linux-next: build failure after merge of the char-misc tree
Hi Greg,
On Tue, 28 Jul 2020 09:53:36 +0200 Greg KH wrote:
>
> On Tue, Jul 28, 2020 at 05:33:31PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > On Mon, 27 Jul 2020 11:24:48 +0200 Greg KH wrote:
> > >
> > > On Mon, Jul 27, 2020 at 06:08:31PM +1000, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > After merging the char-misc tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > In file included from drivers/misc/habanalabs/goya/goya.c:8:
> > > > drivers/misc/habanalabs/goya/goyaP.h:12:10: fatal error: habanalabs.h:
> > > > No such file or directory
> > > >12 | #include "habanalabs.h"
> > > > | ^~
> > > > In file included from drivers/misc/habanalabs/goya/goya_security.c:8:
> > > > drivers/misc/habanalabs/goya/goyaP.h:12:10: fatal error: habanalabs.h:
> > > > No such file or directory
> > > >12 | #include "habanalabs.h"
> > > > | ^~
> > > >
> > > > Presumably caused by commit
> > > >
> > > > 70b2f993ea4a ("habanalabs: create common folder")
> > > >
> > > > I have used the char-misc tree from next-20200724 for today.
> > >
> > > Ugh, this is a mess of a merge with this driver.
> > >
> > > Oded, I'll take Stephen's merge resolutions here and push out a new
> > > version, and try to resolve this error, but if you could verify I got it
> > > correct, that would be great.
> >
> > The conflicts are gone, but I still get these errors.
>
> Very odd, I can not duplicate this at all here. I just did a clean
> checkout of the char-misc-next branch and a full 'make allmodconfig' for
> x86_64, and it worked just fine.
>
> Are you sure it's not coming from some other tree?
Do you build with a separate object tree? I always use make O=...
which makes the difference. I tested with just your tree.
--
Cheers,
Stephen Rothwell
pgpCDKondsvw_.pgp
Description: OpenPGP digital signature
[PATCH v2] Staging : media : atomisp : fixed a brace coding sytle issue
From: Ankit Baluni
Removed braces for a 'if' condition as it contain only single line &
there is no need for braces for such case according to coding style
rules.
Signed-off-by: Ankit Baluni
---
drivers/staging/media/atomisp/pci/atomisp_cmd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
index 8ea65bef35d2..28b96b66f4f3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.c
@@ -4981,9 +4981,8 @@ enum mipi_port_id __get_mipi_port(struct atomisp_device
*isp,
case ATOMISP_CAMERA_PORT_SECONDARY:
return MIPI_PORT1_ID;
case ATOMISP_CAMERA_PORT_TERTIARY:
- if (MIPI_PORT1_ID + 1 != N_MIPI_PORT_ID) {
+ if (MIPI_PORT1_ID + 1 != N_MIPI_PORT_ID)
return MIPI_PORT1_ID + 1;
- }
/* fall through */
default:
dev_err(isp->dev, "unsupported port: %d\n", port);
--
2.25.1
Re: BUG: omap5: v5.8-rc7 boot fails
* H. Nikolaus Schaller [200727 20:51]: > Hi Tony, > after trying v5.8-rc7 the Pyra boot hangs after ca. 3 seconds > (a little random what the last log line is). > > I could bisect it to: > > 6cfcd5563b4fadbf49ba8fa481978e5e86d30322 is the first bad commit > commit 6cfcd5563b4fadbf49ba8fa481978e5e86d30322 > Author: Tony Lindgren > Date: Mon Jul 13 09:26:01 2020 -0700 > > clocksource/drivers/timer-ti-dm: Fix suspend and resume for am3 and am4 > > And a git revert makes it boot again. > > I haven't had time to do more tests (e.g. with omap3/4 or on omap5uevm). Oops sorry about that, I'll take a look. Regards, Tony
RE: mmotm 2020-07-27-18-18 uploaded (drivers/scsi/ufs/: SCSI_UFS_EXYNOS)
Hi Randy, > -Original Message- > From: Randy Dunlap > Sent: 28 July 2020 08:53 > To: Andrew Morton ; broo...@kernel.org; linux- > fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; linux...@kvack.org; > linux-n...@vger.kernel.org; mho...@suse.cz; mm-comm...@vger.kernel.org; > s...@canb.auug.org.au; linux-scsi ; Alim Akhtar > ; Seungwon Jeon > Subject: Re: mmotm 2020-07-27-18-18 uploaded (drivers/scsi/ufs/: > SCSI_UFS_EXYNOS) > > On 7/27/20 6:19 PM, Andrew Morton wrote: > > The mm-of-the-moment snapshot 2020-07-27-18-18 has been uploaded to > > > >http://www.ozlabs.org/~akpm/mmotm/ > > > > mmotm-readme.txt says > > > > README for mm-of-the-moment: > > > > http://www.ozlabs.org/~akpm/mmotm/ > > > > This is a snapshot of my -mm patch queue. Uploaded at random > > hopefully more than once a week. > > > > You will need quilt to apply these patches to the latest Linus release > > (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is > > duplicated in http://ozlabs.org/~akpm/mmotm/series > > > > on i386: > > when CONFIG_OF is not set/enabled: > > WARNING: unmet direct dependencies detected for PHY_SAMSUNG_UFS > Depends on [n]: OF [=n] && (ARCH_EXYNOS || COMPILE_TEST [=y]) > Selected by [m]: > - SCSI_UFS_EXYNOS [=m] && SCSI_LOWLEVEL [=y] && SCSI [=y] && > SCSI_UFSHCD_PLATFORM [=m] && (ARCH_EXYNOS || COMPILE_TEST [=y]) > Have already posted a fix for this [1] [1] https://www.spinics.net/lists/linux-scsi/msg144970.html > > Full randconfig file is attached. > Thanks for config file, I can reproduce it and confirm that [1] above fixes this Warning. > > -- > ~Randy > Reported-by: Randy Dunlap
Re: [PATCH v6 01/13] mfd: add simple regmap based I2C driver
Am 2020-07-28 10:15, schrieb Lee Jones: On Tue, 28 Jul 2020, Michael Walle wrote: Am 2020-07-28 09:19, schrieb Lee Jones: > On Sun, 26 Jul 2020, Michael Walle wrote: > > > There are I2C devices which contain several different functions but > > doesn't require any special access functions. For these kind of > > drivers > > an I2C regmap should be enough. > > > > Create an I2C driver which creates an I2C regmap and enumerates its > > children. If a device wants to use this as its MFD core driver, it has > > to add an individual compatible string. It may provide its own regmap > > configuration. > > > > Subdevices can use dev_get_regmap() on the parent to get their regmap > > instance. > > > > Signed-off-by: Michael Walle > > --- > > Changes since v5: > > - removed "select MFD_CORE" in Kconfig > > - removed help text in Kconfig, we assume that the users of this > > That's the opposite of what I asked for. What is the use to describe the symbol, if it is not user selectable? I'm not aware this is done anywhere in the kernel, am I missing something? You mean in menuconfig? I find 'help's helpful even outside of menuconfig. Surely I'm not the only one who reads them 'raw'? Its already available in the header of the file. But sure, I can copy it. > >driver will have a "select MFD_SIMPLE_MFD_I2C". Instead added > >a small description to the driver itself. > > - removed "struct simple_mfd_i2c_config" and use regmap_config > >directly > > - changed builtin_i2c_driver() to module_i2c_driver(), added > >MODULE_ boilerplate > > - cleaned up the included files > > > > Changes since v4: > > - new patch. Lee, please bear with me. I didn't want to delay the > >new version (where a lot of remarks on the other patches were > >addressed) even more, just because we haven't figured out how > >to deal with the MFD part. So for now, I've included this one. > > > > drivers/mfd/Kconfig | 5 > > drivers/mfd/Makefile | 1 + > > drivers/mfd/simple-mfd-i2c.c | 55 > > > > 3 files changed, 61 insertions(+) > > create mode 100644 drivers/mfd/simple-mfd-i2c.c > > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > > index 33df0837ab41..c08539c7a166 100644 > > --- a/drivers/mfd/Kconfig > > +++ b/drivers/mfd/Kconfig > > @@ -1162,6 +1162,11 @@ config MFD_SI476X_CORE > > To compile this driver as a module, choose M here: the > > module will be called si476x-core. > > > > +config MFD_SIMPLE_MFD_I2C > > + tristate > > + depends on I2C > > + select REGMAP_I2C > > Please provide a full help. See above. > > > config MFD_SM501 > > tristate "Silicon Motion SM501" > > depends on HAS_DMA > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > index a60e5f835283..78d24a3e7c9e 100644 > > --- a/drivers/mfd/Makefile > > +++ b/drivers/mfd/Makefile > > @@ -264,3 +264,4 @@ obj-$(CONFIG_MFD_STMFX) += stmfx.o > > obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o > > > > obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o > > +obj-$(CONFIG_MFD_SIMPLE_MFD_I2C) += simple-mfd-i2c.o > > diff --git a/drivers/mfd/simple-mfd-i2c.c > > b/drivers/mfd/simple-mfd-i2c.c > > new file mode 100644 > > index ..45090ddad104 > > --- /dev/null > > +++ b/drivers/mfd/simple-mfd-i2c.c > > @@ -0,0 +1,55 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * A very simple I2C MFD driver > > Simple MFD - I2C ok. > > + * The driver enumerates its children and registers a common > > regmap. Use > > + * dev_get_regmap(pdev->dev.parent, NULL) in the child nodes to > > fetch that > > + * regmap instance. > > This driver creates a single register map with the intention for it to > be shared by all sub-devices. Children can use their parent's device > structure (dev.parent) in order reference it. Should this be appended or should it replace my paragraph? If its the latter, the "enumeration of the children" is missing. If you want to keep that part, try: This driver creates a single register map with the intention for it to be shared by all sub-devices. Children can use their parent's device structure (dev.parent) in order reference it. Once the register map has been successfully initialised, any sub-devices represented by child nodes in Device Tree will be subsequently registered. > > + * In the future this driver might be extended to support also > > other interfaces > > + * like SPI etc. > > Remove this please. Why would you remove information about the intention of this driver? If someone looks for a place to implement its SPI/I3C/Slimbus MFD driver this might come in handy. By all means put something similar in the commit log, but it has no place in the driver itself. Besides, if we were to add support for SPI, it is likely to be a completely separate/unrelated driver. Why would that be another driver? It would be 90% copy paste with regmap_init_i2c() replaced by regmap_init_spi(
Re: [PATCH v6 02/13] dt-bindings: mfd: Add bindings for sl28cpld
On Tue, 28 Jul 2020, Michael Walle wrote: > Am 2020-07-28 09:24, schrieb Lee Jones: > > On Sun, 26 Jul 2020, Michael Walle wrote: > > > > > Add a device tree bindings for the board management controller found > > > on > > > the Kontron SMARC-sAL28 board. > > > > > > Signed-off-by: Michael Walle > > > Reviewed-by: Rob Herring > > > --- > > > Changes since v5: > > > - none > > > > > > Changes since v4: > > > - fix the regex of the unit-address > > > > > > Changes since v3: > > > - see cover letter > > > > > > .../bindings/gpio/kontron,sl28cpld-gpio.yaml | 54 +++ > > > .../hwmon/kontron,sl28cpld-hwmon.yaml | 27 > > > .../kontron,sl28cpld-intc.yaml| 54 +++ > > > .../bindings/mfd/kontron,sl28cpld.yaml| 153 > > > ++ > > > .../bindings/pwm/kontron,sl28cpld-pwm.yaml| 35 > > > .../watchdog/kontron,sl28cpld-wdt.yaml| 35 > > > 6 files changed, 358 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > > > create mode 100644 > > > Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml > > > create mode 100644 > > > Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml > > > create mode 100644 > > > Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml > > > create mode 100644 > > > Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml > > > create mode 100644 > > > Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml > > > > > > diff --git > > > a/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > > > b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > > > new file mode 100644 > > > index ..9a63a158a796 > > > --- /dev/null > > > +++ > > > b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > > > @@ -0,0 +1,54 @@ > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/gpio/kontron,sl28cpld-gpio.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: GPIO driver for the sl28cpld board management controller > > > + > > > +maintainers: > > > + - Michael Walle > > > + > > > +description: | > > > + This module is part of the sl28cpld multi-function device. For more > > > + details see > > > Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml. > > > > Paths are normally relative. > > grep Documentation/ Documentation > > I know there are a lot false positives (esp in the first one).. > > $ grep -r "\.\./" Documentation | wc -l > 1826 > $ grep -r "Documentation/" Documentation|wc -l > 2862 I actually meant just for Device Tree bindings, but it does appear that 'Documentation' is used a bunch there too. My reasons for not liking full paths is that the intention was always to move 'Documentation/devicetree' to a new location outside of the kernel source tree. [...] > > > +%YAML 1.2 > > > +--- > > > +$id: http://devicetree.org/schemas/mfd/kontron,sl28cpld.yaml# > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > + > > > +title: Kontron's sl28cpld board management controller > > > > "S128CPLD" ? > > still not, its sl28cpld, think of a project/code name, not the product > appended with CPLD. > > > "Board Management Controller (BMC)" ? > > sounds like IPMI, which I wanted to avoid. Is there a datasheet? > > > +maintainers: > > > + - Michael Walle > > > + > > > +description: | > > > + The board management controller may contain different IP blocks > > > like > > > + watchdog, fan monitoring, PWM controller, interrupt controller > > > and a > > > + GPIO controller. > > > + > > > +properties: > > > + compatible: > > > +const: kontron,sl28cpld-r1 > > > > We don't usually code revision numbers in compatible strings. > > > > Is there any way to pull this from the H/W? > > No, unfortunately you can't. And I really want to keep that, in case > in the future there are some backwards incompatible changes. Rob, I know you reviewed this already, but you can give your opinion on this specifically please? I know that we have pushed back on this in the past. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] mtd: revert "spi-nor: intel: provide a range for poll_timout"
Hi, Mika, On 7/23/20 12:05 PM, Alexander Sverdlin wrote: > > Hello Tudor, > > On 22/07/2020 19:03, tudor.amba...@microchip.com wrote: >> On 7/22/20 7:37 PM, Alexander Sverdlin wrote: > > [...] > >>> I've performed my testing as well and got the following results: >>> >>> Vanilla Linux 4.9 (i.e. before the introduction of the offending >>> patch): >>> >>> dd if=/dev/flash/by-name/XXX of=/dev/null bs=4k >>> 1280+0 records in >>> 1280+0 records out >>> 5242880 bytes (5.2 MB, 5.0 MiB) copied, 3.91981 s, 1.3 MB/s >>> >>> Vanilla 4.19 (i.e. with offending patch): >>> >>> dd if=/dev/flash/by-name/XXX of=/dev/null bs=4k >>> 1280+0 records in >>> 1280+0 records out >>> 5242880 bytes (5.2 MB, 5.0 MiB) copied, 6.70891 s, 781 kB/s >>> >>> 4.19 + revert: >>> >>> dd if=/dev/flash/by-name/XXX of=/dev/null bs=4k >>> 1280+0 records in >>> 1280+0 records out >>> 5242880 bytes (5.2 MB, 5.0 MiB) copied, 3.90503 s, 1.3 MB/s >>> [cut] > with 10us it looks like this: > > dd if=/dev/flash/by-name/... of=/dev/null bs=4k > 1280+0 records in > 1280+0 records out > 5242880 bytes (5.2 MB, 5.0 MiB) copied, 4.33816 s, 1.2 MB/s > > Which means, there is a performance regression and it would depend on > the test case, how bad it will be... > We need a bit of a context here. Using a tight-loop for polling and having a 5 secs timeout is fishy. For anything that's expected to complete less than a few usec, it's usually better to poll continuously, but then a timeout of 5s is way too big. Can we shrink the timeout to few msecs? I'll queue this to spi-nor/next to fix the perf regression, but I would like to continue the discussion and to come up with an incremental patch on top of this one. Cheers, ta
Re: linux-next: manual merge of the devicetree tree with the pci tree
On 7/28/2020 11:19 AM, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/pci/qcom,pcie.txt
between commits:
736ae5c91712 ("dt-bindings: PCI: qcom: Add missing clks")
b11b8cc161de ("dt-bindings: PCI: qcom: Add ext reset")
d511580ea9c2 ("dt-bindings: PCI: qcom: Add ipq8064 rev 2 variant")
from the pci tree and commit:
70172d196947 ("dt-bindings: pci: convert QCOM pci bindings to YAML")
from the devicetree tree.
I don;t know how to fixed it up so I just left the latter one . This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
Rob/Bjorn,
Please let me know if I can provide a patch rebased to linux-next.
Bjorn can pick up the patch after review and Rob can drop the old pci
yaml conversion patch.
let me know your thoughts.
Re: [PATCHv2] coresight: etm4x: Fix etm4_count race by moving cpuhp callbacks to init
Quoting Sai Prakash Ranjan (2020-07-28 00:51:02)
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c
> b/drivers/hwtracing/coresight/coresight-etm4x.c
> index 6d7d2169bfb2..adb71987a1e3 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -48,8 +48,6 @@ module_param(pm_save_enable, int, 0444);
> MODULE_PARM_DESC(pm_save_enable,
> "Save/restore state on power down: 1 = never, 2 = self-hosted");
>
> -/* The number of ETMv4 currently registered */
> -static int etm4_count;
> static struct etmv4_drvdata *etmdrvdata[NR_CPUS];
> static void etm4_set_default_config(struct etmv4_config *config);
> static int etm4_set_event_filters(struct etmv4_drvdata *drvdata,
> @@ -1403,12 +1401,9 @@ static int etm4_pm_setup_cpuslocked(void)
Is this only called from __init now? If so please mark it as __init
then.
> {
> int ret;
>
> - if (etm4_count++)
> - return 0;
> -
> ret = cpu_pm_register_notifier(&etm4_cpu_pm_nb);
> if (ret)
> - goto reduce_count;
> + return ret;
>
> ret =
> cpuhp_setup_state_nocalls_cpuslocked(CPUHP_AP_ARM_CORESIGHT_STARTING,
>"arm/coresight4:starting",
> @@ -1432,17 +1427,11 @@ static int etm4_pm_setup_cpuslocked(void)
>
> unregister_notifier:
> cpu_pm_unregister_notifier(&etm4_cpu_pm_nb);
> -
> -reduce_count:
> - --etm4_count;
> return ret;
> }
>
> static void etm4_pm_clear(void)
This is __init too?
> {
> - if (--etm4_count != 0)
> - return;
> -
> cpu_pm_unregister_notifier(&etm4_cpu_pm_nb);
> cpuhp_remove_state_nocalls(CPUHP_AP_ARM_CORESIGHT_STARTING);
> if (hp_online) {
> @@ -1598,4 +1576,29 @@ static struct amba_driver etm4x_driver = {
> .probe = etm4_probe,
> .id_table = etm4_ids,
> };
> -builtin_amba_driver(etm4x_driver);
> +
> +static int __init etm4x_init(void)
> +{
> + int ret;
> +
> + cpus_read_lock();
> + ret = etm4_pm_setup_cpuslocked();
> + cpus_read_unlock();
> +
> + /* etm4_pm_setup_cpuslocked() does its own cleanup - exit on error */
> + if (ret)
> + return ret;
> +
> + ret = amba_driver_register(&etm4x_driver);
> + if (ret) {
> + pr_info("Error registering etm4x driver\n");
Use pr_err() please.
> + goto err_init;
> + }
> +
> + return ret;
> +
> +err_init:
Why is this a goto?
> + etm4_pm_clear();
> + return ret;
Instead of just putting this in the if (ret) arm?
> +}
> +module_init(etm4x_init);
It was device_initcall before with builtin_amba_driver(), best to not
change that.
[v2 1/4] ACPI: APD: Change name from ST to FCH
AMD SoC general pupose clk is present in new platforms with
same MMIO mappings. We can reuse the same clk handler support
for other platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
v2: pulled in clk changes so that patch compiles individually
drivers/acpi/acpi_apd.c| 14 +++---
drivers/clk/x86/clk-st.c | 4 ++--
.../linux/platform_data/{clk-st.h => clk-fch.h}| 10 +-
3 files changed, 14 insertions(+), 14 deletions(-)
rename include/linux/platform_data/{clk-st.h => clk-fch.h} (53%)
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index ba2612e9a0eb..2d99e46add1a 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -8,7 +8,7 @@
*/
#include
-#include
+#include
#include
#include
#include
@@ -79,11 +79,11 @@ static int misc_check_res(struct acpi_resource *ares, void
*data)
return !acpi_dev_resource_memory(ares, &res);
}
-static int st_misc_setup(struct apd_private_data *pdata)
+static int fch_misc_setup(struct apd_private_data *pdata)
{
struct acpi_device *adev = pdata->adev;
struct platform_device *clkdev;
- struct st_clk_data *clk_data;
+ struct fch_clk_data *clk_data;
struct resource_entry *rentry;
struct list_head resource_list;
int ret;
@@ -106,7 +106,7 @@ static int st_misc_setup(struct apd_private_data *pdata)
acpi_dev_free_resource_list(&resource_list);
- clkdev = platform_device_register_data(&adev->dev, "clk-st",
+ clkdev = platform_device_register_data(&adev->dev, "clk-fch",
PLATFORM_DEVID_NONE, clk_data,
sizeof(*clk_data));
return PTR_ERR_OR_ZERO(clkdev);
@@ -135,8 +135,8 @@ static const struct apd_device_desc cz_uart_desc = {
.properties = uart_properties,
};
-static const struct apd_device_desc st_misc_desc = {
- .setup = st_misc_setup,
+static const struct apd_device_desc fch_misc_desc = {
+ .setup = fch_misc_setup,
};
#endif
@@ -239,7 +239,7 @@ static const struct acpi_device_id acpi_apd_device_ids[] = {
{ "AMD0020", APD_ADDR(cz_uart_desc) },
{ "AMDI0020", APD_ADDR(cz_uart_desc) },
{ "AMD0030", },
- { "AMD0040", APD_ADDR(st_misc_desc)},
+ { "AMD0040", APD_ADDR(fch_misc_desc)},
#endif
#ifdef CONFIG_ARM64
{ "APMC0D0F", APD_ADDR(xgene_i2c_desc) },
diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-st.c
index 25d4b97aff9b..c2438874d9f2 100644
--- a/drivers/clk/x86/clk-st.c
+++ b/drivers/clk/x86/clk-st.c
@@ -8,7 +8,7 @@
#include
#include
#include
-#include
+#include
#include
/* Clock Driving Strength 2 register */
@@ -31,7 +31,7 @@ static struct clk_hw *hws[ST_MAX_CLKS];
static int st_clk_probe(struct platform_device *pdev)
{
- struct st_clk_data *st_data;
+ struct fch_clk_data *st_data;
st_data = dev_get_platdata(&pdev->dev);
if (!st_data || !st_data->base)
diff --git a/include/linux/platform_data/clk-st.h
b/include/linux/platform_data/clk-fch.h
similarity index 53%
rename from include/linux/platform_data/clk-st.h
rename to include/linux/platform_data/clk-fch.h
index 7cdb6a402b35..850ca776156d 100644
--- a/include/linux/platform_data/clk-st.h
+++ b/include/linux/platform_data/clk-fch.h
@@ -1,17 +1,17 @@
/* SPDX-License-Identifier: MIT */
/*
- * clock framework for AMD Stoney based clock
+ * clock framework for AMD misc clocks
*
* Copyright 2018 Advanced Micro Devices, Inc.
*/
-#ifndef __CLK_ST_H
-#define __CLK_ST_H
+#ifndef __CLK_FCH_H
+#define __CLK_FCH_H
#include
-struct st_clk_data {
+struct fch_clk_data {
void __iomem *base;
};
-#endif /* __CLK_ST_H */
+#endif /* __CLK_FCH_H */
--
2.20.1
Re: [PATCH 1/2] clk: imx: imx8m: avoid memory leak
Quoting peng@nxp.com (2020-07-27 19:54:48) > From: Peng Fan > > Use devm_kzalloc to avoid memory leak when probe fail. Please add () to functions in commit text. > > Signed-off-by: Peng Fan
[v2 2/4] clk: x86: Change name from ST to FCH
AMD SoC general pupose clk is present in new platforms with
minor differences. We can reuse the same clk driver for other
platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
v2: Moved some changes to acp:apd patch so that individual patches
compile
drivers/clk/x86/Makefile| 2 +-
drivers/clk/x86/{clk-st.c => clk-fch.c} | 24
2 files changed, 13 insertions(+), 13 deletions(-)
rename drivers/clk/x86/{clk-st.c => clk-fch.c} (75%)
diff --git a/drivers/clk/x86/Makefile b/drivers/clk/x86/Makefile
index 7c774ea7ddeb..18564efdc651 100644
--- a/drivers/clk/x86/Makefile
+++ b/drivers/clk/x86/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_PMC_ATOM) += clk-pmc-atom.o
-obj-$(CONFIG_X86_AMD_PLATFORM_DEVICE) += clk-st.o
+obj-$(CONFIG_X86_AMD_PLATFORM_DEVICE) += clk-fch.o
clk-x86-lpss-objs := clk-lpt.o
obj-$(CONFIG_X86_INTEL_LPSS) += clk-x86-lpss.o
obj-$(CONFIG_CLK_LGM_CGU) += clk-cgu.o clk-cgu-pll.o clk-lgm.o
diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-fch.c
similarity index 75%
rename from drivers/clk/x86/clk-st.c
rename to drivers/clk/x86/clk-fch.c
index c2438874d9f2..b252f0cf0628 100644
--- a/drivers/clk/x86/clk-st.c
+++ b/drivers/clk/x86/clk-fch.c
@@ -29,12 +29,12 @@
static const char * const clk_oscout1_parents[] = { "clk48MHz", "clk25MHz" };
static struct clk_hw *hws[ST_MAX_CLKS];
-static int st_clk_probe(struct platform_device *pdev)
+static int fch_clk_probe(struct platform_device *pdev)
{
- struct fch_clk_data *st_data;
+ struct fch_clk_data *fch_data;
- st_data = dev_get_platdata(&pdev->dev);
- if (!st_data || !st_data->base)
+ fch_data = dev_get_platdata(&pdev->dev);
+ if (!fch_data || !fch_data->base)
return -EINVAL;
hws[ST_CLK_48M] = clk_hw_register_fixed_rate(NULL, "clk48MHz", NULL, 0,
@@ -44,12 +44,12 @@ static int st_clk_probe(struct platform_device *pdev)
hws[ST_CLK_MUX] = clk_hw_register_mux(NULL, "oscout1_mux",
clk_oscout1_parents, ARRAY_SIZE(clk_oscout1_parents),
- 0, st_data->base + CLKDRVSTR2, OSCOUT1CLK25MHZ, 3, 0, NULL);
+ 0, fch_data->base + CLKDRVSTR2, OSCOUT1CLK25MHZ, 3, 0, NULL);
clk_set_parent(hws[ST_CLK_MUX]->clk, hws[ST_CLK_48M]->clk);
hws[ST_CLK_GATE] = clk_hw_register_gate(NULL, "oscout1", "oscout1_mux",
- 0, st_data->base + MISCCLKCNTL1, OSCCLKENB,
+ 0, fch_data->base + MISCCLKCNTL1, OSCCLKENB,
CLK_GATE_SET_TO_DISABLE, NULL);
devm_clk_hw_register_clkdev(&pdev->dev, hws[ST_CLK_GATE], "oscout1",
@@ -58,7 +58,7 @@ static int st_clk_probe(struct platform_device *pdev)
return 0;
}
-static int st_clk_remove(struct platform_device *pdev)
+static int fch_clk_remove(struct platform_device *pdev)
{
int i;
@@ -67,12 +67,12 @@ static int st_clk_remove(struct platform_device *pdev)
return 0;
}
-static struct platform_driver st_clk_driver = {
+static struct platform_driver fch_clk_driver = {
.driver = {
- .name = "clk-st",
+ .name = "clk-fch",
.suppress_bind_attrs = true,
},
- .probe = st_clk_probe,
- .remove = st_clk_remove,
+ .probe = fch_clk_probe,
+ .remove = fch_clk_remove,
};
-builtin_platform_driver(st_clk_driver);
+builtin_platform_driver(fch_clk_driver);
--
2.20.1
[3/4] ACPI: APD: Add a fmw property is_raven
Since there is slight difference in AMD RV based soc in misc
clk architecture. The fmw property will help in differentiating
the SoCs.
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c | 4
include/linux/platform_data/clk-fch.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index 2d99e46add1a..d879ba28826c 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -82,6 +82,7 @@ static int misc_check_res(struct acpi_resource *ares, void
*data)
static int fch_misc_setup(struct apd_private_data *pdata)
{
struct acpi_device *adev = pdata->adev;
+ const union acpi_object *obj;
struct platform_device *clkdev;
struct fch_clk_data *clk_data;
struct resource_entry *rentry;
@@ -98,6 +99,9 @@ static int fch_misc_setup(struct apd_private_data *pdata)
if (ret < 0)
return -ENOENT;
+ acpi_dev_get_property(adev, "is-rv", ACPI_TYPE_INTEGER, &obj);
+ clk_data->is_rv = obj->integer.value;
+
list_for_each_entry(rentry, &resource_list, node) {
clk_data->base = devm_ioremap(&adev->dev, rentry->res->start,
resource_size(rentry->res));
diff --git a/include/linux/platform_data/clk-fch.h
b/include/linux/platform_data/clk-fch.h
index 850ca776156d..b9f682459f08 100644
--- a/include/linux/platform_data/clk-fch.h
+++ b/include/linux/platform_data/clk-fch.h
@@ -12,6 +12,7 @@
struct fch_clk_data {
void __iomem *base;
+ u32 is_rv;
};
#endif /* __CLK_FCH_H */
--
2.20.1
[v3 4/4] clk: x86: Support RV architecture
There is minor difference between previous family of SoC and
the current one. Which is the there is only 48Mh fixed clk.
There is no mux and no option to select another freq as there in previous.
Signed-off-by: Akshu Agrawal
---
v2: Consolidated the loops in remove.
v3: Removed negation in condition to make it simple
drivers/clk/x86/clk-fch.c | 53 ---
1 file changed, 38 insertions(+), 15 deletions(-)
diff --git a/drivers/clk/x86/clk-fch.c b/drivers/clk/x86/clk-fch.c
index b252f0cf0628..8f7c5142b0f0 100644
--- a/drivers/clk/x86/clk-fch.c
+++ b/drivers/clk/x86/clk-fch.c
@@ -26,6 +26,10 @@
#define ST_CLK_GATE3
#define ST_MAX_CLKS4
+#define RV_CLK_48M 0
+#define RV_CLK_GATE1
+#define RV_MAX_CLKS2
+
static const char * const clk_oscout1_parents[] = { "clk48MHz", "clk25MHz" };
static struct clk_hw *hws[ST_MAX_CLKS];
@@ -37,33 +41,52 @@ static int fch_clk_probe(struct platform_device *pdev)
if (!fch_data || !fch_data->base)
return -EINVAL;
- hws[ST_CLK_48M] = clk_hw_register_fixed_rate(NULL, "clk48MHz", NULL, 0,
-4800);
- hws[ST_CLK_25M] = clk_hw_register_fixed_rate(NULL, "clk25MHz", NULL, 0,
-2500);
+ if (!fch_data->is_rv) {
+ hws[ST_CLK_48M] = clk_hw_register_fixed_rate(NULL, "clk48MHz",
+ NULL, 0, 4800);
+ hws[ST_CLK_25M] = clk_hw_register_fixed_rate(NULL, "clk25MHz",
+ NULL, 0, 2500);
+
+ hws[ST_CLK_MUX] = clk_hw_register_mux(NULL, "oscout1_mux",
+ clk_oscout1_parents, ARRAY_SIZE(clk_oscout1_parents),
+ 0, fch_data->base + CLKDRVSTR2, OSCOUT1CLK25MHZ, 3, 0,
+ NULL);
- hws[ST_CLK_MUX] = clk_hw_register_mux(NULL, "oscout1_mux",
- clk_oscout1_parents, ARRAY_SIZE(clk_oscout1_parents),
- 0, fch_data->base + CLKDRVSTR2, OSCOUT1CLK25MHZ, 3, 0, NULL);
+ clk_set_parent(hws[ST_CLK_MUX]->clk, hws[ST_CLK_48M]->clk);
- clk_set_parent(hws[ST_CLK_MUX]->clk, hws[ST_CLK_48M]->clk);
+ hws[ST_CLK_GATE] = clk_hw_register_gate(NULL, "oscout1",
+ "oscout1_mux", 0, fch_data->base + MISCCLKCNTL1,
+ OSCCLKENB, CLK_GATE_SET_TO_DISABLE, NULL);
- hws[ST_CLK_GATE] = clk_hw_register_gate(NULL, "oscout1", "oscout1_mux",
- 0, fch_data->base + MISCCLKCNTL1, OSCCLKENB,
- CLK_GATE_SET_TO_DISABLE, NULL);
+ devm_clk_hw_register_clkdev(&pdev->dev, hws[ST_CLK_GATE],
+ "oscout1", NULL);
+ } else {
+ hws[RV_CLK_48M] = clk_hw_register_fixed_rate(NULL, "clk48MHz",
+ NULL, 0, 4800);
- devm_clk_hw_register_clkdev(&pdev->dev, hws[ST_CLK_GATE], "oscout1",
- NULL);
+ hws[RV_CLK_GATE] = clk_hw_register_gate(NULL, "oscout1",
+ "clk48MHz", 0, fch_data->base + MISCCLKCNTL1,
+ OSCCLKENB, CLK_GATE_SET_TO_DISABLE, NULL);
+
+ devm_clk_hw_register_clkdev(&pdev->dev, hws[RV_CLK_GATE],
+ "oscout1", NULL);
+ }
return 0;
}
static int fch_clk_remove(struct platform_device *pdev)
{
- int i;
+ int i, clks;
+ struct fch_clk_data *fch_data;
- for (i = 0; i < ST_MAX_CLKS; i++)
+ fch_data = dev_get_platdata(&pdev->dev);
+
+ clks = fch_data->is_rv ? RV_MAX_CLKS : ST_MAX_CLKS;
+
+ for (i = 0; i < clks; i++)
clk_hw_unregister(hws[i]);
+
return 0;
}
--
2.20.1
[PATCH] /proc/PID/smaps: Consistent whitespace output format
The keys in smaps output are padded to fixed width with spaces.
All except for THPeligible that uses tabs (only since
commit c06306696f83 ("mm: thp: fix false negative of shmem vma's THP
eligibility")).
Unify the output formatting to save time debugging some naïve parsers.
(Part of the unification is also aligning FilePmdMapped with others.)
Signed-off-by: Michal Koutný
---
fs/proc/task_mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index dbda4499a859..5066b0251ed8 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -786,7 +786,7 @@ static void __show_smap(struct seq_file *m, const struct
mem_size_stats *mss,
SEQ_PUT_DEC(" kB\nLazyFree: ", mss->lazyfree);
SEQ_PUT_DEC(" kB\nAnonHugePages: ", mss->anonymous_thp);
SEQ_PUT_DEC(" kB\nShmemPmdMapped: ", mss->shmem_thp);
- SEQ_PUT_DEC(" kB\nFilePmdMapped: ", mss->file_thp);
+ SEQ_PUT_DEC(" kB\nFilePmdMapped: ", mss->file_thp);
SEQ_PUT_DEC(" kB\nShared_Hugetlb: ", mss->shared_hugetlb);
seq_put_decimal_ull_width(m, " kB\nPrivate_Hugetlb: ",
mss->private_hugetlb >> 10, 7);
@@ -816,7 +816,7 @@ static int show_smap(struct seq_file *m, void *v)
__show_smap(m, &mss, false);
- seq_printf(m, "THPeligible: %d\n",
+ seq_printf(m, "THPeligible:%d\n",
transparent_hugepage_enabled(vma));
if (arch_pkeys_enabled())
--
2.27.0
Re: [PATCH] objtool,x86: Verify poke_int3_handler() is self contained
On Mon, Jul 27, 2020 at 10:56:03PM +0200, Thomas Gleixner wrote: > pet...@infradead.org writes: > > Abuse the SMAP rules to ensure poke_int3_handler() doesn't call out to > > anything. > > Yuck. Isn't that what noinstr is for or am I missing something? Well, we don't want poke_int3_handler() to call out to noinstr either. So noinstr only allows calling noinstr, The above hack only allows it calling uaccess-safe functions, and the group of functions that is both noinstr and uaccess-safe is 'small'. But like I said yesterday, perhaps this wants it own annotation. Then we can also verify the lack of any dynamic code. So yes, yuck and a bad idea, ignore this ;-)
Re: [PATCH 4.19 00/86] 4.19.135-rc1 review
On Mon, 27 Jul 2020 at 19:40, Greg Kroah-Hartman
wrote:
>
> This is the start of the stable review cycle for the 4.19.135 release.
> There are 86 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 29 Jul 2020 13:48:51 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
>
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.135-rc1.gz
> or in the git tree and branch at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -
> Pseudo-Shortlog of commits:
Results from Linaro’s test farm.
Regressions detected on x86_64.
Boot failures on x86_64 devices running 4.19.135-rc1 kernel.
Summary
kernel: 4.19.135-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: e11702667f84474535b156dbb194deffa0a6cdb4
git describe: v4.19.134-87-ge11702667f84
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.134-87-ge11702667f84
> Muchun Song
> mm: memcg/slab: fix memory leak at non-root kmem_cache destroy
[2.510884]
[2.510884] WARNING: possible recursive locking detected
[2.510884] 4.19.135-rc1 #1 Not tainted
[2.510884]
[2.510884] swapper/0/1 is trying to acquire lock:
[2.510884] 88703397 (slab_mutex){+.+.}, at:
kmem_cache_destroy+0x9a/0x2b0
[2.510884]
[2.510884] but task is already holding lock:
[2.510884] 88703397 (slab_mutex){+.+.}, at:
kmem_cache_destroy+0x45/0x2b0
[2.510884]
[2.510884] other info that might help us debug this:
[2.510884] Possible unsafe locking scenario:
[2.510884]
[2.510884]CPU0
[2.510884]
[2.510884] lock(slab_mutex);
[2.510884] lock(slab_mutex);
[2.510884]
[2.510884] *** DEADLOCK ***
[2.510884]
[2.510884] May be due to missing lock nesting notation
[2.510884]
[2.510884] 3 locks held by swapper/0/1:
[2.510884] #0: 8702dddc (cpu_hotplug_lock.rw_sem){},
at: kmem_cache_destroy+0x32/0x2b0
[2.510884] #1: 50103e4d (mem_hotplug_lock.rw_sem){},
at: kmem_cache_destroy+0x37/0x2b0
[2.510884] #2: 88703397 (slab_mutex){+.+.}, at:
kmem_cache_destroy+0x45/0x2b0
[2.510884]
[2.510884] stack backtrace:
[2.510884] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.19.135-rc1 #1
[2.510884] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[2.510884] Call Trace:
[2.510884] dump_stack+0x7a/0xa5
[2.510884] __lock_acquire+0x6f1/0x1380
[2.510884] ? ret_from_fork+0x3a/0x50
[2.510884] lock_acquire+0x95/0x190
[2.510884] ? lock_acquire+0x95/0x190
[2.510884] ? kmem_cache_destroy+0x9a/0x2b0
[2.510884] ? kmem_cache_destroy+0x9a/0x2b0
[2.510884] __mutex_lock+0x83/0x990
[2.510884] ? kmem_cache_destroy+0x9a/0x2b0
[2.510884] ? kmem_cache_destroy+0x60/0x2b0
[2.510884] ? set_debug_rodata+0x17/0x17
[2.510884] ? set_debug_rodata+0x17/0x17
[2.510884] mutex_lock_nested+0x1b/0x20
[2.510884] ? get_online_mems+0x5f/0x90
[2.510884] ? mutex_lock_nested+0x1b/0x20
[2.510884] kmem_cache_destroy+0x9a/0x2b0
[2.510884] ? set_debug_rodata+0x17/0x17
[2.510884] intel_iommu_init+0x11c6/0x1326
[2.510884] ? kfree+0xc4/0x240
[2.510884] ? lockdep_hardirqs_on+0xef/0x180
[2.510884] ? kfree+0xc4/0x240
[2.510884] ? trace_hardirqs_on+0x4c/0x100
[2.510884] ? unpack_to_rootfs+0x272/0x29a
[2.510884] ? e820__memblock_setup+0x64/0x64
[2.510884] ? set_debug_rodata+0x17/0x17
[2.510884] pci_iommu_init+0x1a/0x44
[2.510884] ? e820__memblock_setup+0x64/0x64
[2.510884] ? pci_iommu_init+0x1a/0x44
[2.510884] do_one_initcall+0x61/0x2b4
[2.510884] ? set_debug_rodata+0xa/0x17
[2.510884] ? rcu_read_lock_sched_held+0x81/0x90
[2.510884] kernel_init_freeable+0x1d8/0x270
[2.510884] ? rest_init+0x190/0x190
[2.510884] kernel_init+0xe/0x110
[2.510884] ret_from_fork+0x3a/0x50
Full test log:
https://pastebin.com/PWkk0YaF
--
Linaro LKFT
https://lkft.linaro.org
Re: [PATCH v6 01/13] mfd: add simple regmap based I2C driver
On Tue, 28 Jul 2020, Michael Walle wrote: > Am 2020-07-28 10:15, schrieb Lee Jones: > > On Tue, 28 Jul 2020, Michael Walle wrote: > > > > > Am 2020-07-28 09:19, schrieb Lee Jones: > > > > On Sun, 26 Jul 2020, Michael Walle wrote: > > > > > > > > > There are I2C devices which contain several different functions but > > > > > doesn't require any special access functions. For these kind of > > > > > drivers > > > > > an I2C regmap should be enough. > > > > > > > > > > Create an I2C driver which creates an I2C regmap and enumerates its > > > > > children. If a device wants to use this as its MFD core driver, it has > > > > > to add an individual compatible string. It may provide its own regmap > > > > > configuration. > > > > > > > > > > Subdevices can use dev_get_regmap() on the parent to get their regmap > > > > > instance. > > > > > > > > > > Signed-off-by: Michael Walle > > > > > --- > > > > > Changes since v5: > > > > > - removed "select MFD_CORE" in Kconfig > > > > > - removed help text in Kconfig, we assume that the users of this > > > > > > > > That's the opposite of what I asked for. > > > > > > What is the use to describe the symbol, if it is not user selectable? > > > I'm not aware this is done anywhere in the kernel, am I missing > > > something? > > > > You mean in menuconfig? > > > > I find 'help's helpful even outside of menuconfig. > > > > Surely I'm not the only one who reads them 'raw'? > > Its already available in the header of the file. But sure, I can > copy it. Thanks. [...] > > > Why would you remove information about the intention of this driver? > > > If > > > someone > > > looks for a place to implement its SPI/I3C/Slimbus MFD driver this > > > might > > > come > > > in handy. > > > > By all means put something similar in the commit log, but it has no > > place in the driver itself. Besides, if we were to add support for > > SPI, it is likely to be a completely separate/unrelated driver. > > Why would that be another driver? It would be 90% copy paste with > regmap_init_i2c() replaced by regmap_init_spi() and i2c_driver replaced > by spi_driver. We'll investigate options if/when the time comes. If 'spi_driver' and 'i2c_driver' can *sensibly* co-exist, then that is certainly an option we can explore. > But I don't care. I'll remove it. Please. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCHv8 0/6] n_gsm serdev support and GNSS driver for droid4
* Pavel Machek [200726 08:25]: > Hi! > > > > Here's the updated set of these patches fixed up for Johan's and > > > Pavel's earlier comments. > > > > > > This series does the following: > > > > > > 1. Adds functions to n_gsm.c for serdev-ngsm.c driver to use > > > > > > 2. Adds a generic serdev-ngsm.c driver that brings up the TS 27.010 > > >TTY ports configured in devicetree with help of n_gsm.c > > > > > > 3. Allows the use of standard Linux device drivers for dedicated > > >TS 27.010 channels for devices like GNSS and ALSA found on some > > >modems for example > > > > Unfortunately that does not seem to be the case just yet. Your gnss > > driver is still aware that it's using n_gsm for the transport and calls > > into the "parent" serdev-ngsm driver instead of using the serdev > > interface (e.g. as if this was still and MFD driver). > > > > If you model this right, the GNSS driver should work equally well > > regardless of whether you use the serial interface (with n_gsm) or USB > > (e.g. cdc-acm or usb-serial). > > We are not going to see that protocol anywhere else, so why is that > a good goal? Yes it seems this GNSS implementation is different from the one provided by gobi. > Anyway, Tony, is there newer version of this patchset? It would be > good to get something in... Sorry it will likely be few more weeks before I can look at this stuff again. > Can I help somehow? I think I'm pretty clear on what needs to be done regarding this patchset. Probably taking a look at if we could implement a minimal raw /dev/gsmtty* read/write access in ofono using ell instead of gatchat would help most :) So something that mbim modem is already doing I think, sorry have not had a chance to look at that either. The /dev/gsmtty* devices should not change even with the further changes to this patchset. Regards, Tony
Re: [PATCH v6 02/13] dt-bindings: mfd: Add bindings for sl28cpld
Am 2020-07-28 10:27, schrieb Lee Jones: On Tue, 28 Jul 2020, Michael Walle wrote: Am 2020-07-28 09:24, schrieb Lee Jones: > On Sun, 26 Jul 2020, Michael Walle wrote: > > > Add a device tree bindings for the board management controller found > > on > > the Kontron SMARC-sAL28 board. > > > > Signed-off-by: Michael Walle > > Reviewed-by: Rob Herring > > --- > > Changes since v5: > > - none > > > > Changes since v4: > > - fix the regex of the unit-address > > > > Changes since v3: > > - see cover letter > > > > .../bindings/gpio/kontron,sl28cpld-gpio.yaml | 54 +++ > > .../hwmon/kontron,sl28cpld-hwmon.yaml | 27 > > .../kontron,sl28cpld-intc.yaml| 54 +++ > > .../bindings/mfd/kontron,sl28cpld.yaml| 153 > > ++ > > .../bindings/pwm/kontron,sl28cpld-pwm.yaml| 35 > > .../watchdog/kontron,sl28cpld-wdt.yaml| 35 > > 6 files changed, 358 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > > create mode 100644 > > Documentation/devicetree/bindings/hwmon/kontron,sl28cpld-hwmon.yaml > > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/kontron,sl28cpld-intc.yaml > > create mode 100644 > > Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml > > create mode 100644 > > Documentation/devicetree/bindings/pwm/kontron,sl28cpld-pwm.yaml > > create mode 100644 > > Documentation/devicetree/bindings/watchdog/kontron,sl28cpld-wdt.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > > b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > > new file mode 100644 > > index ..9a63a158a796 > > --- /dev/null > > +++ > > b/Documentation/devicetree/bindings/gpio/kontron,sl28cpld-gpio.yaml > > @@ -0,0 +1,54 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/gpio/kontron,sl28cpld-gpio.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: GPIO driver for the sl28cpld board management controller > > + > > +maintainers: > > + - Michael Walle > > + > > +description: | > > + This module is part of the sl28cpld multi-function device. For more > > + details see > > Documentation/devicetree/bindings/mfd/kontron,sl28cpld.yaml. > > Paths are normally relative. grep Documentation/ Documentation I know there are a lot false positives (esp in the first one).. $ grep -r "\.\./" Documentation | wc -l 1826 $ grep -r "Documentation/" Documentation|wc -l 2862 I actually meant just for Device Tree bindings, but it does appear that 'Documentation' is used a bunch there too. My reasons for not liking full paths is that the intention was always to move 'Documentation/devicetree' to a new location outside of the kernel source tree. I see. I'll change that. > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/mfd/kontron,sl28cpld.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Kontron's sl28cpld board management controller > > "S128CPLD" ? still not, its sl28cpld, think of a project/code name, not the product appended with CPLD. > "Board Management Controller (BMC)" ? sounds like IPMI, which I wanted to avoid. Is there a datasheet? No there isn't. > > +maintainers: > > + - Michael Walle > > + > > +description: | > > + The board management controller may contain different IP blocks > > like > > + watchdog, fan monitoring, PWM controller, interrupt controller > > and a > > + GPIO controller. > > + > > +properties: > > + compatible: > > +const: kontron,sl28cpld-r1 > > We don't usually code revision numbers in compatible strings. > > Is there any way to pull this from the H/W? No, unfortunately you can't. And I really want to keep that, in case in the future there are some backwards incompatible changes. Rob, I know you reviewed this already, but you can give your opinion on this specifically please? I know that we have pushed back on this in the past. Oh, come one. That is an arbitrary string. "sl28cpld-r1" is the first implementation of this. A future "sl28cpld-r2" might look completely different and might not suite the simple MFD at all. "sl28cpld" is a made up name - as "sl28cpld-r1" is, too. -michael
Re: [PATCH] MIPS: qi_lb60: Fix routing to audio amplifier
On Mon, Jul 27, 2020 at 08:11:28PM +0200, Paul Cercueil wrote:
> The ROUT (right channel output of audio codec) was connected to INL
> (left channel of audio amplifier) instead of INR (right channel of audio
> amplifier).
>
> Fixes: 8ddebad15e9b ("MIPS: qi_lb60: Migrate to devicetree")
> Cc: sta...@vger.kernel.org # v5.3
> Signed-off-by: Paul Cercueil
> ---
> arch/mips/boot/dts/ingenic/qi_lb60.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
Re: [PATCH v3 1/5] of_address: Add bus type match for pci ranges parser
On Mon, Jul 27, 2020 at 11:50:14AM -0600, Rob Herring wrote: > On Fri, Jul 24, 2020 at 7:45 PM Jiaxun Yang wrote: > > > > So the parser can be used to parse range property of ISA bus. > > > > As they're all using PCI-like method of range property, there is no need > > start a new parser. > > > > Signed-off-by: Jiaxun Yang > > > > -- > > v2: Drop useless check, fix some na for bus_addr > > add define of of_range_parser_init according to > > Rob's suggestion. > > v3: Abstract out has_flags. simplify define. > > --- > > drivers/of/address.c | 29 + > > include/linux/of_address.h | 4 > > 2 files changed, 21 insertions(+), 12 deletions(-) > > Reviewed-by: Rob Herring Rob, are you ok with merging this via the mips-next tree ? Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
