Re: [PATCH 2/3] perf metricgroup: Fix uncore metric expressions
On Thu, Sep 10, 2020 at 12:41 PM Ian Rogers wrote: > > On Wed, Sep 9, 2020 at 10:52 AM Ian Rogers wrote: > > > > On Wed, Sep 9, 2020 at 2:53 AM Namhyung Kim wrote: > > > > > > Hi Ian, > > > > > > On Wed, Sep 9, 2020 at 5:02 PM Ian Rogers wrote: > > > > > > > > A metric like DRAM_BW_Use has on SkylakeX events > > > > uncore_imc/cas_count_read/ > > > > and uncore_imc/case_count_write/. These events open 6 events per socket > > > > with pmu names of uncore_imc_[0-5]. The current metric setup code in > > > > find_evsel_group assumes one ID will map to 1 event to be recorded in > > > > metric_events. For events with multiple matches, the first event is > > > > recorded in metric_events (avoiding matching >1 event with the same > > > > name) and the evlist_used updated so that duplicate events aren't > > > > removed when the evlist has unused events removed. > > > > > > > > Before this change: > > > > $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1 > > > > > > > > Performance counter stats for 'system wide': > > > > > > > > 41.14 MiB uncore_imc/cas_count_read/ > > > > 1,002,614,251 ns duration_time > > > > > > > >1.002614251 seconds time elapsed > > > > > > > > After this change: > > > > $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1 > > > > > > > > Performance counter stats for 'system wide': > > > > > > > > 157.47 MiB uncore_imc/cas_count_read/ # 0.00 > > > > DRAM_BW_Use > > > > > > Hmm.. I guess the 0.00 result is incorrect, no? > > > > Agreed. There are a number of pre-existing bugs in this code. I'll try > > to look into this one. > > There was a bug where the metric_leader wasn't being set correctly and > so the accumulation of values wasn't working as expected. There's a > small fix in: > https://lore.kernel.org/lkml/20200910032632.511566-3-irog...@google.com/T/#u > that also does the change I mentioned below. > > The metric still remains at 0.0 following this change as I believe > there is a bug in the metric. The metric expression is: > "( 64 * ( uncore_imc@cas_count_read@ + uncore_imc@cas_count_write@ ) / > 10 ) / duration_time" > ie the counts of uncore_imc/cas_count_read/ and > uncore_imc/cas_count_write/ are being first being scaled up by 64, > that is to turn a count of cache lines into bytes, the count is then > divided by 10 or a GB to supposedly give GB/s. However, the > counts are read and scaled: > > ... > void perf_stat__update_shadow_stats(struct evsel *counter, u64 count, > ... > count *= counter->scale; > ... > > The scale value from > /sys/devices/uncore_imc_0/events/cas_count_read.scale is > 6.103515625e-5 or 64/(1024*1024). This means the result of the > expression is 64 times too large but in PB/s and so too small to > display. I don't rule out there being other issues but this appears to > be a significant one. Printing using intervals also looks suspicious > as the count appears to just increase rather than vary up and down. You're right! Maybe we can change it to simply like below and change the unit to MiB/s? ( uncore_imc@cas_count_read@ + uncore_imc@cas_count_write@ ) / duration_time Thanks Namhyung
[PATCH v3 2/2] idr: Document that ida_simple_{get,remove}() are deprecated
These two functions are deprecated. Users should call ida_alloc() or ida_free() respectively instead. Add documentation to this effect until the macro can be removed. Cc: Greg KH Reviewed-by: Tri Vo Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org Cc: Matthew Wilcox Signed-off-by: Stephen Boyd --- include/linux/idr.h | 4 1 file changed, 4 insertions(+) diff --git a/include/linux/idr.h b/include/linux/idr.h index b235ed987021..a0dce14090a9 100644 --- a/include/linux/idr.h +++ b/include/linux/idr.h @@ -314,6 +314,10 @@ static inline void ida_init(struct ida *ida) xa_init_flags(>xa, IDA_INIT_FLAGS); } +/* + * ida_simple_get() and ida_simple_remove() are deprecated. Use + * ida_alloc() and ida_free() instead respectively. + */ #define ida_simple_get(ida, start, end, gfp) \ ida_alloc_range(ida, start, (end) - 1, gfp) #define ida_simple_remove(ida, id) ida_free(ida, id) -- Sent by a computer, using git, on the internet
[PATCH v3 1/2] idr: Document calling context for IDA APIs mustn't use locks
The documentation for these functions indicates that callers don't need
to hold a lock while calling them, but that documentation is only in one
place under "IDA Usage". Let's state the same information on each IDA
function so that it's clear what the calling context requires.
Furthermore, let's document ida_simple_get() with the same information
so that callers know how this API works.
Cc: Greg KH
Cc: Tri Vo
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: Matthew Wilcox
Signed-off-by: Stephen Boyd
---
include/linux/idr.h | 9 ++---
lib/idr.c | 9 ++---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/include/linux/idr.h b/include/linux/idr.h
index 3ade03e5c7af..b235ed987021 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -263,7 +263,8 @@ void ida_destroy(struct ida *ida);
*
* Allocate an ID between 0 and %INT_MAX, inclusive.
*
- * Context: Any context.
+ * Context: Any context. It is safe to call this function without
+ * locking in your code.
* Return: The allocated ID, or %-ENOMEM if memory could not be allocated,
* or %-ENOSPC if there are no free IDs.
*/
@@ -280,7 +281,8 @@ static inline int ida_alloc(struct ida *ida, gfp_t gfp)
*
* Allocate an ID between @min and %INT_MAX, inclusive.
*
- * Context: Any context.
+ * Context: Any context. It is safe to call this function without
+ * locking in your code.
* Return: The allocated ID, or %-ENOMEM if memory could not be allocated,
* or %-ENOSPC if there are no free IDs.
*/
@@ -297,7 +299,8 @@ static inline int ida_alloc_min(struct ida *ida, unsigned
int min, gfp_t gfp)
*
* Allocate an ID between 0 and @max, inclusive.
*
- * Context: Any context.
+ * Context: Any context. It is safe to call this function without
+ * locking in your code.
* Return: The allocated ID, or %-ENOMEM if memory could not be allocated,
* or %-ENOSPC if there are no free IDs.
*/
diff --git a/lib/idr.c b/lib/idr.c
index c2cf2c52bbde..3fa8be43696f 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -372,7 +372,8 @@ EXPORT_SYMBOL(idr_replace);
* Allocate an ID between @min and @max, inclusive. The allocated ID will
* not exceed %INT_MAX, even if @max is larger.
*
- * Context: Any context.
+ * Context: Any context. It is safe to call this function without
+ * locking in your code.
* Return: The allocated ID, or %-ENOMEM if memory could not be allocated,
* or %-ENOSPC if there are no free IDs.
*/
@@ -479,7 +480,8 @@ EXPORT_SYMBOL(ida_alloc_range);
* @ida: IDA handle.
* @id: Previously allocated ID.
*
- * Context: Any context.
+ * Context: Any context. It is safe to call this function without
+ * locking in your code.
*/
void ida_free(struct ida *ida, unsigned int id)
{
@@ -531,7 +533,8 @@ EXPORT_SYMBOL(ida_free);
* or freed. If the IDA is already empty, there is no need to call this
* function.
*
- * Context: Any context.
+ * Context: Any context. It is safe to call this function without
+ * locking in your code.
*/
void ida_destroy(struct ida *ida)
{
base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
--
Sent by a computer, using git, on the internet
[PATCH v3 0/8] Add PHY USB3 drivers for Hikey 970
This patch series add the PHY layer needed in order to support the USB functionality on Hikey 970 boards. v3: - split a namespace patch on two (one with code changes and another one with dt-bindings changes); - placed just the PHY driver on this series. Another series will add the USB HUB driver and the DTS changes required to enable USB support for this board. Mauro Carvalho Chehab (6): phy: hisilicon: phy-hi3670-usb3: use a consistent namespace dts: phy: phy-hi3670-usb3.txt: use a consistent namespace phy: hisilicon: phy-hi3670-usb3: fix coding style phy: hisilicon: phy-hi3670-usb3: change some DT properties dt-bindings: phy: convert phy-kirin970-usb3.txt to yaml MAINTAINERS: add myself as maintainer for Kirin 970 USB PHY Yu Chen (2): phy: hisilicon: add USB physical layer for Kirin 3670 phy: hisilicon: phy-hi3670-usb3: fix some issues at the init code .../bindings/phy/hisilicon,hi3670-usb3.yaml | 72 ++ MAINTAINERS | 9 +- drivers/phy/hisilicon/Kconfig | 10 + drivers/phy/hisilicon/Makefile| 1 + drivers/phy/hisilicon/phy-hi3670-usb3.c | 671 ++ 5 files changed, 762 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml create mode 100644 drivers/phy/hisilicon/phy-hi3670-usb3.c -- 2.26.2
[PATCH] taskstats: fix CGROUPSTATS_CMD_GET for cgroup v2
We found cgroupstats_build would return -EINVAL when using netlink
CGROUPSTATS_CMD_GET interface to get stats on cgroup v2. Fix it by
supporting cgroup v2 kernfs directory in cgroupstats_build, and export
cgroup2_fs_type like we did for cgroup_fs_type.
Reported-by: Daowen Luo
Tested-by: Chengming Zhou
Signed-off-by: Chengming Zhou
---
kernel/cgroup/cgroup-internal.h | 1 +
kernel/cgroup/cgroup-v1.c | 5 +++--
kernel/cgroup/cgroup.c | 3 +--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index bfbeabc17a9d..9ca05fb513c2 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -151,6 +151,7 @@ extern spinlock_t css_set_lock;
extern struct cgroup_subsys *cgroup_subsys[];
extern struct list_head cgroup_roots;
extern struct file_system_type cgroup_fs_type;
+extern struct file_system_type cgroup2_fs_type;
/* iterate across the hierarchies */
#define for_each_root(root)\
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 191c329e482a..6d9e9b553276 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -686,13 +686,14 @@ int proc_cgroupstats_show(struct seq_file *m, void *v)
int cgroupstats_build(struct cgroupstats *stats, struct dentry *dentry)
{
struct kernfs_node *kn = kernfs_node_from_dentry(dentry);
+ struct file_system_type *s_type = dentry->d_sb->s_type;
struct cgroup *cgrp;
struct css_task_iter it;
struct task_struct *tsk;
/* it should be kernfs_node belonging to cgroupfs and is a directory */
- if (dentry->d_sb->s_type != _fs_type || !kn ||
- kernfs_type(kn) != KERNFS_DIR)
+ if ((s_type != _fs_type && s_type != _fs_type) ||
+ !kn || kernfs_type(kn) != KERNFS_DIR)
return -EINVAL;
mutex_lock(_mutex);
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index dd247747ec14..0e23ae3b1e56 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -206,7 +206,6 @@ struct cgroup_namespace init_cgroup_ns = {
.root_cset = _css_set,
};
-static struct file_system_type cgroup2_fs_type;
static struct cftype cgroup_base_files[];
static int cgroup_apply_control(struct cgroup *cgrp);
@@ -2162,7 +2161,7 @@ struct file_system_type cgroup_fs_type = {
.fs_flags = FS_USERNS_MOUNT,
};
-static struct file_system_type cgroup2_fs_type = {
+struct file_system_type cgroup2_fs_type = {
.name = "cgroup2",
.init_fs_context= cgroup_init_fs_context,
.parameters = cgroup2_fs_parameters,
--
2.11.0
Re: [PATCH -next] soundwire: intel: Remove ununsed function
On 09-09-20, 08:46, Pierre-Louis Bossart wrote: > > > On 9/9/20 8:15 AM, YueHaibing wrote: > > If CONFIG_PM is not set, build warns: > > > > drivers/soundwire/intel.c:488:12: warning: 'intel_link_power_down' defined > > but not used [-Wunused-function] > > > > Move this to #ifdef block. > > Yes, thanks for the report, it's a valid issue, but maybe the fix is to add > __maybe_unused more consistently and remove the CONFIG_PM dependency. > > Vinod, what would you prefer? __maybe_unused is the recommendation, it should be updated to use that Thanks -- ~Vinod
Re: [PATCH v4 3/4] mm/pageblock: work around multiple arch's cmpxchg support issue
On Thu, Sep 03, 2020 at 03:01:22PM +0800, Alex Shi wrote: > Armv6, sh2, sparc32 and xtensa can not do cmpxchg1, so we have to use > cmpxchg4 on it. > > Here we mark above 4 arch's NO_CMPXCHG_BYTE, and would add more if we > found. > > This is the first usages of cmpxchg flase sharing change. We'd better > check more cmpxchg usages in current kernel... I think a positive symbol, e.g. HAVE_CMPXCHG_BYTE is a lot easier to understand, and also fool-proof.
Re: [PATCH v2 3/3] perf metricgroup: Fix uncore metric expressions
On Thu, Sep 10, 2020 at 12:26 PM Ian Rogers wrote:
>
> A metric like DRAM_BW_Use has on SkylakeX events uncore_imc/cas_count_read/
> and uncore_imc/case_count_write/. These events open 6 events per socket
> with pmu names of uncore_imc_[0-5]. The current metric setup code in
> find_evsel_group assumes one ID will map to 1 event to be recorded in
> metric_events. For events with multiple matches, the first event is
> recorded in metric_events (avoiding matching >1 event with the same
> name) and the evlist_used updated so that duplicate events aren't
> removed when the evlist has unused events removed.
>
> Before this change:
> $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1
>
> Performance counter stats for 'system wide':
>
> 41.14 MiB uncore_imc/cas_count_read/
> 1,002,614,251 ns duration_time
>
>1.002614251 seconds time elapsed
>
> After this change:
> $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1
>
> Performance counter stats for 'system wide':
>
> 157.47 MiB uncore_imc/cas_count_read/ # 0.00 DRAM_BW_Use
> 126.97 MiB uncore_imc/cas_count_write/
> 1,003,019,728 ns duration_time
>
> v2. avoids iterating over the whole evlist as suggested by
> namhy...@kernel.org. It also fixes the metric_leader computation
> that was broken in the same commits.
>
> Erroneous duplication introduced in:
> commit 2440689d62e9 ("perf metricgroup: Remove duped metric group events").
>
> Fixes: ded80bda8bc9 ("perf expr: Migrate expr ids table to a hashmap").
> Reported-by: Jin Yao
> Signed-off-by: Ian Rogers
> ---
> tools/perf/util/metricgroup.c | 45 ---
> 1 file changed, 42 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
> index 662f4e8777d5..79080de9217d 100644
> --- a/tools/perf/util/metricgroup.c
> +++ b/tools/perf/util/metricgroup.c
> @@ -206,6 +206,18 @@ static struct evsel *find_evsel_group(struct evlist
> *perf_evlist,
> sizeof(struct evsel *) * idnum);
> current_leader = ev->leader;
> }
> + /*
> +* Check for duplicate events with the same name. For example,
> +* uncore_imc/cas_count_read/ will turn into 6 events per
> socket
> +* on skylakex. Only the first such event is placed in
> +* metric_events.
> +*/
> + for (i = 0; i < matched_events; i++) {
> + if (!strcmp(metric_events[i]->name, ev->name))
> + break;
> + }
> + if (i != matched_events)
> + continue;
We have the same logic in the below. Maybe it'd better to factor out..
> if (hashmap__find(>ids, ev->name, (void **)_ptr)) {
> if (has_constraint) {
> /*
> @@ -245,9 +257,36 @@ static struct evsel *find_evsel_group(struct evlist
> *perf_evlist,
> metric_events[idnum] = NULL;
>
> for (i = 0; i < idnum; i++) {
> - ev = metric_events[i];
> - ev->metric_leader = ev;
> - set_bit(ev->idx, evlist_used);
> + /* Don't free used events. */
> + set_bit(metric_events[i]->idx, evlist_used);
> + /*
> +* The metric leader points to the identically named event in
> +* metric_events.
> +*/
> + metric_events[i]->metric_leader = metric_events[i];
> + /*
> +* Mark two events with identical names in the same group (or
> +* globally) as being in use as uncore events may be
> duplicated
> +* for each pmu. Set the metric leader to be the event that
> +* appears in metric_events.
> +*/
I thought this again, and it's not guaranteed that the metric leader is
a group leader so below won't work IMHO. Instead we should iterate
evlist always, but started from the metric leader with the
evlist__for_each_entry_continue.
Thanks
Namhyung
> + if (!has_constraint) {
> + for_each_group_evsel(ev, metric_events[i]->leader) {
> + if (ev != metric_events[i] &&
> + !strcmp(metric_events[i]->name,
> ev->name)) {
> + set_bit(ev->idx, evlist_used);
> + ev->metric_leader = metric_events[i];
> + }
> + }
> + } else {
> + evlist__for_each_entry(perf_evlist, ev) {
> + if (ev != metric_events[i] &&
> + !strcmp(metric_events[i]->name,
> ev->name)) {
> +
Re: [PATCH v2 0/7] ASoC/soundwire: filter out invalid PARITY errors
On 08-09-20, 21:45, Bard Liao wrote: > Some codecs may report fake PARITY errors in the initial state. This > series will filter them out. Applied, thanks -- ~Vinod
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On Wed, Sep 09, 2020 at 01:34:18PM -0600, James Hilliard wrote:
> This patch detects and reverses the effects of the malicious FTDI
> Windows driver version 2.12.00(FTDIgate).
>
> While we currently load the ftdi_sio driver for devices with
> FTDI_BRICK_PID(0x) userspace applications that expect the
> appropriate FTDI_8U232AM_PID(0x6001) PID may not work properly.
>
> Since the malicious FTDI driver modifies the PID without modifying
> the normal checksum field we can detect and limit the unbricking
> to devices that were bricked specifically using the FTDI checksum
> preimage attack technique used by the official Windows drivers.
>
> This should have no effect on devices where the PID was deliberately
> set to FTDI_BRICK_PID(0x) as the checksum would normally change
> and the preimage target(address 62) should be 0. We validate that
> the preimage target is not 0 before attempting to unbrick.
>
> Since we only write to even addresses this should have no effect at
> all on non-counterfeit FTDI hardware due to the hardware only
> committing EEPROM writes when odd addresses are written.
>
> References:
> https://marcan.st/transf/detect_ftdi_clone.py
> https://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/
> https://www.eevblog.com/forum/reviews/ftdi-driver-kills-fake-ftdi-ft232/msg535270/#msg535270
> https://lkml.org/lkml/2014/10/23/266
> https://lore.kernel.org/patchwork/patch/509929/
> https://lore.kernel.org/patchwork/patch/510097/
>
> Signed-off-by: Russ Dill
> Signed-off-by: James Hilliard
> Cc: Hector Martin
> ---
> Changes v1 -> v2:
> - Move ftdi_read_eeprom and ftdi_write_eeprom outside #ifdef CONFIG_GPIOLIB
> ---
> drivers/usb/serial/ftdi_sio.c | 181 +++---
> drivers/usb/serial/ftdi_sio.h | 4 +
> 2 files changed, 152 insertions(+), 33 deletions(-)
This is interesting, but not something that is really needed on a Linux
machine right? The "bricked" devices work just fine on Linux, and Linux
does not cause these devices to ever be "bricked", so why build into the
Linux kernel an option that only is needed by another operating system?
If you have "bricked" devices, you can use the userspace tool to fix
them up so that they can work properly on other operating systems, as a
utility. But to build this into Linux feels very odd to me.
That being said, code review:
>
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 871cdccf3a5f..85324e2ea107 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1062,6 +1062,9 @@ static const char *ftdi_chip_name[] = {
> /* function prototypes for a FTDI serial converter */
> static int ftdi_sio_probe(struct usb_serial *serial,
> const struct usb_device_id *id);
> +static int ftdi_read_eeprom(struct usb_serial *serial, void *dst, u16 addr,
> + u16 nbytes);
No need for this, just keep this function in the same place in the file,
right?
> +static int ftdi_write_eeprom(struct usb_serial_port *port, u8 addr, u16
> data);
> static int ftdi_sio_port_probe(struct usb_serial_port *port);
> static int ftdi_sio_port_remove(struct usb_serial_port *port);
> static int ftdi_open(struct tty_struct *tty, struct usb_serial_port *port);
> @@ -1996,39 +1999,6 @@ static int ftdi_gpio_direction_output(struct gpio_chip
> *gc, unsigned int gpio,
> return result;
> }
>
> -static int ftdi_read_eeprom(struct usb_serial *serial, void *dst, u16 addr,
> - u16 nbytes)
> -{
> - int read = 0;
> -
> - if (addr % 2 != 0)
> - return -EINVAL;
> - if (nbytes % 2 != 0)
> - return -EINVAL;
> -
> - /* Read EEPROM two bytes at a time */
> - while (read < nbytes) {
> - int rv;
> -
> - rv = usb_control_msg(serial->dev,
> - usb_rcvctrlpipe(serial->dev, 0),
> - FTDI_SIO_READ_EEPROM_REQUEST,
> - FTDI_SIO_READ_EEPROM_REQUEST_TYPE,
> - 0, (addr + read) / 2, dst + read, 2,
> - WDR_TIMEOUT);
> - if (rv < 2) {
> - if (rv >= 0)
> - return -EIO;
> - else
> - return rv;
> - }
> -
> - read += rv;
> - }
> -
> - return 0;
> -}
Why move this function?
> -
> static int ftdi_gpio_init_ft232h(struct usb_serial_port *port)
> {
> struct ftdi_private *priv = usb_get_serial_port_data(port);
> @@ -2234,10 +2204,149 @@ static int ftdi_sio_probe(struct usb_serial *serial,
> return 0;
> }
>
> +static int ftdi_read_eeprom(struct usb_serial *serial, void *dst, u16 addr,
> + u16 nbytes)
> +{
> + int read = 0;
> +
> + if (addr % 2 !=
Re: [RESEND PATCH v2 2/2] drm/mediatek: mtk_dpi: Convert to bridge driver
On Thu, Sep 10, 2020 at 06:35:21AM +0800, Chun-Kuang Hu wrote:
> Hi, Andrzej & Neil:
>
> Enric Balletbo i Serra 於 2020年8月26日 週三
> 下午4:53寫道：
>
> >
> > Convert mtk_dpi to a bridge driver with built-in encoder support for
> > compatibility with existing component drivers.
> >
>
> This is a DRM-bridge related patch, how do you think about it?
bridge stuff is also maintained in drm-misc, so good to go imo.
For the bigger picture I think it'd be really good if bridges drivers
would use the of bridge lookup, and not hand roll something with
component. So 2nd step of converting this over to a proper bridge driver
would be to replace the component code here too.
Cheers, Daniel
>
> Regards,
> Chun-Kuang.
>
> > Reviewed-by: Chun-Kuang Hu
> > Signed-off-by: Enric Balletbo i Serra
> > ---
> >
> > Changes in v2:
> > - Maintain error message when attach to bridge fails. (Boris)
> >
> > drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++
> > 1 file changed, 42 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > index f7372dbdac0e..589ef33a1780 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> > @@ -64,6 +64,7 @@ enum mtk_dpi_out_color_format {
> > struct mtk_dpi {
> > struct mtk_ddp_comp ddp_comp;
> > struct drm_encoder encoder;
> > + struct drm_bridge bridge;
> > struct drm_bridge *next_bridge;
> > void __iomem *regs;
> > struct device *dev;
> > @@ -83,9 +84,9 @@ struct mtk_dpi {
> > int refcount;
> > };
> >
> > -static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
> > +static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
> > {
> > - return container_of(e, struct mtk_dpi, encoder);
> > + return container_of(b, struct mtk_dpi, bridge);
> > }
> >
> > enum mtk_dpi_polarity {
> > @@ -521,50 +522,53 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi
> > *dpi,
> > return 0;
> > }
> >
> > -static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
> > - const struct drm_display_mode *mode,
> > - struct drm_display_mode
> > *adjusted_mode)
> > +static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
> > {
> > - return true;
> > + drm_encoder_cleanup(encoder);
> > }
> >
> > -static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
> > -struct drm_display_mode *mode,
> > -struct drm_display_mode *adjusted_mode)
> > +static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
> > + .destroy = mtk_dpi_encoder_destroy,
> > +};
> > +
> > +static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
> > +enum drm_bridge_attach_flags flags)
> > {
> > - struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
> > + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> > +
> > + return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
> > +>bridge, flags);
> > +}
> > +
> > +static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
> > + const struct drm_display_mode *mode,
> > + const struct drm_display_mode
> > *adjusted_mode)
> > +{
> > + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> >
> > drm_mode_copy(>mode, adjusted_mode);
> > }
> >
> > -static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
> > +static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
> > {
> > - struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
> > + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> >
> > mtk_dpi_power_off(dpi);
> > }
> >
> > -static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
> > +static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
> > {
> > - struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
> > + struct mtk_dpi *dpi = bridge_to_dpi(bridge);
> >
> > mtk_dpi_power_on(dpi);
> > mtk_dpi_set_display_mode(dpi, >mode);
> > }
> >
> > -static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
> > - struct drm_crtc_state *crtc_state,
> > - struct drm_connector_state *conn_state)
> > -{
> > - return 0;
> > -}
> > -
> > -static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs
> > = {
> > - .mode_fixup = mtk_dpi_encoder_mode_fixup,
> > - .mode_set = mtk_dpi_encoder_mode_set,
> > - .disable = mtk_dpi_encoder_disable,
> > - .enable = mtk_dpi_encoder_enable,
> > - .atomic_check = mtk_dpi_atomic_check,
> > +static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
> > + .attach = mtk_dpi_bridge_attach,
> > +
[PATCH 2/2] arm64: dts: mt8183: kukui: Set uart0 to mmio32 iotype
Set uart0 iotype to mmio32 to make earlycon work with stdout-path.
Signed-off-by: Hsin-Yi Wang
---
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index f0a070535b340..f6991bdaac1c6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -750,6 +750,8 @@ {
{
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
status = "okay";
};
--
2.28.0.526.ge36021eeef-goog
[PATCH 1/2] arm64: dts: mt8173: elm: Set uart0 to mmio32 iotype
Set uart0 iotype to mmio32 to make earlycon work with stdout-path.
Signed-off-by: Hsin-Yi Wang
---
arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
index a5a12b2599a4a..d54e62f72c65d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi
@@ -1160,6 +1160,8 @@ {
};
{
+ reg-io-width = <4>;
+ reg-shift = <2>;
status = "okay";
};
--
2.28.0.526.ge36021eeef-goog
Re: [PATCH -next] drm/bridge/tc358775: Remove unneeded semicolon
On Wed, Sep 09, 2020 at 08:19:00PM +0800, Zheng Bin wrote:
> Fixes coccicheck warning:
>
> drivers/gpu/drm/bridge/tc358775.c:488:2-3: Unneeded semicolon
>
> Signed-off-by: Zheng Bin
Queued for 5.10, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/bridge/tc358775.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358775.c
> b/drivers/gpu/drm/bridge/tc358775.c
> index d951cdc58297..2272adcc5b4a 100644
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -485,7 +485,7 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> val |= TC358775_LVCFG_PCLKDIV(DIVIDE_BY_6);
> } else {
> val |= TC358775_LVCFG_PCLKDIV(DIVIDE_BY_3);
> - };
> + }
> d2l_write(tc->i2c, LVCFG, val);
> }
>
> --
> 2.26.0.106.g9fadedd
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2 0/2] MTE support for KVM guest
On Wed, Sep 09, 2020 at 06:45:33PM -0700, Richard Henderson wrote: > On 9/9/20 8:25 AM, Andrew Jones wrote: > >> * Provide a KVM-specific method to extract the tags from guest memory. > >>This might also have benefits in terms of providing an easy way to > >>read bulk tag data from guest memory (since the LDGM instruction > >>isn't available at EL0). > > > > Maybe we need a new version of KVM_GET_DIRTY_LOG that also provides > > the tags for all addresses of each dirty page. > > KVM_GET_DIRTY_LOG just provides one bit per dirty page, no? Then VMM copies > the data out from its local address to guest memory. > > There'd be no difference with or without tags, afaik. It's just about how VMM > copies the data, with or without tags. Right, as long as it's fast enough to do for_each_dirty_page(page, dirty_log) for (i = 0; i < host-page-size/16; i += 16) append_tag(LDG(page + i)) to get all the tags for each dirty page. I understood it would be faster to use LDGM, but we'd need a new ioctl for that. So I was proposing we just piggyback on a new dirty-log ioctl instead. Thanks, drew
Re: linux-next: Tree for Aug 26
On Thu, Sep 10, 2020 at 02:14:32PM +1000, Stephen Rothwell wrote: > Hi all, > > On Mon, 7 Sep 2020 10:55:47 +0200 Anders Roxell > wrote: > > > > On Thu, 3 Sep 2020 at 18:14, Paul E. McKenney wrote: > > > > > > On Thu, Sep 03, 2020 at 10:39:10AM +0200, Anders Roxell wrote: > > > > Hi Paul, > > > > > > > > On Sat, 29 Aug 2020 at 00:59, Paul E. McKenney > > > > wrote: > > > > > > > > > > On Fri, Aug 28, 2020 at 09:24:19PM +0200, Anders Roxell wrote: > > > > > > On Fri, 28 Aug 2020 at 15:29, Paul E. McKenney > > > > > > wrote: > > > > > > > > > > > > > > On Fri, Aug 28, 2020 at 09:37:17AM +0200, Anders Roxell wrote: > > > > > > > > On Wed, 26 Aug 2020 at 21:39, Paul E. McKenney > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Aug 26, 2020 at 08:19:01PM +0200, Anders Roxell > > > > > > > > > wrote: > > > > > > > > > > On Wed, 26 Aug 2020 at 08:33, Stephen Rothwell > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > > > > > > > I've built and run an arm64 allmodconfig kernel where I use > > > > > > > > > > the > > > > > > > > > > defconfig as the base, I do this for testing purposes. > > > > > > > > > > I can see the following call trace [1]: > > > > > > > > > > > > > > > > > > > > [ 2595.811453][T1] Running tests on all trace events: > > > > > > > > > > [ 2595.860933][T1] Testing all events: > > > > > > > > > > [ 4316.066072][T8] kworker/dying (8) used greatest > > > > > > > > > > stack depth: > > > > > > > > > > 27056 bytes left > > > > > > > > > > [ 8561.924871][C0] watchdog: BUG: soft lockup - CPU#0 > > > > > > > > > > stuck for > > > > > > > > > > 22s! [migration/0:14] > > > > > > > > > > [ 8561.934498][C0] Modules linked in: > > > > > > > > > > [ 8561.942303][C0] irq event stamp: 4044 > > > > > > > > > > [ 8561.949044][C0] hardirqs last enabled at (4043): > > > > > > > > > > [] _raw_spin_unlock_irqrestore+0xac/0x138 > > > > > > > > > > [ 8561.960848][C0] hardirqs last disabled at (4044): > > > > > > > > > > [] __schedule+0xf8/0x7e0 > > > > > > > > > > [ 8561.971418][C0] softirqs last enabled at (3698): > > > > > > > > > > [] __do_softirq+0x524/0x5f8 > > > > > > > > > > [ 8561.982191][C0] softirqs last disabled at (3689): > > > > > > > > > > [] __irq_exit_rcu+0x128/0x1a0 > > > > > > > > > > [ 8561.993068][C0] CPU: 0 PID: 14 Comm: migration/0 > > > > > > > > > > Tainted: G > > > > > > > > > >W 5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1 > > > > > > > > > > [ 8562.005684][C0] Hardware name: linux,dummy-virt (DT) > > > > > > > > > > [ 8562.013247][C0] pstate: 8045 (Nzcv daif +PAN > > > > > > > > > > -UAO BTYPE=--) > > > > > > > > > > [ 8562.021657][C0] pc : arch_local_irq_enable+0x58/0x80 > > > > > > > > > > [ 8562.029323][C0] lr : _raw_spin_unlock_irq+0x84/0xc0 > > > > > > > > > > [ 8562.036739][C0] sp : 698efaa0 > > > > > > > > > > [ 8562.042984][C0] x29: 698efaa0 x28: > > > > > > > > > > 6ad0f270 > > > > > > > > > > [ 8562.053814][C0] x27: 6ad0f248 x26: > > > > > > > > > > 698d4718 > > > > > > > > > > [ 8562.064687][C0] x25: 6ad0e798 x24: > > > > > > > > > > a000139e3a40 > > > > > > > > > > [ 8562.075506][C0] x23: 0001 x22: > > > > > > > > > > a000154f5000 > > > > > > > > > > [ 8562.086425][C0] x21: 6ad0e798 x20: > > > > > > > > > > 6ad0e780 > > > > > > > > > > [ 8562.097255][C0] x19: a000126a905c x18: > > > > > > > > > > 14c0 > > > > > > > > > > [ 8562.108071][C0] x17: 1500 x16: > > > > > > > > > > 1440 > > > > > > > > > > [ 8562.118918][C0] x15: f1f1f1f1 x14: > > > > > > > > > > 003d0900 > > > > > > > > > > [ 8562.129739][C0] x13: 3d09 x12: > > > > > > > > > > 8d31df41 > > > > > > > > > > [ 8562.140544][C0] x11: 1fffed31df40 x10: > > > > > > > > > > 8d31df40 > > > > > > > > > > [ 8562.151366][C0] x9 : dfffa000 x8 : > > > > > > > > > > 698efa07 > > > > > > > > > > [ 8562.162247][C0] x7 : 0001 x6 : > > > > > > > > > > 72ce20c0 > > > > > > > > > > [ 8562.173072][C0] x5 : 698d4040 x4 : > > > > > > > > > > dfffa000 > > > > > > > > > > [ 8562.183954][C0] x3 : a0001040f904 x2 : > > > > > > > > > > 0007 > > > > > > > > > > [ 8562.194811][C0] x1 : a0001408 x0 : > > > > > > > > > > 00e0 > > > > > > > > > > [ 8562.205858][C0] Call trace: > > > > > > > > > > [ 8562.211739][C0] arch_local_irq_enable+0x58/0x80 > > > > > > > > > > [ 8562.219076][C0] _raw_spin_unlock_irq+0x84/0xc0 > > > > > > > > > > [ 8562.226394][C0] __schedule+0x75c/0x7e0 > > > > > > > > > > [ 8562.233074][C0] preempt_schedule_notrace+0x64/0xc0 > > > > > > > > > > [ 8562.268210][C0]
[PATCH net v2] net: Clarify the difference between hard_header_len and needed_headroom
The difference between hard_header_len and needed_headroom has long been
confusing to driver developers. Let's clarify it.
The understanding on this issue in this patch is based on the following
reasons:
1.
In af_packet.c, the function packet_snd first reserves a headroom of
length (dev->hard_header_len + dev->needed_headroom).
Then if the socket is a SOCK_DGRAM socket, it calls dev_hard_header,
which calls dev->header_ops->create, to create the link layer header.
If the socket is a SOCK_RAW socket, it "un-reserves" a headroom of
length (dev->hard_header_len), and checks if the user has provided a
header of length (dev->hard_header_len) (in dev_validate_header).
This shows the developers of af_packet.c expect hard_header_len to
be consistent with header_ops.
2.
In af_packet.c, the function packet_sendmsg_spkt has a FIXME comment.
That comment states that prepending an LL header internally in a driver
is considered a bug. I believe this bug can be fixed by setting
hard_header_len to 0, making the internal header completely invisible
to af_packet.c (and requesting the headroom in needed_headroom instead).
3.
There is a commit for a WiFi driver:
commit 9454f7a895b8 ("mwifiex: set needed_headroom, not hard_header_len")
According to the discussion about it at:
https://patchwork.kernel.org/patch/11407493/
The author tried to set the WiFi driver's hard_header_len to the Ethernet
header length, and request additional header space internally needed by
setting needed_headroom. This means this usage is already adopted by
driver developers.
Cc: Willem de Bruijn
Cc: Eric Dumazet
Cc: Brian Norris
Cc: Cong Wang
Signed-off-by: Xie He
---
Change from v1:
Small change to the commit message.
---
include/linux/netdevice.h | 4 ++--
net/packet/af_packet.c| 19 +--
2 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 7bd4fcdd0738..3999b04e435d 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1691,8 +1691,8 @@ enum netdev_priv_flags {
* @min_mtu: Interface Minimum MTU value
* @max_mtu: Interface Maximum MTU value
* @type: Interface hardware type
- * @hard_header_len: Maximum hardware header length.
- * @min_header_len: Minimum hardware header length
+ * @hard_header_len: Maximum length of the headers created by header_ops
+ * @min_header_len: Minimum length of the headers created by header_ops
*
* @needed_headroom: Extra headroom the hardware may need, but not in all
* cases can this be guaranteed
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 2b33e977a905..0e324b08cb2e 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -93,12 +93,15 @@
/*
Assumptions:
- - if device has no dev->hard_header routine, it adds and removes ll header
- inside itself. In this case ll header is invisible outside of device,
- but higher levels still should reserve dev->hard_header_len.
- Some devices are enough clever to reallocate skb, when header
- will not fit to reserved space (tunnel), another ones are silly
- (PPP).
+ - If the device has no dev->header_ops, there is no LL header visible
+ above the device. In this case, its hard_header_len should be 0.
+ The device may prepend its own header internally. In this case, its
+ needed_headroom should be set to the space needed for it to add its
+ internal header.
+ For example, a WiFi driver pretending to be an Ethernet driver should
+ set its hard_header_len to be the Ethernet header length, and set its
+ needed_headroom to be (the real WiFi header length - the fake Ethernet
+ header length).
- packet socket receives packets with pulled ll header,
so that SOCK_RAW should push it back.
@@ -2937,10 +2940,14 @@ static int packet_snd(struct socket *sock, struct
msghdr *msg, size_t len)
skb_reset_network_header(skb);
err = -EINVAL;
+ if (!dev->header_ops)
+ WARN_ON_ONCE(dev->hard_header_len != 0);
if (sock->type == SOCK_DGRAM) {
offset = dev_hard_header(skb, dev, ntohs(proto), addr, NULL,
len);
if (unlikely(offset < 0))
goto out_free;
+ WARN_ON_ONCE(offset > dev->hard_header_len);
+ WARN_ON_ONCE(offset < dev->min_header_len);
} else if (reserve) {
skb_reserve(skb, -reserve);
if (len < reserve + sizeof(struct ipv6hdr) &&
--
2.25.1
[PATCH 3/3] dma-mapping: introduce DMA range map, supplanting dma_pfn_offset
From: Jim Quinlan
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
The function of_dma_get_range() has been modified so that it takes a single
argument -- the device node -- and returns a map, NULL, or an error code.
The map is an array that holds the information regarding the DMA regions.
Each range entry contains the address offset, the cpu_start address, the
dma_start address, and the size of the region.
of_dma_configure() is the typical manner to set range offsets but there are
a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
driver code. These cases now invoke the function
dma_attach_offset_range(dev, cpu_addr, dma_addr, size).
Signed-off-by: Jim Quinlan
[hch: various interface cleanups]
Signed-off-by: Christoph Hellwig
Tested-by: Nathan Chancellor
---
arch/arm/include/asm/dma-direct.h | 9 +--
arch/arm/mach-keystone/keystone.c | 17 ++--
arch/sh/drivers/pci/pcie-sh7786.c | 9 ++-
arch/x86/pci/sta2x11-fixup.c | 6 +-
drivers/acpi/arm64/iort.c | 6 +-
drivers/base/core.c | 2 +
drivers/gpu/drm/sun4i/sun4i_backend.c | 8 +-
drivers/iommu/io-pgtable-arm.c| 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 9 ++-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 11 ++-
drivers/of/address.c | 73 -
drivers/of/device.c | 44 ++
drivers/of/of_private.h | 11 +--
drivers/of/unittest.c | 34 +---
drivers/remoteproc/remoteproc_core.c | 4 +-
.../staging/media/sunxi/cedrus/cedrus_hw.c| 10 ++-
drivers/usb/core/message.c| 5 +-
drivers/usb/core/usb.c| 3 +-
include/linux/device.h| 4 +-
include/linux/dma-direct.h| 52 ++--
include/linux/dma-mapping.h | 19 -
kernel/dma/coherent.c | 7 +-
kernel/dma/direct.c | 81 ++-
23 files changed, 303 insertions(+), 123 deletions(-)
diff --git a/arch/arm/include/asm/dma-direct.h
b/arch/arm/include/asm/dma-direct.h
index de0f4ff9279615..a443d5257a21ed 100644
--- a/arch/arm/include/asm/dma-direct.h
+++ b/arch/arm/include/asm/dma-direct.h
@@ -16,8 +16,8 @@
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- if (dev)
- pfn -= dev->dma_pfn_offset;
+ if (dev && dev->dma_range_map)
+ pfn = PFN_DOWN(translate_phys_to_dma(dev, PFN_PHYS(pfn)));
return (dma_addr_t)__pfn_to_bus(pfn);
}
@@ -25,9 +25,8 @@ static inline unsigned long dma_to_pfn(struct device *dev,
dma_addr_t addr)
{
unsigned long pfn = __bus_to_pfn(addr);
- if (dev)
- pfn += dev->dma_pfn_offset;
-
+ if (dev && dev->dma_range_map)
+ pfn = PFN_DOWN(translate_dma_to_phys(dev, PFN_PHYS(pfn)));
return pfn;
}
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index dcd031ba84c2e0..09a65c2dfd7327 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -25,8 +26,6 @@
#include "keystone.h"
#ifdef CONFIG_ARM_LPAE
-static unsigned long keystone_dma_pfn_offset __read_mostly;
-
static int keystone_platform_notifier(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -39,9 +38,12 @@ static int keystone_platform_notifier(struct notifier_block
*nb,
return NOTIFY_BAD;
if (!dev->of_node) {
- dev->dma_pfn_offset = keystone_dma_pfn_offset;
- dev_err(dev, "set dma_pfn_offset%08lx\n",
- dev->dma_pfn_offset);
+ int ret = dma_direct_set_offset(dev, KEYSTONE_HIGH_PHYS_START,
+ KEYSTONE_LOW_PHYS_START,
+ KEYSTONE_HIGH_PHYS_SIZE);
+ dev_err(dev, "set dma_offset%08llx%s\n",
+ KEYSTONE_HIGH_PHYS_START - KEYSTONE_LOW_PHYS_START,
+ ret ? " failed" : "");
}
return NOTIFY_OK;
}
@@ -54,11 +56,8 @@ static struct notifier_block platform_nb = {
static void __init keystone_init(void)
{
#ifdef CONFIG_ARM_LPAE
- if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
- keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
-
[PATCH 1/3] ARM/dma-mapping: move various helpers from dma-mapping.h to dma-direct.h
Move the helpers to translate to and from direct mapping DMA addresses
to dma-direct.h. This not only is the most logical place, but the new
placement also avoids dependency loops with pending commits.
Signed-off-by: Christoph Hellwig
---
arch/arm/common/dmabounce.c| 2 +-
arch/arm/include/asm/dma-direct.h | 70 ++
arch/arm/include/asm/dma-mapping.h | 70 --
3 files changed, 71 insertions(+), 71 deletions(-)
diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index f4b719bde76367..d3e00ea9208834 100644
--- a/arch/arm/common/dmabounce.c
+++ b/arch/arm/common/dmabounce.c
@@ -24,7 +24,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/arch/arm/include/asm/dma-direct.h
b/arch/arm/include/asm/dma-direct.h
index 7c3001a6a775bf..de0f4ff9279615 100644
--- a/arch/arm/include/asm/dma-direct.h
+++ b/arch/arm/include/asm/dma-direct.h
@@ -2,6 +2,76 @@
#ifndef ASM_ARM_DMA_DIRECT_H
#define ASM_ARM_DMA_DIRECT_H 1
+#include
+
+#ifdef __arch_page_to_dma
+#error Please update to __arch_pfn_to_dma
+#endif
+
+/*
+ * dma_to_pfn/pfn_to_dma/dma_to_virt/virt_to_dma are architecture private
+ * functions used internally by the DMA-mapping API to provide DMA
+ * addresses. They must not be used by drivers.
+ */
+#ifndef __arch_pfn_to_dma
+static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
+{
+ if (dev)
+ pfn -= dev->dma_pfn_offset;
+ return (dma_addr_t)__pfn_to_bus(pfn);
+}
+
+static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
+{
+ unsigned long pfn = __bus_to_pfn(addr);
+
+ if (dev)
+ pfn += dev->dma_pfn_offset;
+
+ return pfn;
+}
+
+static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
+{
+ if (dev) {
+ unsigned long pfn = dma_to_pfn(dev, addr);
+
+ return phys_to_virt(__pfn_to_phys(pfn));
+ }
+
+ return (void *)__bus_to_virt((unsigned long)addr);
+}
+
+static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
+{
+ if (dev)
+ return pfn_to_dma(dev, virt_to_pfn(addr));
+
+ return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
+}
+
+#else
+static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
+{
+ return __arch_pfn_to_dma(dev, pfn);
+}
+
+static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
+{
+ return __arch_dma_to_pfn(dev, addr);
+}
+
+static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
+{
+ return __arch_dma_to_virt(dev, addr);
+}
+
+static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
+{
+ return __arch_virt_to_dma(dev, addr);
+}
+#endif
+
static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
{
unsigned int offset = paddr & ~PAGE_MASK;
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca3451..0a1a536368c3a4 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -8,8 +8,6 @@
#include
#include
-#include
-
#include
#include
@@ -23,74 +21,6 @@ static inline const struct dma_map_ops
*get_arch_dma_ops(struct bus_type *bus)
return NULL;
}
-#ifdef __arch_page_to_dma
-#error Please update to __arch_pfn_to_dma
-#endif
-
-/*
- * dma_to_pfn/pfn_to_dma/dma_to_virt/virt_to_dma are architecture private
- * functions used internally by the DMA-mapping API to provide DMA
- * addresses. They must not be used by drivers.
- */
-#ifndef __arch_pfn_to_dma
-static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
-{
- if (dev)
- pfn -= dev->dma_pfn_offset;
- return (dma_addr_t)__pfn_to_bus(pfn);
-}
-
-static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
-{
- unsigned long pfn = __bus_to_pfn(addr);
-
- if (dev)
- pfn += dev->dma_pfn_offset;
-
- return pfn;
-}
-
-static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
-{
- if (dev) {
- unsigned long pfn = dma_to_pfn(dev, addr);
-
- return phys_to_virt(__pfn_to_phys(pfn));
- }
-
- return (void *)__bus_to_virt((unsigned long)addr);
-}
-
-static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
-{
- if (dev)
- return pfn_to_dma(dev, virt_to_pfn(addr));
-
- return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
-}
-
-#else
-static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
-{
- return __arch_pfn_to_dma(dev, pfn);
-}
-
-static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
-{
- return __arch_dma_to_pfn(dev, addr);
-}
-
-static inline void *dma_to_virt(struct device *dev, dma_addr_t addr)
-{
- return __arch_dma_to_virt(dev, addr);
-}
-
-static inline
support range based offsets in dma-direct
Hi all, this series adds range-based offsets to the dma-direct implementation. The guts of the change are a patch from Jim with some modifications from me, but to do it nicely we need to ARM patches to prepare for it as well. Diffstat: arch/arm/common/dmabounce.c|2 arch/arm/include/asm/dma-direct.h | 69 + arch/arm/include/asm/dma-mapping.h | 70 -- arch/arm/mach-keystone/keystone.c | 21 +++-- arch/sh/drivers/pci/pcie-sh7786.c |9 +- arch/x86/pci/sta2x11-fixup.c |6 + drivers/acpi/arm64/iort.c |6 + drivers/base/core.c|2 drivers/gpu/drm/sun4i/sun4i_backend.c |8 +- drivers/iommu/io-pgtable-arm.c |2 drivers/media/platform/sunxi/sun4i-csi/sun4i_csi.c |9 ++ drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 11 ++ drivers/of/address.c | 73 -- drivers/of/device.c| 44 +++ drivers/of/of_private.h| 11 +- drivers/of/unittest.c | 34 ++-- drivers/remoteproc/remoteproc_core.c |4 - drivers/staging/media/sunxi/cedrus/cedrus_hw.c | 10 ++ drivers/usb/core/message.c |5 - drivers/usb/core/usb.c |3 include/linux/device.h |4 - include/linux/dma-direct.h | 52 +++-- include/linux/dma-mapping.h| 19 kernel/dma/coherent.c |7 - kernel/dma/direct.c| 81 - 25 files changed, 373 insertions(+), 189 deletions(-)
[PATCH 2/3] ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE
The DMA offset notifier can only be used if PHYS_OFFSET is at least
KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
phys_addr_t. Currently the code compiles fine despite that, a pending
change to the DMA offset handling would create a compiler warning for
this case. Add an ifdef to not compile the code except for LPAE
configs.
Signed-off-by: Christoph Hellwig
---
arch/arm/mach-keystone/keystone.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 638808c4e12247..dcd031ba84c2e0 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -24,6 +24,7 @@
#include "keystone.h"
+#ifdef CONFIG_ARM_LPAE
static unsigned long keystone_dma_pfn_offset __read_mostly;
static int keystone_platform_notifier(struct notifier_block *nb,
@@ -48,14 +49,17 @@ static int keystone_platform_notifier(struct notifier_block
*nb,
static struct notifier_block platform_nb = {
.notifier_call = keystone_platform_notifier,
};
+#endif /* CONFIG_ARM_LPAE */
static void __init keystone_init(void)
{
+#ifdef CONFIG_ARM_LPAE
if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
KEYSTONE_LOW_PHYS_START);
bus_register_notifier(_bus_type, _nb);
}
+#endif
keystone_pm_runtime_init();
}
--
2.28.0
Re: [PATCH v2 2/3] perf metricgroup: Fix typo in comment.
On Thu, Sep 10, 2020 at 12:26 PM Ian Rogers wrote: > > Add missing character. > > Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Thanks Namhyung > --- > tools/perf/util/metricgroup.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c > index 8831b964288f..662f4e8777d5 100644 > --- a/tools/perf/util/metricgroup.c > +++ b/tools/perf/util/metricgroup.c > @@ -150,7 +150,7 @@ static void expr_ids__exit(struct expr_ids *ids) > } > > /** > - * Find a group of events in perf_evlist that correpond to those from a > parsed > + * Find a group of events in perf_evlist that correspond to those from a > parsed > * metric expression. Note, as find_evsel_group is called in the same order > as > * perf_evlist was constructed, metric_no_merge doesn't need to test for > * underfilling a group. > -- > 2.28.0.526.ge36021eeef-goog >
Re: [PATCH v2 1/3] perf stat: Remove dead code
Hi Ian, On Thu, Sep 10, 2020 at 12:26 PM Ian Rogers wrote: > > No need to set os.evsel twice. > > Signed-off-by: Ian Rogers Acked-by: Namhyung Kim Btw, I think setting the 'out' variable can be moved out of the loop. Thanks Namhyung > --- > tools/perf/util/stat-display.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c > index 493ec372fdec..4b57c0c07632 100644 > --- a/tools/perf/util/stat-display.c > +++ b/tools/perf/util/stat-display.c > @@ -946,7 +946,6 @@ static void print_metric_headers(struct perf_stat_config > *config, > out.print_metric = print_metric_header; > out.new_line = new_line_metric; > out.force_header = true; > - os.evsel = counter; > perf_stat__print_shadow_stats(config, counter, 0, > 0, > , > -- > 2.28.0.526.ge36021eeef-goog >
Re: [RFC 03/10] phy: hisilicon: phy-hi3670-usb3: use a consistent namespace
Em Wed, 9 Sep 2020 14:15:59 -0600
Rob Herring escreveu:
> On Fri, Sep 4, 2020 at 4:23 AM Mauro Carvalho Chehab
> wrote:
> >
> > Rename hikey970 to hi3670, in order to use a namespace
> > similar to hi3660 driver.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > .../bindings/phy/phy-hi3670-usb3.txt | 4 +-
>
> Bindings should be a separate patch.
Ok. I'll split it.
>
> > drivers/phy/hisilicon/phy-hi3670-usb3.c | 98 +--
> > 2 files changed, 51 insertions(+), 51 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.txt
> > b/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.txt
> > index 4cb02612ff23..2fb27cb8beaf 100644
> > --- a/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.txt
> > +++ b/Documentation/devicetree/bindings/phy/phy-hi3670-usb3.txt
> > @@ -2,7 +2,7 @@ Hisilicon Kirin970 usb PHY
> > ---
> >
> > Required properties:
> > -- compatible: should be "hisilicon,kirin970-usb-phy"
> > +- compatible: should be "hisilicon,hi3670-usb-phy"
>
> Unless this is unused, we can't just change it. It's an ABI.
From upstream PoV, this binding is for a new driver that will be added
via this patchset.
>
> > - #phy-cells: must be 0
> > - hisilicon,pericrg-syscon: phandle of syscon used to control phy.
> > - hisilicon,pctrl-syscon: phandle of syscon used to control phy.
> > @@ -14,7 +14,7 @@ Refer to phy/phy-bindings.txt for the generic PHY binding
> > properties
> >
> > Example:
> > usb_phy: usbphy {
> > - compatible = "hisilicon,kirin970-usb-phy";
> > + compatible = "hisilicon,hi3670-usb-phy";
> > #phy-cells = <0>;
> > hisilicon,pericrg-syscon = <_ctrl>;
> > hisilicon,pctrl-syscon = <>;
Thanks,
Mauro
[PATCH] lib/mpi: remove A_LIMB_1
After commit 7cf4206a99d1b3 Remove unused code from MPI library, the macro is not used anymore. Remove it to tame gcc warning: ../lib/mpi/mpi-bit.c:24: warning: macro "A_LIMB_1" is not used [-Wunused-macros] Signed-off-by: Alex Shi Cc: linux-kernel@vger.kernel.org --- lib/mpi/mpi-bit.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/lib/mpi/mpi-bit.c b/lib/mpi/mpi-bit.c index 503537e08436..18030a01494f 100644 --- a/lib/mpi/mpi-bit.c +++ b/lib/mpi/mpi-bit.c @@ -21,8 +21,6 @@ #include "mpi-internal.h" #include "longlong.h" -#define A_LIMB_1 ((mpi_limb_t) 1) - / * Sometimes we have MSL (most significant limbs) which are 0; * this is for some reasons not good, so this function removes them. -- 1.8.3.1
Re: [PATCH v2] arm64: dts: mt8183-kukui: add scp node
On Wed, Sep 9, 2020 at 4:58 PM Matthias Brugger wrote:
>
>
>
> On 09/09/2020 10:14, Pi-Hsun Shih wrote:
> > Add scp node to mt8183-kukui
> >
> > Fixes: 0d5e41709f76 ("arm64: dts: mt8183: add scp node")
> > Signed-off-by: Pi-Hsun Shih
> > ---
> >
> > Change since v1:
> > * Add Fixes tag.
> >
> > ---
> > .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 30 +++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > index f0a070535b34..85f7c33ba446 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> > @@ -90,6 +90,18 @@ pp3300_alw: regulator6 {
> > regulator-max-microvolt = <330>;
> > };
> >
> > + reserved_memory: reserved-memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > +
> > + scp_mem_reserved: scp_mem_region {
> > + compatible = "shared-dma-pool";
> > + reg = <0 0x5000 0 0x290>;
> > + no-map;
> > + };
> > + };
> > +
>
> Do we expect other boards to have a different memory reservation? I can see
> that
> EVB and Kukui uses the same. If not, we should add the node in mt8183.dtsi
> instead.
>
> Regards,
> Matthias
All our current boards use the same memory reservation, but it's still
possible for future boards based on mt8183 to use different SCP memory
size, so I feel this should still be left out of mt8183.dtsi.
>
> > max98357a: codec0 {
> > compatible = "maxim,max98357a";
> > sdmode-gpios = < 175 0>;
> > @@ -524,6 +536,13 @@ pins_clk {
> > };
> > };
> >
> > + scp_pins: scp {
> > + pins_scp_uart {
> > + pinmux = ,
> > + ;
> > + };
> > + };
> > +
> > spi0_pins: spi0 {
> > pins_spi{
> > pinmux = ,
> > @@ -651,6 +670,17 @@ pins_wifi_wakeup {
> > };
> > };
> >
> > + {
> > + status = "okay";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_pins>;
> > +
> > + cros_ec {
> > + compatible = "google,cros-ec-rpmsg";
> > + mtk,rpmsg-name = "cros-ec-rpmsg";
> > + };
> > +};
> > +
> > _data {
> > status = "okay";
> > };
> >
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On 9/10/2020 10:02, Oliver Neukum wrote: Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard: This patch detects and reverses the effects of the malicious FTDI Windows driver version 2.12.00(FTDIgate). Hi, this raises questions. Should we do this unconditionally without asking? Does this belong into kernel space? My answer to both of those question is a strong NO. The patch author tries to justify the patch with egoistical arguments (easier for him and his customers) without thinking of all other users of memory constrained embedded hardware that doesn't need the patch code but have to carry it. The bricked PID is btw already supported by the linux ftdi driver so there is no functionality gain in the patch. br Lars
Re: [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
On 10-09-20, 13:30, Hector Yuan wrote: > On Thu, 2020-09-10 at 10:33 +0530, Viresh Kumar wrote: > > On 10-09-20, 12:31, Hector Yuan wrote: > > > The CPUfreq HW present in some Mediatek chipsets offloads the steps > > > necessary for changing the frequency of CPUs. > > > The driver implements the cpufreq driver interface for this hardware > > > engine. > > > > > > This patch depends on the MT6779 DTS patch submitted by Hanks Chen > > > https://lkml.org/lkml/2020/8/4/1094 > > > > Thanks for hanging there. Looks good to me. I will apply it once Rob > > Ack's the binding patch. > > > > Many thanks for your help. May I know if you can add Reviewed-by tag to > this patch set. Since this patchset is going to get merged via my tree (ARM cpufreq tree), a reviewed-by isn't required here. I will queue it up for 5.10-rc1 after I receive an Ack from Rob. > I would like to prepare some patches for more features > based on this. Is that okay to you? Thanks again. That should be fine. -- viresh
Re: [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
On Thu, 2020-09-10 at 10:33 +0530, Viresh Kumar wrote: > On 10-09-20, 12:31, Hector Yuan wrote: > > The CPUfreq HW present in some Mediatek chipsets offloads the steps > > necessary for changing the frequency of CPUs. > > The driver implements the cpufreq driver interface for this hardware > > engine. > > > > This patch depends on the MT6779 DTS patch submitted by Hanks Chen > > https://lkml.org/lkml/2020/8/4/1094 > > Thanks for hanging there. Looks good to me. I will apply it once Rob > Ack's the binding patch. > Many thanks for your help. May I know if you can add Reviewed-by tag to this patch set. I would like to prepare some patches for more features based on this. Is that okay to you? Thanks again.
[PATCH v8 3/3] ASoC: qcom: sc7180: Add machine driver for sound card registration
From: Ajit Pandey
Add new driver to register sound card on sc7180 trogdor board and
do the required configuration for lpass cpu dai and external codecs
connected over MI2S interfaces.
Signed-off-by: Ajit Pandey
Signed-off-by: Cheng-Yi Chiang
---
sound/soc/qcom/Kconfig | 12 ++
sound/soc/qcom/Makefile | 2 +
sound/soc/qcom/sc7180.c | 270
3 files changed, 284 insertions(+)
create mode 100644 sound/soc/qcom/sc7180.c
diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index a607ace8b089..0459185ee243 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -116,4 +116,16 @@ config SND_SOC_SDM845
SDM845 SoC-based systems.
Say Y if you want to use audio device on this SoCs.
+config SND_SOC_SC7180
+ tristate "SoC Machine driver for SC7180 boards"
+ depends on I2C
+ select SND_SOC_QCOM_COMMON
+ select SND_SOC_LPASS_SC7180
+ select SND_SOC_MAX98357A
+ select SND_SOC_RT5682_I2C
+ help
+ To add support for audio on Qualcomm Technologies Inc.
+ SC7180 SoC-based systems.
+ Say Y if you want to use audio device on this SoCs.
+
endif #SND_SOC_QCOM
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index 7972c9479ab0..0cdcbf367ef1 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -17,12 +17,14 @@ snd-soc-storm-objs := storm.o
snd-soc-apq8016-sbc-objs := apq8016_sbc.o
snd-soc-apq8096-objs := apq8096.o
snd-soc-sdm845-objs := sdm845.o
+snd-soc-sc7180-objs := sc7180.o
snd-soc-qcom-common-objs := common.o
obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o
obj-$(CONFIG_SND_SOC_APQ8016_SBC) += snd-soc-apq8016-sbc.o
obj-$(CONFIG_SND_SOC_MSM8996) += snd-soc-apq8096.o
obj-$(CONFIG_SND_SOC_SDM845) += snd-soc-sdm845.o
+obj-$(CONFIG_SND_SOC_SC7180) += snd-soc-sc7180.o
obj-$(CONFIG_SND_SOC_QCOM_COMMON) += snd-soc-qcom-common.o
#DSP lib
diff --git a/sound/soc/qcom/sc7180.c b/sound/soc/qcom/sc7180.c
new file mode 100644
index ..1fad946e3e07
--- /dev/null
+++ b/sound/soc/qcom/sc7180.c
@@ -0,0 +1,270 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+//
+// sc7180.c -- ALSA SoC Machine driver for SC7180
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../codecs/rt5682.h"
+#include "common.h"
+#include "lpass.h"
+
+#define DEFAULT_SAMPLE_RATE_48K48000
+#define DEFAULT_MCLK_RATE 1920
+#define RT5682_PLL1_FREQ (48000 * 512)
+
+struct sc7180_snd_data {
+ u32 pri_mi2s_clk_count;
+ struct snd_soc_jack hs_jack;
+ struct device_node *hs_jack_of_node;
+ struct snd_soc_jack hdmi_jack;
+ struct device_node *hdmi_jack_of_node;
+};
+
+static void sc7180_jack_free(struct snd_jack *jack)
+{
+ struct snd_soc_component *component = jack->private_data;
+
+ snd_soc_component_set_jack(component, NULL, NULL);
+}
+
+static int sc7180_headset_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_card *card = rtd->card;
+ struct sc7180_snd_data *pdata = snd_soc_card_get_drvdata(card);
+ struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
+ struct snd_soc_component *component = codec_dai->component;
+ struct snd_jack *jack;
+ int rval;
+
+ rval = snd_soc_card_jack_new(
+ card, "Headset Jack",
+ SND_JACK_HEADSET |
+ SND_JACK_HEADPHONE |
+ SND_JACK_BTN_0 | SND_JACK_BTN_1 |
+ SND_JACK_BTN_2 | SND_JACK_BTN_3,
+ >hs_jack, NULL, 0);
+
+ if (rval < 0) {
+ dev_err(card->dev, "Unable to add Headset Jack\n");
+ return rval;
+ }
+
+ jack = pdata->hs_jack.jack;
+
+ snd_jack_set_key(jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
+ snd_jack_set_key(jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
+ snd_jack_set_key(jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
+ snd_jack_set_key(jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);
+
+ jack->private_data = component;
+ jack->private_free = sc7180_jack_free;
+
+ return snd_soc_component_set_jack(component, >hs_jack, NULL);
+}
+
+static int sc7180_hdmi_init(struct snd_soc_pcm_runtime *rtd)
+{
+ struct snd_soc_card *card = rtd->card;
+ struct sc7180_snd_data *pdata = snd_soc_card_get_drvdata(card);
+ struct snd_soc_dai *codec_dai = asoc_rtd_to_codec(rtd, 0);
+ struct snd_soc_component *component = codec_dai->component;
+ struct snd_jack *jack;
+ int rval;
+
+ rval = snd_soc_card_jack_new(
+ card, "HDMI Jack",
+ SND_JACK_LINEOUT,
+ >hdmi_jack, NULL, 0);
+
+ if (rval < 0) {
+ dev_err(card->dev, "Unable to add HDMI Jack\n");
+ return rval;
[PATCH v8 2/3] ASoC: qcom: dt-bindings: Add sc7180 machine bindings
Add devicetree bindings documentation file for sc7180 sound card.
Signed-off-by: Cheng-Yi Chiang
---
.../bindings/sound/qcom,sc7180.yaml | 130 ++
1 file changed, 130 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/qcom,sc7180.yaml
diff --git a/Documentation/devicetree/bindings/sound/qcom,sc7180.yaml
b/Documentation/devicetree/bindings/sound/qcom,sc7180.yaml
new file mode 100644
index ..a1fc53e33b07
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,sc7180.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/qcom,sc7180.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies Inc. SC7180 ASoC sound card driver
+
+maintainers:
+ - Rohit kumar
+ - Cheng-Yi Chiang
+
+description:
+ This binding describes the SC7180 sound card which uses LPASS for audio.
+
+properties:
+ compatible:
+const: qcom,sc7180-sndcard
+
+ audio-routing:
+$ref: /schemas/types.yaml#/definitions/non-unique-string-array
+description:
+ A list of the connections between audio components. Each entry is a
+ pair of strings, the first being the connection's sink, the second
+ being the connection's source.
+
+ model:
+$ref: /schemas/types.yaml#/definitions/string
+description: User specified audio sound card name
+
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+patternProperties:
+ "^dai-link(@[0-9])?$":
+description:
+ Each subnode represents a dai link. Subnodes of each dai links would be
+ cpu/codec dais.
+
+type: object
+
+properties:
+ link-name:
+description: Indicates dai-link name and PCM stream name.
+$ref: /schemas/types.yaml#/definitions/string
+maxItems: 1
+
+ reg:
+description: dai link address.
+
+ cpu:
+description: Holds subnode which indicates cpu dai.
+type: object
+properties:
+ sound-dai: true
+
+ codec:
+description: Holds subnode which indicates codec dai.
+type: object
+properties:
+ sound-dai: true
+
+required:
+ - link-name
+ - cpu
+ - codec
+
+additionalProperties: false
+
+required:
+ - compatible
+ - model
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+
+ - |
+sound {
+compatible = "qcom,sc7180-sndcard";
+model = "sc7180-snd-card";
+
+audio-routing =
+"Headphone Jack", "HPOL",
+"Headphone Jack", "HPOR";
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+dai-link@0 {
+link-name = "MultiMedia0";
+reg = <0>;
+cpu {
+sound-dai = <_cpu 0>;
+};
+
+codec {
+sound-dai = < 0>;
+};
+};
+
+dai-link@1 {
+link-name = "MultiMedia1";
+reg = <1>;
+cpu {
+sound-dai = <_cpu 1>;
+};
+
+codec {
+sound-dai = <>;
+};
+};
+
+dai-link@2 {
+link-name = "MultiMedia2";
+reg = <2>;
+cpu {
+sound-dai = <_hdmi 0>;
+};
+
+codec {
+sound-dai = <_dp>;
+};
+};
+};
--
2.28.0.526.ge36021eeef-goog
[PATCH v8 1/3] ASoC: hdmi-codec: Use set_jack ops to set jack
Use set_jack ops to set jack so machine drivers do not need to include
hdmi-codec.h explicitly.
Signed-off-by: Cheng-Yi Chiang
---
include/sound/hdmi-codec.h | 3 ---
sound/soc/codecs/hdmi-codec.c| 12
sound/soc/mediatek/mt8173/mt8173-rt5650.c| 5 ++---
sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c | 5 ++---
.../mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c | 5 ++---
sound/soc/rockchip/rockchip_max98090.c | 3 +--
6 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index 7754631a3102..b55970859a13 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -117,9 +117,6 @@ struct hdmi_codec_pdata {
struct snd_soc_component;
struct snd_soc_jack;
-int hdmi_codec_set_jack_detect(struct snd_soc_component *component,
- struct snd_soc_jack *jack);
-
#define HDMI_CODEC_DRV_NAME "hdmi-audio-codec"
#endif /* __HDMI_CODEC_H__ */
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 8c6f540533ba..d1de5bcd5daa 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -698,13 +698,9 @@ static void plugged_cb(struct device *dev, bool plugged)
hdmi_codec_jack_report(hcp, 0);
}
-/**
- * hdmi_codec_set_jack_detect - register HDMI plugged callback
- * @component: the hdmi-codec instance
- * @jack: ASoC jack to report (dis)connection events on
- */
-int hdmi_codec_set_jack_detect(struct snd_soc_component *component,
- struct snd_soc_jack *jack)
+static int hdmi_codec_set_jack_detect(struct snd_soc_component *component,
+ struct snd_soc_jack *jack,
+ void *data)
{
struct hdmi_codec_priv *hcp = snd_soc_component_get_drvdata(component);
int ret = -EOPNOTSUPP;
@@ -720,7 +716,6 @@ int hdmi_codec_set_jack_detect(struct snd_soc_component
*component,
}
return ret;
}
-EXPORT_SYMBOL_GPL(hdmi_codec_set_jack_detect);
static int hdmi_dai_spdif_probe(struct snd_soc_dai *dai)
{
@@ -806,6 +801,7 @@ static const struct snd_soc_component_driver hdmi_driver = {
.use_pmdown_time= 1,
.endianness = 1,
.non_legacy_dai_naming = 1,
+ .set_jack = hdmi_codec_set_jack_detect,
};
static int hdmi_codec_probe(struct platform_device *pdev)
diff --git a/sound/soc/mediatek/mt8173/mt8173-rt5650.c
b/sound/soc/mediatek/mt8173/mt8173-rt5650.c
index 347b095d478d..c28ebf891cb0 100644
--- a/sound/soc/mediatek/mt8173/mt8173-rt5650.c
+++ b/sound/soc/mediatek/mt8173/mt8173-rt5650.c
@@ -11,7 +11,6 @@
#include
#include
#include
-#include
#include "../../codecs/rt5645.h"
#define MCLK_FOR_CODECS12288000
@@ -154,8 +153,8 @@ static int mt8173_rt5650_hdmi_init(struct
snd_soc_pcm_runtime *rtd)
if (ret)
return ret;
- return hdmi_codec_set_jack_detect(asoc_rtd_to_codec(rtd, 0)->component,
- _rt5650_hdmi_jack);
+ return snd_soc_component_set_jack(asoc_rtd_to_codec(rtd, 0)->component,
+ _rt5650_hdmi_jack, NULL);
}
enum {
diff --git a/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c
b/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c
index 06d0a4f80fc1..e53c6200d5a7 100644
--- a/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c
+++ b/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c
@@ -10,7 +10,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -369,8 +368,8 @@ static int mt8183_da7219_max98357_hdmi_init(struct
snd_soc_pcm_runtime *rtd)
if (ret)
return ret;
- return hdmi_codec_set_jack_detect(asoc_rtd_to_codec(rtd, 0)->component,
- >hdmi_jack);
+ return snd_soc_component_set_jack(asoc_rtd_to_codec(rtd, 0)->component,
+ >hdmi_jack, NULL);
}
static struct snd_soc_dai_link mt8183_da7219_dai_links[] = {
diff --git a/sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c
b/sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c
index 07410d7afaa9..327dfad41e31 100644
--- a/sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c
+++ b/sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -350,8 +349,8 @@ mt8183_mt6358_ts3a227_max98357_hdmi_init(struct
snd_soc_pcm_runtime *rtd)
if (ret)
return ret;
- return hdmi_codec_set_jack_detect(asoc_rtd_to_codec(rtd, 0)->component,
- >hdmi_jack);
+ return snd_soc_component_set_jack(asoc_rtd_to_codec(rtd, 0)->component,
+
[PATCH v8 0/3] Add documentation and machine driver for SC7180 sound card
Note: - The machine driver patch is made by the collaboration of Cheng-Yi Chiang Rohit kumar Ajit Pandey But Ajit has left codeaurora. - This patch series needs HDMI DAI name defined in sc7180-lpass.h. https://patchwork.kernel.org/patch/11745565/ Changes from v1 to v2: - Ducumentation: Addressed all suggestions from Doug. - Machine driver: - Fix comment style for license. - Sort includes. - Remove sc7180_snd_hw_params. - Remove sc7180_dai_init and use aux device instead for headset jack registration. - Statically define format for Primary MI2S. - Atomic is not a concern because there is mutex in card to make sure startup and shutdown happen sequentially. - Fix missing return -EINVAL in startup. - Use static sound card. - Use devm_kzalloc to avoid kfree. Changes from v2 to v3: - Ducumentation: Addressed suggestions from Srini. - Machine driver: - Reuse qcom_snd_parse_of to parse properties. - Remove playback-only and capture-only. - Misc fixes to address comments. Changes from v3 to v4: - Ducumentation: Addressed suggestions from Rob. - Remove definition of dai. - Use 'sound-dai: true' for sound-dai schema. - Add reg property to pass 'make dt_binding_check' check although reg is not used in the driver. - Machine driver: - Add Reviewed-by: Tzung-Bi Shih Changes from v4 to v5: - Documentation: Addressed suggestions from Rob. - Add definition for "#address-cells" and "#size-cells". - Add additionalProperties: false - Add required properties. Changes from v5 to v6: - Documentation: Addressed suggestions from Rob. - Drop contains in compatible strings. - Only allow dai-link@[0-9] - Remove reg ref since it has a type definition already. Changes from v6 to v7 - Documentation: - Add headset-jack and hdmi-jack to specify the codec responsible for jack detection. - HDMI codec driver: - Use component set_jack ops instead of exporting hdmi_codec_set_jack_detect. - Machine driver: - Removed aux device following Stephan's suggestion. - Use headset-jack and hdmi-jack to specify the codec responsible for jack detection. - Add support for HDMI(actually DP) playback. Changes from v7 to v8 - Documentation: - Remove headset-jack and hdmi-jack. - Machine driver: - Let machine driver decide whether there is a jack on the DAI. Ajit Pandey (1): ASoC: qcom: sc7180: Add machine driver for sound card registration Cheng-Yi Chiang (2): ASoC: hdmi-codec: Use set_jack ops to set jack ASoC: qcom: dt-bindings: Add sc7180 machine bindings .../bindings/sound/qcom,sc7180.yaml | 130 + include/sound/hdmi-codec.h| 3 - sound/soc/codecs/hdmi-codec.c | 12 +- sound/soc/mediatek/mt8173/mt8173-rt5650.c | 5 +- .../mediatek/mt8183/mt8183-da7219-max98357.c | 5 +- .../mt8183/mt8183-mt6358-ts3a227-max98357.c | 5 +- sound/soc/qcom/Kconfig| 12 + sound/soc/qcom/Makefile | 2 + sound/soc/qcom/sc7180.c | 270 ++ sound/soc/rockchip/rockchip_max98090.c| 3 +- 10 files changed, 425 insertions(+), 22 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/qcom,sc7180.yaml create mode 100644 sound/soc/qcom/sc7180.c -- 2.28.0.526.ge36021eeef-goog
[PATCH] mm: remove unused marco writeback
Unlike others we don't use the marco writeback. so let's remove it to tame gcc warning: mm/memory-failure.c:827: warning: macro "writeback" is not used [-Wunused-macros] Signed-off-by: Alex Shi Cc: Naoya Horiguchi Cc: Andrew Morton Cc: linux...@kvack.org Cc: linux-kernel@vger.kernel.org --- mm/memory-failure.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/mm/memory-failure.c b/mm/memory-failure.c index f1aa6433f404..3a97440cdf8c 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -824,7 +824,6 @@ static int me_huge_page(struct page *p, unsigned long pfn) #define sc ((1UL << PG_swapcache) | (1UL << PG_swapbacked)) #define unevict(1UL << PG_unevictable) #define mlock (1UL << PG_mlocked) -#define writeback (1UL << PG_writeback) #define lru(1UL << PG_lru) #define head (1UL << PG_head) #define slab (1UL << PG_slab) @@ -873,7 +872,6 @@ static int me_huge_page(struct page *p, unsigned long pfn) #undef sc #undef unevict #undef mlock -#undef writeback #undef lru #undef head #undef slab -- 1.8.3.1
Re: [PATCH net-next RFC v3 01/14] devlink: Add reload action option to devlink reload command
On Wed, Sep 9, 2020 at 10:51 PM Moshe Shemesh wrote:
>
>
> On 9/7/2020 8:58 PM, Jakub Kicinski wrote:
> > On Mon, 7 Sep 2020 16:46:01 +0300 Moshe Shemesh wrote:
> >>> In that sense I don't like --live because it doesn't really say much.
> >>> AFAIU it means 1) no link flap; 2) < 2 sec datapath downtime; 3) no
> >>> configuration is lost in kernel or device (including netdev config,
> >>> link config, flow rules, counters etc.). I was hoping at least the
> >>> documentation in patch 14 would be more precise.
> >> Actually, while writing "no-reset" or "live-patching" I meant also no
> >> downtime at all and nothing resets (config, rules ... anything), that
> >> fits mlx5 live-patching.
> >>
> >> However, to make it more generic, I can allow few seconds downtime and
> >> add similar constrains as you mentioned here to "no-reset". I will add
> >> that to the documentation patch.
> > Oh! If your device supports no downtime and packet loss at all that's
> > great. You don't have to weaken the definition now, whoever needs a
> > weaker definition can add a different constraint level later, no?
>
>
> Yes, but if we are thinking there will be more levels, maybe the flag
> "--live" or "--no_reset" is less extendable, we may need new attr. I
> mean should I have uAPI command line like:
>
> $ devlink dev reload DEV [ netns { PID | NAME | ID } ] [ action {
> driver_reinit | fw_activate } [ limit_level no_reset ] ]
>
This sounds good. As coming to our device, user can issue
$devlink dev reload DEV action fw_activate
which resets both firmware and driver entities to activate the new
firmware (either pending flashed firmware or reset current firmware).
Thanks for the patch series.
Re: [PATCH] net: bluetooth: Fix null pointer dereference in hci_event_packet()
On Thu, Sep 10, 2020 at 10:04:24AM +0530, Anmol Karn wrote:
> Prevent hci_phy_link_complete_evt() from dereferencing 'hcon->amp_mgr'
> as NULL. Fix it by adding pointer check for it.
>
> Reported-and-tested-by: syzbot+0bef568258653cff2...@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=0bef568258653cff272f
> Signed-off-by: Anmol Karn
> ---
> net/bluetooth/hci_event.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 4b7fc430793c..871e16804433 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -4936,6 +4936,11 @@ static void hci_phy_link_complete_evt(struct hci_dev
> *hdev,
> return;
> }
>
> + if (IS_ERR_OR_NULL(hcon->amp_mgr)) {
> + hci_dev_unlock(hdev);
> + return;
> + }
> +
In patches that fix a NULL pointer dereference, please include a brief
explanation of why the pointer can be NULL, including what it means
semantically; and why the proposed change is the best fix for the problem.
Also, why IS_ERR_OR_NULL()?
- Eric
[tip:WIP.x86/seves] BUILD SUCCESS 1ac0dc494a9796d6f94ff392f16e0c9a8cea7021
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/seves branch HEAD: 1ac0dc494a9796d6f94ff392f16e0c9a8cea7021 x86/sev-es: Check required CPU features for SEV-ES elapsed time: 720m configs tested: 100 configs skipped: 7 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig h8300 h8s-sim_defconfig mips fuloong2e_defconfig sh apsh4a3a_defconfig arm footbridge_defconfig sh ecovec24_defconfig powerpc powernv_defconfig powerpc mgcoge_defconfig armneponset_defconfig m68kstmark2_defconfig arm lpc18xx_defconfig mips jazz_defconfig m68k m5249evb_defconfig pariscgeneric-32bit_defconfig arm assabet_defconfig armdove_defconfig arm cm_x300_defconfig shecovec24-romimage_defconfig cskydefconfig i386defconfig sh polaris_defconfig m68kmvme16x_defconfig c6x allyesconfig openrisc simple_smp_defconfig mips maltasmvp_eva_defconfig alpha defconfig sh ul2_defconfig powerpccell_defconfig m68k multi_defconfig arm nhk8815_defconfig sh se7206_defconfig xtensaxip_kc705_defconfig mips rb532_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20200909 x86_64 randconfig-a006-20200909 x86_64 randconfig-a003-20200909 x86_64 randconfig-a001-20200909 x86_64 randconfig-a005-20200909 x86_64 randconfig-a002-20200909 i386 randconfig-a004-20200909 i386 randconfig-a005-20200909 i386 randconfig-a006-20200909 i386 randconfig-a002-20200909 i386 randconfig-a001-20200909 i386 randconfig-a003-20200909 i386 randconfig-a016-20200909 i386 randconfig-a015-20200909 i386 randconfig-a011-20200909 i386 randconfig-a013-20200909 i386 randconfig-a014-20200909 i386 randconfig-a012-20200909 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a013-20200909 x86_64 randconfig-a016-20200909 x86_64 randconfig-a011-20200909 x86_64 randconfig-a012-20200909 x86_64 randconfig-a015-20200909 x86_64 randconfig-a014
Re: [PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
On 10-09-20, 12:31, Hector Yuan wrote: > The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary > for changing the frequency of CPUs. > The driver implements the cpufreq driver interface for this hardware engine. > > This patch depends on the MT6779 DTS patch submitted by Hanks Chen > https://lkml.org/lkml/2020/8/4/1094 Thanks for hanging there. Looks good to me. I will apply it once Rob Ack's the binding patch. -- viresh
Re: [PATCH -next] regulator: bd718x7: Make some variable static
On Thu, 2020-09-10 at 11:42 +0800, YueHaibing wrote:
> Fix sparse warnings:
>
> drivers/regulator/bd718x7-regulator.c:576:28: warning: symbol
> 'bd71847_swcontrol_ops' was not declared. Should it be static?
> drivers/regulator/bd718x7-regulator.c:585:28: warning: symbol
> 'bd71847_hwcontrol_ops' was not declared. Should it be static?
> drivers/regulator/bd718x7-regulator.c:902:28: warning: symbol
> 'bd71837_swcontrol_ops' was not declared. Should it be static?
> drivers/regulator/bd718x7-regulator.c:913:28: warning: symbol
> 'bd71837_hwcontrol_ops' was not declared. Should it be static?
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Acked-By: Matti Vaittinen
Thanks for taking care of this!
> ---
> drivers/regulator/bd718x7-regulator.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/regulator/bd718x7-regulator.c
> b/drivers/regulator/bd718x7-regulator.c
> index 159c917b9c4c..0774467994fb 100644
> --- a/drivers/regulator/bd718x7-regulator.c
> +++ b/drivers/regulator/bd718x7-regulator.c
> @@ -573,7 +573,7 @@ static int buck_set_hw_dvs_levels(struct
> device_node *np,
> return rohm_regulator_set_dvs_levels(>dvs, np, desc, cfg-
> >regmap);
> }
>
> -const struct regulator_ops *bd71847_swcontrol_ops[] = {
> +static const struct regulator_ops *bd71847_swcontrol_ops[] = {
> _dvs_buck_regulator_ops,
> _dvs_buck_regulator_ops,
> _pickable_range_buck_ops,
> _pickable_range_buck_ops,
> _buck_regulator_nolinear_ops,
> _buck_regulator_ops,
> @@ -582,7 +582,7 @@ const struct regulator_ops
> *bd71847_swcontrol_ops[] = {
> _pickable_range_ldo_ops, _ldo_regulator_ops,
> };
>
> -const struct regulator_ops *bd71847_hwcontrol_ops[] = {
> +static const struct regulator_ops *bd71847_hwcontrol_ops[] = {
> _HWOPNAME(bd718xx_dvs_buck_regulator_ops),
> _HWOPNAME(bd718xx_dvs_buck_regulator_ops),
> _HWOPNAME(bd718xx_pickable_range_buck_ops),
> @@ -899,7 +899,7 @@ static struct bd718xx_regulator_data
> bd71847_regulators[] = {
> },
> };
>
> -const struct regulator_ops *bd71837_swcontrol_ops[] = {
> +static const struct regulator_ops *bd71837_swcontrol_ops[] = {
> _dvs_buck_regulator_ops,
> _dvs_buck_regulator_ops,
> _dvs_buck_regulator_ops,
> _dvs_buck_regulator_ops,
> _pickable_range_buck_ops, _buck_regulator_ops,
> @@ -910,7 +910,7 @@ const struct regulator_ops
> *bd71837_swcontrol_ops[] = {
> _ldo_regulator_ops,
> };
>
> -const struct regulator_ops *bd71837_hwcontrol_ops[] = {
> +static const struct regulator_ops *bd71837_hwcontrol_ops[] = {
> _HWOPNAME(bd718xx_dvs_buck_regulator_ops),
> _HWOPNAME(bd718xx_dvs_buck_regulator_ops),
> _buck34_ops_hwctrl, _buck34_ops_hwctrl,
Re: possible deadlock in _snd_pcm_stream_lock_irqsave
Thanks for reporting.
On Wed, Sep 09, 2020 at 10:33:04AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit e918188611f073063415f40fae568fa4d86d9044
> Author: Boqun Feng
> Date: Fri Aug 7 07:42:20 2020 +
>
> locking: More accurate annotations for read_lock()
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=112dc24390
> start commit: dff9f829 Add linux-next specific files for 20200908
> git tree: linux-next
> final oops: https://syzkaller.appspot.com/x/report.txt?x=132dc24390
> console output: https://syzkaller.appspot.com/x/log.txt?x=152dc24390
>From what I see in the output, probably this is the new deadlock
possibility we find with lockdep, basically if we have:
CPU 0: CPU 1:
read_lock(snd_card::ctl_file_rwlock);
spin_lock(snd_pcm_group::lock);
read_lock(snd_card::ctl_file_rwlock);
spin_lock(snd_pcm_group::lock);
, because the read_lock() on CPU 1 will be a fair read lock(IOW, not a
recursive reader). And if there is a third CPU is also waiting for the
write_lock(), CPU 1 cannot get the read_lock() due to the fairness:
CPU 0: CPU 1:
CPU 2:
read_lock(snd_card::ctl_file_rwlock);
spin_lock(snd_pcm_group::lock);
write_lock(snd_card::ctl_file_rwlock);
read_lock(snd_card::ctl_file_rwlock); // fair read lock, can only get the lock
if CPU 2 get its lock
spin_lock(snd_pcm_group::lock);
That said, I'm still looking into the code to find whether there is a
lock combination of CPU 1. Given I'm not familiar with sound subsystem,
I will appreciate any help on finding the lock pattern on CPU 1 ;-)
Regards,
Boqun
> kernel config: https://syzkaller.appspot.com/x/.config?x=37b3426c77bda44c
> dashboard link: https://syzkaller.appspot.com/bug?extid=561a74f84100162990b2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1209e24590
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=154b15ed90
>
> Reported-by: syzbot+561a74f8410016299...@syzkaller.appspotmail.com
> Fixes: e918188611f0 ("locking: More accurate annotations for read_lock()")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On Wed, Sep 9, 2020 at 9:49 PM Hector Martin "marcan"
wrote:
>
>
>
> On September 10, 2020 12:46:20 PM GMT+09:00, James Hilliard
> wrote:
> >On Wed, Sep 9, 2020 at 9:17 PM Hector Martin "marcan"
> > wrote:
> >>
> >>
> >>
> >> On September 10, 2020 12:02:34 PM GMT+09:00, Oliver Neukum
> > wrote:
> >> >Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
> >> >> This patch detects and reverses the effects of the malicious FTDI
> >> >> Windows driver version 2.12.00(FTDIgate).
> >> >
> >> >Hi,
> >> >
> >> >this raises questions.
> >> >Should we do this unconditionally without asking?
> >> >Does this belong into kernel space?
> >>
> >> I agree; this is very cute, but does it really need to be an
> >automatic Linux feature? Presumably someone looking to fix a bricked
> >FTDI chip can just run my script, and those who just want to use those
> >chips with Linux already can since the driver binds to the zero PID.
> >Well for one your script is not easily useable with embedded platforms
> >like mine where I ran into this issue, I have no python2 interpreter
> >available in my production builds.
>
> Surely you can port the exact same algorithm to plain userspace C, as you did
> to kernel space C :)
Sure, but it would be significantly more complex, require a lot more code
and testing since there can be other userspace apps interacting with the
hardware, in addition to being less reliable and potentially difficult
to install
for some setups. Detecting and dealing with this issue in the kernel is
very simple and reliable in comparison. There's also potentially permissions
issues if one wants to do this from userspace from my understanding.
>
> >>
> >> I am deeply amused by the idea of Linux automatically fixing problems
> >caused by malicious Windows drivers, but thinking objectively, I'm not
> >sure if that's the right thing to do.
> >From my understanding Linux fixing up hardware issues caused
> >by faulty/weird Windows drivers isn't exactly unusual.
>
> I'm not aware of any instances like this where nonvolatile memory is
> modified. At most you'll get things like resetting devices that a previous
> windows warm boot misconfigured, I think?
Yeah, I think it's mostly nonvolatile memory, I've seen this issue quite a bit
with some of the Realtek ethernet drivers.
I think user experience for devices should be that one can move
a USB device from Linux to Windows and back without having to manually
reprogram an eeprom. The sheer amount of resources FTDI has wasted
with their malicious Windows driver is crazy and likely far exceeds any losses
from counterfeiting. I think due to how widespread this issue is it makes sense
to aggressively and automatically mitigate the damages wherever possible, it's
also likely a major source of ewaste since people may throw out perfectly
functional hardware without knowing it can be fixed easily.
>
> >>
> >> >
> >> >> +static int ftdi_repair_brick(struct usb_serial_port *port)
> >> >> +{
> >> >> +struct ftdi_private *priv = usb_get_serial_port_data(port);
> >> >> +int orig_latency;
> >> >> +int rv;
> >> >> +u16 *eeprom_data;
> >> >> +u16 checksum;
> >> >> +int eeprom_size;
> >> >> +int result;
> >> >> +
> >> >> +switch (priv->chip_type) {
> >> >> +case FT232RL:
> >> >> +eeprom_size = 0x40;
> >> >> +break;
> >> >> +default:
> >> >> +/* Unsupported for brick repair */
> >> >> +return 0;
> >> >> +}
> >> >> +
> >> >> +/* Latency timer needs to be 0x77 to unlock EEPROM
> >programming */
> >> >> +if (priv->latency != 0x77) {
> >> >> +orig_latency = priv->latency;
> >> >> +priv->latency = 0x77;
> >> >> +rv = write_latency_timer(port);
> >> >> +priv->latency = orig_latency;
> >> >> +if (rv < 0)
> >> >> +return -EIO;
> >> >> +}
> >> >
> >> >Do you really want to change this without returning to the original?
> >> >
> >> > Regards
> >> > Oliver
> >>
> >> --
> >> Hector Martin "marcan" (hec...@marcansoft.com)
> >> Public key: https://mrcn.st/pub
>
> --
> Hector Martin "marcan" (hec...@marcansoft.com)
> Public key: https://mrcn.st/pub
BUG: stack guard page was hit in validate_chain (2)
Hello, syzbot found the following issue on: HEAD commit:9322c47b Merge tag 'xfs-5.9-fixes-2' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1142839590 kernel config: https://syzkaller.appspot.com/x/.config?x=e1c560d0f4e121c9 dashboard link: https://syzkaller.appspot.com/bug?extid=5846c06bbd501a165e52 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+5846c06bbd501a165...@syzkaller.appspotmail.com BUG: stack guard page was hit at 554f5028 (stack is 460081ac..7ee658c0) kernel stack overflow (double-fault): [#1] PREEMPT SMP KASAN CPU: 0 PID: 17122 Comm: syz-executor.2 Not tainted 5.9.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:validate_chain+0x3f/0x88a0 kernel/locking/lockdep.c:3171 Code: 01 00 00 49 89 ce 89 54 24 68 48 89 7c 24 28 65 48 8b 04 25 28 00 00 00 48 89 84 24 b0 01 00 00 49 bf 00 00 00 00 00 fc ff df <48> 89 34 24 4c 8d 6e 20 4c 89 e8 48 c1 e8 03 48 89 44 24 58 42 8a RSP: 0018:c90008d1ffe0 EFLAGS: 00010082 RAX: ffa821a9c58d6a00 RBX: 8afcba70 RCX: 041395c41cf575f9 RDX: RSI: 88808c830990 RDI: 88808c830080 RBP: c90008d201d0 R08: dc00 R09: fbfff167d899 R10: fbfff167d899 R11: R12: 041395c41cf575f9 R13: 88808c8309b0 R14: 041395c41cf575f9 R15: dc00 FS: 7f2bfc628700() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: c90008d1ffe0 CR3: 15958000 CR4: 001526f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __lock_acquire+0x110b/0x2ae0 kernel/locking/lockdep.c:4426 lock_acquire+0x140/0x6f0 kernel/locking/lockdep.c:5006 seqcount_lockdep_reader_access include/linux/seqlock.h:102 [inline] read_seqcount_t_begin+0xb3/0x1a0 include/linux/seqlock.h:311 read_seqbegin include/linux/seqlock.h:752 [inline] zone_span_seqbegin include/linux/memory_hotplug.h:80 [inline] page_outside_zone_boundaries mm/page_alloc.c:561 [inline] bad_range+0x7e/0x260 mm/page_alloc.c:590 rmqueue+0xde/0x1c90 mm/page_alloc.c:3409 get_page_from_freelist+0x631/0xcc0 mm/page_alloc.c:3828 __alloc_pages_nodemask+0x27e/0x5c0 mm/page_alloc.c:4882 __alloc_pages include/linux/gfp.h:509 [inline] __alloc_pages_node include/linux/gfp.h:522 [inline] kmem_getpages+0x37/0x1d0 mm/slab.c:1376 cache_grow_begin+0x64/0x2b0 mm/slab.c:2590 cache_alloc_refill+0x359/0x3f0 mm/slab.c:2962 cache_alloc mm/slab.c:3045 [inline] slab_alloc_node mm/slab.c:3241 [inline] kmem_cache_alloc_node_trace+0x285/0x2a0 mm/slab.c:3592 __do_kmalloc_node mm/slab.c:3614 [inline] __kmalloc_node_track_caller+0x37/0x60 mm/slab.c:3629 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0xde/0x4f0 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1094 [inline] nlmsg_new include/net/netlink.h:940 [inline] rtmsg_ifinfo_build_skb+0x81/0x180 net/core/rtnetlink.c:3804 rtmsg_ifinfo_event net/core/rtnetlink.c:3840 [inline] rtnetlink_event+0xed/0x1b0 net/core/rtnetlink.c:5614 notifier_call_chain kernel/notifier.c:83 [inline] __raw_notifier_call_chain kernel/notifier.c:361 [inline] raw_notifier_call_chain+0xe7/0x170 kernel/notifier.c:368 call_netdevice_notifiers_info net/core/dev.c:2033 [inline] call_netdevice_notifiers_extack net/core/dev.c:2045 [inline] call_netdevice_notifiers net/core/dev.c:2059 [inline] netdev_features_change net/core/dev.c:1444 [inline] netdev_sync_lower_features net/core/dev.c:9372 [inline] __netdev_update_features+0xa11/0x1860 net/core/dev.c:9503 netdev_change_features+0x2e/0x140 net/core/dev.c:9575 bond_compute_features+0x5d0/0x690 drivers/net/bonding/bond_main.c:1308 bond_slave_netdev_event drivers/net/bonding/bond_main.c:3375 [inline] bond_netdev_event+0x31a/0xb50 drivers/net/bonding/bond_main.c:3415 notifier_call_chain kernel/notifier.c:83 [inline] __raw_notifier_call_chain kernel/notifier.c:361 [inline] raw_notifier_call_chain+0xe7/0x170 kernel/notifier.c:368 call_netdevice_notifiers_info net/core/dev.c:2033 [inline] call_netdevice_notifiers_extack net/core/dev.c:2045 [inline] call_netdevice_notifiers net/core/dev.c:2059 [inline] netdev_features_change net/core/dev.c:1444 [inline] netdev_sync_lower_features net/core/dev.c:9372 [inline] __netdev_update_features+0xa11/0x1860 net/core/dev.c:9503 netdev_change_features+0x2e/0x140 net/core/dev.c:9575 bond_compute_features+0x5d0/0x690 drivers/net/bonding/bond_main.c:1308 bond_slave_netdev_event drivers/net/bonding/bond_main.c:3375 [inline] bond_netdev_event+0x31a/0xb50
[Linux-kernel-mentees] [PATCH] net: bluetooth: Fix null pointer dereference in hci_event_packet()
Prevent hci_phy_link_complete_evt() from dereferencing 'hcon->amp_mgr'
as NULL. Fix it by adding pointer check for it.
Reported-and-tested-by: syzbot+0bef568258653cff2...@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=0bef568258653cff272f
Signed-off-by: Anmol Karn
---
net/bluetooth/hci_event.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 4b7fc430793c..871e16804433 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -4936,6 +4936,11 @@ static void hci_phy_link_complete_evt(struct hci_dev
*hdev,
return;
}
+ if (IS_ERR_OR_NULL(hcon->amp_mgr)) {
+ hci_dev_unlock(hdev);
+ return;
+ }
+
if (ev->status) {
hci_conn_del(hcon);
hci_dev_unlock(hdev);
--
2.28.0
Re: [PATCH v2] certs: Add EFI_CERT_X509_GUID support for dbx entries
> On Sep 9, 2020, at 11:40 AM, Randy Dunlap wrote:
>
> On 9/9/20 10:27 AM, Eric Snowberg wrote:
>> diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
>> index 38ec7f5f9041..d8f2e0fdfbf4 100644
>> --- a/include/crypto/pkcs7.h
>> +++ b/include/crypto/pkcs7.h
>> @@ -26,11 +26,19 @@ extern int pkcs7_get_content_data(const struct
>> pkcs7_message *pkcs7,
>>const void **_data, size_t *_datalen,
>>size_t *_headerlen);
>>
>> +#ifdef CONFIG_PKCS7_MESSAGE_PARSER
>> /*
>> * pkcs7_trust.c
>> */
>> extern int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
>> struct key *trust_keyring);
>> +#else
>> +static inline int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
>> + struct key *trust_keyring)
>> +{
>> +return -ENOKEY;
>> +}
>> +#endif
>
> Just to be clear, you want to do the #else block when
> CONFIG_PKCS7_MESSAGE_PARSER=m. Is that correct?
>
> If so, it might be clearer to use
>
> #if IS_BUILTIN(CONFIG_PKCS7_MESSAGE_PARSER)
>
I just added this part to fix a build error when none of the
asymmetrical keys are defined within a config. I failed to notice
CONFIG_PKCS7_MESSAGE_PARSER could be configured to build as a module
too. The code I added that uses pkcs7_validate_trust is always
builtin. Taking this into account, please disregard this patch.
I will need to solve this a different way. Thanks for pointing this
out.
[PATCH v7] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
The CPUfreq HW present in some Mediatek chipsets offloads the steps necessary for changing the frequency of CPUs. The driver implements the cpufreq driver interface for this hardware engine. This patch depends on the MT6779 DTS patch submitted by Hanks Chen https://lkml.org/lkml/2020/8/4/1094 Hector.Yuan (2): cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW .../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141 ++ drivers/cpufreq/Kconfig.arm| 12 + drivers/cpufreq/Makefile |1 + drivers/cpufreq/mediatek-cpufreq-hw.c | 277 4 files changed, 431 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml create mode 100644 drivers/cpufreq/mediatek-cpufreq-hw.c
[PATCH v7 2/2] dt-bindings: cpufreq: add bindings for MediaTek cpufreq HW
From: "Hector.Yuan"
Add devicetree bindings for MediaTek HW driver.
Signed-off-by: Hector.Yuan
---
.../bindings/cpufreq/cpufreq-mediatek-hw.yaml | 141
1 file changed, 141 insertions(+)
create mode 100644
Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
new file mode 100644
index 000..118a163
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
@@ -0,0 +1,141 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek's CPUFREQ Bindings
+
+maintainers:
+ - Hector Yuan
+
+description:
+ CPUFREQ HW is a hardware engine used by MediaTek
+ SoCs to manage frequency in hardware. It is capable of controlling frequency
+ for multiple clusters.
+
+properties:
+ compatible:
+const: "mediatek,cpufreq-hw"
+
+ reg:
+minItems: 1
+maxItems: 2
+description: |
+ Addresses and sizes for the memory of the HW bases in each frequency
domain.
+
+ reg-names:
+items:
+ - const: "freq-domain0"
+ - const: "freq-domain1"
+description: |
+ Frequency domain name. i.e.
+ "freq-domain0", "freq-domain1".
+
+ "#freq-domain-cells":
+const: 1
+description: |
+ Number of cells in a freqency domain specifier.
+
+ mtk-freq-domain:
+maxItems: 1
+description: |
+ Define this cpu belongs to which frequency domain. i.e.
+ cpu0-3 belong to frequency domain0,
+ cpu4-6 belong to frequency domain1.
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - "#freq-domain-cells"
+
+examples:
+ - |
+cpus {
+#address-cells = <1>;
+#size-cells = <0>;
+
+cpu0: cpu@0 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+mtk-freq-domain = <_hw 0>;
+reg = <0x000>;
+};
+
+cpu1: cpu@1 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+mtk-freq-domain = <_hw 0>;
+reg = <0x100>;
+};
+
+cpu2: cpu@2 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+mtk-freq-domain = <_hw 0>;
+reg = <0x200>;
+};
+
+cpu3: cpu@3 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+mtk-freq-domain = <_hw 0>;
+reg = <0x300>;
+};
+
+cpu4: cpu@4 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+mtk-freq-domain = <_hw 1>;
+reg = <0x400>;
+};
+
+cpu5: cpu@5 {
+device_type = "cpu";
+compatible = "arm,cortex-a55";
+enable-method = "psci";
+mtk-freq-domain = <_hw 1>;
+reg = <0x500>;
+};
+
+cpu6: cpu@6 {
+device_type = "cpu";
+compatible = "arm,cortex-a75";
+enable-method = "psci";
+mtk-freq-domain = <_hw 1>;
+reg = <0x600>;
+};
+
+cpu7: cpu@7 {
+device_type = "cpu";
+compatible = "arm,cortex-a75";
+enable-method = "psci";
+mtk-freq-domain = <_hw 1>;
+reg = <0x700>;
+};
+};
+
+/* ... */
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+cpufreq_hw: cpufreq@11bc00 {
+compatible = "mediatek,cpufreq-hw";
+reg = <0 0x11bc10 0 0x8c>,
+ <0 0x11bca0 0 0x8c>;
+reg-names = "freq-domain0", "freq-domain1";
+#freq-domain-cells = <1>;
+};
+};
+
+
+
+
--
1.7.9.5
[PATCH v7 1/2] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
From: "Hector.Yuan"
Add MT6779 cpufreq HW support.
Signed-off-by: Hector.Yuan
---
drivers/cpufreq/Kconfig.arm | 12 ++
drivers/cpufreq/Makefile |1 +
drivers/cpufreq/mediatek-cpufreq-hw.c | 277 +
3 files changed, 290 insertions(+)
create mode 100644 drivers/cpufreq/mediatek-cpufreq-hw.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index c6cbfc8..8e58c12 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -121,6 +121,18 @@ config ARM_MEDIATEK_CPUFREQ
help
This adds the CPUFreq driver support for MediaTek SoCs.
+config ARM_MEDIATEK_CPUFREQ_HW
+ tristate "MediaTek CPUFreq HW driver"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ default m
+ help
+ Support for the CPUFreq HW driver.
+ Some MediaTek chipsets have a HW engine to offload the steps
+ necessary for changing the frequency of the CPUs. Firmware loaded
+ in this engine exposes a programming interface to the OS.
+ The driver implements the cpufreq interface for this HW engine.
+ Say Y if you want to support CPUFreq HW.
+
config ARM_OMAP2PLUS_CPUFREQ
bool "TI OMAP2+"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index f6670c4..dc1f371 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_ARM_IMX6Q_CPUFREQ) +=
imx6q-cpufreq.o
obj-$(CONFIG_ARM_IMX_CPUFREQ_DT) += imx-cpufreq-dt.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ) += mediatek-cpufreq.o
+obj-$(CONFIG_ARM_MEDIATEK_CPUFREQ_HW) += mediatek-cpufreq-hw.o
obj-$(CONFIG_MACH_MVEBU_V7)+= mvebu-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
diff --git a/drivers/cpufreq/mediatek-cpufreq-hw.c
b/drivers/cpufreq/mediatek-cpufreq-hw.c
new file mode 100644
index 000..8fa12e5
--- /dev/null
+++ b/drivers/cpufreq/mediatek-cpufreq-hw.c
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LUT_MAX_ENTRIES32U
+#define LUT_FREQ GENMASK(11, 0)
+#define LUT_ROW_SIZE 0x4
+
+enum {
+ REG_LUT_TABLE,
+ REG_ENABLE,
+ REG_PERF_STATE,
+
+ REG_ARRAY_SIZE,
+};
+
+struct cpufreq_mtk {
+ struct cpufreq_frequency_table *table;
+ void __iomem *reg_bases[REG_ARRAY_SIZE];
+ cpumask_t related_cpus;
+};
+
+static const u16 cpufreq_mtk_offsets[REG_ARRAY_SIZE] = {
+ [REG_LUT_TABLE] = 0x0,
+ [REG_ENABLE]= 0x84,
+ [REG_PERF_STATE]= 0x88,
+};
+
+static struct cpufreq_mtk *mtk_freq_domain_map[NR_CPUS];
+
+static int mtk_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+ unsigned int index)
+{
+ struct cpufreq_mtk *c = policy->driver_data;
+
+ writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+ return 0;
+}
+
+static unsigned int mtk_cpufreq_hw_get(unsigned int cpu)
+{
+ struct cpufreq_mtk *c;
+ unsigned int index;
+
+ c = mtk_freq_domain_map[cpu];
+
+ index = readl_relaxed(c->reg_bases[REG_PERF_STATE]);
+ index = min(index, LUT_MAX_ENTRIES - 1);
+
+ return c->table[index].frequency;
+}
+
+static int mtk_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
+{
+ struct cpufreq_mtk *c;
+
+ c = mtk_freq_domain_map[policy->cpu];
+ if (!c) {
+ pr_err("No scaling support for CPU%d\n", policy->cpu);
+ return -ENODEV;
+ }
+
+ cpumask_copy(policy->cpus, >related_cpus);
+
+ policy->freq_table = c->table;
+ policy->driver_data = c;
+
+ /* HW should be in enabled state to proceed now */
+ writel_relaxed(0x1, c->reg_bases[REG_ENABLE]);
+
+ return 0;
+}
+
+static int mtk_cpufreq_hw_cpu_exit(struct cpufreq_policy *policy)
+{
+ struct cpufreq_mtk *c;
+
+ c = mtk_freq_domain_map[policy->cpu];
+ if (!c) {
+ pr_err("No scaling support for CPU%d\n", policy->cpu);
+ return -ENODEV;
+ }
+
+ /* HW should be in paused state now */
+ writel_relaxed(0x0, c->reg_bases[REG_ENABLE]);
+
+ return 0;
+}
+
+static struct cpufreq_driver cpufreq_mtk_hw_driver = {
+ .flags = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+ CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
+ .verify = cpufreq_generic_frequency_table_verify,
+ .target_index = mtk_cpufreq_hw_target_index,
+ .get= mtk_cpufreq_hw_get,
+ .init = mtk_cpufreq_hw_cpu_init,
+ .exit =
Re: [Nouveau] [PATCH] drm/nouveau: Add fine-grain temperature reporting
On Thu, 10 Sep 2020 at 00:07, Jeremy Cline wrote:
>
> On Wed, Sep 09, 2020 at 10:22:14AM +0200, Karol Herbst wrote:
> > On Wed, Sep 9, 2020 at 6:06 AM Ben Skeggs wrote:
> > >
> > > On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote:
> > > >
> > > > Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of
> > > > new gp1xx temperature sensor") added support for reading finer-grain
> > > > temperatures, but continued to report temperatures in 1 degree Celsius
> > > > increments via nvkm_therm_temp_get().
> > > >
> > > > Rather than altering nvkm_therm_temp_get() to report finer-grain
> > > > temperatures, which would be inconvenient for other users of the
> > > > function, a second interface has been added to line up with hwmon's
> > > > native unit of temperature.
> > > Hey Jeremy,
> > >
> > > Sorry this slipped past me until now. I'm OK with adding support for
> > > millidegree temperature reporting, but don't think we need to keep
> > > both interfaces around and would rather see the existing code
> > > converted to return millidegrees (even on GPUs that don't support it)
> > > instead of degrees.
> > >
> > > Thanks!
> > > Ben.
> > >
> >
> > just a note as I was trying something like that in the past: we have a
> > lot of code which fetches the temperature and there are a lot of
> > places where we would then do a divide by 1000, so having a wrapper
> > function at least makes sense. If we want to keep the func pointers?
> > well.. I guess the increased CPU overhead wouldn't be as bad if all
> > sub classes do this static * 1000 as well either. I just think we
> > should have both interfaces in subdev/therm.h so we can just keep most
> > of the current code as is.
> >
>
> Indeed. My initial plan was to change the meaning of temp_get() and
> adjust all the users, but there's around a dozen of them and based on my
> understanding of the users none of them cared much about such accuracy.
>
> However, I do find having one way to do things appealing, so if there's
> a strong preference for it, I'm happy to produce a somewhat more
> invasive patch where all users expect millidegrees.
Yeah, I do have a strong preference for not having to keep multiple
interfaces around unnecessarily. It'd be somewhat different if we had
external interactions, but this is all stuff within the module and we
should be able to make these kinds of changes without too much pain.
Ben.
>
> - Jeremy
>
linux-next: manual merge of the extcon tree with the drm-misc tree
Hi all,
Today's linux-next merge of the extcon tree got a conflict in:
MAINTAINERS
between commit:
f61249dddecc ("MAINTAINERS: Add entry for i.MX 8MQ DCSS driver")
from the drm-misc tree and commit:
d0e3c25150dd ("MAINTAINERS: Add entry for NXP PTN5150A CC driver")
from the extcon tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc MAINTAINERS
index 623c53ab5bd5,da94c9b12f1b..
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@@ -12496,14 -12430,13 +12496,21 @@@ F:
drivers/iio/gyro/fxas21002c_core.
F:drivers/iio/gyro/fxas21002c_i2c.c
F:drivers/iio/gyro/fxas21002c_spi.c
+NXP i.MX 8MQ DCSS DRIVER
+M:Laurentiu Palcu
+R:Lucas Stach
+L:dri-de...@lists.freedesktop.org
+S:Maintained
+F:Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
+F:drivers/gpu/drm/imx/dcss/
+
+ NXP PTN5150A CC LOGIC AND EXTCON DRIVER
+ M:Krzysztof Kozlowski
+ L:linux-kernel@vger.kernel.org
+ S:Maintained
+ F:Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
+ F:drivers/extcon/extcon-ptn5150.c
+
NXP SGTL5000 DRIVER
M:Fabio Estevam
L:alsa-de...@alsa-project.org (moderated for non-subscribers)
pgpYtRtRF1q3b.pgp
Description: OpenPGP digital signature
[PATCH 2/2] spi: spi-mtk-nor: support 36bit dma addressing to mediatek spi-nor
This patch enables direct mappings over 32bit range to spi-mtk-nor.
Signed-off-by: Ikjoon Jang
---
drivers/spi/spi-mtk-nor.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-mtk-nor.c b/drivers/spi/spi-mtk-nor.c
index 6e6ca2b8e6c8..eb93ae34e670 100644
--- a/drivers/spi/spi-mtk-nor.c
+++ b/drivers/spi/spi-mtk-nor.c
@@ -78,6 +78,8 @@
#define MTK_NOR_REG_DMA_FADR 0x71c
#define MTK_NOR_REG_DMA_DADR 0x720
#define MTK_NOR_REG_DMA_END_DADR 0x724
+#define MTK_NOR_REG_DMA_DADR_HB0x738
+#define MTK_NOR_REG_DMA_END_DADR_HB0x73c
#define MTK_NOR_PRG_MAX_SIZE 6
// Reading DMA src/dst addresses have to be 16-byte aligned
@@ -101,6 +103,7 @@ struct mtk_nor {
unsigned int spi_freq;
bool wbuf_en;
bool has_irq;
+ bool high_dma;
struct completion op_done;
};
@@ -279,6 +282,11 @@ static int mtk_nor_read_dma(struct mtk_nor *sp, u32 from,
unsigned int length,
writel(dma_addr, sp->base + MTK_NOR_REG_DMA_DADR);
writel(dma_addr + length, sp->base + MTK_NOR_REG_DMA_END_DADR);
+ if (sp->high_dma) {
+ writel(dma_addr >> 32, sp->base + MTK_NOR_REG_DMA_DADR_HB);
+ writel((dma_addr + length) >> 32, sp->base +
MTK_NOR_REG_DMA_END_DADR_HB);
+ }
+
if (sp->has_irq) {
reinit_completion(>op_done);
mtk_nor_rmw(sp, MTK_NOR_REG_IRQ_EN, MTK_NOR_IRQ_DMA, 0);
@@ -578,7 +586,8 @@ static const struct spi_controller_mem_ops mtk_nor_mem_ops
= {
};
static const struct of_device_id mtk_nor_match[] = {
- { .compatible = "mediatek,mt8173-nor" },
+ { .compatible = "mediatek,mt8192-nor", .data = (void *)36 },
+ { .compatible = "mediatek,mt8173-nor", .data = (void *)32 },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mtk_nor_match);
@@ -591,6 +600,7 @@ static int mtk_nor_probe(struct platform_device *pdev)
u8 *buffer;
struct clk *spi_clk, *ctlr_clk;
int ret, irq;
+ unsigned long dma_bits;
base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(base))
@@ -614,6 +624,12 @@ static int mtk_nor_probe(struct platform_device *pdev)
buffer = (u8 *)(((ulong)buffer + MTK_NOR_DMA_ALIGN) &
~MTK_NOR_DMA_ALIGN_MASK);
+ dma_bits = (unsigned long)of_device_get_match_data(>dev);
+ if (dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(dma_bits))) {
+ dev_err(>dev, "failed to set dma mask(%lu)\n", dma_bits);
+ return -EINVAL;
+ }
+
ctlr = spi_alloc_master(>dev, sizeof(*sp));
if (!ctlr) {
dev_err(>dev, "failed to allocate spi controller\n");
@@ -640,6 +656,7 @@ static int mtk_nor_probe(struct platform_device *pdev)
sp->dev = >dev;
sp->spi_clk = spi_clk;
sp->ctlr_clk = ctlr_clk;
+ sp->high_dma = (dma_bits > 32);
irq = platform_get_irq_optional(pdev, 0);
if (irq < 0) {
--
2.28.0.526.ge36021eeef-goog
Re: linux-next: Tree for Aug 26
Hi all, On Mon, 7 Sep 2020 10:55:47 +0200 Anders Roxell wrote: > > On Thu, 3 Sep 2020 at 18:14, Paul E. McKenney wrote: > > > > On Thu, Sep 03, 2020 at 10:39:10AM +0200, Anders Roxell wrote: > > > Hi Paul, > > > > > > On Sat, 29 Aug 2020 at 00:59, Paul E. McKenney > > > wrote: > > > > > > > > On Fri, Aug 28, 2020 at 09:24:19PM +0200, Anders Roxell wrote: > > > > > On Fri, 28 Aug 2020 at 15:29, Paul E. McKenney > > > > > wrote: > > > > > > > > > > > > On Fri, Aug 28, 2020 at 09:37:17AM +0200, Anders Roxell wrote: > > > > > > > On Wed, 26 Aug 2020 at 21:39, Paul E. McKenney > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Aug 26, 2020 at 08:19:01PM +0200, Anders Roxell wrote: > > > > > > > > > On Wed, 26 Aug 2020 at 08:33, Stephen Rothwell > > > > > > > > > wrote: > > > > > > > > > > > > > > > > [ . . . ] > > > > > > > > > > > > > > > > > I've built and run an arm64 allmodconfig kernel where I use > > > > > > > > > the > > > > > > > > > defconfig as the base, I do this for testing purposes. > > > > > > > > > I can see the following call trace [1]: > > > > > > > > > > > > > > > > > > [ 2595.811453][T1] Running tests on all trace events: > > > > > > > > > [ 2595.860933][T1] Testing all events: > > > > > > > > > [ 4316.066072][T8] kworker/dying (8) used greatest stack > > > > > > > > > depth: > > > > > > > > > 27056 bytes left > > > > > > > > > [ 8561.924871][C0] watchdog: BUG: soft lockup - CPU#0 > > > > > > > > > stuck for > > > > > > > > > 22s! [migration/0:14] > > > > > > > > > [ 8561.934498][C0] Modules linked in: > > > > > > > > > [ 8561.942303][C0] irq event stamp: 4044 > > > > > > > > > [ 8561.949044][C0] hardirqs last enabled at (4043): > > > > > > > > > [] _raw_spin_unlock_irqrestore+0xac/0x138 > > > > > > > > > [ 8561.960848][C0] hardirqs last disabled at (4044): > > > > > > > > > [] __schedule+0xf8/0x7e0 > > > > > > > > > [ 8561.971418][C0] softirqs last enabled at (3698): > > > > > > > > > [] __do_softirq+0x524/0x5f8 > > > > > > > > > [ 8561.982191][C0] softirqs last disabled at (3689): > > > > > > > > > [] __irq_exit_rcu+0x128/0x1a0 > > > > > > > > > [ 8561.993068][C0] CPU: 0 PID: 14 Comm: migration/0 > > > > > > > > > Tainted: G > > > > > > > > >W 5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1 > > > > > > > > > [ 8562.005684][C0] Hardware name: linux,dummy-virt (DT) > > > > > > > > > [ 8562.013247][C0] pstate: 8045 (Nzcv daif +PAN -UAO > > > > > > > > > BTYPE=--) > > > > > > > > > [ 8562.021657][C0] pc : arch_local_irq_enable+0x58/0x80 > > > > > > > > > [ 8562.029323][C0] lr : _raw_spin_unlock_irq+0x84/0xc0 > > > > > > > > > [ 8562.036739][C0] sp : 698efaa0 > > > > > > > > > [ 8562.042984][C0] x29: 698efaa0 x28: > > > > > > > > > 6ad0f270 > > > > > > > > > [ 8562.053814][C0] x27: 6ad0f248 x26: > > > > > > > > > 698d4718 > > > > > > > > > [ 8562.064687][C0] x25: 6ad0e798 x24: > > > > > > > > > a000139e3a40 > > > > > > > > > [ 8562.075506][C0] x23: 0001 x22: > > > > > > > > > a000154f5000 > > > > > > > > > [ 8562.086425][C0] x21: 6ad0e798 x20: > > > > > > > > > 6ad0e780 > > > > > > > > > [ 8562.097255][C0] x19: a000126a905c x18: > > > > > > > > > 14c0 > > > > > > > > > [ 8562.108071][C0] x17: 1500 x16: > > > > > > > > > 1440 > > > > > > > > > [ 8562.118918][C0] x15: f1f1f1f1 x14: > > > > > > > > > 003d0900 > > > > > > > > > [ 8562.129739][C0] x13: 3d09 x12: > > > > > > > > > 8d31df41 > > > > > > > > > [ 8562.140544][C0] x11: 1fffed31df40 x10: > > > > > > > > > 8d31df40 > > > > > > > > > [ 8562.151366][C0] x9 : dfffa000 x8 : > > > > > > > > > 698efa07 > > > > > > > > > [ 8562.162247][C0] x7 : 0001 x6 : > > > > > > > > > 72ce20c0 > > > > > > > > > [ 8562.173072][C0] x5 : 698d4040 x4 : > > > > > > > > > dfffa000 > > > > > > > > > [ 8562.183954][C0] x3 : a0001040f904 x2 : > > > > > > > > > 0007 > > > > > > > > > [ 8562.194811][C0] x1 : a0001408 x0 : > > > > > > > > > 00e0 > > > > > > > > > [ 8562.205858][C0] Call trace: > > > > > > > > > [ 8562.211739][C0] arch_local_irq_enable+0x58/0x80 > > > > > > > > > [ 8562.219076][C0] _raw_spin_unlock_irq+0x84/0xc0 > > > > > > > > > [ 8562.226394][C0] __schedule+0x75c/0x7e0 > > > > > > > > > [ 8562.233074][C0] preempt_schedule_notrace+0x64/0xc0 > > > > > > > > > [ 8562.268210][C0] ftrace_ops_list_func+0x494/0x4e0 > > > > > > > > > [ 8562.275735][C0] ftrace_graph_call+0x0/0x4 > > > > > > > > > [ 8562.282647][C0] preempt_count_add+0xc/0x240 > > > > > > > > > [ 8562.289686][C0] schedule+0xe4/0x160 > > > > > > > > > [ 8562.296187][C0]
[PATCH 1/2] dt-bindings: spi: add mt8192-nor compatible string
Add MT8192 spi-nor controller binding. Signed-off-by: Ikjoon Jang --- Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml index 42c9205ac991..55c239446a5b 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml @@ -30,6 +30,7 @@ properties: - mediatek,mt7622-nor - mediatek,mt7623-nor - mediatek,mt7629-nor + - mediatek,mt8192-nor - enum: - mediatek,mt8173-nor - items: -- 2.28.0.526.ge36021eeef-goog
[PATCH v3 0/3] Introduce mini-dump support for remoteproc
Sometimes firmware sizes can be in ten's of MB's and reading all the memory during coredump can consume lot of time and memory. Introducing support for mini-dumps. Mini-dump contains smallest amount of useful information, that could help to debug subsystem crashes. During bootup memory is allocated in SMEM (Shared memory) in the form of a table that contains the physical addresses and sizes of the regions that are supposed to be collected during coredump. This memory is shared amongst all processors in a Qualcomm platform, so all remoteprocs fill in their entry in the global table once they are out of reset. This patch series adds support for parsing the global minidump table and uses the current coredump frameork to expose this memory to userspace during remoteproc's recovery. This patch series also integrates the patch: https://patchwork.kernel.org/patch/11695541/ sent by Siddharth. Changelog: v2 -> v3: - Refactored code to remove dependency on Qualcomm configs. - Renamed do_rproc_minidump to rproc_minidump and marked as exported symbol. v1 -> v2: - 3 kernel test robot warnings have been resolved. - Introduced priv_cleanup op in order to making the cleaning of private elements used by the remoteproc more readable. - Removed rproc_cleanup_priv as it is no longer needed. - Switched to if/else format for rproc_alloc in order to keep the static const decalaration of adsp_minidump_ops. Siddharth Gupta (3): remoteproc: core: Add ops to enable custom coredump functionality remoteproc: qcom: Add capability to collect minidumps remoteproc: qcom: Add minidump id for sm8150 modem remoteproc drivers/remoteproc/qcom_minidump.h | 64 + drivers/remoteproc/qcom_q6v5_pas.c | 107 - drivers/remoteproc/remoteproc_core.c| 6 +- drivers/remoteproc/remoteproc_coredump.c| 138 drivers/remoteproc/remoteproc_elf_helpers.h | 27 ++ include/linux/remoteproc.h | 5 + 6 files changed, 344 insertions(+), 3 deletions(-) create mode 100644 drivers/remoteproc/qcom_minidump.h -- Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: linux-next: build failure after merge of the nand tree
Hi all,
On Tue, 8 Sep 2020 13:35:36 +1000 Stephen Rothwell
wrote:
>
> After merging the nand tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c: In function
> 'common_nfc_set_geometry':
> drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c:513:33: error: 'chip' undeclared
> (first use in this function)
> 513 | nanddev_get_ecc_requirements(>base);
> | ^~~~
> drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c:513:33: note: each undeclared
> identifier is reported only once for each function it appears in
>
> Caused by commit
>
> aa5faaa5f95c ("mtd: rawnand: Use nanddev_get/set_ecc_requirements() when
> relevant")
>
> I have used the nand tree from next-20200903 for today.
I am still getting this failure.
--
Cheers,
Stephen Rothwell
pgpfjeodxwqGl.pgp
Description: OpenPGP digital signature
[PATCH 0/2] Add 36bit dma support to mediatek spi-nor controller.
mt8192-nor has 36bit addressing support, this patch adds 36bit address handlings to spi-mtk-nor. Ikjoon Jang (2): dt-bindings: spi: add mt8192-nor compatible string spi: spi-mtk-nor: support 36bit dma addressing to mediatek spi-nor .../bindings/spi/mediatek,spi-mtk-nor.yaml| 1 + drivers/spi/spi-mtk-nor.c | 19 ++- 2 files changed, 19 insertions(+), 1 deletion(-) -- 2.28.0.526.ge36021eeef-goog
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On Wed, Sep 9, 2020 at 9:47 PM Hector Martin "marcan"
wrote:
>
>
>
> On September 10, 2020 12:40:59 PM GMT+09:00, James Hilliard
> wrote:
> >On Wed, Sep 9, 2020 at 9:02 PM Oliver Neukum wrote:
> >>
> >> Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
> >> > This patch detects and reverses the effects of the malicious FTDI
> >> > Windows driver version 2.12.00(FTDIgate).
> >>
> >> Hi,
> >>
> >> this raises questions.
> >> Should we do this unconditionally without asking?
> >Well I think since we can reliably detect devices that have been
> >bricked by the malicious windows driver it's fine. I was careful to
> >ensure that this will bail out and not try to change anything unless
> >all
> >conditions match this specific brick attack.
> >> Does this belong into kernel space?
> >This seemed to be by far the simplest option for embedded systems
> >that need to automatically detect and repair the bricked eeproms.
> >
> >People seem to have plugged a bunch of counterfeit FTDI Arduino's
> >that normally attach to an embedded Linux host into windows for
> >some reason for a kiosk platform of mine which messed up the
> >userspace detection/mappings. This seemed like the best way to
> >avoid this being a support issue requiring manual unbricking
> >prochedures.
>
> If you need to update the kernel on this platform anyway to use this feature,
> why not just introduce a userspace script to fix the bricked units instead?
I considered that but it appeared to be far more complex as I would
have to validate all the interactions with my other userspace apps.
I haven't tested this but I suspect there may also be issues having
userspace code access these control messages, especially since
I build the ftdi_sio driver into my kernels rather than using a module.
>
> Needing this autofixed seems like somewhat of a niche use case better served
> by a script on platforms where it might be a problem, rather than upstream
> kernel code.
I figured this would be useful for anyone with these bricked devices
as I have wasted a lot of time debugging this issue since I wasn't
expecting the ID's to have changed.
I'm assuming it happened because I use USB hubs and firmware was
being flashed for different hub attached hardware devices by moving
the entire hub to Windows even though the userspace arduino control
application doesn't run on Windows at the moment.
I can't think of any case where this would be harmful as I have
plenty of sanity checks before fixing the brick to ensure it only
unbricks devices that have the preimage attack signature.
This is an annoying enough issue that I think autofixing makes sense
simply so that everyone can avoid wasting time debugging the issue
manually.
>
> >>
> >> > +static int ftdi_repair_brick(struct usb_serial_port *port)
> >> > +{
> >> > + struct ftdi_private *priv = usb_get_serial_port_data(port);
> >> > + int orig_latency;
> >> > + int rv;
> >> > + u16 *eeprom_data;
> >> > + u16 checksum;
> >> > + int eeprom_size;
> >> > + int result;
> >> > +
> >> > + switch (priv->chip_type) {
> >> > + case FT232RL:
> >> > + eeprom_size = 0x40;
> >> > + break;
> >> > + default:
> >> > + /* Unsupported for brick repair */
> >> > + return 0;
> >> > + }
> >> > +
> >> > + /* Latency timer needs to be 0x77 to unlock EEPROM
> >programming */
> >> > + if (priv->latency != 0x77) {
> >> > + orig_latency = priv->latency;
> >> > + priv->latency = 0x77;
> >> > + rv = write_latency_timer(port);
> >> > + priv->latency = orig_latency;
> >> > + if (rv < 0)
> >> > + return -EIO;
> >> > + }
> >>
> >> Do you really want to change this without returning to the original?
> >> @@ -2255,6 +2364,12 @@ static int ftdi_sio_port_probe(struct
> >usb_serial_port *port)
> >> ftdi_set_max_packet_size(port);
> >> if (read_latency_timer(port) < 0)
> >> priv->latency = 16;
> >> + vendor_id =
> >le16_to_cpu(port->serial->dev->descriptor.idVendor);
> >> + product_id =
> >le16_to_cpu(port->serial->dev->descriptor.idProduct);
> >> + if (vendor_id == FTDI_VID &&
> >> + product_id == FTDI_BRICK_PID &&
> >> + priv->chip_type == FT232RL)
> >> + ftdi_repair_brick(port);
> >> write_latency_timer(port);
> >It should get restored here.
> >> create_sysfs_attrs(port);
> >>
> >>
> >> Regards
> >> Oliver
> >>
>
> --
> Hector Martin "marcan" (hec...@marcansoft.com)
> Public key: https://mrcn.st/pub
[PATCH] brcmsmac: phytbl_lcn: Remove unused variable 'dot11lcn_gain_tbl_rev1'
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.c:108:18:
warning: ‘dot11lcn_gain_tbl_rev1’ defined but not used
[-Wunused-const-variable=]
static const u32 dot11lcn_gain_tbl_rev1[] = {
^~
commit ebcfc66f56a4 ("brcmsmac: phytbl_lcn: Remove unused array
'dot11lcnphytbl_rx_gain_info_rev1'")
left behind this, remove it.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
.../brcm80211/brcmsmac/phy/phytbl_lcn.c | 99 ---
1 file changed, 99 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.c
index 7526aa441de1..5331b5468e14 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phytbl_lcn.c
@@ -105,105 +105,6 @@ static const u32 dot11lcn_gain_tbl_rev0[] = {
0x,
};
-static const u32 dot11lcn_gain_tbl_rev1[] = {
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x0008,
- 0x0004,
- 0x0008,
- 0x0001,
- 0x0005,
- 0x0009,
- 0x000D,
- 0x0011,
- 0x0051,
- 0x0091,
- 0x0011,
- 0x0051,
- 0x0091,
- 0x00d1,
- 0x0053,
- 0x0093,
- 0x00d3,
- 0x00d7,
- 0x0117,
- 0x0517,
- 0x0917,
- 0x0957,
- 0x0d57,
- 0x1157,
- 0x1197,
- 0x5197,
- 0x9197,
- 0xd197,
- 0x00011197,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x0008,
- 0x0004,
- 0x0008,
- 0x0001,
- 0x0005,
- 0x0009,
- 0x000D,
- 0x0011,
- 0x0051,
- 0x0091,
- 0x0011,
- 0x0051,
- 0x0091,
- 0x00d1,
- 0x0053,
- 0x0093,
- 0x00d3,
- 0x00d7,
- 0x0117,
- 0x0517,
- 0x0917,
- 0x0957,
- 0x0d57,
- 0x1157,
- 0x5157,
- 0x9157,
- 0xd157,
- 0x00011157,
- 0x00015157,
- 0x00019157,
- 0x0001d157,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
- 0x,
-};
-
static const u16 dot11lcn_aux_gain_idx_tbl_rev0[] = {
0x0401,
0x0402,
--
2.17.1
[PATCH] brcmsmac: phy_lcn: Remove unused variable lcnphy_rx_iqcomp_table_rev0
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c:361:25: warning:
‘lcnphy_rx_iqcomp_table_rev0’ defined but not used [-Wunused-const-variable=]
struct lcnphy_rx_iqcomp lcnphy_rx_iqcomp_table_rev0[] = {
^~~
commit 38c95e0258a0 ("brcmsmac: phy_lcn: Remove a bunch of unused variables")
left behind this, remove it.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
.../broadcom/brcm80211/brcmsmac/phy/phy_lcn.c | 55 ---
1 file changed, 55 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
index b8193c99e864..7071b63042cd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_lcn.c
@@ -357,61 +357,6 @@ u16 rxiq_cal_rf_reg[11] = {
RADIO_2064_REG12A,
};
-static const
-struct lcnphy_rx_iqcomp lcnphy_rx_iqcomp_table_rev0[] = {
- {1, 0, 0},
- {2, 0, 0},
- {3, 0, 0},
- {4, 0, 0},
- {5, 0, 0},
- {6, 0, 0},
- {7, 0, 0},
- {8, 0, 0},
- {9, 0, 0},
- {10, 0, 0},
- {11, 0, 0},
- {12, 0, 0},
- {13, 0, 0},
- {14, 0, 0},
- {34, 0, 0},
- {38, 0, 0},
- {42, 0, 0},
- {46, 0, 0},
- {36, 0, 0},
- {40, 0, 0},
- {44, 0, 0},
- {48, 0, 0},
- {52, 0, 0},
- {56, 0, 0},
- {60, 0, 0},
- {64, 0, 0},
- {100, 0, 0},
- {104, 0, 0},
- {108, 0, 0},
- {112, 0, 0},
- {116, 0, 0},
- {120, 0, 0},
- {124, 0, 0},
- {128, 0, 0},
- {132, 0, 0},
- {136, 0, 0},
- {140, 0, 0},
- {149, 0, 0},
- {153, 0, 0},
- {157, 0, 0},
- {161, 0, 0},
- {165, 0, 0},
- {184, 0, 0},
- {188, 0, 0},
- {192, 0, 0},
- {196, 0, 0},
- {200, 0, 0},
- {204, 0, 0},
- {208, 0, 0},
- {212, 0, 0},
- {216, 0, 0},
-};
-
static const u32 lcnphy_23bitgaincode_table[] = {
0x200100,
0x200200,
--
2.17.1
Re: [PATCH v8 1/2] fpga: dfl: create a dfl bus type to support DFL devices
> > > Applied to for-next, > > (I added the Documentation/ABI/testing...) file to MAINTAINERS. > > Please run checkpatch next time. Thanks for your fix. I run the checkpatch but I do ignored the warning about MAINTAINERS. I'll take care of it then. Thanks, Yilun > > Cheers, > Moritz
[PATCH -next] riscv/mm/fault: Fix old style declaration warning
Fix gcc build warning:
arch/riscv/mm/fault.c:81:1: warning: ‘inline’ is not at beginning of
declaration [-Wold-style-declaration]
static void inline vmalloc_fault(struct pt_regs *regs, int code, unsigned long
addr)
^~
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
arch/riscv/mm/fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index a23eaf5ce95c..a173432ccf82 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -78,7 +78,7 @@ static inline void bad_area(struct pt_regs *regs, struct
mm_struct *mm, int code
no_context(regs, addr);
}
-static void inline vmalloc_fault(struct pt_regs *regs, int code, unsigned long
addr)
+static inline void vmalloc_fault(struct pt_regs *regs, int code, unsigned long
addr)
{
pgd_t *pgd, *pgd_k;
pud_t *pud, *pud_k;
--
2.17.1
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On September 10, 2020 12:46:20 PM GMT+09:00, James Hilliard
wrote:
>On Wed, Sep 9, 2020 at 9:17 PM Hector Martin "marcan"
> wrote:
>>
>>
>>
>> On September 10, 2020 12:02:34 PM GMT+09:00, Oliver Neukum
> wrote:
>> >Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
>> >> This patch detects and reverses the effects of the malicious FTDI
>> >> Windows driver version 2.12.00(FTDIgate).
>> >
>> >Hi,
>> >
>> >this raises questions.
>> >Should we do this unconditionally without asking?
>> >Does this belong into kernel space?
>>
>> I agree; this is very cute, but does it really need to be an
>automatic Linux feature? Presumably someone looking to fix a bricked
>FTDI chip can just run my script, and those who just want to use those
>chips with Linux already can since the driver binds to the zero PID.
>Well for one your script is not easily useable with embedded platforms
>like mine where I ran into this issue, I have no python2 interpreter
>available in my production builds.
Surely you can port the exact same algorithm to plain userspace C, as you did
to kernel space C :)
>>
>> I am deeply amused by the idea of Linux automatically fixing problems
>caused by malicious Windows drivers, but thinking objectively, I'm not
>sure if that's the right thing to do.
>From my understanding Linux fixing up hardware issues caused
>by faulty/weird Windows drivers isn't exactly unusual.
I'm not aware of any instances like this where nonvolatile memory is modified.
At most you'll get things like resetting devices that a previous windows warm
boot misconfigured, I think?
>>
>> >
>> >> +static int ftdi_repair_brick(struct usb_serial_port *port)
>> >> +{
>> >> +struct ftdi_private *priv = usb_get_serial_port_data(port);
>> >> +int orig_latency;
>> >> +int rv;
>> >> +u16 *eeprom_data;
>> >> +u16 checksum;
>> >> +int eeprom_size;
>> >> +int result;
>> >> +
>> >> +switch (priv->chip_type) {
>> >> +case FT232RL:
>> >> +eeprom_size = 0x40;
>> >> +break;
>> >> +default:
>> >> +/* Unsupported for brick repair */
>> >> +return 0;
>> >> +}
>> >> +
>> >> +/* Latency timer needs to be 0x77 to unlock EEPROM
>programming */
>> >> +if (priv->latency != 0x77) {
>> >> +orig_latency = priv->latency;
>> >> +priv->latency = 0x77;
>> >> +rv = write_latency_timer(port);
>> >> +priv->latency = orig_latency;
>> >> +if (rv < 0)
>> >> +return -EIO;
>> >> +}
>> >
>> >Do you really want to change this without returning to the original?
>> >
>> > Regards
>> > Oliver
>>
>> --
>> Hector Martin "marcan" (hec...@marcansoft.com)
>> Public key: https://mrcn.st/pub
--
Hector Martin "marcan" (hec...@marcansoft.com)
Public key: https://mrcn.st/pub
Re: [PATCH v6 1/2] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
On Thu, 2020-09-10 at 09:12 +0530, Viresh Kumar wrote:
> On 09-09-20, 21:34, Hector Yuan wrote:
> > +static unsigned int mtk_cpufreq_hw_get(unsigned int cpu)
> > +{
> > + struct cpufreq_mtk *c;
> > + struct cpufreq_policy *policy;
> > + unsigned int index;
> > +
> > + policy = cpufreq_cpu_get_raw(cpu);
> > + if (!policy)
> > + return 0;
>
> Why didn't you drop policy as we discussed in previous version ?
>
Sorry I missed that. Thank you.
> > + c = mtk_freq_domain_map[cpu];
> > +
> > + index = readl_relaxed(c->reg_bases[REG_PERF_STATE]);
> > + index = min(index, LUT_MAX_ENTRIES - 1);
> > +
> > + return policy->freq_table[index].frequency;
>
> policy->freq_table and c->table are same, isn't it ?
>
Yes, you are right.
> > +}
> > +
> > +static struct platform_driver mtk_cpufreq_hw_driver = {
> > + .probe = mtk_cpufreq_hw_driver_probe,
> > + .remove = mtk_cpufreq_hw_driver_remove,
> > + .driver = {
> > + .name = "mtk-cpufreq-hw",
> > + .of_match_table = mtk_cpufreq_hw_match,
> > + },
> > +};
> > +
>
> Remove this blank line.
>
OK
> > +module_platform_driver(mtk_cpufreq_hw_driver);
> > +
> > +MODULE_DESCRIPTION("mtk CPUFREQ HW Driver");
>
> Maybe write this is "Mediatek cpufreq-hw driver" ?
>
OK
> > +MODULE_LICENSE("GPL v2");
> > --
> > 1.7.9.5
>
[v2,2/3] PCI: mediatek: Add new generation controller support
MediaTek's PCIe host controller has three generation HWs, the new generation HW is an individual bridge, it supoorts Gen3 speed and up to 256 MSI interrupt numbers for multi-function devices. Add support for new Gen3 controller which can be found on MT8192. Signed-off-by: Jianjun Wang Acked-by: Ryder Lee --- drivers/pci/controller/Kconfig | 14 + drivers/pci/controller/Makefile |1 + drivers/pci/controller/pcie-mediatek-gen3.c | 1076 +++ 3 files changed, 1091 insertions(+) create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig index f18c3725ef80..83daa772595b 100644 --- a/drivers/pci/controller/Kconfig +++ b/drivers/pci/controller/Kconfig @@ -239,6 +239,20 @@ config PCIE_MEDIATEK Say Y here if you want to enable PCIe controller support on MediaTek SoCs. +config PCIE_MEDIATEK_GEN3 + tristate "MediaTek GEN3 PCIe controller" + depends on ARCH_MEDIATEK || COMPILE_TEST + depends on OF + depends on PCI_MSI_IRQ_DOMAIN + help + Adds support for PCIe Gen3 MAC controller for MediaTek SoCs. + This PCIe controller provides the capable of Gen3, Gen2 and + Gen1 speed, and support up to 256 MSI interrupt numbers for + multi-function devices. + + Say Y here if you want to enable Gen3 PCIe controller support on + MediaTek SoCs. + config PCIE_TANGO_SMP8759 bool "Tango SMP8759 PCIe controller (DANGEROUS)" depends on ARCH_TANGO && PCI_MSI && OF diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile index bcdbf49ab1e4..9c1b96777597 100644 --- a/drivers/pci/controller/Makefile +++ b/drivers/pci/controller/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o +obj-$(CONFIG_PCIE_MEDIATEK_GEN3) += pcie-mediatek-gen3.o obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o obj-$(CONFIG_VMD) += vmd.o obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c new file mode 100644 index ..f8c8bdf88d33 --- /dev/null +++ b/drivers/pci/controller/pcie-mediatek-gen3.c @@ -0,0 +1,1076 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * MediaTek PCIe host controller driver. + * + * Copyright (c) 2020 MediaTek Inc. + * Author: Jianjun Wang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../pci.h" + +#define PCIE_SETTING_REG 0x80 +#define PCIE_PCI_IDS_1 0x9c +#define PCI_CLASS(class) (class << 8) +#define PCIE_RC_MODE BIT(0) + +#define PCIE_CFGNUM_REG0x140 +#define PCIE_CFG_DEVFN(devfn) ((devfn) & GENMASK(7, 0)) +#define PCIE_CFG_BUS(bus) (((bus) << 8) & GENMASK(15, 8)) +#define PCIE_CFG_BYTE_EN(bytes)(((bytes) << 16) & GENMASK(19, 16)) +#define PCIE_CFG_FORCE_BYTE_EN BIT(20) +#define PCIE_CFG_OFFSET_ADDR 0x1000 +#define PCIE_CFG_HEADER(devfn, bus) \ + (PCIE_CFG_DEVFN(devfn) | PCIE_CFG_BUS(bus)) + +#define PCIE_CFG_HEADER_FORCE_BE(devfn, bus, bytes) \ + (PCIE_CFG_HEADER(devfn, bus) | PCIE_CFG_BYTE_EN(bytes) \ +| PCIE_CFG_FORCE_BYTE_EN) + +#define PCIE_RST_CTRL_REG 0x148 +#define PCIE_MAC_RSTB BIT(0) +#define PCIE_PHY_RSTB BIT(1) +#define PCIE_BRG_RSTB BIT(2) +#define PCIE_PE_RSTB BIT(3) + +#define PCIE_MISC_STATUS_REG 0x14C +#define PCIE_LTR_MSG_RECEIVED BIT(0) +#define PCIE_PCIE_MSG_RECEIVED BIT(1) + +#define PCIE_LTSSM_STATUS_REG 0x150 +#define PCIE_LTSSM_STATE_MASK GENMASK(28, 24) +#define PCIE_LTSSM_STATE(val) ((val & PCIE_LTSSM_STATE_MASK) >> 24) +#define PCIE_LTSSM_STATE_L00x10 +#define PCIE_LTSSM_STATE_L1_IDLE 0x13 +#define PCIE_LTSSM_STATE_L2_IDLE 0x14 + +#define PCIE_LINK_STATUS_REG 0x154 +#define PCIE_PORT_LINKUP BIT(8) + +#define PCIE_MSI_SET_NUM 8 +#define PCIE_MSI_IRQS_PER_SET 32 +#define PCIE_MSI_IRQS_NUM \ + (PCIE_MSI_IRQS_PER_SET * (PCIE_MSI_SET_NUM)) + +#define PCIE_INT_ENABLE_REG0x180 +#define PCIE_MSI_MASK GENMASK(PCIE_MSI_SET_NUM + 8 - 1, 8) +#define PCIE_MSI_SHIFT 8 +#define PCIE_INTX_SHIFT24 +#define PCIE_INTX_MASK GENMASK(27, 24) +#define PCIE_MSG_MASK BIT(28) +#define PCIE_AER_MASK BIT(29) +#define
[v2,3/3] MAINTAINERS: update entry for MediaTek PCIe controller
Add maintainer for MediaTek PCIe controller driver. Signed-off-by: Jianjun Wang Acked-by: Ryder Lee --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index deaafb617361..5c6110468526 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13459,6 +13459,7 @@ F: drivers/pci/controller/dwc/pcie-histb.c PCIE DRIVER FOR MEDIATEK M: Ryder Lee +M: Jianjun Wang L: linux-...@vger.kernel.org L: linux-media...@lists.infradead.org S: Supported -- 2.25.1
[v2,1/3] dt-bindings: PCI: mediatek: Add YAML schema
Add YAML schemas documentation for Gen3 PCIe controller on
MediaTek SoCs.
Signed-off-by: Jianjun Wang
Acked-by: Ryder Lee
---
.../bindings/pci/mediatek-pcie-gen3.yaml | 130 ++
1 file changed, 130 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
new file mode 100644
index ..a2dfc0d15d2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/mediatek-pcie-gen3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Gen3 PCIe controller on MediaTek SoCs
+
+maintainers:
+ - Jianjun Wang
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+ compatible:
+oneOf:
+ - const: mediatek,gen3-pcie
+ - const: mediatek,mt8192-pcie
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ bus-range:
+description: Range of bus numbers associated with this controller.
+
+ ranges:
+minItems: 1
+maxItems: 8
+
+ resets:
+minItems: 1
+maxItems: 2
+
+ reset-names:
+anyOf:
+ - const: mac-rst
+ - const: phy-rst
+
+ clocks:
+maxItems: 5
+
+ assigned-clocks:
+maxItems: 1
+
+ assigned-clock-parents:
+maxItems: 1
+
+ phys:
+maxItems: 1
+
+ '#interrupt-cells':
+const: 1
+
+ interrupt-controller:
+description: Interrupt controller node for handling legacy PCI interrupts.
+type: object
+properties:
+ '#address-cells':
+const: 0
+ '#interrupt-cells':
+const: 1
+ interrupt-controller: true
+
+required:
+ - '#address-cells'
+ - '#interrupt-cells'
+ - interrupt-controller
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ranges
+ - clocks
+ - '#interrupt-cells'
+ - interrupt-controller
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+#include
+
+bus {
+#address-cells = <2>;
+#size-cells = <2>;
+
+pcie: pcie@1123 {
+compatible = "mediatek,mt8192-pcie";
+device_type = "pci";
+#address-cells = <3>;
+#size-cells = <2>;
+reg = <0x00 0x1123 0x00 0x4000>;
+reg-names = "pcie-mac";
+interrupts = ;
+bus-range = <0x00 0xff>;
+ranges = <0x8200 0x00 0x1200 0x00 0x1200 0x00
0x100>;
+clocks = < 40>,
+ < 43>,
+ < 97>,
+ < 99>,
+ < 111>;
+assigned-clocks = < 50>;
+assigned-clock-parents = < 91>;
+
+phys = <>;
+phy-names = "pcie-phy";
+resets = <_rst 0>;
+reset-names = "phy-rst";
+
+#interrupt-cells = <1>;
+interrupt-map-mask = <0 0 0 0x7>;
+interrupt-map = <0 0 0 1 _intc 0>,
+<0 0 0 2 _intc 1>,
+<0 0 0 3 _intc 2>,
+<0 0 0 4 _intc 3>;
+pcie_intc: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+};
+};
+};
--
2.25.1
[v2,0/3] PCI: mediatek: Add new generation controller support
These series patches add pcie-mediatek-gen3.c and dt-bindings file to support new generation PCIe controller. Change in v2: 1. Fix the typo of dt-bindings patch 2. Remove the unnecessary properties in binding document 3. dispos the irq mappings of msi top domain when irq teardown Jianjun Wang (3): dt-bindings: PCI: mediatek: Add YAML schema PCI: mediatek: Add new generation controller support MAINTAINERS: update entry for MediaTek PCIe controller .../bindings/pci/mediatek-pcie-gen3.yaml | 130 ++ MAINTAINERS |1 + drivers/pci/controller/Kconfig| 14 + drivers/pci/controller/Makefile |1 + drivers/pci/controller/pcie-mediatek-gen3.c | 1076 + 5 files changed, 1222 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c -- 2.25.1
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On September 10, 2020 12:40:59 PM GMT+09:00, James Hilliard
wrote:
>On Wed, Sep 9, 2020 at 9:02 PM Oliver Neukum wrote:
>>
>> Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
>> > This patch detects and reverses the effects of the malicious FTDI
>> > Windows driver version 2.12.00(FTDIgate).
>>
>> Hi,
>>
>> this raises questions.
>> Should we do this unconditionally without asking?
>Well I think since we can reliably detect devices that have been
>bricked by the malicious windows driver it's fine. I was careful to
>ensure that this will bail out and not try to change anything unless
>all
>conditions match this specific brick attack.
>> Does this belong into kernel space?
>This seemed to be by far the simplest option for embedded systems
>that need to automatically detect and repair the bricked eeproms.
>
>People seem to have plugged a bunch of counterfeit FTDI Arduino's
>that normally attach to an embedded Linux host into windows for
>some reason for a kiosk platform of mine which messed up the
>userspace detection/mappings. This seemed like the best way to
>avoid this being a support issue requiring manual unbricking
>prochedures.
If you need to update the kernel on this platform anyway to use this feature,
why not just introduce a userspace script to fix the bricked units instead?
Needing this autofixed seems like somewhat of a niche use case better served by
a script on platforms where it might be a problem, rather than upstream kernel
code.
>>
>> > +static int ftdi_repair_brick(struct usb_serial_port *port)
>> > +{
>> > + struct ftdi_private *priv = usb_get_serial_port_data(port);
>> > + int orig_latency;
>> > + int rv;
>> > + u16 *eeprom_data;
>> > + u16 checksum;
>> > + int eeprom_size;
>> > + int result;
>> > +
>> > + switch (priv->chip_type) {
>> > + case FT232RL:
>> > + eeprom_size = 0x40;
>> > + break;
>> > + default:
>> > + /* Unsupported for brick repair */
>> > + return 0;
>> > + }
>> > +
>> > + /* Latency timer needs to be 0x77 to unlock EEPROM
>programming */
>> > + if (priv->latency != 0x77) {
>> > + orig_latency = priv->latency;
>> > + priv->latency = 0x77;
>> > + rv = write_latency_timer(port);
>> > + priv->latency = orig_latency;
>> > + if (rv < 0)
>> > + return -EIO;
>> > + }
>>
>> Do you really want to change this without returning to the original?
>> @@ -2255,6 +2364,12 @@ static int ftdi_sio_port_probe(struct
>usb_serial_port *port)
>> ftdi_set_max_packet_size(port);
>> if (read_latency_timer(port) < 0)
>> priv->latency = 16;
>> + vendor_id =
>le16_to_cpu(port->serial->dev->descriptor.idVendor);
>> + product_id =
>le16_to_cpu(port->serial->dev->descriptor.idProduct);
>> + if (vendor_id == FTDI_VID &&
>> + product_id == FTDI_BRICK_PID &&
>> + priv->chip_type == FT232RL)
>> + ftdi_repair_brick(port);
>> write_latency_timer(port);
>It should get restored here.
>> create_sysfs_attrs(port);
>>
>>
>> Regards
>> Oliver
>>
--
Hector Martin "marcan" (hec...@marcansoft.com)
Public key: https://mrcn.st/pub
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On Wed, Sep 9, 2020 at 9:17 PM Hector Martin "marcan"
wrote:
>
>
>
> On September 10, 2020 12:02:34 PM GMT+09:00, Oliver Neukum
> wrote:
> >Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
> >> This patch detects and reverses the effects of the malicious FTDI
> >> Windows driver version 2.12.00(FTDIgate).
> >
> >Hi,
> >
> >this raises questions.
> >Should we do this unconditionally without asking?
> >Does this belong into kernel space?
>
> I agree; this is very cute, but does it really need to be an automatic Linux
> feature? Presumably someone looking to fix a bricked FTDI chip can just run
> my script, and those who just want to use those chips with Linux already can
> since the driver binds to the zero PID.
Well for one your script is not easily useable with embedded platforms
like mine where I ran into this issue, I have no python2 interpreter
available in my production builds.
>
> I am deeply amused by the idea of Linux automatically fixing problems caused
> by malicious Windows drivers, but thinking objectively, I'm not sure if
> that's the right thing to do.
>From my understanding Linux fixing up hardware issues caused
by faulty/weird Windows drivers isn't exactly unusual.
>
> >
> >> +static int ftdi_repair_brick(struct usb_serial_port *port)
> >> +{
> >> +struct ftdi_private *priv = usb_get_serial_port_data(port);
> >> +int orig_latency;
> >> +int rv;
> >> +u16 *eeprom_data;
> >> +u16 checksum;
> >> +int eeprom_size;
> >> +int result;
> >> +
> >> +switch (priv->chip_type) {
> >> +case FT232RL:
> >> +eeprom_size = 0x40;
> >> +break;
> >> +default:
> >> +/* Unsupported for brick repair */
> >> +return 0;
> >> +}
> >> +
> >> +/* Latency timer needs to be 0x77 to unlock EEPROM programming */
> >> +if (priv->latency != 0x77) {
> >> +orig_latency = priv->latency;
> >> +priv->latency = 0x77;
> >> +rv = write_latency_timer(port);
> >> +priv->latency = orig_latency;
> >> +if (rv < 0)
> >> +return -EIO;
> >> +}
> >
> >Do you really want to change this without returning to the original?
> >
> > Regards
> > Oliver
>
> --
> Hector Martin "marcan" (hec...@marcansoft.com)
> Public key: https://mrcn.st/pub
Re: [PATCH] ide/macide: Convert Mac IDE driver to platform driver
Hi Finn, Am 10.09.2020 um 12:23 schrieb Finn Thain: + return 0; + +release_mem: + release_mem_region(mem->start, resource_size(mem)); Not needed, as you used devm_*() for allocation. OK, I'll remove this. I put it there after I looked at falconide.c and wondered whether the automatic release would take place after both init failure and exit (or just exit). I see now that pata_gayle.c does it differently. pata_gayle.c has probably seen more testing (in the platform environment), so I'd go with what's done there. Cheers, Michael
[PATCH -next] regulator: bd718x7: Make some variable static
Fix sparse warnings:
drivers/regulator/bd718x7-regulator.c:576:28: warning: symbol
'bd71847_swcontrol_ops' was not declared. Should it be static?
drivers/regulator/bd718x7-regulator.c:585:28: warning: symbol
'bd71847_hwcontrol_ops' was not declared. Should it be static?
drivers/regulator/bd718x7-regulator.c:902:28: warning: symbol
'bd71837_swcontrol_ops' was not declared. Should it be static?
drivers/regulator/bd718x7-regulator.c:913:28: warning: symbol
'bd71837_hwcontrol_ops' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/regulator/bd718x7-regulator.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/bd718x7-regulator.c
b/drivers/regulator/bd718x7-regulator.c
index 159c917b9c4c..0774467994fb 100644
--- a/drivers/regulator/bd718x7-regulator.c
+++ b/drivers/regulator/bd718x7-regulator.c
@@ -573,7 +573,7 @@ static int buck_set_hw_dvs_levels(struct device_node *np,
return rohm_regulator_set_dvs_levels(>dvs, np, desc, cfg->regmap);
}
-const struct regulator_ops *bd71847_swcontrol_ops[] = {
+static const struct regulator_ops *bd71847_swcontrol_ops[] = {
_dvs_buck_regulator_ops, _dvs_buck_regulator_ops,
_pickable_range_buck_ops, _pickable_range_buck_ops,
_buck_regulator_nolinear_ops, _buck_regulator_ops,
@@ -582,7 +582,7 @@ const struct regulator_ops *bd71847_swcontrol_ops[] = {
_pickable_range_ldo_ops, _ldo_regulator_ops,
};
-const struct regulator_ops *bd71847_hwcontrol_ops[] = {
+static const struct regulator_ops *bd71847_hwcontrol_ops[] = {
_HWOPNAME(bd718xx_dvs_buck_regulator_ops),
_HWOPNAME(bd718xx_dvs_buck_regulator_ops),
_HWOPNAME(bd718xx_pickable_range_buck_ops),
@@ -899,7 +899,7 @@ static struct bd718xx_regulator_data bd71847_regulators[] =
{
},
};
-const struct regulator_ops *bd71837_swcontrol_ops[] = {
+static const struct regulator_ops *bd71837_swcontrol_ops[] = {
_dvs_buck_regulator_ops, _dvs_buck_regulator_ops,
_dvs_buck_regulator_ops, _dvs_buck_regulator_ops,
_pickable_range_buck_ops, _buck_regulator_ops,
@@ -910,7 +910,7 @@ const struct regulator_ops *bd71837_swcontrol_ops[] = {
_ldo_regulator_ops,
};
-const struct regulator_ops *bd71837_hwcontrol_ops[] = {
+static const struct regulator_ops *bd71837_hwcontrol_ops[] = {
_HWOPNAME(bd718xx_dvs_buck_regulator_ops),
_HWOPNAME(bd718xx_dvs_buck_regulator_ops),
_buck34_ops_hwctrl, _buck34_ops_hwctrl,
--
2.17.1
Re: [PATCH v6 1/2] cpufreq: mediatek-hw: Add support for Mediatek cpufreq HW driver
On 09-09-20, 21:34, Hector Yuan wrote:
> +static unsigned int mtk_cpufreq_hw_get(unsigned int cpu)
> +{
> + struct cpufreq_mtk *c;
> + struct cpufreq_policy *policy;
> + unsigned int index;
> +
> + policy = cpufreq_cpu_get_raw(cpu);
> + if (!policy)
> + return 0;
Why didn't you drop policy as we discussed in previous version ?
> + c = mtk_freq_domain_map[cpu];
> +
> + index = readl_relaxed(c->reg_bases[REG_PERF_STATE]);
> + index = min(index, LUT_MAX_ENTRIES - 1);
> +
> + return policy->freq_table[index].frequency;
policy->freq_table and c->table are same, isn't it ?
> +}
> +
> +static struct platform_driver mtk_cpufreq_hw_driver = {
> + .probe = mtk_cpufreq_hw_driver_probe,
> + .remove = mtk_cpufreq_hw_driver_remove,
> + .driver = {
> + .name = "mtk-cpufreq-hw",
> + .of_match_table = mtk_cpufreq_hw_match,
> + },
> +};
> +
Remove this blank line.
> +module_platform_driver(mtk_cpufreq_hw_driver);
> +
> +MODULE_DESCRIPTION("mtk CPUFREQ HW Driver");
Maybe write this is "Mediatek cpufreq-hw driver" ?
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.9.5
--
viresh
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On Wed, Sep 9, 2020 at 9:02 PM Oliver Neukum wrote:
>
> Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
> > This patch detects and reverses the effects of the malicious FTDI
> > Windows driver version 2.12.00(FTDIgate).
>
> Hi,
>
> this raises questions.
> Should we do this unconditionally without asking?
Well I think since we can reliably detect devices that have been
bricked by the malicious windows driver it's fine. I was careful to
ensure that this will bail out and not try to change anything unless all
conditions match this specific brick attack.
> Does this belong into kernel space?
This seemed to be by far the simplest option for embedded systems
that need to automatically detect and repair the bricked eeproms.
People seem to have plugged a bunch of counterfeit FTDI Arduino's
that normally attach to an embedded Linux host into windows for
some reason for a kiosk platform of mine which messed up the
userspace detection/mappings. This seemed like the best way to
avoid this being a support issue requiring manual unbricking
prochedures.
>
> > +static int ftdi_repair_brick(struct usb_serial_port *port)
> > +{
> > + struct ftdi_private *priv = usb_get_serial_port_data(port);
> > + int orig_latency;
> > + int rv;
> > + u16 *eeprom_data;
> > + u16 checksum;
> > + int eeprom_size;
> > + int result;
> > +
> > + switch (priv->chip_type) {
> > + case FT232RL:
> > + eeprom_size = 0x40;
> > + break;
> > + default:
> > + /* Unsupported for brick repair */
> > + return 0;
> > + }
> > +
> > + /* Latency timer needs to be 0x77 to unlock EEPROM programming */
> > + if (priv->latency != 0x77) {
> > + orig_latency = priv->latency;
> > + priv->latency = 0x77;
> > + rv = write_latency_timer(port);
> > + priv->latency = orig_latency;
> > + if (rv < 0)
> > + return -EIO;
> > + }
>
> Do you really want to change this without returning to the original?
> @@ -2255,6 +2364,12 @@ static int ftdi_sio_port_probe(struct usb_serial_port
> *port)
> ftdi_set_max_packet_size(port);
> if (read_latency_timer(port) < 0)
> priv->latency = 16;
> + vendor_id = le16_to_cpu(port->serial->dev->descriptor.idVendor);
> + product_id = le16_to_cpu(port->serial->dev->descriptor.idProduct);
> + if (vendor_id == FTDI_VID &&
> + product_id == FTDI_BRICK_PID &&
> + priv->chip_type == FT232RL)
> + ftdi_repair_brick(port);
> write_latency_timer(port);
It should get restored here.
> create_sysfs_attrs(port);
>
>
> Regards
> Oliver
>
Re: [PATCH 2/3] perf metricgroup: Fix uncore metric expressions
On Wed, Sep 9, 2020 at 10:52 AM Ian Rogers wrote:
>
> On Wed, Sep 9, 2020 at 2:53 AM Namhyung Kim wrote:
> >
> > Hi Ian,
> >
> > On Wed, Sep 9, 2020 at 5:02 PM Ian Rogers wrote:
> > >
> > > A metric like DRAM_BW_Use has on SkylakeX events
> > > uncore_imc/cas_count_read/
> > > and uncore_imc/case_count_write/. These events open 6 events per socket
> > > with pmu names of uncore_imc_[0-5]. The current metric setup code in
> > > find_evsel_group assumes one ID will map to 1 event to be recorded in
> > > metric_events. For events with multiple matches, the first event is
> > > recorded in metric_events (avoiding matching >1 event with the same
> > > name) and the evlist_used updated so that duplicate events aren't
> > > removed when the evlist has unused events removed.
> > >
> > > Before this change:
> > > $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1
> > >
> > > Performance counter stats for 'system wide':
> > >
> > > 41.14 MiB uncore_imc/cas_count_read/
> > > 1,002,614,251 ns duration_time
> > >
> > >1.002614251 seconds time elapsed
> > >
> > > After this change:
> > > $ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1
> > >
> > > Performance counter stats for 'system wide':
> > >
> > > 157.47 MiB uncore_imc/cas_count_read/ # 0.00 DRAM_BW_Use
> >
> > Hmm.. I guess the 0.00 result is incorrect, no?
>
> Agreed. There are a number of pre-existing bugs in this code. I'll try
> to look into this one.
There was a bug where the metric_leader wasn't being set correctly and
so the accumulation of values wasn't working as expected. There's a
small fix in:
https://lore.kernel.org/lkml/20200910032632.511566-3-irog...@google.com/T/#u
that also does the change I mentioned below.
The metric still remains at 0.0 following this change as I believe
there is a bug in the metric. The metric expression is:
"( 64 * ( uncore_imc@cas_count_read@ + uncore_imc@cas_count_write@ ) /
10 ) / duration_time"
ie the counts of uncore_imc/cas_count_read/ and
uncore_imc/cas_count_write/ are being first being scaled up by 64,
that is to turn a count of cache lines into bytes, the count is then
divided by 10 or a GB to supposedly give GB/s. However, the
counts are read and scaled:
...
void perf_stat__update_shadow_stats(struct evsel *counter, u64 count,
...
count *= counter->scale;
...
The scale value from
/sys/devices/uncore_imc_0/events/cas_count_read.scale is
6.103515625e-5 or 64/(1024*1024). This means the result of the
expression is 64 times too large but in PB/s and so too small to
display. I don't rule out there being other issues but this appears to
be a significant one. Printing using intervals also looks suspicious
as the count appears to just increase rather than vary up and down.
Jin Yao, I don't know if you can take a look?
Thanks,
Ian
> > > 126.97 MiB uncore_imc/cas_count_write/
> > > 1,003,019,728 ns duration_time
> > >
> > > Erroneous duplication introduced in:
> > > commit 2440689d62e9 ("perf metricgroup: Remove duped metric group
> > > events").
> > >
> > > Fixes: ded80bda8bc9 ("perf expr: Migrate expr ids table to a hashmap").
> > > Reported-by: Jin, Yao
> > > Signed-off-by: Ian Rogers
> > > ---
> > [SNIP]
> > > @@ -248,6 +260,16 @@ static struct evsel *find_evsel_group(struct evlist
> > > *perf_evlist,
> > > ev = metric_events[i];
> > > ev->metric_leader = ev;
> > > set_bit(ev->idx, evlist_used);
> > > + /*
> > > +* Mark two events with identical names in the same group
> > > as
> > > +* being in use as uncore events may be duplicated for
> > > each pmu.
> > > +*/
> > > + evlist__for_each_entry(perf_evlist, ev) {
> > > + if (metric_events[i]->leader == ev->leader &&
> > > + !strcmp(metric_events[i]->name, ev->name)) {
> > > + set_bit(ev->idx, evlist_used);
> >
> > I'm not sure whether they are grouped together.
> > But if so, you can use for_each_group_member(ev, leader).
>
> Good suggestion, unfortunately the groups may be removed for things
> like NMI watchdog or --metric-no-group and so there wouldn't be a
> leader to follow. We could do something like this:
>
> if (metric_events[i]->leader) {
> for_each_group_member(ev, leader) {
> if (!strcmp(metric_events[i]->name, ev->name))
> set_bit(ev->idx, evlist_used);
> }
> } else {
> evlist__for_each_entry(perf_evlist, ev) {
> if (!ev->leader && !strcmp(metric_events[i]->name, ev->name))
> set_bit(ev->idx, evlist_used);
> }
> }
> }
>
> What do you think?
>
> Thanks,
> Ian
>
> > Thanks
> > Namhyung
> >
> >
> > > + }
> > > + }
> > > }
> > >
> > > return metric_events[0];
> > > --
> > > 2.28.0.526.ge36021eeef-goog
> > >
Re: [PATCH v8 1/2] fpga: dfl: create a dfl bus type to support DFL devices
Hi Xu,
On Mon, Sep 07, 2020 at 10:23:13PM +0800, Xu Yilun wrote:
> A new bus type "dfl" is introduced for private features which are not
> initialized by DFL feature drivers (dfl-fme & dfl-afu drivers). So these
> private features could be handled by separate driver modules.
>
> DFL feature drivers (dfl-fme, dfl-port) will create DFL devices on
> enumeration. DFL drivers could be registered on this bus to match these
> DFL devices. They are matched by dfl type & feature_id.
>
> Signed-off-by: Xu Yilun
> Signed-off-by: Wu Hao
> Signed-off-by: Matthew Gerlach
> Signed-off-by: Russ Weight
> Reviewed-by: Tom Rix
> Acked-by: Wu Hao
> ---
> v2: change the bus uevent format.
> change the dfl device's sysfs name format.
> refactor dfl_dev_add().
> minor fixes for comments from Hao and Tom.
> v3: no change.
> v4: improve the uevent format, 4 bits for type & 12 bits for id.
> change dfl_device->type to u8.
> A dedicate field in struct dfl_feature for dfl device instance.
> error out if dfl_device already exist on dfl_devs_init().
> v5: minor fixes for Hao's comments
> v6: the input param of dfl_devs_add() changes to struct
> dfl_feature_platform_data.
> improve the comments.
> v7: no change.
> v8: remove the dfl_info_attr macro.
> some minor fixes for Moritz's comments.
> ---
> Documentation/ABI/testing/sysfs-bus-dfl | 15 ++
> drivers/fpga/dfl.c | 265
> +++-
> drivers/fpga/dfl.h | 86 +++
> 3 files changed, 358 insertions(+), 8 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-dfl
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-dfl
> b/Documentation/ABI/testing/sysfs-bus-dfl
> new file mode 100644
> index 000..23543be
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-dfl
> @@ -0,0 +1,15 @@
> +What:/sys/bus/dfl/devices/dfl_dev.X/type
> +Date:Aug 2020
> +KernelVersion: 5.10
> +Contact: Xu Yilun
> +Description: Read-only. It returns type of DFL FIU of the device. Now DFL
> + supports 2 FIU types, 0 for FME, 1 for PORT.
> + Format: 0x%x
> +
> +What:/sys/bus/dfl/devices/dfl_dev.X/feature_id
> +Date:Aug 2020
> +KernelVersion: 5.10
> +Contact: Xu Yilun
> +Description: Read-only. It returns feature identifier local to its DFL FIU
> + type.
> + Format: 0x%x
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index 52cafa2..b450870 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -30,12 +30,6 @@ static DEFINE_MUTEX(dfl_id_mutex);
> * index to dfl_chardevs table. If no chardev support just set devt_type
> * as one invalid index (DFL_FPGA_DEVT_MAX).
> */
> -enum dfl_id_type {
> - FME_ID, /* fme id allocation and mapping */
> - PORT_ID,/* port id allocation and mapping */
> - DFL_ID_MAX,
> -};
> -
> enum dfl_fpga_devt_type {
> DFL_FPGA_DEVT_FME,
> DFL_FPGA_DEVT_PORT,
> @@ -250,6 +244,247 @@ int dfl_fpga_check_port_id(struct platform_device
> *pdev, void *pport_id)
> }
> EXPORT_SYMBOL_GPL(dfl_fpga_check_port_id);
>
> +static DEFINE_IDA(dfl_device_ida);
> +
> +static const struct dfl_device_id *
> +dfl_match_one_device(const struct dfl_device_id *id, struct dfl_device *ddev)
> +{
> + if (id->type == ddev->type && id->feature_id == ddev->feature_id)
> + return id;
> +
> + return NULL;
> +}
> +
> +static int dfl_bus_match(struct device *dev, struct device_driver *drv)
> +{
> + struct dfl_device *ddev = to_dfl_dev(dev);
> + struct dfl_driver *ddrv = to_dfl_drv(drv);
> + const struct dfl_device_id *id_entry;
> +
> + id_entry = ddrv->id_table;
> + if (id_entry) {
> + while (id_entry->feature_id) {
> + if (dfl_match_one_device(id_entry, ddev)) {
> + ddev->id_entry = id_entry;
> + return 1;
> + }
> + id_entry++;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int dfl_bus_probe(struct device *dev)
> +{
> + struct dfl_driver *ddrv = to_dfl_drv(dev->driver);
> + struct dfl_device *ddev = to_dfl_dev(dev);
> +
> + return ddrv->probe(ddev);
> +}
> +
> +static int dfl_bus_remove(struct device *dev)
> +{
> + struct dfl_driver *ddrv = to_dfl_drv(dev->driver);
> + struct dfl_device *ddev = to_dfl_dev(dev);
> +
> + if (ddrv->remove)
> + ddrv->remove(ddev);
> +
> + return 0;
> +}
> +
> +static int dfl_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
> +{
> + struct dfl_device *ddev = to_dfl_dev(dev);
> +
> + /* The type has 4 valid bits and feature_id has 12 valid bits */
> + return add_uevent_var(env, "MODALIAS=dfl:t%01Xf%03X",
> + ddev->type, ddev->feature_id);
> +}
> +
> +static ssize_t
>
[PATCH 2/3] Documentation/admin-guide: kernel-parameters: hyphenate comma-separated
When "comma separated" is used as a compound adjective, it should be hyphenated. Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org --- Documentation/admin-guide/kernel-parameters.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) --- linux-next-20200909.orig/Documentation/admin-guide/kernel-parameters.txt +++ linux-next-20200909/Documentation/admin-guide/kernel-parameters.txt @@ -1385,7 +1385,7 @@ ftrace_filter=[function-list] [FTRACE] Limit the functions traced by the function - tracer at boot up. function-list is a comma separated + tracer at boot up. function-list is a comma-separated list of functions. This list can be changed at run time by the set_ftrace_filter file in the debugfs tracing directory. @@ -1399,13 +1399,13 @@ ftrace_graph_filter=[function-list] [FTRACE] Limit the top level callers functions traced by the function graph tracer at boot up. - function-list is a comma separated list of functions + function-list is a comma-separated list of functions that can be changed at run time by the set_graph_function file in the debugfs tracing directory. ftrace_graph_notrace=[function-list] [FTRACE] Do not trace from the functions specified in - function-list. This list is a comma separated list of + function-list. This list is a comma-separated list of functions that can be changed at run time by the set_graph_notrace file in the debugfs tracing directory. @@ -2407,7 +2407,7 @@ when set. Format: - libata.force= [LIBATA] Force configurations. The format is comma + libata.force= [LIBATA] Force configurations. The format is comma- separated list of "[ID:]VAL" where ID is PORT[.DEVICE]. PORT and DEVICE are decimal numbers matching port, link or device. Basically, it matches @@ -5123,7 +5123,7 @@ stacktrace_filter=[function-list] [FTRACE] Limit the functions that the stack tracer - will trace at boot up. function-list is a comma separated + will trace at boot up. function-list is a comma-separated list of functions. This list can be changed at run time by the stack_trace_filter file in the debugfs tracing directory. Note, this enables stack tracing @@ -5326,7 +5326,7 @@ trace_event=[event-list] [FTRACE] Set and start specified trace events in order to facilitate early boot debugging. The event-list is a - comma separated list of trace events to enable. See + comma-separated list of trace events to enable. See also Documentation/trace/events.rst trace_options=[option-list]
[PATCH v2 2/3] perf metricgroup: Fix typo in comment.
Add missing character. Signed-off-by: Ian Rogers --- tools/perf/util/metricgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c index 8831b964288f..662f4e8777d5 100644 --- a/tools/perf/util/metricgroup.c +++ b/tools/perf/util/metricgroup.c @@ -150,7 +150,7 @@ static void expr_ids__exit(struct expr_ids *ids) } /** - * Find a group of events in perf_evlist that correpond to those from a parsed + * Find a group of events in perf_evlist that correspond to those from a parsed * metric expression. Note, as find_evsel_group is called in the same order as * perf_evlist was constructed, metric_no_merge doesn't need to test for * underfilling a group. -- 2.28.0.526.ge36021eeef-goog
[PATCH 3/3] Documentation/admin-guide: kernel-parameters: add early_param() to list of types of boot parameters
early_param() is missing from the list of types of kernel command line parameters that are listed in kernel-parameters.txt, so add it (so that I can find parameters more easily). Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org --- Documentation/admin-guide/kernel-parameters.rst |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-next-20200909.orig/Documentation/admin-guide/kernel-parameters.rst +++ linux-next-20200909/Documentation/admin-guide/kernel-parameters.rst @@ -3,8 +3,8 @@ The kernel's command-line parameters -The following is a consolidated list of the kernel parameters as -implemented by the __setup(), core_param() and module_param() macros +The following is a consolidated list of the kernel parameters as implemented +by the __setup(), early_param(), core_param() and module_param() macros and sorted into English Dictionary order (defined as ignoring all punctuation and sorting digits before letters in a case insensitive manner), and with descriptions where known.
[PATCH v2 3/3] perf metricgroup: Fix uncore metric expressions
A metric like DRAM_BW_Use has on SkylakeX events uncore_imc/cas_count_read/
and uncore_imc/case_count_write/. These events open 6 events per socket
with pmu names of uncore_imc_[0-5]. The current metric setup code in
find_evsel_group assumes one ID will map to 1 event to be recorded in
metric_events. For events with multiple matches, the first event is
recorded in metric_events (avoiding matching >1 event with the same
name) and the evlist_used updated so that duplicate events aren't
removed when the evlist has unused events removed.
Before this change:
$ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1
Performance counter stats for 'system wide':
41.14 MiB uncore_imc/cas_count_read/
1,002,614,251 ns duration_time
1.002614251 seconds time elapsed
After this change:
$ /tmp/perf/perf stat -M DRAM_BW_Use -a -- sleep 1
Performance counter stats for 'system wide':
157.47 MiB uncore_imc/cas_count_read/ # 0.00 DRAM_BW_Use
126.97 MiB uncore_imc/cas_count_write/
1,003,019,728 ns duration_time
v2. avoids iterating over the whole evlist as suggested by
namhy...@kernel.org. It also fixes the metric_leader computation
that was broken in the same commits.
Erroneous duplication introduced in:
commit 2440689d62e9 ("perf metricgroup: Remove duped metric group events").
Fixes: ded80bda8bc9 ("perf expr: Migrate expr ids table to a hashmap").
Reported-by: Jin Yao
Signed-off-by: Ian Rogers
---
tools/perf/util/metricgroup.c | 45 ---
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/metricgroup.c b/tools/perf/util/metricgroup.c
index 662f4e8777d5..79080de9217d 100644
--- a/tools/perf/util/metricgroup.c
+++ b/tools/perf/util/metricgroup.c
@@ -206,6 +206,18 @@ static struct evsel *find_evsel_group(struct evlist
*perf_evlist,
sizeof(struct evsel *) * idnum);
current_leader = ev->leader;
}
+ /*
+* Check for duplicate events with the same name. For example,
+* uncore_imc/cas_count_read/ will turn into 6 events per socket
+* on skylakex. Only the first such event is placed in
+* metric_events.
+*/
+ for (i = 0; i < matched_events; i++) {
+ if (!strcmp(metric_events[i]->name, ev->name))
+ break;
+ }
+ if (i != matched_events)
+ continue;
if (hashmap__find(>ids, ev->name, (void **)_ptr)) {
if (has_constraint) {
/*
@@ -245,9 +257,36 @@ static struct evsel *find_evsel_group(struct evlist
*perf_evlist,
metric_events[idnum] = NULL;
for (i = 0; i < idnum; i++) {
- ev = metric_events[i];
- ev->metric_leader = ev;
- set_bit(ev->idx, evlist_used);
+ /* Don't free used events. */
+ set_bit(metric_events[i]->idx, evlist_used);
+ /*
+* The metric leader points to the identically named event in
+* metric_events.
+*/
+ metric_events[i]->metric_leader = metric_events[i];
+ /*
+* Mark two events with identical names in the same group (or
+* globally) as being in use as uncore events may be duplicated
+* for each pmu. Set the metric leader to be the event that
+* appears in metric_events.
+*/
+ if (!has_constraint) {
+ for_each_group_evsel(ev, metric_events[i]->leader) {
+ if (ev != metric_events[i] &&
+ !strcmp(metric_events[i]->name, ev->name)) {
+ set_bit(ev->idx, evlist_used);
+ ev->metric_leader = metric_events[i];
+ }
+ }
+ } else {
+ evlist__for_each_entry(perf_evlist, ev) {
+ if (ev != metric_events[i] &&
+ !strcmp(metric_events[i]->name, ev->name)) {
+ set_bit(ev->idx, evlist_used);
+ ev->metric_leader = metric_events[i];
+ }
+ }
+ }
}
return metric_events[0];
--
2.28.0.526.ge36021eeef-goog
[PATCH v2 1/3] perf stat: Remove dead code
No need to set os.evsel twice. Signed-off-by: Ian Rogers --- tools/perf/util/stat-display.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/perf/util/stat-display.c b/tools/perf/util/stat-display.c index 493ec372fdec..4b57c0c07632 100644 --- a/tools/perf/util/stat-display.c +++ b/tools/perf/util/stat-display.c @@ -946,7 +946,6 @@ static void print_metric_headers(struct perf_stat_config *config, out.print_metric = print_metric_header; out.new_line = new_line_metric; out.force_header = true; - os.evsel = counter; perf_stat__print_shadow_stats(config, counter, 0, 0, , -- 2.28.0.526.ge36021eeef-goog
[PATCH -next] drm/amd/display: Fix possible memleak in dp_trigger_hotplug()
If parse_write_buffer_into_params() fails, we should free
wr_buf before return.
Fixes: 6f77b2ac6280 ("drm/amd/display: Add connector HPD trigger debugfs entry")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 83da24aced45..11e16fbe484d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1089,8 +1089,10 @@ static ssize_t dp_trigger_hotplug(struct file *f, const
char __user *buf,
if (parse_write_buffer_into_params(wr_buf, wr_buf_size,
(long *)param, buf,
max_param_num,
- _nums))
+ _nums)) {
+ kfree(wr_buf);
return -EINVAL;
+ }
if (param_nums <= 0) {
DRM_DEBUG_DRIVER("user data not be read\n");
--
2.17.1
[PATCH 0/3] Documentation/admin-guide: kernel-parameters: parameter cleanups
Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org [PATCH 1/3] Documentation/admin-guide: kernel-parameters: update CMA entries [PATCH 2/3] Documentation/admin-guide: kernel-parameters: hyphenate comma-separated [PATCH 3/3] Documentation/admin-guide: kernel-parameters: add early_param() to list of types of boot parameters Documentation/admin-guide/kernel-parameters.rst |4 +- Documentation/admin-guide/kernel-parameters.txt | 22 +++--- 2 files changed, 13 insertions(+), 13 deletions(-)
[PATCH 1/3] Documentation/admin-guide: kernel-parameters: update CMA entries
Add qualifying build option legend [CMA] to kernel boot options that requirce CMA support to be enabled for them to be usable. Also capitalize 'CMA' when it is used as an acronym. Signed-off-by: Randy Dunlap Cc: Jonathan Corbet Cc: linux-...@vger.kernel.org --- Documentation/admin-guide/kernel-parameters.txt | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- linux-next-20200909.orig/Documentation/admin-guide/kernel-parameters.txt +++ linux-next-20200909/Documentation/admin-guide/kernel-parameters.txt @@ -591,7 +591,7 @@ some critical bits. cma=nn[MG]@[start[MG][-end[MG]]] - [ARM,X86,KNL] + [ARM,X86,KNL,CMA] Sets the size of kernel global memory area for contiguous memory allocations and optionally the placement constraint by the physical address range of @@ -600,7 +600,7 @@ include/linux/dma-contiguous.h cma_pernuma=nn[MG] - [ARM64,KNL] + [ARM64,KNL,CMA] Sets the size of kernel per-numa memory area for contiguous memory allocations. A value of 0 disables per-numa CMA altogether. And If this option is not @@ -1524,12 +1524,12 @@ hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET registers. Default set by CONFIG_HPET_MMAP_DEFAULT. - hugetlb_cma=[HW] The size of a cma area used for allocation + hugetlb_cma=[HW,CMA] The size of a CMA area used for allocation of gigantic hugepages. Format: nn[KMGTPE] - Reserve a cma area of given size and allocate gigantic - hugepages using the cma allocator. If enabled, the + Reserve a CMA area of given size and allocate gigantic + hugepages using the CMA allocator. If enabled, the boot-time allocation of gigantic hugepages is skipped. hugepages= [HW] Number of HugeTLB pages to allocate at boot.
[PATCH 2/3] drm/amd/display: Add tracepoint for amdgpu_dm
Debug amdgpu_dm could be a complicated task, therefore, this commit adds
tracepoints in some convenient functions such as plane and connector
check inside amdgpu_dm.
Co-developed-by: Nicholas Kazlauskas
Signed-off-by: Nicholas Kazlauskas
Signed-off-by: Rodrigo Siqueira
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 ++
.../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 287 ++
2 files changed, 304 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index cb624ee70545..552ca67c2a71 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5424,6 +5424,8 @@ amdgpu_dm_connector_atomic_check(struct drm_connector
*conn,
struct drm_crtc_state *new_crtc_state;
int ret;
+ trace_amdgpu_dm_connector_atomic_check(new_con_state);
+
if (!crtc)
return 0;
@@ -5542,6 +5544,8 @@ static int dm_crtc_helper_atomic_check(struct drm_crtc
*crtc,
struct dm_crtc_state *dm_crtc_state = to_dm_crtc_state(state);
int ret = -EINVAL;
+ trace_amdgpu_dm_crtc_atomic_check(state);
+
dm_update_crtc_active_planes(crtc, state);
if (unlikely(!dm_crtc_state->stream &&
@@ -5916,6 +5920,8 @@ static int dm_plane_atomic_check(struct drm_plane *plane,
struct drm_crtc_state *new_crtc_state;
int ret;
+ trace_amdgpu_dm_plane_atomic_check(state);
+
dm_plane_state = to_dm_plane_state(state);
if (!dm_plane_state->dc_state)
@@ -5956,6 +5962,8 @@ static void dm_plane_atomic_async_update(struct drm_plane
*plane,
struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(new_state->state, plane);
+ trace_amdgpu_dm_atomic_update_cursor(new_state);
+
swap(plane->state->fb, new_state->fb);
plane->state->src_x = new_state->src_x;
@@ -7546,6 +7554,8 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
int crtc_disable_count = 0;
bool mode_set_reset_required = false;
+ trace_amdgpu_dm_atomic_commit_tail_begin(state);
+
drm_atomic_helper_update_legacy_modeset_state(dev, state);
dm_state = dm_atomic_get_new_state(state);
@@ -8616,6 +8626,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
int ret, i;
bool lock_and_validation_needed = false;
+ trace_amdgpu_dm_atomic_check_begin(state);
+
ret = drm_atomic_helper_check_modeset(dev, state);
if (ret)
goto fail;
@@ -8912,6 +8924,9 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
/* Must be success */
WARN_ON(ret);
+
+ trace_amdgpu_dm_atomic_check_finish(state, ret);
+
return ret;
fail:
@@ -8922,6 +8937,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
else
DRM_DEBUG_DRIVER("Atomic check failed with err: %d \n", ret);
+ trace_amdgpu_dm_atomic_check_finish(state, ret);
+
return ret;
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h
index dd34e11b1079..5fb4c4a5c349 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_trace.h
@@ -30,6 +30,12 @@
#define _AMDGPU_DM_TRACE_H_
#include
+#include
+#include
+#include
+#include
+#include
+#include
DECLARE_EVENT_CLASS(amdgpu_dc_reg_template,
TP_PROTO(unsigned long *count, uint32_t reg, uint32_t
value),
@@ -89,6 +95,287 @@ TRACE_EVENT(amdgpu_dc_performance,
(unsigned long)__entry->write_delta,
(unsigned long)__entry->writes)
);
+
+TRACE_EVENT(amdgpu_dm_connector_atomic_check,
+ TP_PROTO(const struct drm_connector_state *state),
+ TP_ARGS(state),
+
+ TP_STRUCT__entry(
+__field(uint32_t, conn_id)
+__field(const struct drm_connector_state *,
conn_state)
+__field(const struct drm_atomic_state *, state)
+__field(const struct drm_crtc_commit *, commit)
+__field(uint32_t, crtc_id)
+__field(uint32_t, best_encoder_id)
+__field(enum drm_link_status, link_status)
+__field(bool, self_refresh_aware)
+__field(enum hdmi_picture_aspect,
picture_aspect_ratio)
+__field(unsigned int, content_type)
+__field(unsigned int, hdcp_content_type)
+__field(unsigned int, content_protection)
+__field(unsigned int, scaling_mode)
+__field(u32, colorspace)
+
回复: RCU: Question rcu_preempt_blocked_readers_cgp in rcu_gp_fqs_loop func
发件人: Paul E. McKenney
发送时间: 2020年9月9日 19:22
收件人: Zhang, Qiang
抄送: Joel Fernandes; Uladzislau Rezki; Josh Triplett; Steven Rostedt; Mathieu
Desnoyers; Lai Jiangshan; rcu; LKML
主题: Re: RCU: Question rcu_preempt_blocked_readers_cgp in rcu_gp_fqs_loop
func
On Wed, Sep 09, 2020 at 07:03:39AM +, Zhang, Qiang wrote:
>
> When config preempt RCU, and then there are multiple levels node, the
> current task is preempted in rcu read critical region.
> the current task be add to "rnp->blkd_tasks" link list, and the
> "rnp->gp_tasks" may be assigned a value . these rnp is leaf node in RCU
> tree.
>
> But in "rcu_gp_fqs_loop" func, we check blocked readers in root node.
>
> static void rcu_gp_fqs_loop(void)
> {
> .
> struct rcu_node *rnp = rcu_get_root();
> .
> if (!READ_ONCE(rnp->qsmask) &&
>!rcu_preempt_blocked_readers_cgp(rnp))
> --> rnp is root node
> break;
>
> }
>
> the root node's blkd_tasks never add task, the "rnp->gp_tasks" is never be
> assigned value, this check is invailed.
> Should we check leaf nodes like this
>There are two cases:
>1. There is only a single rcu_node structure, which is both root
> and leaf. In this case, the current check is required: Both
> ->qsmask and the ->blkd_tasks list must be checked. Your
>rcu_preempt_blocked_readers() would work in this case, but
>the current code is a bit faster because it does not need
>to acquire the ->lock nor does it need the loop overhead.
>2. There are multiple levels. In this case, as you say, the root
>rcu_node structure's ->blkd_tasks list will always be empty.
>But also in this case, the root rcu_node structure's ->qsmask
>cannot be zero until all the leaf rcu_node structures' ->qsmask
>fields are zero and their ->blkd_tasks lists no longer have
>tasks blocking the current grace period. This means that your
> rcu_preempt_blocked_readers() function would never return
> true in this case.
>So the current code is fine.
>Are you seeing failures on mainline kernels? If so, what is the failure
>mode?
Yes it's right, thank you for your explanation.
thanks
Qiang
> Thanx, Paul
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1846,6 +1846,25 @@ static bool rcu_gp_init(void)
> return true;
> }
>
> +static bool rcu_preempt_blocked_readers(void)
> +{
> + struct rcu_node *rnp;
> + unsigned long flags;
> + bool ret = false;
> +
> + rcu_for_each_leaf_node(rnp) {
> + raw_spin_lock_irqsave_rcu_node(rnp, flags);
> + if (rcu_preempt_blocked_readers_cgp(rnp)) {
> + ret = true;
> + raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> + break;
> + }
> + raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> + }
> +
> + return ret;
> +}
> +
> /*
> * Helper function for swait_event_idle_exclusive() wakeup at
> force-quiescent-state
> * time.
> @@ -1864,7 +1883,7 @@ static bool rcu_gp_fqs_check_wake(int *gfp)
> return true;
>
> // The current grace period has completed.
> - if (!READ_ONCE(rnp->qsmask) && !rcu_preempt_blocked_readers_cgp(rnp))
> + if (!READ_ONCE(rnp->qsmask) && !rcu_preempt_blocked_readers())
> return true;
>
> return false;
> @@ -1927,7 +1946,7 @@ static void rcu_gp_fqs_loop(void)
> /* Locking provides needed memory barriers. */
> /* If grace period done, leave loop. */
> if (!READ_ONCE(rnp->qsmask) &&
> - !rcu_preempt_blocked_readers_cgp(rnp))
> + !rcu_preempt_blocked_readers())
> break;
> /* If time for quiescent-state forcing, do it. */
> if (!time_after(rcu_state.jiffies_force_qs, jiffies) ||
> --
>
>
> thanks
> Qiang
Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom
On September 10, 2020 12:02:34 PM GMT+09:00, Oliver Neukum
wrote:
>Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
>> This patch detects and reverses the effects of the malicious FTDI
>> Windows driver version 2.12.00(FTDIgate).
>
>Hi,
>
>this raises questions.
>Should we do this unconditionally without asking?
>Does this belong into kernel space?
I agree; this is very cute, but does it really need to be an automatic Linux
feature? Presumably someone looking to fix a bricked FTDI chip can just run my
script, and those who just want to use those chips with Linux already can since
the driver binds to the zero PID.
I am deeply amused by the idea of Linux automatically fixing problems caused by
malicious Windows drivers, but thinking objectively, I'm not sure if that's the
right thing to do.
>
>> +static int ftdi_repair_brick(struct usb_serial_port *port)
>> +{
>> +struct ftdi_private *priv = usb_get_serial_port_data(port);
>> +int orig_latency;
>> +int rv;
>> +u16 *eeprom_data;
>> +u16 checksum;
>> +int eeprom_size;
>> +int result;
>> +
>> +switch (priv->chip_type) {
>> +case FT232RL:
>> +eeprom_size = 0x40;
>> +break;
>> +default:
>> +/* Unsupported for brick repair */
>> +return 0;
>> +}
>> +
>> +/* Latency timer needs to be 0x77 to unlock EEPROM programming */
>> +if (priv->latency != 0x77) {
>> +orig_latency = priv->latency;
>> +priv->latency = 0x77;
>> +rv = write_latency_timer(port);
>> +priv->latency = orig_latency;
>> +if (rv < 0)
>> +return -EIO;
>> +}
>
>Do you really want to change this without returning to the original?
>
> Regards
> Oliver
--
Hector Martin "marcan" (hec...@marcansoft.com)
Public key: https://mrcn.st/pub
[PATCH 2/6] clocksource: sp804: remove unused sp804_timer_disable() and timer-sp804.h
Since commit 7484c727b636 ("ARM: realview: delete the RealView board
files") and commit 16956fed35fe ("ARM: versatile: switch to DT only
booting and remove legacy code"), there's no one to use the functions
defined or declared in include/clocksource/timer-sp804.h. Delete it.
Signed-off-by: Zhen Lei
---
drivers/clocksource/timer-sp804.c | 7 ---
include/clocksource/timer-sp804.h | 29 -
2 files changed, 36 deletions(-)
delete mode 100644 include/clocksource/timer-sp804.h
diff --git a/drivers/clocksource/timer-sp804.c
b/drivers/clocksource/timer-sp804.c
index bec2d372e0df..97b41a493253 100644
--- a/drivers/clocksource/timer-sp804.c
+++ b/drivers/clocksource/timer-sp804.c
@@ -18,8 +18,6 @@
#include
#include
-#include
-
#include "timer-sp.h"
static long __init sp804_get_clock_rate(struct clk *clk, const char *name)
@@ -67,11 +65,6 @@ static u64 notrace sp804_read(void)
return ~readl_relaxed(sched_clock_base + TIMER_VALUE);
}
-void __init sp804_timer_disable(void __iomem *base)
-{
- writel(0, base + TIMER_CTRL);
-}
-
int __init __sp804_clocksource_and_sched_clock_init(void __iomem *base,
const char *name,
struct clk *clk,
diff --git a/include/clocksource/timer-sp804.h
b/include/clocksource/timer-sp804.h
deleted file mode 100644
index a5b41f31a1c2..
--- a/include/clocksource/timer-sp804.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __CLKSOURCE_TIMER_SP804_H
-#define __CLKSOURCE_TIMER_SP804_H
-
-struct clk;
-
-int __sp804_clocksource_and_sched_clock_init(void __iomem *,
-const char *, struct clk *, int);
-int __sp804_clockevents_init(void __iomem *, unsigned int,
-struct clk *, const char *);
-void sp804_timer_disable(void __iomem *);
-
-static inline void sp804_clocksource_init(void __iomem *base, const char *name)
-{
- __sp804_clocksource_and_sched_clock_init(base, name, NULL, 0);
-}
-
-static inline void sp804_clocksource_and_sched_clock_init(void __iomem *base,
- const char *name)
-{
- __sp804_clocksource_and_sched_clock_init(base, name, NULL, 1);
-}
-
-static inline void sp804_clockevents_init(void __iomem *base, unsigned int
irq, const char *name)
-{
- __sp804_clockevents_init(base, irq, NULL, name);
-
-}
-#endif
--
2.26.0.106.g9fadedd
[PATCH 1/6] clocksource: sp804: cleanup clk_get_sys()
From: Kefeng Wang
Move the clk_get_sys() part into sp804_get_clock_rate(), cleanup the same
code.
Signed-off-by: Kefeng Wang
Signed-off-by: Zhen Lei
---
drivers/clocksource/timer-sp804.c | 30 ++
1 file changed, 10 insertions(+), 20 deletions(-)
diff --git a/drivers/clocksource/timer-sp804.c
b/drivers/clocksource/timer-sp804.c
index 5cd0abf9b396..bec2d372e0df 100644
--- a/drivers/clocksource/timer-sp804.c
+++ b/drivers/clocksource/timer-sp804.c
@@ -22,11 +22,18 @@
#include "timer-sp.h"
-static long __init sp804_get_clock_rate(struct clk *clk)
+static long __init sp804_get_clock_rate(struct clk *clk, const char *name)
{
long rate;
int err;
+ if (!clk)
+ clk = clk_get_sys("sp804", name);
+ if (IS_ERR(clk)) {
+ pr_err("sp804: %s clock not found: %ld\n", name, PTR_ERR(clk));
+ return PTR_ERR(clk);
+ }
+
err = clk_prepare(clk);
if (err) {
pr_err("sp804: clock failed to prepare: %d\n", err);
@@ -72,16 +79,7 @@ int __init __sp804_clocksource_and_sched_clock_init(void
__iomem *base,
{
long rate;
- if (!clk) {
- clk = clk_get_sys("sp804", name);
- if (IS_ERR(clk)) {
- pr_err("sp804: clock not found: %d\n",
- (int)PTR_ERR(clk));
- return PTR_ERR(clk);
- }
- }
-
- rate = sp804_get_clock_rate(clk);
+ rate = sp804_get_clock_rate(clk, name);
if (rate < 0)
return -EINVAL;
@@ -173,15 +171,7 @@ int __init __sp804_clockevents_init(void __iomem *base,
unsigned int irq, struct
struct clock_event_device *evt = _clockevent;
long rate;
- if (!clk)
- clk = clk_get_sys("sp804", name);
- if (IS_ERR(clk)) {
- pr_err("sp804: %s clock not found: %d\n", name,
- (int)PTR_ERR(clk));
- return PTR_ERR(clk);
- }
-
- rate = sp804_get_clock_rate(clk);
+ rate = sp804_get_clock_rate(clk, name);
if (rate < 0)
return -EINVAL;
--
2.26.0.106.g9fadedd
[PATCH 4/6] clocksource: sp804: support non-standard register offset
The ARM SP804 supports a maximum of 32-bit counter, but Hisilicon extends
it to 64-bit. That means, the registers: TimerXload, TimerXValue and
TimerXBGLoad are 64bits, all other registers are the same as those in the
SP804. The driver code can be completely reused except that the register
offset is different.
Currently, we get a timer register address by: add the constant register
offset to the timer base address. e.g. "base + TIMER_CTRL". It can not be
dynamically adjusted at run time.
So create a new structure "sp804_timer" to record the original registers
offset, and create a new structure "sp804_clkevt" to record the
calculated registers address. So the "base + TIMER_CTRL" is changed to
"clkevt->ctrl", this will faster than "base + timer->ctrl".
For example:
struct sp804_timer arm_sp804_timer = {
.ctrl = TIMER_CTRL,
};
struct sp804_clkevt clkevt;
clkevt.ctrl = base + arm_sp804_timer.ctrl;
- writel(0, base + TIMER_CTRL);
+ writel(0, clkevt.ctrl);
Signed-off-by: Zhen Lei
---
drivers/clocksource/timer-sp.h| 26 +++
drivers/clocksource/timer-sp804.c | 108 +++---
2 files changed, 108 insertions(+), 26 deletions(-)
diff --git a/drivers/clocksource/timer-sp.h b/drivers/clocksource/timer-sp.h
index b2037eb94a41..1ab75cbed0e0 100644
--- a/drivers/clocksource/timer-sp.h
+++ b/drivers/clocksource/timer-sp.h
@@ -10,6 +10,7 @@
*
* Every SP804 contains two identical timers.
*/
+#define NR_TIMERS 2
#define TIMER_1_BASE 0x00
#define TIMER_2_BASE 0x20
@@ -29,3 +30,28 @@
#define TIMER_RIS 0x10/* CVR ro */
#define TIMER_MIS 0x14/* CVR ro */
#define TIMER_BGLOAD 0x18/* CVR rw */
+
+struct sp804_timer {
+ int load;
+ int value;
+ int ctrl;
+ int intclr;
+ int ris;
+ int mis;
+ int bgload;
+ int timer_base[NR_TIMERS];
+ int width;
+};
+
+struct sp804_clkevt {
+ void __iomem *base;
+ void __iomem *load;
+ void __iomem *value;
+ void __iomem *ctrl;
+ void __iomem *intclr;
+ void __iomem *ris;
+ void __iomem *mis;
+ void __iomem *bgload;
+ unsigned long reload;
+ int width;
+};
diff --git a/drivers/clocksource/timer-sp804.c
b/drivers/clocksource/timer-sp804.c
index e0c3779621eb..68440e139dfd 100644
--- a/drivers/clocksource/timer-sp804.c
+++ b/drivers/clocksource/timer-sp804.c
@@ -20,6 +20,17 @@
#include "timer-sp.h"
+struct sp804_timer __initdata arm_sp804_timer = {
+ .load = TIMER_LOAD,
+ .value = TIMER_VALUE,
+ .ctrl = TIMER_CTRL,
+ .intclr = TIMER_INTCLR,
+ .timer_base = {TIMER_1_BASE, TIMER_2_BASE},
+ .width = 32,
+};
+
+static struct sp804_clkevt sp804_clkevt[NR_TIMERS];
+
static long __init sp804_get_clock_rate(struct clk *clk, const char *name)
{
long rate;
@@ -58,11 +69,26 @@ static long __init sp804_get_clock_rate(struct clk *clk,
const char *name)
return rate;
}
-static void __iomem *sched_clock_base;
+static struct sp804_clkevt * __init sp804_clkevt_get(void __iomem *base)
+{
+ int i;
+
+ for (i = 0; i < NR_TIMERS; i++) {
+ if (sp804_clkevt[i].base == base)
+ return _clkevt[i];
+ }
+
+ /* It's impossible to reach here */
+ WARN_ON(1);
+
+ return NULL;
+}
+
+static struct sp804_clkevt *sched_clkevt;
static u64 notrace sp804_read(void)
{
- return ~readl_relaxed(sched_clock_base + TIMER_VALUE);
+ return ~readl_relaxed(sched_clkevt->value);
}
int __init sp804_clocksource_and_sched_clock_init(void __iomem *base,
@@ -71,22 +97,25 @@ int __init sp804_clocksource_and_sched_clock_init(void
__iomem *base,
int use_sched_clock)
{
long rate;
+ struct sp804_clkevt *clkevt;
rate = sp804_get_clock_rate(clk, name);
if (rate < 0)
return -EINVAL;
- writel(0, base + TIMER_CTRL);
- writel(0x, base + TIMER_LOAD);
- writel(0x, base + TIMER_VALUE);
+ clkevt = sp804_clkevt_get(base);
+
+ writel(0, clkevt->ctrl);
+ writel(0x, clkevt->load);
+ writel(0x, clkevt->value);
writel(TIMER_CTRL_32BIT | TIMER_CTRL_ENABLE | TIMER_CTRL_PERIODIC,
- base + TIMER_CTRL);
+ clkevt->ctrl);
- clocksource_mmio_init(base + TIMER_VALUE, name,
+ clocksource_mmio_init(clkevt->value, name,
rate, 200, 32, clocksource_mmio_readl_down);
if (use_sched_clock) {
- sched_clock_base = base;
+ sched_clkevt = clkevt;
sched_clock_register(sp804_read, 32, rate);
}
@@ -94,8 +123,7 @@ int __init sp804_clocksource_and_sched_clock_init(void
__iomem *base,
}
[PATCH 5/6] clocksource: sp804: add support for Hisilicon sp804 timer
The ARM SP804 supports a maximum of 32-bit counter, but Hisilicon extends
it to 64-bit. That means, the registers: TimerXload, TimerXValue and
TimerXBGLoad are 64bits, all other registers are the same as those in the
SP804. The driver code can be completely reused except that the register
offset is different.
Use compatible = "hisi,sp804" mark as Hisilicon sp804 timer.
Signed-off-by: Zhen Lei
---
drivers/clocksource/timer-sp.h| 12
drivers/clocksource/timer-sp804.c | 15 +++
2 files changed, 27 insertions(+)
diff --git a/drivers/clocksource/timer-sp.h b/drivers/clocksource/timer-sp.h
index 1ab75cbed0e0..6ca8d82e8544 100644
--- a/drivers/clocksource/timer-sp.h
+++ b/drivers/clocksource/timer-sp.h
@@ -31,6 +31,18 @@
#define TIMER_MIS 0x14/* CVR ro */
#define TIMER_BGLOAD 0x18/* CVR rw */
+
+#define HISI_TIMER_1_BASE 0x00
+#define HISI_TIMER_2_BASE 0x40
+#define HISI_TIMER_LOAD0x00
+#define HISI_TIMER_VALUE 0x08
+#define HISI_TIMER_CTRL0x10
+#define HISI_TIMER_INTCLR 0x14
+#define HISI_TIMER_RIS 0x18
+#define HISI_TIMER_MIS 0x1c
+#define HISI_TIMER_BGLOAD 0x20
+
+
struct sp804_timer {
int load;
int value;
diff --git a/drivers/clocksource/timer-sp804.c
b/drivers/clocksource/timer-sp804.c
index 68440e139dfd..736b0476629f 100644
--- a/drivers/clocksource/timer-sp804.c
+++ b/drivers/clocksource/timer-sp804.c
@@ -29,6 +29,15 @@ struct sp804_timer __initdata arm_sp804_timer = {
.width = 32,
};
+struct sp804_timer __initdata hisi_sp804_timer = {
+ .load = HISI_TIMER_LOAD,
+ .value = HISI_TIMER_VALUE,
+ .ctrl = HISI_TIMER_CTRL,
+ .intclr = HISI_TIMER_INTCLR,
+ .timer_base = {HISI_TIMER_1_BASE, HISI_TIMER_2_BASE},
+ .width = 64,
+};
+
static struct sp804_clkevt sp804_clkevt[NR_TIMERS];
static long __init sp804_get_clock_rate(struct clk *clk, const char *name)
@@ -315,6 +324,12 @@ static int __init arm_sp804_of_init(struct device_node *np)
}
TIMER_OF_DECLARE(sp804, "arm,sp804", arm_sp804_of_init);
+static int __init hisi_sp804_of_init(struct device_node *np)
+{
+ return sp804_of_init(np, _sp804_timer);
+}
+TIMER_OF_DECLARE(hisi_sp804, "hisi,sp804", hisi_sp804_of_init);
+
static int __init integrator_cp_of_init(struct device_node *np)
{
static int init_count = 0;
--
2.26.0.106.g9fadedd
[PATCH 0/6] clocksource: sp804: add support for Hisilicon sp804 timer
The ARM SP804 supports a maximum of 32-bit counter, but Hisilicon extends
it to 64-bit. That means, the registers: TimerXload, TimerXValue and
TimerXBGLoad are 64bits, all other registers are the same as those in the
SP804. The driver code can be completely reused except that the register
offset is different
The register offset differences between ARM-SP804 and HISI-SP804 are as follows:
ARM-SP804 HISI-SP804
TIMER_LOAD 0x00HISI_TIMER_LOAD 0x00
HISI_TIMER_LOAD_H 0x04
TIMER_VALUE 0x04HISI_TIMER_VALUE0x08
HISI_TIMER_VALUE_H 0x0c
TIMER_CTRL 0x08HISI_TIMER_CTRL 0x10
TIMER_INTCLR0x0cHISI_TIMER_INTCLR 0x14
TIMER_RIS 0x10HISI_TIMER_RIS 0x18
TIMER_MIS 0x14HISI_TIMER_MIS 0x1c
TIMER_BGLOAD0x18HISI_TIMER_BGLOAD 0x20
HISI_TIMER_BGLOAD_H 0x24
TIMER_2_BASE0x20HISI_TIMER_2_BASE 0x40
In order to make the timer-sp804 driver support both ARM-SP804 and HISI-SP804.
Create a new structure "sp804_clkevt" to record the calculated registers
address in advance, avoid judging and calculating the register address every
place that is used.
For example:
struct sp804_timer arm_sp804_timer = {
.ctrl = TIMER_CTRL,
};
struct sp804_timer hisi_sp804_timer = {
.ctrl = HISI_TIMER_CTRL,
};
struct sp804_clkevt clkevt;
In the initialization phase:
if (hisi_sp804)
clkevt.ctrl = base + hisi_sp804_timer.ctrl;
else if (arm_sp804)
clkevt.ctrl = base + arm_sp804_timer.ctrl;
After initialization:
- writel(0, base + TIMER_CTRL);
+ writel(0, clkevt.ctrl);
Additional information:
These patch series are the V2 of https://lore.kernel.org/patchwork/cover/681876/
And many of the main ideas in https://lore.kernel.org/patchwork/patch/681875/
have been considered.
Thanks for Daniel Lezcano's review comments.
Kefeng Wang (1):
clocksource: sp804: cleanup clk_get_sys()
Zhen Lei (5):
clocksource: sp804: remove unused sp804_timer_disable() and
timer-sp804.h
clocksource: sp804: prepare for support non-standard register offset
clocksource: sp804: support non-standard register offset
clocksource: sp804: add support for Hisilicon sp804 timer
clocksource: sp804: enable Hisilicon sp804 timer 64bit mode
drivers/clocksource/timer-sp.h| 47
drivers/clocksource/timer-sp804.c | 194 --
include/clocksource/timer-sp804.h | 29 -
3 files changed, 178 insertions(+), 92 deletions(-)
delete mode 100644 include/clocksource/timer-sp804.h
--
2.26.0.106.g9fadedd
[PATCH 3/6] clocksource: sp804: prepare for support non-standard register offset
Do a bit of cleaning, to make the next patch looks more clear. The
details are as follows:
1. Remove a mismatched comment. It just temporarily disable a timer,
and the timer will be set to periodic mode later.
2. Add two local variables: timer1_base and timer2_base in
sp804_of_init(), To avoid repeatedly calculate the base address of
timer2, and make it easier to recognize timer1.
3. Delete the leading "__" of __sp804_clocksource_and_sched_clock_init()
and __sp804_clockevents_init().
No functional change.
Signed-off-by: Zhen Lei
---
drivers/clocksource/timer-sp804.c | 36 ++-
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/clocksource/timer-sp804.c
b/drivers/clocksource/timer-sp804.c
index 97b41a493253..e0c3779621eb 100644
--- a/drivers/clocksource/timer-sp804.c
+++ b/drivers/clocksource/timer-sp804.c
@@ -65,10 +65,10 @@ static u64 notrace sp804_read(void)
return ~readl_relaxed(sched_clock_base + TIMER_VALUE);
}
-int __init __sp804_clocksource_and_sched_clock_init(void __iomem *base,
-const char *name,
-struct clk *clk,
-int use_sched_clock)
+int __init sp804_clocksource_and_sched_clock_init(void __iomem *base,
+ const char *name,
+ struct clk *clk,
+ int use_sched_clock)
{
long rate;
@@ -76,7 +76,6 @@ int __init __sp804_clocksource_and_sched_clock_init(void
__iomem *base,
if (rate < 0)
return -EINVAL;
- /* setup timer 0 as free-running clocksource */
writel(0, base + TIMER_CTRL);
writel(0x, base + TIMER_LOAD);
writel(0x, base + TIMER_VALUE);
@@ -159,7 +158,8 @@ static struct clock_event_device sp804_clockevent = {
.rating = 300,
};
-int __init __sp804_clockevents_init(void __iomem *base, unsigned int irq,
struct clk *clk, const char *name)
+int __init sp804_clockevents_init(void __iomem *base, unsigned int irq,
+ struct clk *clk, const char *name)
{
struct clock_event_device *evt = _clockevent;
long rate;
@@ -188,6 +188,8 @@ static int __init sp804_of_init(struct device_node *np)
{
static bool initialized = false;
void __iomem *base;
+ void __iomem *timer1_base;
+ void __iomem *timer2_base;
int irq, ret = -EINVAL;
u32 irq_num = 0;
struct clk *clk1, *clk2;
@@ -197,9 +199,12 @@ static int __init sp804_of_init(struct device_node *np)
if (!base)
return -ENXIO;
+ timer1_base = base;
+ timer2_base = base + TIMER_2_BASE;
+
/* Ensure timers are disabled */
- writel(0, base + TIMER_CTRL);
- writel(0, base + TIMER_2_BASE + TIMER_CTRL);
+ writel(0, timer1_base + TIMER_CTRL);
+ writel(0, timer2_base + TIMER_CTRL);
if (initialized || !of_device_is_available(np)) {
ret = -EINVAL;
@@ -228,21 +233,22 @@ static int __init sp804_of_init(struct device_node *np)
of_property_read_u32(np, "arm,sp804-has-irq", _num);
if (irq_num == 2) {
- ret = __sp804_clockevents_init(base + TIMER_2_BASE, irq, clk2,
name);
+ ret = sp804_clockevents_init(timer2_base, irq, clk2, name);
if (ret)
goto err;
- ret = __sp804_clocksource_and_sched_clock_init(base, name,
clk1, 1);
+ ret = sp804_clocksource_and_sched_clock_init(timer1_base,
+name, clk1, 1);
if (ret)
goto err;
} else {
- ret = __sp804_clockevents_init(base, irq, clk1 , name);
+ ret = sp804_clockevents_init(timer1_base, irq, clk1, name);
if (ret)
goto err;
- ret =__sp804_clocksource_and_sched_clock_init(base +
TIMER_2_BASE,
- name, clk2, 1);
+ ret = sp804_clocksource_and_sched_clock_init(timer2_base,
+name, clk2, 1);
if (ret)
goto err;
}
@@ -282,7 +288,7 @@ static int __init integrator_cp_of_init(struct device_node
*np)
goto err;
if (!init_count) {
- ret = __sp804_clocksource_and_sched_clock_init(base, name, clk,
0);
+ ret = sp804_clocksource_and_sched_clock_init(base, name, clk,
0);
if (ret)
goto err;
} else {
@@ -290,7 +296,7 @@ static int __init integrator_cp_of_init(struct device_node
*np)
if (irq <=
[PATCH 0/3] Enlarge tracepoints in the display component
Debug issues related to display can be a challenge due to the complexity around this topic and different source of information might help in this process. We already have support for tracepoints inside the display component, i.e., we have the basic functionalities available and we just need to expand it in order to make it more valuable for debugging. For this reason, this patchset reworks part of the current tracepoint options and add different sets of tracing inside amdgpu_dm, display core, and DCN10. The first patch of this series just rework part of the current tracepoints and the last set of patches introduces new tracepoints. This first patchset version is functional. Please, let me know what I can improve in the current version but also let me know what kind of tracepoint I can add for the next version. Finally, I want to highlight that this work is based on a set of patches originally made by Nicholas Kazlauskas. Rodrigo Siqueira (3): drm/amd/display: Rework registers tracepoint drm/amd/display: Add tracepoint for amdgpu_dm drm/amd/display: Add pipe_state tracepoint .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + .../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 514 -- drivers/gpu/drm/amd/display/dc/core/dc.c | 11 + .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 17 +- 4 files changed, 523 insertions(+), 36 deletions(-) -- 2.28.0
[PATCH 6/6] clocksource: sp804: enable Hisilicon sp804 timer 64bit mode
A 100MHZ 32-bit timer will be wrapped up less than 43s. Although the
kernel maintains a software high 32-bit count in the tick IRQ. But it's
not applicable to the user mode APPs.
Note: The kernel still uses the lower 32 bits of the timer.
Signed-off-by: Zhen Lei
---
drivers/clocksource/timer-sp.h| 9 +
drivers/clocksource/timer-sp804.c | 8
2 files changed, 17 insertions(+)
diff --git a/drivers/clocksource/timer-sp.h b/drivers/clocksource/timer-sp.h
index 6ca8d82e8544..6c0a902926eb 100644
--- a/drivers/clocksource/timer-sp.h
+++ b/drivers/clocksource/timer-sp.h
@@ -35,22 +35,28 @@
#define HISI_TIMER_1_BASE 0x00
#define HISI_TIMER_2_BASE 0x40
#define HISI_TIMER_LOAD0x00
+#define HISI_TIMER_LOAD_H 0x04
#define HISI_TIMER_VALUE 0x08
+#define HISI_TIMER_VALUE_H 0x0c
#define HISI_TIMER_CTRL0x10
#define HISI_TIMER_INTCLR 0x14
#define HISI_TIMER_RIS 0x18
#define HISI_TIMER_MIS 0x1c
#define HISI_TIMER_BGLOAD 0x20
+#define HISI_TIMER_BGLOAD_H0x24
struct sp804_timer {
int load;
+ int load_h;
int value;
+ int value_h;
int ctrl;
int intclr;
int ris;
int mis;
int bgload;
+ int bgload_h;
int timer_base[NR_TIMERS];
int width;
};
@@ -58,12 +64,15 @@ struct sp804_timer {
struct sp804_clkevt {
void __iomem *base;
void __iomem *load;
+ void __iomem *load_h;
void __iomem *value;
+ void __iomem *value_h;
void __iomem *ctrl;
void __iomem *intclr;
void __iomem *ris;
void __iomem *mis;
void __iomem *bgload;
+ void __iomem *bgload_h;
unsigned long reload;
int width;
};
diff --git a/drivers/clocksource/timer-sp804.c
b/drivers/clocksource/timer-sp804.c
index 736b0476629f..53498cf63c3b 100644
--- a/drivers/clocksource/timer-sp804.c
+++ b/drivers/clocksource/timer-sp804.c
@@ -31,7 +31,9 @@ struct sp804_timer __initdata arm_sp804_timer = {
struct sp804_timer __initdata hisi_sp804_timer = {
.load = HISI_TIMER_LOAD,
+ .load_h = HISI_TIMER_LOAD_H,
.value = HISI_TIMER_VALUE,
+ .value_h= HISI_TIMER_VALUE_H,
.ctrl = HISI_TIMER_CTRL,
.intclr = HISI_TIMER_INTCLR,
.timer_base = {HISI_TIMER_1_BASE, HISI_TIMER_2_BASE},
@@ -117,6 +119,10 @@ int __init sp804_clocksource_and_sched_clock_init(void
__iomem *base,
writel(0, clkevt->ctrl);
writel(0x, clkevt->load);
writel(0x, clkevt->value);
+ if (clkevt->width == 64) {
+ writel(0x, clkevt->load_h);
+ writel(0x, clkevt->value_h);
+ }
writel(TIMER_CTRL_32BIT | TIMER_CTRL_ENABLE | TIMER_CTRL_PERIODIC,
clkevt->ctrl);
@@ -233,7 +239,9 @@ static void __init sp804_clkevt_init(struct sp804_timer
*timer, void __iomem *ba
clkevt = _clkevt[i];
clkevt->base= timer_base;
clkevt->load= timer_base + timer->load;
+ clkevt->load_h = timer_base + timer->load_h;
clkevt->value = timer_base + timer->value;
+ clkevt->value_h = timer_base + timer->value_h;
clkevt->ctrl= timer_base + timer->ctrl;
clkevt->intclr = timer_base + timer->intclr;
clkevt->width = timer->width;
--
2.26.0.106.g9fadedd
[PATCH v3 00/10] Support qcom USB3+DP combo phy (or type-c phy)
This patch series is based on v12 of the msm DP driver submission[1]
plus a compliance patch[2]. In the v5 patch series review I suggested
that the DP PHY and PLL be split out of the drm driver and moved to the
qmp phy driver. This patch series does that, but it is still marked as
an RFC because there are a couple more things to do, mostly updating the
DT binding and getting agreement on how to structure the code.
Eventually I believe the qmp phy driver will need to listen for type-c
notifiers or somehow know the type-c pinout being used so this driver
can program things slightly differently. Right now, I don't have any way
to test it though, so I've left it as future work. For some more
details, the DP phy and the USB3 phy share the same physical pins on the
SoC and those pins pretty much line up with a type-c pinout modulo some
CC pins for cable orientation detection logic that lives on the PMIC. So
the DP phy can use all four lanes or it can use two lanes and the USB3
phy can use two lanes. In the hardware designs that I have access to it
is always two lanes for USB3 and two lanes for DP going through what
looks like a type-c pinout so this just hard codes that configuration in
the driver.
Here's the example node that I'm using on sc7180:
usb_1_qmpphy: phy-wrapper@88e9000 {
compatible = "qcom,sc7180-qmp-usb3-dp-phy";
reg = <0 0x088e9000 0 0x18c>, // usb pll (or serdes)
<0 0x088e8000 0 0x38>, // dp com
<0 0x088ea000 0 0x40>; // dp pll (or serdes)
status = "disabled";
#address-cells = <2>;
#size-cells = <2>;
ranges;
clocks = < GCC_USB3_PRIM_PHY_AUX_CLK>,
< GCC_USB_PHY_CFG_AHB2PHY_CLK>,
< GCC_USB3_PRIM_CLKREF_CLK>,
< GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
clock-names = "aux", "cfg_ahb", "ref", "com_aux";
resets = < GCC_USB3_PHY_PRIM_BCR>,
< GCC_USB3_DP_PHY_PRIM_BCR>;
reset-names = "phy", "common";
usb_1_ssphy: usb3-phy@88e9200 {
reg = <0 0x088e9200 0 0x128>, // tx0
<0 0x088e9400 0 0x200>, // rx0
<0 0x088e9c00 0 0x218>, // pcs
<0 0x088e9600 0 0x128>, // tx1
<0 0x088e9800 0 0x200>, // rx1
<0 0x088e9a00 0 0x18>; // pcs misc
#clock-cells = <0>;
#phy-cells = <0>;
clocks = < GCC_USB3_PRIM_PHY_PIPE_CLK>;
clock-names = "pipe0";
clock-output-names = "usb3_phy_pipe_clk_src";
};
dp_phy: dp-phy@88ea200 {
reg = <0 0x088ea200 0 0x200>, // tx0
<0 0x088ea400 0 0x200>, // rx0
<0 0x088eaa00 0 0x200>, // dp phy
<0 0x088ea600 0 0x200>, // tx1
<0 0x088ea800 0 0x200>; // rx1
#clock-cells = <1>;
#phy-cells = <0>;
};
};
I had to put the serdes register region in the wrapper node and jam the
common area (dp_com) in the middle. Sort of a mess but it was the best I
could do to make the driver changes minimially invasive. I also had to
change the node names to 'usb3-phy' and 'dp-phy' from 'phy' so that I
could differentiate the different phys in the driver. Otherwise the qmp
driver was already mostly prepared for two different phys to sit next to
each other inside the phy wrapper so it was mostly just a chore of
moving code from one place to another.
The last patch in this series rips out the DP PHY and PLL code from the
drm driver and wires in the phy API calls instead. I don't know the
merge path for it. Maybe Rob Clark can pick it up and I can pick the clk
patch into clk-next and the phy patches can go via the phy tree, then
everything can meet in linux-next. There are still some more TODOs in
the code but they feel minor enough to fix with more testing.
Changes from v2
(https://lore.kernel.org/r/20200902230215.3452712-1-swb...@chromium.org)
* Added regs to sc7180 dp struct
* s/QSERDES_COM_RESETSM_CNTRL/QSERDES_V3_COM_RESETSM_CNTRL/ in
qcom_qmp_phy_configure_dp_phy()
Changes from v1
(https://lore.kernel.org/r/20200826024711.220080-1-swb...@chromium.org)
* New patch for devm_platform_ioremap_resource()
* Moved serdes tables to sc7180 patch
* Removed more dead code from drm driver in last patch
* Reset aux phy is kept around now. Slightly moved where we init the
phy and setup aux
* Added a phy_exit() call to last patch so we properly shut down DP on
disconnect and can work on multiple plugs
Changes from RFC
[PATCH v3 03/10] phy: qcom-qmp: Remove 'initialized' in favor of 'init_count'
We already track if any phy inside the qmp wrapper has been initialized
by means of the struct qcom_qmp::init_count member. Let's drop the
duplicate 'initalized' member to simplify the code a bit.
Cc: Jeykumar Sankaran
Cc: Chandan Uddaraju
Cc: Vara Reddy
Cc: Tanmay Shah
Reviewed-by: Bjorn Andersson
Cc: Manu Gautam
Cc: Sandeep Maheswaram
Cc: Douglas Anderson
Cc: Sean Paul
Cc: Jonathan Marek
Cc: Dmitry Baryshkov
Cc: Rob Clark
Signed-off-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 7ee9e966dc6d..4a23ba9361b3 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -1844,7 +1844,6 @@ struct qmp_phy {
* @phys: array of per-lane phy descriptors
* @phy_mutex: mutex lock for PHY common block initialization
* @init_count: phy common block initialization count
- * @phy_initialized: indicate if PHY has been initialized
* @ufs_reset: optional UFS PHY reset handle
*/
struct qcom_qmp {
@@ -1861,7 +1860,6 @@ struct qcom_qmp {
struct mutex phy_mutex;
int init_count;
- bool phy_initialized;
struct reset_control *ufs_reset;
};
@@ -2748,7 +2746,6 @@ static int qcom_qmp_phy_enable(struct phy *phy)
dev_err(qmp->dev, "phy initialization timed-out\n");
goto err_pcs_ready;
}
- qmp->phy_initialized = true;
return 0;
err_pcs_ready:
@@ -2792,8 +2789,6 @@ static int qcom_qmp_phy_disable(struct phy *phy)
qcom_qmp_phy_com_exit(qmp);
- qmp->phy_initialized = false;
-
return 0;
}
@@ -2868,7 +2863,7 @@ static int __maybe_unused
qcom_qmp_phy_runtime_suspend(struct device *dev)
if (cfg->type != PHY_TYPE_USB3)
return 0;
- if (!qmp->phy_initialized) {
+ if (!qmp->init_count) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
@@ -2894,7 +2889,7 @@ static int __maybe_unused
qcom_qmp_phy_runtime_resume(struct device *dev)
if (cfg->type != PHY_TYPE_USB3)
return 0;
- if (!qmp->phy_initialized) {
+ if (!qmp->init_count) {
dev_vdbg(dev, "PHY not initialized, bailing out\n");
return 0;
}
--
Sent by a computer, using git, on the internet
[PATCH v3 09/10] clk: qcom: dispcc: Update DP clk ops for phy design
The clk_rcg2_dp_determine_rate() function is used for the DP pixel clk.
This function should return the rate that can be achieved by the pixel
clk in 'struct clk_rate_request::rate' and match the logic similar to
what is seen in clk_rcg2_dp_set_rate(). But that isn't the case. Instead
the code merely bubbles the rate request up to the parent of the pixel
clk and doesn't try to do a rational approximation of the rate that
would be achieved by picking some m/n value for the RCG.
Let's change this logic so that we can assume the parent clk frequency
is fixed (it is because it's the VCO of the DP PLL that is configured
based on the link rate) and so that we can calculate what the m/n value
will be and adjust the req->rate appropriately.
Cc: Jeykumar Sankaran
Cc: Chandan Uddaraju
Cc: Vara Reddy
Cc: Tanmay Shah
Cc: Bjorn Andersson
Cc: Manu Gautam
Cc: Sandeep Maheswaram
Cc: Douglas Anderson
Cc: Sean Paul
Cc: Stephen Boyd
Cc: Jonathan Marek
Cc: Dmitry Baryshkov
Cc: Rob Clark
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/clk-rcg2.c | 19 +--
drivers/clk/qcom/dispcc-sc7180.c | 3 ---
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 357159fe85b5..59a5a0f261f3 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -1182,14 +1182,21 @@ static int clk_rcg2_dp_set_rate_and_parent(struct
clk_hw *hw,
static int clk_rcg2_dp_determine_rate(struct clk_hw *hw,
struct clk_rate_request *req)
{
- struct clk_rate_request parent_req = *req;
- int ret;
+ struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+ unsigned long num, den;
+ u64 tmp;
- ret = __clk_determine_rate(clk_hw_get_parent(hw), _req);
- if (ret)
- return ret;
+ /* Parent rate is a fixed phy link rate */
+ rational_best_approximation(req->best_parent_rate, req->rate,
+ GENMASK(rcg->mnd_width - 1, 0),
+ GENMASK(rcg->mnd_width - 1, 0), , );
+
+ if (!num || !den)
+ return -EINVAL;
- req->best_parent_rate = parent_req.rate;
+ tmp = req->best_parent_rate * num;
+ do_div(tmp, den);
+ req->rate = tmp;
return 0;
}
diff --git a/drivers/clk/qcom/dispcc-sc7180.c b/drivers/clk/qcom/dispcc-sc7180.c
index 0a5d395bce93..f487515701e3 100644
--- a/drivers/clk/qcom/dispcc-sc7180.c
+++ b/drivers/clk/qcom/dispcc-sc7180.c
@@ -202,7 +202,6 @@ static struct clk_rcg2 disp_cc_mdss_dp_crypto_clk_src = {
.name = "disp_cc_mdss_dp_crypto_clk_src",
.parent_data = disp_cc_parent_data_1,
.num_parents = ARRAY_SIZE(disp_cc_parent_data_1),
- .flags = CLK_SET_RATE_PARENT,
.ops = _byte2_ops,
},
};
@@ -216,7 +215,6 @@ static struct clk_rcg2 disp_cc_mdss_dp_link_clk_src = {
.name = "disp_cc_mdss_dp_link_clk_src",
.parent_data = disp_cc_parent_data_1,
.num_parents = ARRAY_SIZE(disp_cc_parent_data_1),
- .flags = CLK_SET_RATE_PARENT,
.ops = _byte2_ops,
},
};
@@ -230,7 +228,6 @@ static struct clk_rcg2 disp_cc_mdss_dp_pixel_clk_src = {
.name = "disp_cc_mdss_dp_pixel_clk_src",
.parent_data = disp_cc_parent_data_1,
.num_parents = ARRAY_SIZE(disp_cc_parent_data_1),
- .flags = CLK_SET_RATE_PARENT,
.ops = _dp_ops,
},
};
--
Sent by a computer, using git, on the internet
[PATCH v3 08/10] phy: qcom-qmp: Add support for sc7180 DP phy
Add the necessary compatible strings and phy data for the sc7180 USB3+DP
combo phy.
Cc: Jeykumar Sankaran
Cc: Chandan Uddaraju
Cc: Vara Reddy
Cc: Tanmay Shah
Cc: Bjorn Andersson
Cc: Manu Gautam
Cc: Sandeep Maheswaram
Cc: Douglas Anderson
Cc: Sean Paul
Cc: Jonathan Marek
Cc: Dmitry Baryshkov
Cc: Rob Clark
Link: https://lore.kernel.org/r/20200609034623.10844-1-tan...@codeaurora.org
Signed-off-by: Stephen Boyd
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 124
1 file changed, 124 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index dd9574ce2e52..7ad9e1489455 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -947,6 +947,88 @@ static const struct qmp_phy_init_tbl qmp_v3_usb3_tx_tbl[]
= {
QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x06),
};
+static const struct qmp_phy_init_tbl qmp_v3_dp_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0x37),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_ENABLE1, 0x0e),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_BUF_ENABLE, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START1_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP3_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BG_TIMER, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORECLK_DIV_MODE0, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_CTRL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x1f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+};
+
+static const struct qmp_phy_init_tbl qmp_v3_dp_serdes_tbl_rbr[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x0c),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x69),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START2_MODE0, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START3_MODE0, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0x6f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x08),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x00),
+};
+
+static const struct qmp_phy_init_tbl qmp_v3_dp_serdes_tbl_hbr[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x69),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START2_MODE0, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START3_MODE0, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x0e),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x00),
+};
+
+static const struct qmp_phy_init_tbl qmp_v3_dp_serdes_tbl_hbr2[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x8c),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START2_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START3_MODE0, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0x1f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x1c),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x00),
+};
+
+static const struct qmp_phy_init_tbl qmp_v3_dp_serdes_tbl_hbr3[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x69),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START2_MODE0, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DIV_FRAC_START3_MODE0, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0x2f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x2a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x08),
+};
+
+static const struct qmp_phy_init_tbl qmp_v3_dp_tx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_TRANSCEIVER_BIAS_EN, 0x1a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_VMODE_CTRL1, 0x40),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_PRE_STALL_LDO_BOOST_EN, 0x30),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_INTERFACE_SELECT, 0x3d),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_CLKBUF_ENABLE, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_RESET_TSYNC_EN, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_TRAN_DRVR_EMP_EN, 0x03),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_PARRATE_REC_DETECT_IDLE_EN, 0x00),
+
Re: [PATCH] ARM: config: aspeed: Fix selection of media drivers
On Wed, 26 Aug 2020 at 07:19, Joel Stanley wrote:
>
> In the 5.7 merge window the media kconfig was restructued. For most
> platforms these changes set CONFIG_MEDIA_SUPPORT_FILTER=y which keeps
> unwanted drivers disabled.
>
> The exception is if a config sets EMBEDDED or EXPERT (see b0cd4fb27665).
> In that case the filter is set to =n, causing a bunch of DVB tuner drivers
> (MEDIA_TUNER_*) to be accidentally enabled. This was noticed as it blew
> out the build time for the Aspeed defconfigs.
>
> Enabling the filter means the Aspeed config also needs to set
> CONFIG_MEDIA_PLATFORM_SUPPORT=y in order to have the CONFIG_VIDEO_ASPEED
> driver enabled.
>
> Fixes: 06b93644f4d1 ("media: Kconfig: add an option to filter in/out platform
> drivers")
> Fixes: b0cd4fb27665 ("media: Kconfig: on !EMBEDDED && !EXPERT, enable driver
> filtering")
> Cc: sta...@vger.kernel.org
> CC: Mauro Carvalho Chehab
> Signed-off-by: Joel Stanley
> ---
>
> Another solution would be to revert b0cd4fb27665 ("media: Kconfig: on
> !EMBEDDED && !EXPERT, enable driver filtering"). I assume this was done
> to be helpful, but in practice it has enabled the TUNER drivers (and
> others) for the following configs that didn't have them before:
Mauro, did you have any thoughts here?
Otherwise I'll merge the fix for the aspeed configs for 5.10.
Cheers,
Joel
>
> $ git grep -lE "(CONFIG_EXPERT|CONFIG_EMBEDDED)" arch/*/configs/ | xargs
> grep -l MEDIA_SUPPORT
> arch/arm/configs/aspeed_g4_defconfig
> arch/arm/configs/aspeed_g5_defconfig
> arch/arm/configs/at91_dt_defconfig
> arch/arm/configs/bcm2835_defconfig
> arch/arm/configs/davinci_all_defconfig
> arch/arm/configs/ezx_defconfig
> arch/arm/configs/imote2_defconfig
> arch/arm/configs/imx_v4_v5_defconfig
> arch/arm/configs/imx_v6_v7_defconfig
> arch/arm/configs/milbeaut_m10v_defconfig
> arch/arm/configs/multi_v7_defconfig
> arch/arm/configs/omap2plus_defconfig
> arch/arm/configs/pxa_defconfig
> arch/arm/configs/qcom_defconfig
> arch/arm/configs/sama5_defconfig
> arch/arm/configs/tegra_defconfig
> arch/mips/configs/ci20_defconfig
> arch/mips/configs/lemote2f_defconfig
> arch/mips/configs/loongson3_defconfig
> arch/mips/configs/pistachio_defconfig
>
> I've cc'd the maintainers of these defconfigs so they are aware.
>
> ---
> arch/arm/configs/aspeed_g4_defconfig | 3 ++-
> arch/arm/configs/aspeed_g5_defconfig | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/configs/aspeed_g4_defconfig
> b/arch/arm/configs/aspeed_g4_defconfig
> index 303f75a3baec..58d293b63581 100644
> --- a/arch/arm/configs/aspeed_g4_defconfig
> +++ b/arch/arm/configs/aspeed_g4_defconfig
> @@ -160,7 +160,8 @@ CONFIG_SENSORS_TMP421=y
> CONFIG_SENSORS_W83773G=y
> CONFIG_WATCHDOG_SYSFS=y
> CONFIG_MEDIA_SUPPORT=y
> -CONFIG_MEDIA_CAMERA_SUPPORT=y
> +CONFIG_MEDIA_SUPPORT_FILTER=y
> +CONFIG_MEDIA_PLATFORM_SUPPORT=y
> CONFIG_V4L_PLATFORM_DRIVERS=y
> CONFIG_VIDEO_ASPEED=y
> CONFIG_DRM=y
> diff --git a/arch/arm/configs/aspeed_g5_defconfig
> b/arch/arm/configs/aspeed_g5_defconfig
> index b0d056d49abe..cc2449ed6e6d 100644
> --- a/arch/arm/configs/aspeed_g5_defconfig
> +++ b/arch/arm/configs/aspeed_g5_defconfig
> @@ -175,7 +175,8 @@ CONFIG_SENSORS_TMP421=y
> CONFIG_SENSORS_W83773G=y
> CONFIG_WATCHDOG_SYSFS=y
> CONFIG_MEDIA_SUPPORT=y
> -CONFIG_MEDIA_CAMERA_SUPPORT=y
> +CONFIG_MEDIA_SUPPORT_FILTER=y
> +CONFIG_MEDIA_PLATFORM_SUPPORT=y
> CONFIG_V4L_PLATFORM_DRIVERS=y
> CONFIG_VIDEO_ASPEED=y
> CONFIG_DRM=y
> --
> 2.28.0
>
Re: [PATCH] ARM: dts: rainier: Disable internal pull-downs on eMMC pins
On Thu, 10 Sep 2020 at 03:12, Andrew Jeffery wrote:
>
> There's a veritable tug-of-war going on in the design, so disable one of
> the warring parties.
>
> Signed-off-by: Andrew Jeffery
Applied to the aspeed tree for 5.10.
Cheers,
Joel
> ---
> arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
> b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
> index 1fa233d2da26..21ae880c7530 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
> @@ -180,6 +180,10 @@ _controller {
> status = "okay";
> };
>
> +_emmc_default {
> + bias-disable;
> +};
> +
> {
> status = "okay";
> };
> --
> 2.25.1
>
RE: [PATCH 1/3] dt-bindings: rtc-2127: Add bindings for nxp,rtc-2127.txt
On Thu, Sep 10, 2020 at 04:25AM, Rob Herring wrote: > -Original Message- > From: Rob Herring > Sent: 2020年9月10日 4:25 > To: Qiang Zhao > Cc: a.zu...@towertech.it; alexandre.bell...@bootlin.com; > linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: Re: [PATCH 1/3] dt-bindings: rtc-2127: Add bindings for > nxp,rtc-2127.txt > > On Thu, Aug 27, 2020 at 05:14:39PM +0800, Qiang Zhao wrote: > > From: Zhao Qiang > > > > Add bindings for nxp,rtc-2127 > > > > Signed-off-by: Zhao Qiang > > --- > > Documentation/devicetree/bindings/rtc/nxp,rtc-2127.txt | 18 > ++ > > 1 file changed, 18 insertions(+) > > create mode 100644 > Documentation/devicetree/bindings/rtc/nxp,rtc-2127.txt > > Bindings should be in DT schema format now. Is there any doc description for DT schema format or example So that I can take as a reference. Thank you! Best Regards Qiang Zhao
