[PATCH] arm64: dts: qcom: sdm845: Use UFS reset gpio instead of pinctrl
We use a pinctrl "workaround" to toggle the UFS reset line. Now that UFS
controller can issue the reset, just specify the line as a GPIO and let
it be reset that way.
Signed-off-by: Stephen Boyd
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 51 +-
1 file changed, 2 insertions(+), 49 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
index 1ebbd568dfd7..611ae48437f1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -701,9 +701,8 @@ ap_ts_i2c: {
_mem_hc {
status = "okay";
- pinctrl-names = "init", "default";
- pinctrl-0 = <_dev_reset_assert>;
- pinctrl-1 = <_dev_reset_deassert>;
+
+ reset-gpios = < 150 GPIO_ACTIVE_LOW>;
vcc-supply = <_pp2950_l20a>;
vcc-max-microamp = <60>;
@@ -1258,52 +1257,6 @@ ap_ts_i2c: {
};
};
- ufs_dev_reset_assert: ufs_dev_reset_assert {
- config {
- pins = "ufs_reset";
- bias-pull-down; /* default: pull down */
- /*
-* UFS_RESET driver strengths are having
-* different values/steps compared to typical
-* GPIO drive strengths.
-*
-* Following table clarifies:
-*
-* HDRV value | UFS_RESET | Typical GPIO
-* (dec)| (mA)|(mA)
-* 0 | 0.8 |2
-* 1 | 1.55|4
-* 2 | 2.35|6
-* 3 | 3.1 |8
-* 4 | 3.9 |10
-* 5 | 4.65|12
-* 6 | 5.4 |14
-* 7 | 6.15|16
-*
-* POR value for UFS_RESET HDRV is 3 which means
-* 3.1mA and we want to use that. Hence just
-* specify 8mA to "drive-strength" binding and
-* that should result into writing 3 to HDRV
-* field.
-*/
- drive-strength = <8>; /* default: 3.1 mA */
- output-low; /* active low reset */
- };
- };
-
- ufs_dev_reset_deassert: ufs_dev_reset_deassert {
- config {
- pins = "ufs_reset";
- bias-pull-down; /* default: pull down */
- /*
-* default: 3.1 mA
-* check comments under ufs_dev_reset_assert
-*/
- drive-strength = <8>;
- output-high; /* active low reset */
- };
- };
-
ap_suspend_l_assert: ap_suspend_l_assert {
config {
pins = "gpio126";
base-commit: a55aa89aab90fae7c815b0551b07be37db359d76
prerequisite-patch-id: 2f2797d174d16a953446039125978c024c34d497
prerequisite-patch-id: 4020423c7331cee87d7679d325c66bafb56a6b69
prerequisite-patch-id: 46f8bd1aa2aee384021beefc9b6ed7315690f96f
--
Sent by a computer through tubes
Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
On Tue, Aug 27, 2019 at 10:02 PM Peng Fan wrote:
>
> From: Peng Fan
>
> The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> actions in software layers running in the EL2 or EL3 exception levels.
> The term "ARM" here relates to the SMC instruction as part of the ARM
> instruction set, not as a standard endorsed by ARM Ltd.
>
> Signed-off-by: Peng Fan
> ---
> .../devicetree/bindings/mailbox/arm-smc.yaml | 125
> +
> 1 file changed, 125 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
>
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> new file mode 100644
> index ..f8eb28d5e307
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> @@ -0,0 +1,125 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM SMC Mailbox Interface
> +
> +maintainers:
> + - Peng Fan
> +
> +description: |
> + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> + call) instruction to trigger a mailbox-connected activity in firmware,
> + executing on the very same core as the caller. By nature this operation
> + is synchronous and this mailbox provides no way for asynchronous messages
> + to be delivered the other way round, from firmware to the OS, but
> + asynchronous notification could also be supported. However the value of
> + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> + message to the mailbox framework, so a synchronous communication can be
> + established, for a asynchronous notification, no value will be returned.
> + The exact meaning of both the action the mailbox triggers as well as the
> + return value is defined by their users and is not subject to this binding.
> +
> + One use case of this mailbox is the SCMI interface, which uses shared
> memory
> + to transfer commands and parameters, and a mailbox to trigger a function
> + call. This allows SoCs without a separate management processor (or when
> + such a processor is not available or used) to use this standardized
> + interface anyway.
> +
> + This binding describes no hardware, but establishes a firmware interface.
> + Upon receiving an SMC using one of the described SMC function identifiers,
> + the firmware is expected to trigger some mailbox connected functionality.
> + The communication follows the ARM SMC calling convention.
> + Firmware expects an SMC function identifier in r0 or w0. The supported
> + identifiers are passed from consumers, or listed in the the arm,func-ids
> + properties as described below. The firmware can return one value in
> + the first SMC result register, it is expected to be an error value,
> + which shall be propagated to the mailbox client.
> +
> + Any core which supports the SMC or HVC instruction can be used, as long as
> + a firmware component running in EL3 or EL2 is handling these calls.
> +
> +properties:
> + compatible:
> +const: arm,smc-mbox
> +
> + "#mbox-cells":
> +const: 1
> +
> + arm,num-chans:
> +description: The number of channels supported.
> +items:
> + minimum: 1
> + maximum: 4096 # Should be enough?
> +
> + method:
> +- enum:
> +- smc
> +- hvc
> +
> + transports:
> +- enum:
> +- mem
> +- reg
> +
> + arm,func-ids:
> +description: |
> + An array of 32-bit values specifying the function IDs used by each
> + mailbox channel. Those function IDs follow the ARM SMC calling
> + convention standard [1].
> +
> + There is one identifier per channel and the number of supported
> + channels is determined by the length of this array.
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +minItems: 0
> +maxItems: 4096 # Should be enough?
> +
> +required:
> + - compatible
> + - "#mbox-cells"
> + - arm,num-chans
> + - transports
> + - method
> +
> +examples:
> + - |
> +sram@91 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x93f000 0x0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x0 0x93f000 0x1000>;
> +
> + cpu_scp_lpri: scp-shmem@0 {
> +compatible = "arm,scmi-shmem";
> +reg = <0x0 0x200>;
> + };
> +
> + cpu_scp_hpri: scp-shmem@200 {
> +compatible = "arm,scmi-shmem";
> +reg = <0x200 0x200>;
> + };
> +};
> +
> +firmware {
> + smc_mbox: mailbox {
> +#mbox-cells = <1>;
> +compatible = "arm,smc-mbox";
> +method = "smc";
> +arm,num-chans = <0x2>;
> +transports = "mem";
> +/* Optional */
> +arm,func-ids = <0xc2fe>, <0xc2ff>;
>
SMC/HVC is synchronously(block) running in
Re: [PATCH v2 3/3] nvme: fire discovery log page change events to userspace
On Thu, Aug 29, 2019 at 11:21:02AM -0700, Sagi Grimberg wrote: >> Yes we do, userspace should use it to order events. Does udev not >> handle that properly today? > > The problem is not ordering of events, its really about the fact that > the chardev can be removed and reallocated for a different controller > (could be a completely different discovery controller) by the time > that userspace handles the event. The same is generally true for lot of kernel devices. We could reduce the chance by using the idr cyclic allocator.
Re: [PATCH] arm64: numa: check the node id before accessing node_to_cpumask_map
On Fri 30-08-19 10:26:31, Yunsheng Lin wrote:
> Some buggy bios may not set the device' numa id, and dev_to_node
> will return -1, which may cause global-out-of-bounds error
> detected by KASAN.
Why should we workaround a buggy bios like that? Is it so widespread and
no BIOS update available? Also, why is this arm64 specific?
> This patch changes cpumask_of_node to return cpu_none_mask if the
> node is not valid, and sync the cpumask_of_node between the
> cpumask_of_node function in numa.h and numa.c.
Why?
> Signed-off-by: Yunsheng Lin
> ---
> arch/arm64/include/asm/numa.h | 6 ++
> arch/arm64/mm/numa.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
> index 626ad01..da891ed 100644
> --- a/arch/arm64/include/asm/numa.h
> +++ b/arch/arm64/include/asm/numa.h
> @@ -25,6 +25,12 @@ const struct cpumask *cpumask_of_node(int node);
> /* Returns a pointer to the cpumask of CPUs on Node 'node'. */
> static inline const struct cpumask *cpumask_of_node(int node)
> {
> + if (node >= nr_node_ids || node < 0)
> + return cpu_none_mask;
> +
> + if (!node_to_cpumask_map[node])
> + return cpu_online_mask;
> +
> return node_to_cpumask_map[node];
> }
> #endif
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index 4f241cc..3846313 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -46,7 +46,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
> */
> const struct cpumask *cpumask_of_node(int node)
> {
> - if (WARN_ON(node >= nr_node_ids))
> + if (WARN_ON(node >= nr_node_ids || node < 0))
> return cpu_none_mask;
>
> if (WARN_ON(node_to_cpumask_map[node] == NULL))
> --
> 2.8.1
--
Michal Hocko
SUSE Labs
Re: [PATCH] mm: memcontrol: fix percpu vmstats and vmevents flush
On Thu 29-08-19 13:31:10, Shakeel Butt wrote:
> Instead of using raw_cpu_read() use per_cpu() to read the actual data of
> the corresponding cpu otherwise we will be reading the data of the
> current cpu for the number of online CPUs.
>
> Fixes: bb65f89b7d3d ("mm: memcontrol: flush percpu vmevents before releasing
> memcg")
> Fixes: c350a99ea2b1 ("mm: memcontrol: flush percpu vmstats before releasing
> memcg")
> Signed-off-by: Shakeel Butt
> Cc: Roman Gushchin
> Cc: Michal Hocko
> Cc: Johannes Weiner
> Cc: Vladimir Davydov
> Cc: Andrew Morton
> Cc:
Ups, missed that when reviewing. Sorry about that.
Acked-by: Michal Hocko
> ---
>
> Note: The buggy patches were marked for stable therefore adding Cc to
> stable.
>
> mm/memcontrol.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 26e2999af608..f4e60ee8b845 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3271,7 +3271,7 @@ static void memcg_flush_percpu_vmstats(struct
> mem_cgroup *memcg)
>
> for_each_online_cpu(cpu)
> for (i = 0; i < MEMCG_NR_STAT; i++)
> - stat[i] += raw_cpu_read(memcg->vmstats_percpu->stat[i]);
> + stat[i] += per_cpu(memcg->vmstats_percpu->stat[i], cpu);
>
> for (mi = memcg; mi; mi = parent_mem_cgroup(mi))
> for (i = 0; i < MEMCG_NR_STAT; i++)
> @@ -3286,8 +3286,8 @@ static void memcg_flush_percpu_vmstats(struct
> mem_cgroup *memcg)
>
> for_each_online_cpu(cpu)
> for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++)
> - stat[i] += raw_cpu_read(
> - pn->lruvec_stat_cpu->count[i]);
> + stat[i] += per_cpu(
> + pn->lruvec_stat_cpu->count[i], cpu);
>
> for (pi = pn; pi; pi = parent_nodeinfo(pi, node))
> for (i = 0; i < NR_VM_NODE_STAT_ITEMS; i++)
> @@ -3306,8 +3306,8 @@ static void memcg_flush_percpu_vmevents(struct
> mem_cgroup *memcg)
>
> for_each_online_cpu(cpu)
> for (i = 0; i < NR_VM_EVENT_ITEMS; i++)
> - events[i] += raw_cpu_read(
> - memcg->vmstats_percpu->events[i]);
> + events[i] += per_cpu(memcg->vmstats_percpu->events[i],
> + cpu);
>
> for (mi = memcg; mi; mi = parent_mem_cgroup(mi))
> for (i = 0; i < NR_VM_EVENT_ITEMS; i++)
> --
> 2.23.0.187.g17f5b7556c-goog
>
--
Michal Hocko
SUSE Labs
Re: [PATCH 5/8] media: cedrus: Detect first slice of a frame
On Thu, 29 Aug 2019 21:04:28 +0200
Jernej Škrabec wrote:
> Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
> napisal(a):
> > Hi Jernej,
> >
> > On Thu, 22 Aug 2019 21:44:57 +0200
> >
> > Jernej Skrabec wrote:
> > > When codec supports multiple slices in one frame, VPU has to know when
> > > first slice of each frame is being processed, presumably to correctly
> > > clear/set data in auxiliary buffers.
> > >
> > > Add first_slice field to cedrus_run structure and set it according to
> > > timestamps of capture and output buffers. If timestamps are different,
> > > it's first slice and viceversa.
> > >
> > > Signed-off-by: Jernej Skrabec
> > > ---
> > >
> > > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > > 2 files changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > > 2f017a651848..32cb38e541c6 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > > @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> > >
> > > struct cedrus_run {
> > >
> > > struct vb2_v4l2_buffer *src;
> > > struct vb2_v4l2_buffer *dst;
> > >
> > > + bool first_slice;
> > >
> > > union {
> > >
> > > struct cedrus_h264_run h264;
> > >
> > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > > 56ca4c9ad01c..d7b54accfe83 100644
> > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > > @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
> > >
> > > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > >
> > > + run.first_slice =
> > > + run.src->vb2_buf.timestamp != run.dst-
> >vb2_buf.timestamp;
> >
> > Can't we use slice->first_mb_in_slice to determine if a slice is the
> > first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
> > support ASO).
>
> I looked in all VPU documentation available to me (which isn't much) and
> there
> is no indication if ASO is supported or not. Do you have any sample video
> with
> out-of-order slices? It's my understanding that this is uncommon.
I'm not entirely sure, but my understanding was that it might be used
when streaming over network where some packets might be lost and
re-emitted later on.
> If it's
> supported, I would leave code as-is.
I remember seeing the ASO acronym mentioned in the hantro G1 spec, but
at the same time we're doing frame-based decoding, so I guess the HW
block expects slices to be ordered in that case. Honestly I don't know,
so let's keep the code as-is.
[PATCH] fs/epoll: fix the edge-triggered mode for epoll itself
From: Heiher
The structure of event pools:
efd[2]:
{
sfd[0] (EPOLLIN)
}
efd[1]:
{
efd[2] (EPOLLIN)
}
efd[0]:
{
efd[2] (EPOLLIN | EPOLLET)
}
When sfd[0] to be readable:
* the epoll_wait(efd[0], ..., 0) should return efd[2]'s events on first call,
and returns 0 on next calls, because efd[2] is added in edge-triggered mode.
* the epoll_wait(efd[1], ..., 0) should returns efd[2]'s events on every calls
until efd[2] is not readable (epoll_wait(efd[2], ...) => 0), because efd[1]
is added in level-triggered mode.
* the epoll_wait(efd[2], ..., 0) should returns sfd[0]'s events on every calls
until sfd[0] is not readable (read(sfd[0], ...) => EAGAIN), because sfd[0]
is added in level-triggered mode.
#include
#include
#include
#include
int main(int argc, char *argv[])
{
int sfd[2];
int efd[3];
int nfds;
struct epoll_event e;
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sfd) < 0)
goto out;
efd[0] = epoll_create(1);
if (efd[0] < 0)
goto out;
efd[1] = epoll_create(1);
if (efd[1] < 0)
goto out;
efd[2] = epoll_create(1);
if (efd[2] < 0)
goto out;
e.events = EPOLLIN;
if (epoll_ctl(efd[2], EPOLL_CTL_ADD, sfd[0], ) < 0)
goto out;
e.events = EPOLLIN;
if (epoll_ctl(efd[1], EPOLL_CTL_ADD, efd[2], ) < 0)
goto out;
e.events = EPOLLIN | EPOLLET;
if (epoll_ctl(efd[0], EPOLL_CTL_ADD, efd[2], ) < 0)
goto out;
if (write(sfd[1], "w", 1) != 1)
goto out;
nfds = epoll_wait(efd[0], , 1, 0);
if (nfds != 1)
goto out;
nfds = epoll_wait(efd[0], , 1, 0);
if (nfds != 0)
goto out;
nfds = epoll_wait(efd[1], , 1, 0);
if (nfds != 1)
goto out;
nfds = epoll_wait(efd[1], , 1, 0);
if (nfds != 1)
goto out;
nfds = epoll_wait(efd[2], , 1, 0);
if (nfds != 1)
goto out;
nfds = epoll_wait(efd[2], , 1, 0);
if (nfds != 1)
goto out;
close(efd[1]);
close(efd[0]);
close(sfd[0]);
close(sfd[1]);
printf("SUCC\n");
return 0;
out:
printf("FAIL\n");
return -1;
}
Signed-off-by: hev
Cc: Eric Wong
Cc: linux-kernel@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
---
fs/eventpoll.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index d7f1f5011fac..a44cb27c636c 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -672,6 +672,7 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
{
__poll_t res;
int pwake = 0;
+ int nwake = 0;
struct epitem *epi, *nepi;
LIST_HEAD(txlist);
@@ -685,6 +686,9 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
if (!ep_locked)
mutex_lock_nested(>mtx, depth);
+ if (!depth || list_empty(>rdllist))
+ nwake = 1;
+
/*
* Steal the ready list, and re-init the original one to the
* empty list. Also, set ep->ovflist to NULL so that events
@@ -739,7 +743,7 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
list_splice(, >rdllist);
__pm_relax(ep->ws);
- if (!list_empty(>rdllist)) {
+ if (nwake && !list_empty(>rdllist)) {
/*
* Wake up (if active) both the eventpoll wait list and
* the ->poll() wait list (delayed after we release the lock).
--
2.23.0
Re: [PATCH] leds: pwm: Use struct_size() helper
On Thu, Aug 29, 2019 at 07:53:20PM -0500, Gustavo A. R. Silva wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct led_pwm_priv {
> ...
> struct led_pwm_data leds[0];
> };
>
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> So, replace the following function:
>
> static inline size_t sizeof_pwm_leds_priv(int num_leds)
> {
>return sizeof(struct led_pwm_priv) +
> (sizeof(struct led_pwm_data) * num_leds);
> }
>
> with:
>
> struct_size(priv, leds, count)
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Kees Cook
-Kees
> ---
> drivers/leds/leds-pwm.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
> index d0e1f2710351..8b6965a563e9 100644
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@ -65,12 +65,6 @@ static int led_pwm_set(struct led_classdev *led_cdev,
> return 0;
> }
>
> -static inline size_t sizeof_pwm_leds_priv(int num_leds)
> -{
> - return sizeof(struct led_pwm_priv) +
> - (sizeof(struct led_pwm_data) * num_leds);
> -}
> -
> static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
> struct led_pwm *led, struct fwnode_handle *fwnode)
> {
> @@ -174,7 +168,7 @@ static int led_pwm_probe(struct platform_device *pdev)
> if (!count)
> return -EINVAL;
>
> - priv = devm_kzalloc(>dev, sizeof_pwm_leds_priv(count),
> + priv = devm_kzalloc(>dev, struct_size(priv, leds, count),
> GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
> --
> 2.23.0
>
--
Kees Cook
Re: [PATCH v3 1/2] net: core: Notify on changes to dev->promiscuity.
Fri, Aug 30, 2019 at 12:12:01AM CEST, da...@davemloft.net wrote: >From: Ido Schimmel >Date: Thu, 29 Aug 2019 22:36:13 +0300 > >> I fully agree that we should make it easy for users to capture offloaded >> traffic, which is why I suggested patching libpcap. Add a flag to >> capable netdevs that tells libpcap that in order to capture all the >> traffic from this interface it needs to add a tc filter with a trap >> action. That way zero familiarity with tc is required from users. > >Why not just make setting promisc mode on the device do this rather than >require all of this tc indirection nonsense? Because the "promisc mode" would gain another meaning. Now how the driver should guess which meaning the user ment when he setted it? filter or trap? That is very confusing. If the flag is the way to do this, let's introduce another flag, like IFF_TRAPPING indicating that user wants exactly this. > >That's the whole point of this conversation I thought?
Re: [PATCH] xfs: Initialize label array properly
On Fri, Aug 30, 2019 at 02:37:07PM +0900, Austin Kim wrote:
> In case kernel stack variable is not initialized properly,
> there is a risk of kernel information disclosure.
>
> So, initialize 'char label[]' array with null characters.
Got a testcase for this? At least a couple other filesystems implement
this ioctl too, which means they all should be checked/tested on a
regular basis.
--D
> Signed-off-by: Austin Kim
> ---
> fs/xfs/xfs_ioctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index 9ea5166..09b3bee 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -2037,7 +2037,7 @@ xfs_ioc_setlabel(
> char__user *newlabel)
> {
> struct xfs_sb *sbp = >m_sb;
> - charlabel[XFSLABEL_MAX + 1];
> + charlabel[XFSLABEL_MAX + 1] = {0};
> size_t len;
> int error;
>
> --
> 2.6.2
>
Re: [PATCH 1/2] w1: add 1-wire master driver for IP block found in SGI ASICs
Hi Thomas, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3-rc6 next-20190829] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thomas-Bogendoerfer/w1-add-1-wire-master-driver-for-IP-block-found-in-SGI-ASICs/20190830-122322 reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme. WARNING: dot(1) not found, for better output quality install graphviz from http://www.graphviz.org WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) >> include/linux/w1.h:156: warning: Function parameter or member 'dev_id' not >> described in 'w1_bus_master' include/linux/w1.h:274: warning: Function parameter or member 'of_match_table' not described in 'w1_family' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'quotactl' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'quota_on' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_free_mnt_opts' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_eat_lsm_opts' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_kern_mount' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_show_options' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_add_mnt_opt' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'd_instantiate' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'getprocattr' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'setprocattr' not described in 'security_list_options' lib/genalloc.c:1: warning: 'gen_pool_add_virt' not found lib/genalloc.c:1: warning: 'gen_pool_alloc' not found lib/genalloc.c:1: warning: 'gen_pool_free' not found lib/genalloc.c:1: warning: 'gen_pool_alloc_algo' not found include/linux/i2c.h:337: warning: Function parameter or member 'init_irq' not described in 'i2c_client' include/linux/spi/spi.h:190: warning: Function parameter or member 'driver_override' not described in 'spi_device' drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not found include/linux/input/sparse-keymap.h:43: warning: Function parameter or member 'sw' not described in 'key_entry' include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' fs/direct-io.c:258: warning: Excess function parameter 'offset' description in 'dio_complete' fs/libfs.c:496: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:647: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' include/linux/skbuff.h:893: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'list' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'head_frag' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member '__pkt_type_offset' not described in 'sk_buff' include/linux/skbuff.h:893:
Re: [PATCH] mm/vmalloc: move 'area->pages' after if statement
On Fri 30-08-19 12:57:16, Austin Kim wrote:
> If !area->pages statement is true where memory allocation fails,
> area is freed.
>
> In this case 'area->pages = pages' should not executed.
> So move 'area->pages = pages' after if statement.
>
> Signed-off-by: Austin Kim
Acked-by: Michal Hocko
Thanks!
> ---
> mm/vmalloc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index b810103..af93ba6 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2416,13 +2416,15 @@ static void *__vmalloc_area_node(struct vm_struct
> *area, gfp_t gfp_mask,
> } else {
> pages = kmalloc_node(array_size, nested_gfp, node);
> }
> - area->pages = pages;
> - if (!area->pages) {
> +
> + if (!pages) {
> remove_vm_area(area->addr);
> kfree(area);
> return NULL;
> }
>
> + area->pages = pages;
> +
> for (i = 0; i < area->nr_pages; i++) {
> struct page *page;
>
> --
> 2.6.2
>
--
Michal Hocko
SUSE Labs
Re: [PATCH 4/5] dt-bindings: dma: ti-edma: Add option for reserved channel ranges
Rob, On 30/08/2019 1.47, Rob Herring wrote: > On Fri, Aug 23, 2019 at 03:56:17PM +0300, Peter Ujfalusi wrote: >> Similarly to paRAM slots, channels can be used by other cores. >> >> Add optional property to configure the reserved channel ranges. >> >> Signed-off-by: Peter Ujfalusi >> --- >> Documentation/devicetree/bindings/dma/ti-edma.txt | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt >> b/Documentation/devicetree/bindings/dma/ti-edma.txt >> index 4bbc94d829c8..1198682ada99 100644 >> --- a/Documentation/devicetree/bindings/dma/ti-edma.txt >> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt >> @@ -42,6 +42,9 @@ Optional properties: >> - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used >> by >> the driver, they are allocated to be used by for example the >> DSP. See example. >> +- ti,edma-reserved-chan-ranges: channel ranges which should not be used by >> +the driver, they are allocated to be used by for example the >> +DSP. See example. > > Based on the other thread, I think extending dma-channel-mask to a > uint32-array makes sense here. Yes, that is the reason I have asked on that and I'm in progress of converting the edma driver to use the dma-channel-mask. Just need to do some shuffling in the driver to get the mask in a form usable by the driver. I'll send an updated series early next week. - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [RFC PATCH v2 2/2] ELF: Add ELF program property parsing support
On Fri, Aug 23, 2019 at 06:23:40PM +0100, Dave Martin wrote:
> ELF program properties will needed for detecting whether to enable
> optional architecture or ABI features for a new ELF process.
>
> For now, there are no generic properties that we care about, so do
> nothing unless CONFIG_ARCH_USE_GNU_PROPERTY=y.
>
> Otherwise, the presence of properties using the PT_PROGRAM_PROPERTY
> phdrs entry (if any), and notify each property to the arch code.
>
> For now, the added code is not used.
>
> Signed-off-by: Dave Martin
Reviewed-by: Kees Cook
Note below...
> [...]
> +static int parse_elf_property(const char *data, size_t *off, size_t datasz,
> + struct arch_elf_state *arch,
> + bool have_prev_type, u32 *prev_type)
> +{
> + size_t size, step;
> + const struct gnu_property *pr;
> + int ret;
> +
> + if (*off == datasz)
> + return -ENOENT;
> +
> + if (WARN_ON(*off > datasz || *off % elf_gnu_property_align))
> + return -EIO;
> +
> + size = datasz - *off;
> + if (size < sizeof(*pr))
> + return -EIO;
> +
> + pr = (const struct gnu_property *)(data + *off);
> + if (pr->pr_datasz > size - sizeof(*pr))
> + return -EIO;
> +
> + step = round_up(sizeof(*pr) + pr->pr_datasz, elf_gnu_property_align);
> + if (step > size)
> + return -EIO;
> +
> + /* Properties are supposed to be unique and sorted on pr_type: */
> + if (have_prev_type && pr->pr_type <= *prev_type)
> + return -EIO;
> + *prev_type = pr->pr_type;
> +
> + ret = arch_parse_elf_property(pr->pr_type,
> + data + *off + sizeof(*pr),
> + pr->pr_datasz, ELF_COMPAT, arch);
I find it slightly hard to read the "cursor" motion in this parse. It
feels strange, for example, to refer twice to "data + *off" with the
second including consumed *pr size. Everything is fine AFAICT in the math,
though, and I haven't been able to construct a convincingly "cleaner"
version. Maybe:
data += *off;
pr = (const struct gnu_property *)data;
data += sizeof(*pr);
...
ret = arch_parse_elf_property(pr->pr_type, data,
pr->pr_datasz, ELF_COMPAT, arch);
But that feels disjoint from the "step" calculation, so... I think what
you have is fine. :)
--
Kees Cook
Re: [PATCH v3 07/11] xfs: remove unlikely() from WARN_ON() condition
On Thu, Aug 29, 2019 at 07:50:21PM +0300, Denis Efremov wrote: > "unlikely(WARN_ON(x))" is excessive. WARN_ON() already uses unlikely() > internally. Looks good, Reviewed-by: Christoph Hellwig
[PATCH] xfs: Initialize label array properly
In case kernel stack variable is not initialized properly,
there is a risk of kernel information disclosure.
So, initialize 'char label[]' array with null characters.
Signed-off-by: Austin Kim
---
fs/xfs/xfs_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index 9ea5166..09b3bee 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -2037,7 +2037,7 @@ xfs_ioc_setlabel(
char__user *newlabel)
{
struct xfs_sb *sbp = >m_sb;
- charlabel[XFSLABEL_MAX + 1];
+ charlabel[XFSLABEL_MAX + 1] = {0};
size_t len;
int error;
--
2.6.2
Re: [PATCH 1/2] arm64: dts: qcom: qcs404: add sleep clk fixed rate oscillator
Quoting Jorge Ramirez-Ortiz (2019-08-29 13:03:39) > This fixed rate clock is required for the operation of some devices > (ie watchdog). > > Signed-off-by: Jorge Ramirez-Ortiz > --- Reviewed-by: Stephen Boyd
Re: [PATCH 2/2] arm64: dts: qcom: qcs404: add the watchdog node
Quoting Jorge Ramirez-Ortiz (2019-08-29 13:03:40) > Allows QCS404 based designs to enable watchdog support > > Signed-off-by: Jorge Ramirez-Ortiz > --- Reviewed-by: Stephen Boyd
Re: [RESEND PATCH v2 1/2] dt-bindings: reset: aoss: Add AOSS reset binding for SC7180 SoCs
Quoting Sibi Sankar (2019-08-24 08:24:10) > Add SC7180 AOSS reset to the list of possible bindings. > > Signed-off-by: Sibi Sankar > --- > Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt | 4 ++-- Can you convert this binding to YAML/JSON schema? Would help to describe the 'one of' requirement below in a more structured way. > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt > b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt > index 510c748656ec5..3eb6a22ced4bc 100644 > --- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt > +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.txt > @@ -8,8 +8,8 @@ Required properties: > - compatible: > Usage: required > Value type: > - Definition: must be: > - "qcom,sdm845-aoss-cc" > + Definition: must be one of:
Re: [PATCH v5, 12/32] drm/mediatek: add mmsys private data for ddp path config
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add mmsys private data for ddp path config
> all these register offset and value will be different in future SOC
> add these define into mmsys private data
> u32 ovl0_mout_en;
> u32 rdma1_sout_sel_in;
> u32 rdma1_sout_dsi0;
> u32 dpi0_sel_in;
> u32 dpi0_sel_in_rdma1;
> u32 dsi0_sel_in;
> u32 dsi0_sel_in_rdma1;
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 86
> +++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 5 ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 3 ++
> 5 files changed, 76 insertions(+), 25 deletions(-)
>
[snip]
>
> void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> + const struct mtk_mmsys_reg_data *reg_data,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next)
> {
> unsigned int addr, value, reg;
>
> - value = mtk_ddp_mout_en(cur, next, );
> + value = mtk_ddp_mout_en(reg_data, cur, next, );
> if (value) {
> reg = readl_relaxed(config_regs + addr) | value;
> writel_relaxed(reg, config_regs + addr);
> }
>
> - mtk_ddp_sout_sel(config_regs, cur, next);
> + value = mtk_ddp_sout_sel(reg_data, cur, next, );
> + if (value)
> + writel_relaxed(value, config_regs + addr);
I think the register could be written inside mtk_ddp_sout_sel(), why do
you move out of that function?
Regards,
CK
>
> - value = mtk_ddp_sel_in(cur, next, );
> + value = mtk_ddp_sel_in(reg_data, cur, next, );
> if (value) {
> reg = readl_relaxed(config_regs + addr) | value;
> writel_relaxed(reg, config_regs + addr);
> @@ -420,18 +455,19 @@ void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> }
>
>
>
Re: [PATCH] arm64: dts: sdm845: Add parent clock for rpmhcc
Quoting Vinod Koul (2019-08-22 10:11:35) > RPM clock controller has parent as xo, so specify that in DT node for > rpmhcc > > Signed-off-by: Vinod Koul > --- Reviewed-by: Stephen Boyd
Re: [PATCH V3 01/10] dt-bindings: soc: Add dvfsrc driver bindings
On Thu, 2019-08-29 at 14:16 -0500, Rob Herring wrote: > On Wed, 28 Aug 2019 20:28:39 +0800, Henry Chen wrote: > > Document the binding for enabling dvfsrc on MediaTek SoC. > > > > Signed-off-by: Henry Chen > > --- > > .../devicetree/bindings/soc/mediatek/dvfsrc.txt| 23 > > ++ > > include/dt-bindings/soc/mtk,dvfsrc.h | 14 + > > 2 files changed, 37 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/soc/mediatek/dvfsrc.txt > > create mode 100644 include/dt-bindings/soc/mtk,dvfsrc.h > > > > Please add Acked-by/Reviewed-by tags when posting new versions. However, > there's no need to repost patches *only* to add the tags. The upstream > maintainer will do that for acks received on the version they apply. > > If a tag was not added on purpose, please state why and what changed. Hi Rob, I'm sorry for the mistake. I stand corrected, and will add tags on next version. Henry
Re: [RFC][PATCH 1/1] Carry ima measurement log for arm64 via kexec_file_load
Why is linux-arm-msm list CCed on this topic?
Quoting Prakhar Srivastava (2019-08-29 13:05:32)
> Carry ima measurement log for arm64 via kexec_file_load.
> add support to kexec_file_load to pass the ima measurement log
These first two sentences look sort of odd for a commit text.
>
> This patch adds entry for the ima measurement log in the
Don't use 'this patch' in commit text. It's in the wrong voice.
> dtb which is then used in the kexec'ed session to fetch the
> segment and then load the ima measurement log.
>
> Signed-off-by: Prakhar Srivastava
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3adcec05b1f6..9e1b831e7baa 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -964,6 +964,13 @@ config KEXEC_FILE
> for kernel and initramfs as opposed to list of segments as
> accepted by previous system call.
>
> +config HAVE_IMA_KEXEC
> + bool "enable arch specific ima buffer pass"
> + depends on KEXEC_FILE
> + help
> + This adds support to carry ima log to the next kernel in case
Should ima be all caps here?
> + of kexec_file_load
Add a full-stop?
> +
> config KEXEC_VERIFY_SIG
> bool "Verify kernel signature during kexec_file_load() syscall"
> depends on KEXEC_FILE
> diff --git a/arch/arm64/include/asm/ima.h b/arch/arm64/include/asm/ima.h
> new file mode 100644
> index ..2c504281028d
> --- /dev/null
> +++ b/arch/arm64/include/asm/ima.h
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_ARM64_IMA_H
> +#define _ASM_ARM64_IMA_H
> +
> +#define FDT_PROP_KEXEC_BUFFER "linux,ima-kexec-buffer"
Is this documented somewhere in the DT bindings?
> +
> +struct kimage;
> +
> +int ima_get_kexec_buffer(void **addr, size_t *size);
> +int ima_free_kexec_buffer(void);
> +
> +#ifdef CONFIG_IMA
> +void remove_ima_buffer(void *fdt, int chosen_node);
> +#else
> +static inline void remove_ima_buffer(void *fdt, int chosen_node) {}
> +#endif
> +
> +#ifdef CONFIG_IMA_KEXEC
> +int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
> + size_t size);
> +
> +int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node);
> +#else
> +static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
> + int chosen_node)
> +{
> + remove_ima_buffer(fdt, chosen_node);
> + return 0;
> +}
> +#endif /* CONFIG_IMA_KEXEC */
> +#endif /* _ASM_ARM64_IMA_H */
> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> index 12a561a54128..ca1f9ad5c4d4 100644
> --- a/arch/arm64/include/asm/kexec.h
> +++ b/arch/arm64/include/asm/kexec.h
> @@ -96,6 +96,8 @@ static inline void crash_post_resume(void) {}
> struct kimage_arch {
> void *dtb;
> unsigned long dtb_mem;
> + phys_addr_t ima_buffer_addr;
> + size_t ima_buffer_size;
Should this be in an ifdef?
> };
>
> extern const struct kexec_file_ops kexec_image_ops;
> @@ -107,6 +109,8 @@ extern int load_other_segments(struct kimage *image,
> unsigned long kernel_load_addr, unsigned long kernel_size,
> char *initrd, unsigned long initrd_len,
> char *cmdline);
> +extern int delete_fdt_mem_rsv(void *fdt, unsigned long start,
> + unsigned long size);
> #endif
>
> #endif /* __ASSEMBLY__ */
> diff --git a/arch/arm64/kernel/ima_kexec.c b/arch/arm64/kernel/ima_kexec.c
> new file mode 100644
> index ..5ae0d776ec42
> --- /dev/null
> +++ b/arch/arm64/kernel/ima_kexec.c
> @@ -0,0 +1,219 @@
> +/*
> + * Copyright (C) 2016 IBM Corporation
> + *
> + * Authors:
> + * Thiago Jung Bauermann
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
Please use a SPDX tag instead of this boiler plate.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int get_addr_size_cells(int *addr_cells, int *size_cells)
> +{
> + struct device_node *root;
> +
> + root = of_find_node_by_path("/");
> + if (!root)
> + return -EINVAL;
> +
> + *addr_cells = of_n_addr_cells(root);
> + *size_cells = of_n_size_cells(root);
> +
> + of_node_put(root);
> +
> + return 0;
> +}
> +
> +static int do_get_kexec_buffer(const void *prop, int len, unsigned long
> *addr,
> + size_t *size)
> +{
> +
> + int ret, addr_cells, size_cells;
> +
> + ret = get_addr_size_cells(_cells, _cells);
> + if (ret)
> + return ret;
> +
> + if (len < 4 * (addr_cells + size_cells))
> + return -ENOENT;
> +
> + *addr = of_read_number(prop, addr_cells);
> +
LOANS !!!
Dial Direct Loan SA Consolidate your debts with Dial Direct Loan SA for your peace of mind at a fixed interest rate of 4.75%,personal and business loans are also welcome.For details file in your applications by sending an email to:dialdirectloan...@mail2consultant.com. Yours in Service, Susan Muller (Mrs.), Senior Consultant, Loan Application Team Dial Direct Loan SA Tel No: +27717231058
Re: [PATCH v2] kunit: fix failure to build without printk
On (08/29/19 11:01), shuah wrote: [..] > Hi Sergey, > > What are the guidelines for using printk(). I recall some discussion > about not using printk(). I am seeing the following from checkpatch > script: Hello, > WARNING: Prefer [subsystem eg: netdev]_level([subsystem]dev, ... then > dev_level(dev, ... then pr_level(... to printk(KERN_LEVEL ... > #105: FILE: include/kunit/test.h:343: > + printk(KERN_LEVEL "\t# %s: " fmt, (test)->name, ##__VA_ARGS__) > Oh, right. So we sort of want people to use pr_err()/pr_info()/pr_"level"() because, otherwise, when people use plain printk(), they tend to forget to add KERN_LEVEL. In kunit case everything looks fine. KERN_LEVEL is there so I'm fine with the patch. You still can switch to pr_info()/pr_err()/pr_etc, just to make checkpatch happier, but that's up to you. > Is there supposed to be pr_level() - I can find dev_level() No, not really. pr_level() stands for pr_"debug"()/pr_"info"()/etc. E.g. #define pr_emerg(fmt, ...) \ printk(KERN_EMERG pr_fmt(fmt), ##__VA_ARGS__) #define pr_alert(fmt, ...) \ printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__) #define pr_crit(fmt, ...) \ printk(KERN_CRIT pr_fmt(fmt), ##__VA_ARGS__) #define pr_err(fmt, ...) \ printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__) #define pr_warning(fmt, ...) \ printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__) #define pr_warn pr_warning #define pr_notice(fmt, ...) \ printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__) #define pr_info(fmt, ...) \ printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__) -ss
Re: [PATCH v4] firmware: google: check if size is valid when decoding VPD data
Quoting Hung-Te Lin (2019-08-29 19:23:58)
> The VPD implementation from Chromium Vital Product Data project used to
> parse data from untrusted input without checking if the meta data is
> invalid or corrupted. For example, the size from decoded content may
> be negative value, or larger than whole input buffer. Such invalid data
> may cause buffer overflow.
>
> To fix that, the size parameters passed to vpd_decode functions should
> be changed to unsigned integer (u32) type, and the parsing of entry
> header should be refactored so every size field is correctly verified
> before starting to decode.
>
> Fixes: ad2ac9d5c5e0 ("firmware: Google VPD: import lib_vpd source files")
> Signed-off-by: Hung-Te Lin
Reviewed-by: Stephen Boyd
[PATCH v2] Bluetooth: hci_qca: wait for Pre shutdown complete event before sending the Power off pulse
When SoC receives pre shut down command, it share the same
with other COEX shared clients. So SoC needs a short time
after sending VS pre shutdown command before turning off
the regulators and sending the power off pulse. Along with
short delay, needs to wait for command complete event for
Pre shutdown VS command
Signed-off-by: Harish Bandi
Reviewed-by: Balakrishna Godavarthi
---
Changes in V2:
- Modified commit text.
---
drivers/bluetooth/btqca.c | 22 ++
drivers/bluetooth/hci_qca.c | 5 +
2 files changed, 27 insertions(+)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index 8b33128..d48dc9e 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -99,6 +99,28 @@ static int qca_send_reset(struct hci_dev *hdev)
return 0;
}
+int qca_send_pre_shutdown_cmd(struct hci_dev *hdev)
+{
+ struct sk_buff *skb;
+ int err;
+
+ bt_dev_dbg(hdev, "QCA pre shutdown cmd");
+
+ skb = __hci_cmd_sync_ev(hdev, QCA_PRE_SHUTDOWN_CMD, 0,
+ NULL, HCI_EV_CMD_COMPLETE, HCI_INIT_TIMEOUT);
+
+ if (IS_ERR(skb)) {
+ err = PTR_ERR(skb);
+ bt_dev_err(hdev, "QCA preshutdown_cmd failed (%d)", err);
+ return err;
+ }
+
+ kfree_skb(skb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(qca_send_pre_shutdown_cmd);
+
static void qca_tlv_check_data(struct rome_config *config,
const struct firmware *fw)
{
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index ab4c18e..43df13c 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1367,6 +1367,11 @@ static int qca_power_off(struct hci_dev *hdev)
{
struct hci_uart *hu = hci_get_drvdata(hdev);
+ /* Perform pre shutdown command */
+ qca_send_pre_shutdown_cmd(hdev);
+
+ usleep_range(8000, 1);
+
qca_power_shutdown(hu);
return 0;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Hoping to hear from you
Dear Sir/Madam, Although you might be apprehensive about my email as we have never met before. I am Mr.Patrick Joseph, a Banker and Head of Operations with Bank here in Burkina Faso West Africa, there is the sum of $28.500,000.00 Million Dollars currently in my branch, there were no beneficiary stated concerning these funds which means no one would ever come to claim it. That is why I ask that can we work together, I will be pleased to work with you as trusted person and see that the fund is transferred out of my Bank into another Bank Account, Once the funds have been transferred to your nominated Bank account we shall then share it in the ratio of 60% for me, 40% for you. If you agree to my business proposal.further details of the transfer will be forwarded to you as soon as i receive your return mail, sending the below information 1. Full Name. 2: Your Private telephone and Fax numbers. 3. Occupations. 4. Date Of Birth 5. Country of Residence. 6. Your full address. Hoping to hear from you as soon as possible. Regards, Mr.Patrick Joseph.
Re: Adding depends-on DT binding to break cyclic dependencies
On Thu, Aug 29, 2019 at 9:28 AM Rob Herring wrote: > > On Thu, Aug 22, 2019 at 1:55 AM Saravana Kannan wrote: > > > > Hi Rob, > > > > Frank, Greg and I got together during ELC and had an extensive and > > very productive discussion about my "postboot supplier state cleanup" > > patch series [1]. The three of us are on the same page now -- the > > series as it stands is the direction we want to go in, with some minor > > refactoring, documentation and naming changes. > > > > However, one of the things Frank is concerned about (and Greg and I > > agree) in the current patch series is that the "cyclic dependency > > breaking" logic has been pushed off to individual drivers using the > > edit_links() callback. > > I would think the core can detect this condition. There's nothing > device specific once you have the dependency tree. You still need to > know what device needs to probe first and the drivers are going to > have that knowledge anyways. So wouldn't it be enough to allow probe > to proceed for devices in the loop. The problem is that device links don't allow creating a cyclic dependency graph -- for good reasons. The last link in the cycle would be rejected. I don't think trying to change device link to allow cyclic links is the right direction to go in nor is it a can of worms I want to open. So, we'll need some other way of tracking the loop and then allowing only those devices in a loop to attempt probing even if their suppliers haven't probed. And then if a device ends up being in more than one loop, things could get even more complicated. And after one of the devices in the loop probes, we still need to somehow figure out the "bad" link and delete it so the last "good" link can be made before all the suppliers have their sync_state() called (because the "good" link hasn't been created yet). That all gets pretty messy. If we are never going to accept any DT changes, then I'd rather go with edit_links() and keep the complexity within the one off weird hardware where there are cycles instead of over complicating the driver core. > Once 1 driver succeeds, then you > can enforce the dependencies on the rest. > > > The concern being, there are going to be multiple device specific ad > > hoc implementations to break a cyclic dependency. Also, if a device > > can be part of a cyclic dependency, the driver for that device has to > > check for specific system/products in which the device is part of a > > cyclic dependency (because it might not always be part of a cycle), > > and then potentially have cycle/product specific code to break the > > cycle (since the cycle can be different on each system/product). > > > > One way to avoid all of the device/driver specific code and simplify > > my patch series by a non-trivial amount would be by adding a > > "depends-on" DT binding that can ONLY be used to break cycles. We can > > document it as such and reject any attempts to use it for other > > purposes. When a depends-on property is present in a device node, that > > specific device's supplier list will be parsed ONLY from the > > depends-on property and the other properties won't be parsed for > > deriving dependency information for that device. > > Seems like only ignoring the dependencies with a cycle would be > sufficient. No, we need to only ignore the "bad" dependency. We can't ignore all the dependencies in the cycle because that would cause the suppliers to clean up the hardware state before the consumers are ready. > For example, consider a clock controller which has 2 clock > inputs from other clock controllers where one has a cycle and one > doesn't. Also consider it has a regulator dependency. We only need to > ignore the dependency for 1 of the clock inputs. The rest of the > dependencies should be honored. Agreed. In this case, if the device used the depends-on property, it'll have to list the 1 clock controller and the regulator. > > Frank, Greg and I like this usage model for a new depends-on DT > > binding. Is this something you'd be willing to accept? > > To do the above, it needs to be inverted. I understand you are basically asking for a "does-not-depend-on" property (like a black list). But I think a whitelist on the rare occasions that we need to override would give more flexibility than a blacklist. It'll also mean we don't have to check every supplier with the entire black list each time. > Convince me that cycles are really a problem anywhere besides clocks. I wouldn't be surprised at all if interconnects end up with cyclic dependencies as support for more of them are added. > I'd be more comfortable with a clock specific property if we only need > it for clocks and I'm having a hard time imagining cycles for other > dependencies. I definitely don't want per-supplier type override. That's just making things too complicated and adding too many DT properties if we need to override more than clocks. -Saravana
Re: [PATCH v2] kunit: fix failure to build without printk
On Thu, 2019-08-29 at 21:44 -0700, Joe Perches wrote: > On Thu, 2019-08-29 at 11:01 -0600, shuah wrote: [] > > WARNING: Prefer [subsystem eg: netdev]_level([subsystem]dev, ... then > > dev_level(dev, ... then pr_level(... to printk(KERN_LEVEL ... > > #105: FILE: include/kunit/test.h:343: > > + printk(KERN_LEVEL "\t# %s: " fmt, (test)->name, ##__VA_ARGS__) > > > > > > Is there supposed to be pr_level() - I can find dev_level() btw: the checkpatch message is meant to be interpreted as Prefer [subsystem eg: netdev]_([subsystem]dev, ...) then dev_(dev, ...) then pr_(...), to printk(KERN_ ...) btw2: dev_level is actually not a function, but a convenience macro argument which indirects to an actual specific logging function. So no, there is not supposed to be a pr_level.
Re: [PATCH v2] kunit: fix failure to build without printk
On Thu, 2019-08-29 at 11:01 -0600, shuah wrote:
> On 8/28/19 3:49 AM, Sergey Senozhatsky wrote:
> > On (08/28/19 02:31), Brendan Higgins wrote:
> > [..]
> > > Previously KUnit assumed that printk would always be present, which is
> > > not a valid assumption to make. Fix that by removing call to
> > > vprintk_emit, and calling printk directly.
> > >
> > > Reported-by: Randy Dunlap
> > > Link:
> > > https://lore.kernel.org/linux-kselftest/0352fae9-564f-4a97-715a-fabe01625...@kernel.org/T/#t
> > > Cc: Stephen Rothwell
> > > Cc: Sergey Senozhatsky
> > > Signed-off-by: Brendan Higgins
> >
> > [..]
> >
> > > -static void kunit_vprintk(const struct kunit *test,
> > > - const char *level,
> > > - struct va_format *vaf)
> > > -{
> > > - kunit_printk_emit(level[1] - '0', "\t# %s: %pV", test->name, vaf);
> > > -}
> >
> > This patch looks good to me. I like the removal of recursive
> > vsprintf() (%pV).
> >
> > -ss
> >
>
> Hi Sergey,
>
> What are the guidelines for using printk(). I recall some discussion
> about not using printk(). I am seeing the following from checkpatch
> script:
>
>
> WARNING: Prefer [subsystem eg: netdev]_level([subsystem]dev, ... then
> dev_level(dev, ... then pr_level(... to printk(KERN_LEVEL ...
> #105: FILE: include/kunit/test.h:343:
> + printk(KERN_LEVEL "\t# %s: " fmt, (test)->name, ##__VA_ARGS__)
>
>
> Is there supposed to be pr_level() - I can find dev_level()
>
> cc'ing Joe Perches for his feedback on this message recommending
> pr_level() which isn't in 5.3.
I don't care for pr_level or KERN_LEVEL in a printk.
I think this is somewhat overly complicated.
I think I'd write it like:
---
include/kunit/test.h | 11 -
kunit/test.c | 69
2 files changed, 26 insertions(+), 54 deletions(-)
diff --git a/include/kunit/test.h b/include/kunit/test.h
index 8b7eb03d4971..aa4abf0a22a5 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -339,9 +339,8 @@ static inline void *kunit_kzalloc(struct kunit *test,
size_t size, gfp_t gfp)
void kunit_cleanup(struct kunit *test);
-void __printf(3, 4) kunit_printk(const char *level,
-const struct kunit *test,
-const char *fmt, ...);
+__printf(2, 3)
+void kunit_printk(const struct kunit *test, const char *fmt, ...);
/**
* kunit_info() - Prints an INFO level message associated with @test.
@@ -353,7 +352,7 @@ void __printf(3, 4) kunit_printk(const char *level,
* Takes a variable number of format parameters just like printk().
*/
#define kunit_info(test, fmt, ...) \
- kunit_printk(KERN_INFO, test, fmt, ##__VA_ARGS__)
+ kunit_printk(test, KERN_INFO fmt, ##__VA_ARGS__)
/**
* kunit_warn() - Prints a WARN level message associated with @test.
@@ -364,7 +363,7 @@ void __printf(3, 4) kunit_printk(const char *level,
* Prints a warning level message.
*/
#define kunit_warn(test, fmt, ...) \
- kunit_printk(KERN_WARNING, test, fmt, ##__VA_ARGS__)
+ kunit_printk(test, KERN_WARNING fmt, ##__VA_ARGS__)
/**
* kunit_err() - Prints an ERROR level message associated with @test.
@@ -375,7 +374,7 @@ void __printf(3, 4) kunit_printk(const char *level,
* Prints an error level message.
*/
#define kunit_err(test, fmt, ...) \
- kunit_printk(KERN_ERR, test, fmt, ##__VA_ARGS__)
+ kunit_printk(test, KERN_ERR fmt, ##__VA_ARGS__)
/**
* KUNIT_SUCCEED() - A no-op expectation. Only exists for code clarity.
diff --git a/kunit/test.c b/kunit/test.c
index b2ca9b94c353..ddb9bffb5a5d 100644
--- a/kunit/test.c
+++ b/kunit/test.c
@@ -16,40 +16,6 @@ static void kunit_set_failure(struct kunit *test)
WRITE_ONCE(test->success, false);
}
-static int kunit_vprintk_emit(int level, const char *fmt, va_list args)
-{
- return vprintk_emit(0, level, NULL, 0, fmt, args);
-}
-
-static int kunit_printk_emit(int level, const char *fmt, ...)
-{
- va_list args;
- int ret;
-
- va_start(args, fmt);
- ret = kunit_vprintk_emit(level, fmt, args);
- va_end(args);
-
- return ret;
-}
-
-static void kunit_vprintk(const struct kunit *test,
- const char *level,
- struct va_format *vaf)
-{
- kunit_printk_emit(level[1] - '0', "\t# %s: %pV", test->name, vaf);
-}
-
-static void kunit_print_tap_version(void)
-{
- static bool kunit_has_printed_tap_version;
-
- if (!kunit_has_printed_tap_version) {
- kunit_printk_emit(LOGLEVEL_INFO, "TAP version 14\n");
- kunit_has_printed_tap_version = true;
- }
-}
-
static size_t kunit_test_cases_len(struct kunit_case *test_cases)
{
struct kunit_case *test_case;
@@ -63,11 +29,9 @@ static size_t kunit_test_cases_len(struct kunit_case
*test_cases)
static void kunit_print_subtest_start(struct kunit_suite *suite)
{
- kunit_print_tap_version();
-
Re: [PATCH V2 1/1] spi: bcm-qspi: Make BSPI default mode
On Thu, Aug 29, 2019 at 3:29 PM Mark Brown wrote: > > On Thu, Aug 29, 2019 at 09:46:13AM +0530, Rayagonda Kokatanur wrote: > > The spi-nor controller defaults to BSPI mode, hence switch back > > to its default mode after MSPI operations (write or erase) > > are completed. > > > > Changes from V1: > > - Address code review comment from Mark Brown. > > As covered in submitting-patches.rst inter-version changelogs should go > after the --- so they don't end up in git. Thank you, I fixed it and sent patch v3 for review.
[PATCH v1 18/18] MAINTAINERS: Add myself as maintainer of LOONGSON64
I'm going to help with LOONGSON64 maintainance as well. Signed-off-by: Jiaxun Yang --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 242970af939c..e14edf51ee15 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10758,6 +10758,7 @@ F: drivers/*/*/*loongson2* MIPS/LOONGSON64 ARCHITECTURE M: Huacai Chen +M: Jiaxun Yang L: linux-m...@vger.kernel.org S: Maintained F: arch/mips/boot/dts/loongson/ -- 2.22.0
[PATCH v1 17/18] MAINTAINERS: Add new pathes to LOONGSON64 ARCHITECTURE
Place newly submited irqchip drivers and devicetree support under MIPS/LOONGSON64 ARCHITECTURE. Signed-off-by: Jiaxun Yang --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d5d4fed632e6..242970af939c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10760,9 +10760,12 @@ MIPS/LOONGSON64 ARCHITECTURE M: Huacai Chen L: linux-m...@vger.kernel.org S: Maintained +F: arch/mips/boot/dts/loongson/ F: arch/mips/loongson64/ F: arch/mips/include/asm/mach-loongson64/ F: drivers/platform/mips/cpu_hwmon.c +F: drivers/irqchip/irq-ls3-* +F: Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-* F: drivers/*/*loongson3* F: drivers/*/*/*loongson3* -- 2.22.0
[PATCH v1 14/18] MIPS: Loongson64: Add generic dts
Add generic device dts for Loongson-3 devices. They seems identical but will be different later. Signed-off-by: Jiaxun Yang --- arch/mips/Kconfig | 4 +- arch/mips/boot/dts/Makefile | 1 + arch/mips/boot/dts/loongson/Makefile | 8 + arch/mips/boot/dts/loongson/ls3-2nodes.dtsi | 8 + arch/mips/boot/dts/loongson/ls3-4nodes.dtsi | 15 ++ arch/mips/boot/dts/loongson/ls3-cpus.dtsi | 150 ++ arch/mips/boot/dts/loongson/ls3-gs464.dtsi| 18 +++ arch/mips/boot/dts/loongson/ls3-gs464e.dtsi | 18 +++ .../boot/dts/loongson/ls3-rs780e-pch.dtsi | 35 arch/mips/boot/dts/loongson/ls3a-package.dtsi | 59 +++ .../boot/dts/loongson/ls3a1000_780e_1way.dts | 12 ++ .../boot/dts/loongson/ls3a1000_780e_2way.dts | 13 ++ .../boot/dts/loongson/ls3a1000_780e_4way.dts | 13 ++ .../boot/dts/loongson/ls3a2000_780e_1way.dts | 12 ++ .../boot/dts/loongson/ls3a2000_780e_2way.dts | 13 ++ .../boot/dts/loongson/ls3a2000_780e_4way.dts | 13 ++ .../boot/dts/loongson/ls3a3000_780e_1way.dts | 12 ++ .../boot/dts/loongson/ls3a3000_780e_2way.dts | 13 ++ .../boot/dts/loongson/ls3a3000_780e_4way.dts | 13 ++ arch/mips/boot/dts/loongson/ls3b-package.dtsi | 59 +++ .../mips/boot/dts/loongson/ls3b_780e_1way.dts | 13 ++ .../mips/boot/dts/loongson/ls3b_780e_2way.dts | 13 ++ 22 files changed, 514 insertions(+), 1 deletion(-) create mode 100644 arch/mips/boot/dts/loongson/Makefile create mode 100644 arch/mips/boot/dts/loongson/ls3-2nodes.dtsi create mode 100644 arch/mips/boot/dts/loongson/ls3-4nodes.dtsi create mode 100644 arch/mips/boot/dts/loongson/ls3-cpus.dtsi create mode 100644 arch/mips/boot/dts/loongson/ls3-gs464.dtsi create mode 100644 arch/mips/boot/dts/loongson/ls3-gs464e.dtsi create mode 100644 arch/mips/boot/dts/loongson/ls3-rs780e-pch.dtsi create mode 100644 arch/mips/boot/dts/loongson/ls3a-package.dtsi create mode 100644 arch/mips/boot/dts/loongson/ls3a1000_780e_1way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3a1000_780e_2way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3a1000_780e_4way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3a2000_780e_1way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3a2000_780e_2way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3a2000_780e_4way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3a3000_780e_1way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3a3000_780e_2way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3a3000_780e_4way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3b-package.dtsi create mode 100644 arch/mips/boot/dts/loongson/ls3b_780e_1way.dts create mode 100644 arch/mips/boot/dts/loongson/ls3b_780e_2way.dts diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 92a2ee773a40..1c27c3a4e036 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -485,6 +485,8 @@ config MACH_LOONGSON64 select SYS_SUPPORTS_LITTLE_ENDIAN select ZONE_DMA32 select SYS_SUPPORTS_ZBOOT + select USE_OF + select BUILTIN_DTB help This enables the support of Loongson-3A/3B/2-series-soc processors @@ -3074,7 +3076,7 @@ endchoice choice prompt "Kernel command line type" if !CMDLINE_OVERRIDE default MIPS_CMDLINE_FROM_DTB if USE_OF && !ATH79 && !MACH_INGENIC && \ -!MIPS_MALTA && \ +!MACH_LOONGSON64 && !MIPS_MALTA && \ !CAVIUM_OCTEON_SOC default MIPS_CMDLINE_FROM_BOOTLOADER diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile index 1e79cab8e269..d429a69bfe30 100644 --- a/arch/mips/boot/dts/Makefile +++ b/arch/mips/boot/dts/Makefile @@ -4,6 +4,7 @@ subdir-y+= cavium-octeon subdir-y += img subdir-y += ingenic subdir-y += lantiq +subdir-y += loongson subdir-y += mscc subdir-y += mti subdir-y += netlogic diff --git a/arch/mips/boot/dts/loongson/Makefile b/arch/mips/boot/dts/loongson/Makefile new file mode 100644 index ..25dca8a89d5d --- /dev/null +++ b/arch/mips/boot/dts/loongson/Makefile @@ -0,0 +1,8 @@ +# SPDX_License_Identifier: GPL_2.0 +dtb-$(CONFIG_MACH_LOONGSON64) += ls3a1000_780e_1way.dtb ls3a1000_780e_2way.dtb ls3a1000_780e_4way.dtb \ + ls3b_780e_1way.dtb ls3b_780e_2way.dtb \ + ls3a2000_780e_1way.dtb ls3a2000_780e_2way.dtb ls3a2000_780e_4way.dtb \ + ls3a3000_780e_1way.dtb ls3a3000_780e_2way.dtb ls3a3000_780e_4way.dtb + + +obj-$(CONFIG_BUILTIN_DTB) += $(addsuffix .o, $(dtb-y)) diff --git a/arch/mips/boot/dts/loongson/ls3-2nodes.dtsi b/arch/mips/boot/dts/loongson/ls3-2nodes.dtsi new file mode 100644 index
[PATCH] drm/amd/powerplay: Variable ps could be NULL when it get dereferenced
Inside function cz_get_performance_level(), pointer ps could be NULL via cast_const_PhwCzPowerState(). However, this pointer is dereferenced without any check, which is potentially unsafe. Signed-off-by: Yizhuo --- drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c index bc839ff0bdd0..d2628e7b612d 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c @@ -1799,6 +1799,9 @@ static int cz_get_performance_level(struct pp_hwmgr *hwmgr, const struct pp_hw_p data = (struct cz_hwmgr *)(hwmgr->backend); ps = cast_const_PhwCzPowerState(state); + if (!ps) + return -EINVAL; + level_index = index > ps->level - 1 ? ps->level - 1 : index; level->coreClock = ps->levels[level_index].engineClock; -- 2.17.1
[PATCH v1 15/18] MIPS: Loongson64: Load built-in dtbs
Load proper dtb according to firmware passed parameters and
CPU PRID.
Signed-off-by: Jiaxun Yang
---
.../asm/mach-loongson64/builtin_dtbs.h| 26 +++
.../include/asm/mach-loongson64/loongson64.h | 2 +
arch/mips/loongson64/env.c| 67 +++
arch/mips/loongson64/setup.c | 15 +
4 files changed, 110 insertions(+)
create mode 100644 arch/mips/include/asm/mach-loongson64/builtin_dtbs.h
diff --git a/arch/mips/include/asm/mach-loongson64/builtin_dtbs.h
b/arch/mips/include/asm/mach-loongson64/builtin_dtbs.h
new file mode 100644
index ..106287d54069
--- /dev/null
+++ b/arch/mips/include/asm/mach-loongson64/builtin_dtbs.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2019 Jiaxun Yang
+ *
+ * Built-in Generic dtbs for MACH_LOONGSON64
+ */
+
+#ifndef __ASM_MACH_LOONGSON64_BUILTIN_DTBS_H_
+#define __ASM_MACH_LOONGSON64_BUILTIN_DTBS_H_
+
+extern u32 __dtb_ls3a1000_780e_1way_begin[];
+extern u32 __dtb_ls3a1000_780e_2way_begin[];
+extern u32 __dtb_ls3a1000_780e_4way_begin[];
+
+extern u32 __dtb_ls3b_780e_1way_begin[];
+extern u32 __dtb_ls3b_780e_2way_begin[];
+
+extern u32 __dtb_ls3a2000_780e_1way_begin[];
+extern u32 __dtb_ls3a2000_780e_2way_begin[];
+extern u32 __dtb_ls3a2000_780e_4way_begin[];
+
+extern u32 __dtb_ls3a3000_780e_1way_begin[];
+extern u32 __dtb_ls3a3000_780e_2way_begin[];
+extern u32 __dtb_ls3a3000_780e_4way_begin[];
+
+#endif
diff --git a/arch/mips/include/asm/mach-loongson64/loongson64.h
b/arch/mips/include/asm/mach-loongson64/loongson64.h
index d877adb99d33..78daa3fb3fa7 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson64.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson64.h
@@ -45,4 +45,6 @@ extern u64 loongson_freqctrl[MAX_PACKAGES];
extern const struct plat_smp_ops loongson3_smp_ops;
extern void __init prom_init_lefi(void);
+extern void *loongson_fdt_blob;
+
#endif
diff --git a/arch/mips/loongson64/env.c b/arch/mips/loongson64/env.c
index 93658cfbf3a6..e46203c4a348 100644
--- a/arch/mips/loongson64/env.c
+++ b/arch/mips/loongson64/env.c
@@ -20,6 +20,7 @@
#include
#include
+#include
#include
u32 cpu_clock_freq;
@@ -126,6 +127,72 @@ void __init prom_init_lefi(void)
loongson_sysconf.cores_per_node - 1) /
loongson_sysconf.cores_per_node;
+ if ((read_c0_prid() & PRID_IMP_MASK) == PRID_IMP_LOONGSON_64) {
+ switch (read_c0_prid() & PRID_REV_MASK) {
+ case PRID_REV_LOONGSON3A_R1:
+ switch (loongson_sysconf.nr_nodes) {
+ case 4:
+ loongson_fdt_blob =
__dtb_ls3a1000_780e_4way_begin;
+ break;
+ case 2:
+ loongson_fdt_blob =
__dtb_ls3a1000_780e_2way_begin;
+ break;
+ case 1:
+ default:
+ loongson_fdt_blob =
__dtb_ls3a1000_780e_1way_begin;
+ break;
+ }
+ break;
+ case PRID_REV_LOONGSON3A_R2_0:
+ case PRID_REV_LOONGSON3A_R2_1:
+ switch (loongson_sysconf.nr_nodes) {
+ case 4:
+ loongson_fdt_blob =
__dtb_ls3a2000_780e_4way_begin;
+ break;
+ case 2:
+ loongson_fdt_blob =
__dtb_ls3a2000_780e_2way_begin;
+ break;
+ case 1:
+ default:
+ loongson_fdt_blob =
__dtb_ls3a2000_780e_1way_begin;
+ break;
+ }
+ break;
+ case PRID_REV_LOONGSON3A_R3_0:
+ case PRID_REV_LOONGSON3A_R3_1:
+ switch (loongson_sysconf.nr_nodes) {
+ case 4:
+ loongson_fdt_blob =
__dtb_ls3a3000_780e_4way_begin;
+ break;
+ case 2:
+ loongson_fdt_blob =
__dtb_ls3a3000_780e_2way_begin;
+ break;
+ case 1:
+ default:
+ loongson_fdt_blob =
__dtb_ls3a3000_780e_1way_begin;
+ break;
+ }
+ break;
+ case PRID_REV_LOONGSON3B_R1:
+ case PRID_REV_LOONGSON3B_R2:
+ switch (loongson_sysconf.nr_nodes) {
+ case 4:
+ loongson_fdt_blob = __dtb_ls3b_780e_2way_begin;
+ break;
+ case 2:
+ default:
+
[PATCH v1 16/18] MIPS: Loongson: Regenerate defconfigs
We've touched kconfig a lot in previous patches. Signed-off-by: Jiaxun Yang --- arch/mips/configs/fuloong2e_defconfig | 8 +++- arch/mips/configs/lemote2f_defconfig | 8 ++-- arch/mips/configs/loongson3_defconfig | 12 3 files changed, 9 insertions(+), 19 deletions(-) diff --git a/arch/mips/configs/fuloong2e_defconfig b/arch/mips/configs/fuloong2e_defconfig index 7a7af706e898..ae8a904ef812 100644 --- a/arch/mips/configs/fuloong2e_defconfig +++ b/arch/mips/configs/fuloong2e_defconfig @@ -15,8 +15,7 @@ CONFIG_EXPERT=y # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y CONFIG_PROFILING=y -CONFIG_MACH_LOONGSON64=y -CONFIG_PCI=y +CONFIG_MACH_LOONGSON2EF=y CONFIG_MIPS32_O32=y CONFIG_MIPS32_N32=y # CONFIG_SUSPEND is not set @@ -36,8 +35,6 @@ CONFIG_IP_MULTICAST=y CONFIG_IP_PNP=y CONFIG_IP_PNP_BOOTP=y CONFIG_NET_IPIP=m -# CONFIG_INET_XFRM_MODE_TRANSPORT is not set -# CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_DIAG is not set # CONFIG_IPV6 is not set CONFIG_NETFILTER=y @@ -83,6 +80,7 @@ CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_PHONET=m CONFIG_NET_9P=m +CONFIG_PCI=y CONFIG_FW_LOADER=m CONFIG_MTD=m CONFIG_MTD_BLOCK=m @@ -142,6 +140,7 @@ CONFIG_HW_RANDOM=y CONFIG_I2C=m CONFIG_I2C_CHARDEV=m CONFIG_I2C_VIAPRO=m +CONFIG_GPIOLIB=y # CONFIG_HWMON is not set CONFIG_FB=y CONFIG_FB_RADEON=y @@ -217,7 +216,6 @@ CONFIG_NLS_CODEPAGE_936=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_CRYPTO_AUTHENC=m -CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_CTS=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m diff --git a/arch/mips/configs/lemote2f_defconfig b/arch/mips/configs/lemote2f_defconfig index d44f1469cf64..0cbe1240314d 100644 --- a/arch/mips/configs/lemote2f_defconfig +++ b/arch/mips/configs/lemote2f_defconfig @@ -12,11 +12,10 @@ CONFIG_LOG_BUF_SHIFT=15 CONFIG_BLK_DEV_INITRD=y CONFIG_EXPERT=y CONFIG_PROFILING=y -CONFIG_MACH_LOONGSON64=y +CONFIG_MACH_LOONGSON2EF=y CONFIG_LEMOTE_MACH2F=y CONFIG_KEXEC=y # CONFIG_SECCOMP is not set -CONFIG_PCI=y CONFIG_MIPS32_O32=y CONFIG_MIPS32_N32=y CONFIG_HIBERNATION=y @@ -26,7 +25,6 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_BLK_DEV_INTEGRITY=y -CONFIG_IOSCHED_DEADLINE=m CONFIG_BINFMT_MISC=m CONFIG_NET=y CONFIG_PACKET=y @@ -44,9 +42,6 @@ CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_SYN_COOKIES=y -CONFIG_INET_XFRM_MODE_TRANSPORT=m -CONFIG_INET_XFRM_MODE_TUNNEL=m -CONFIG_INET_XFRM_MODE_BEET=m CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=y CONFIG_DEFAULT_BIC=y @@ -77,6 +72,7 @@ CONFIG_MAC80211=m CONFIG_MAC80211_LEDS=y CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=y +CONFIG_PCI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_RAM=y diff --git a/arch/mips/configs/loongson3_defconfig b/arch/mips/configs/loongson3_defconfig index 90ee0084d786..66fb44b4d845 100644 --- a/arch/mips/configs/loongson3_defconfig +++ b/arch/mips/configs/loongson3_defconfig @@ -24,15 +24,9 @@ CONFIG_BLK_DEV_INITRD=y CONFIG_SYSCTL_SYSCALL=y CONFIG_EMBEDDED=y CONFIG_MACH_LOONGSON64=y -CONFIG_LOONGSON_MACH3X=y CONFIG_SMP=y CONFIG_HZ_256=y CONFIG_KEXEC=y -CONFIG_PCIEPORTBUS=y -CONFIG_HOTPLUG_PCI_PCIE=y -# CONFIG_PCIEAER is not set -CONFIG_PCIEASPM_PERFORMANCE=y -CONFIG_HOTPLUG_PCI=y CONFIG_MIPS32_O32=y CONFIG_MIPS32_N32=y CONFIG_MODULES=y @@ -41,8 +35,6 @@ CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_PARTITION_ADVANCED=y -CONFIG_IOSCHED_DEADLINE=m -CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_BINFMT_MISC=m CONFIG_KSM=y CONFIG_NET=y @@ -97,6 +89,10 @@ CONFIG_CFG80211_WEXT=y CONFIG_MAC80211=m CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=y +CONFIG_PCIEPORTBUS=y +CONFIG_HOTPLUG_PCI_PCIE=y +CONFIG_PCIEASPM_PERFORMANCE=y +CONFIG_HOTPLUG_PCI=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=m -- 2.22.0
[PATCH v3] kbuild: change *FLAGS_.o to take the path relative to $(obj)
Kbuild provides per-file compiler flag addition/removal:
CFLAGS_.o
CFLAGS_REMOVE_.o
AFLAGS_.o
AFLAGS_REMOVE_.o
CPPFLAGS_.lds
HOSTCFLAGS_.o
HOSTCXXFLAGS_.o
The is the filename of the target with its directory and
suffix stripped.
This syntax comes into a trouble when two files with the same basename
appear in one Makefile, for example:
obj-y += foo.o
obj-y += dir/foo.o
CFLAGS_foo.o :=
Here, the applies to both foo.o and dir/foo.o
The real world problem is:
scripts/kconfig/util.c
scripts/kconfig/lxdialog/util.c
Both files are compiled into scripts/kconfig/mconf, but only the
latter should be given with the ncurses flags.
It is more sensible to use the relative path to the Makefile, like this:
obj-y += foo.o
CFLAGS_foo.o :=
obj-y += dir/foo.o
CFLAGS_dir/foo.o :=
At first, I attempted to replace $(basetarget) with $*. The $* variable
is replaced with the stem ('%') part in a pattern rule. This works with
most of cases, but does not for explicit rules.
For example, arch/ia64/lib/Makefile reuses rule_as_o_S in its own
explicit rules, so $* will be empty, resulting in ignoring the per-file
AFLAGS.
I introduced a new variable, target-stem, which can be used also from
explicit rules.
Signed-off-by: Masahiro Yamada
Acked-by: Marc Zyngier
---
Changes in v3:
- Fix breakage of ia64 lib
Changes in v2:
- Fix build errors for gpu drivers
arch/arm/kvm/Makefile | 5 +++--
arch/x86/entry/vdso/Makefile | 3 ++-
drivers/gpu/drm/amd/display/dc/calcs/Makefile | 6 ++---
drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dml/Makefile | 17 ++
drivers/gpu/drm/amd/display/dc/dsc/Makefile | 7 +++---
drivers/gpu/drm/i915/Makefile | 2 +-
scripts/Makefile.host | 22 +--
scripts/Makefile.lib | 13 ++-
scripts/kconfig/Makefile | 8 +++
10 files changed, 43 insertions(+), 42 deletions(-)
diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
index 531e59f5be9c..b76b75bd9e00 100644
--- a/arch/arm/kvm/Makefile
+++ b/arch/arm/kvm/Makefile
@@ -8,13 +8,14 @@ ifeq ($(plus_virt),+virt)
plus_virt_def := -DREQUIRES_VIRT=1
endif
+KVM := ../../../virt/kvm
+
ccflags-y += -I $(srctree)/$(src) -I $(srctree)/virt/kvm/arm/vgic
-CFLAGS_arm.o := $(plus_virt_def)
+CFLAGS_$(KVM)/arm/arm.o := $(plus_virt_def)
AFLAGS_init.o := -Wa,-march=armv7-a$(plus_virt)
AFLAGS_interrupts.o := -Wa,-march=armv7-a$(plus_virt)
-KVM := ../../../virt/kvm
kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o
$(KVM)/vfio.o
obj-$(CONFIG_KVM_ARM_HOST) += hyp/
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 8df549138193..0f2154106d01 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -89,6 +89,7 @@ $(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS)
$(RETPOLINE_CFLAGS
#
CFLAGS_REMOVE_vdso-note.o = -pg
CFLAGS_REMOVE_vclock_gettime.o = -pg
+CFLAGS_REMOVE_vdso32/vclock_gettime.o = -pg
CFLAGS_REMOVE_vgetcpu.o = -pg
CFLAGS_REMOVE_vvar.o = -pg
@@ -128,7 +129,7 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE
$(obj)/vdsox32.so.dbg: $(obj)/vdsox32.lds $(vobjx32s) FORCE
$(call if_changed,vdso_and_check)
-CPPFLAGS_vdso32.lds = $(CPPFLAGS_vdso.lds)
+CPPFLAGS_vdso32/vdso32.lds = $(CPPFLAGS_vdso.lds)
VDSO_LDFLAGS_vdso32.lds = -m elf_i386 -soname linux-gate.so.1
targets += vdso32/vdso32.lds
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
index 95f332ee3e7e..d930df63772c 100644
--- a/drivers/gpu/drm/amd/display/dc/calcs/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/calcs/Makefile
@@ -32,9 +32,9 @@ endif
calcs_ccflags := -mhard-float -msse $(cc_stack_align)
-CFLAGS_dcn_calcs.o := $(calcs_ccflags)
-CFLAGS_dcn_calc_auto.o := $(calcs_ccflags)
-CFLAGS_dcn_calc_math.o := $(calcs_ccflags) -Wno-tautological-compare
+CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calcs.o := $(calcs_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_auto.o := $(calcs_ccflags)
+CFLAGS_$(AMDDALPATH)/dc/calcs/dcn_calc_math.o := $(calcs_ccflags)
-Wno-tautological-compare
BW_CALCS = dce_calcs.o bw_fixed.o custom_float.o
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
index e9721a906592..83635ad9124e 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/Makefile
@@ -16,7 +16,7 @@ else ifneq ($(call cc-option, -mstack-alignment=16),)
cc_stack_align := -mstack-alignment=16
endif
-CFLAGS_dcn20_resource.o := -mhard-float -msse $(cc_stack_align)
+CFLAGS_$(AMDDALPATH)/dc/dcn20/dcn20_resource.o := -mhard-float -msse
$(cc_stack_align)
AMD_DAL_DCN20 = $(addprefix $(AMDDALPATH)/dc/dcn20/,$(DCN20))
diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile
[PATCH v1 13/18] dt-bindings: Document loongson vendor-prefix
Loongson is a MIPS-compatible processor vendor. Signed-off-by: Jiaxun Yang --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6992ffab..855d5b7a6660 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -529,6 +529,8 @@ patternProperties: description: Linear Technology Corporation "^logicpd,.*": description: Logic PD, Inc. + "^loongson,.*": +description: Loongson Technology Corporation Limited "^lsi,.*": description: LSI Corp. (LSI Logic) "^lwn,.*": -- 2.22.0
[PATCH v1 12/18] dt-bindings: mips: Add loongson cpus & boards
Prepare for later dts. Signed-off-by: Jiaxun Yang --- .../bindings/mips/loongson/cpus.yaml | 38 +++ .../bindings/mips/loongson/devices.yaml | 64 +++ 2 files changed, 102 insertions(+) create mode 100644 Documentation/devicetree/bindings/mips/loongson/cpus.yaml create mode 100644 Documentation/devicetree/bindings/mips/loongson/devices.yaml diff --git a/Documentation/devicetree/bindings/mips/loongson/cpus.yaml b/Documentation/devicetree/bindings/mips/loongson/cpus.yaml new file mode 100644 index ..dc6dd5114d5e --- /dev/null +++ b/Documentation/devicetree/bindings/mips/loongson/cpus.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mips/loongson/cpus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson CPUs bindings + +maintainers: + - Jiaxun Yang + +description: |+ + The device tree allows to describe the layout of CPUs in a system through + the "cpus" node, which in turn contains a number of subnodes (ie "cpu") + defining properties for every cpu. + + Bindings for CPU nodes follow the Devicetree Specification, available from: + + https://www.devicetree.org/specifications/ + +properties: + reg: +maxItems: 1 +description: | + Physical ID of a CPU, Can be read from CP0 EBase.CPUNum. + + compatible: +enum: + - loongson,gs464 + - loongson,gs464e + - loongson,gs264 + - loongson,gs464v + +required: + - device_type + - reg + - compatible +... diff --git a/Documentation/devicetree/bindings/mips/loongson/devices.yaml b/Documentation/devicetree/bindings/mips/loongson/devices.yaml new file mode 100644 index ..aa6c42013d2c --- /dev/null +++ b/Documentation/devicetree/bindings/mips/loongson/devices.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mips/loongson/devices.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson based Platforms Device Tree Bindings + +maintainers: + - Jiaxun Yang +description: | + Devices with a Loongson CPU shall have the following properties. + +properties: + $nodename: +const: '/' + compatible: +oneOf: + + - description: Loongson 3A1000 + RS780E 1Way +items: + - const: loongson,ls3a1000-780e-1way + + - description: Loongson 3A1000 + RS780E 2Way +items: + - const: loongson,ls3a1000-780e-2way + + - description: Loongson 3A1000 + RS780E 4Way +items: + - const: loongson,ls3a1000-780e-4way + + - description: Loongson 3B1000/1500 + RS780E 1Way +items: + - const: loongson,ls3b-780e-1way + + - description: Loongson 3B1000/1500 + RS780E 2Way +items: + - const: loongson,ls3b-780e-2way + + - description: Loongson 3A2000 + RS780E 1Way +items: + - const: loongson,ls3a2000-780e-1way + + - description: Loongson 3A2000 + RS780E 2Way +items: + - const: loongson,ls3a2000-780e-2way + + - description: Loongson 3A2000 + RS780E 4Way +items: + - const: loongson,ls3a2000-780e-4way + + - description: Loongson 3A3000 + RS780E 1Way +items: + - const: loongson,ls3a3000-780e-1way + + - description: Loongson 3A3000 + RS780E 2Way +items: + - const: loongson,ls3a3000-780e-2way + + - description: Loongson 3A3000 + RS780E 4Way +items: + - const: loongson,ls3a3000-780e-4way + +... -- 2.22.0
[PATCH v1 11/18] MIPS: Loongson64: Drop legacy IRQ code
We've made generic irqchip drivers for Loongson-3 platform, it's time
to say goodbye to these legacy code.
Signed-off-by: Jiaxun Yang
---
arch/mips/include/asm/mach-loongson64/irq.h | 1 -
arch/mips/loongson64/irq.c | 167 +---
arch/mips/loongson64/smp.c | 26 ++-
3 files changed, 11 insertions(+), 183 deletions(-)
diff --git a/arch/mips/include/asm/mach-loongson64/irq.h
b/arch/mips/include/asm/mach-loongson64/irq.h
index baed43285163..e57a21fc581c 100644
--- a/arch/mips/include/asm/mach-loongson64/irq.h
+++ b/arch/mips/include/asm/mach-loongson64/irq.h
@@ -35,7 +35,6 @@
#define LOONGSON_INT_COREx_INTy(x, y) (1<<(x) | 1<<(y+4)) /* route to int
y of core x */
extern void fixup_irqs(void);
-extern void loongson3_ipi_interrupt(void);
#include_next
#endif /* __ASM_MACH_LOONGSON64_IRQ_H_ */
diff --git a/arch/mips/loongson64/irq.c b/arch/mips/loongson64/irq.c
index 4d7b80a0ffb9..78cd824cc84e 100644
--- a/arch/mips/loongson64/irq.c
+++ b/arch/mips/loongson64/irq.c
@@ -3,180 +3,17 @@
#include
#include
#include
+#include
#include
-#include
#include
#include "smp.h"
-/* ICU Configuration Regs - r/w */
-
-#define LOONGSON_INTEDGE LOONGSON_REG(LOONGSON_REGBASE + 0x24)
-#define LOONGSON_INTSTEER LOONGSON_REG(LOONGSON_REGBASE + 0x28)
-#define LOONGSON_INTPOLLOONGSON_REG(LOONGSON_REGBASE +
0x2c)
-
-/* ICU Enable Regs - IntEn & IntISR are r/o. */
-
-#define LOONGSON_INTENSET LOONGSON_REG(LOONGSON_REGBASE + 0x30)
-#define LOONGSON_INTENCLR LOONGSON_REG(LOONGSON_REGBASE + 0x34)
-#define LOONGSON_INTEN LOONGSON_REG(LOONGSON_REGBASE + 0x38)
-#define LOONGSON_INTISRLOONGSON_REG(LOONGSON_REGBASE +
0x3c)
-
-extern void loongson3_send_irq_by_ipi(int cpu, int irqs);
-
-unsigned int irq_cpu[16] = {[0 ... 15] = -1};
-unsigned int ht_irq[] = {0, 1, 3, 4, 5, 6, 7, 8, 12, 14, 15};
-unsigned int local_irq = 1<<0 | 1<<1 | 1<<2 | 1<<7 | 1<<8 | 1<<12;
-
-int plat_set_irq_affinity(struct irq_data *d, const struct cpumask *affinity,
- bool force)
-{
- unsigned int cpu;
- struct cpumask new_affinity;
-
- /* I/O devices are connected on package-0 */
- cpumask_copy(_affinity, affinity);
- for_each_cpu(cpu, affinity)
- if (cpu_data[cpu].package > 0)
- cpumask_clear_cpu(cpu, _affinity);
-
- if (cpumask_empty(_affinity))
- return -EINVAL;
-
- cpumask_copy(d->common->affinity, _affinity);
-
- return IRQ_SET_MASK_OK_NOCOPY;
-}
-
-static void ht_irqdispatch(void)
-{
- unsigned int i, irq;
- struct irq_data *irqd;
- struct cpumask affinity;
-
- irq = LOONGSON_HT1_INT_VECTOR(0);
- LOONGSON_HT1_INT_VECTOR(0) = irq; /* Acknowledge the IRQs */
-
- for (i = 0; i < ARRAY_SIZE(ht_irq); i++) {
- if (!(irq & (0x1 << ht_irq[i])))
- continue;
-
- /* handled by local core */
- if (local_irq & (0x1 << ht_irq[i])) {
- do_IRQ(ht_irq[i]);
- continue;
- }
-
- irqd = irq_get_irq_data(ht_irq[i]);
- cpumask_and(, irqd->common->affinity, cpu_active_mask);
- if (cpumask_empty()) {
- do_IRQ(ht_irq[i]);
- continue;
- }
-
- irq_cpu[ht_irq[i]] = cpumask_next(irq_cpu[ht_irq[i]],
);
- if (irq_cpu[ht_irq[i]] >= nr_cpu_ids)
- irq_cpu[ht_irq[i]] = cpumask_first();
-
- if (irq_cpu[ht_irq[i]] == 0) {
- do_IRQ(ht_irq[i]);
- continue;
- }
-
- /* balanced by other cores */
- loongson3_send_irq_by_ipi(irq_cpu[ht_irq[i]], (0x1 <<
ht_irq[i]));
- }
-}
-
-#define UNUSED_IPS (CAUSEF_IP5 | CAUSEF_IP4 | CAUSEF_IP1 | CAUSEF_IP0)
-
-asmlinkage void plat_irq_dispatch(void)
-{
- unsigned int pending;
-
- pending = read_c0_cause() & read_c0_status() & ST0_IM;
-
- if (pending & CAUSEF_IP7)
- do_IRQ(LOONGSON_TIMER_IRQ);
-#if defined(CONFIG_SMP)
- if (pending & CAUSEF_IP6)
- loongson3_ipi_interrupt();
-#endif
- if (pending & CAUSEF_IP3)
- ht_irqdispatch();
- if (pending & CAUSEF_IP2)
- do_IRQ(LOONGSON_UART_IRQ);
- if (pending & UNUSED_IPS) {
- pr_err("%s : spurious interrupt\n", __func__);
- spurious_interrupt();
- }
-}
-
-static inline void mask_loongson_irq(struct irq_data *d) { }
-static inline void unmask_loongson_irq(struct irq_data *d) { }
-
- /* For MIPS IRQs which shared by all cores */
-static struct irq_chip loongson_irq_chip = {
- .name = "Loongson",
- .irq_ack= mask_loongson_irq,
-
[PATCH v1 10/18] irqchip: mips-cpu: Convert to simple domain
The old code is using legacy domain to setup irq_domain for CPU interrupts which requires irq_desc being preallocated. However, when MIPS_CPU_IRQ_BASE >= 16, irq_desc for CPU IRQs may end up unallocated and lead to incorrect behavior. Thus we convert the legacy domain to simple domain which can allocate irq_desc during initialization. Signed-off-by: Jiaxun Yang --- drivers/irqchip/irq-mips-cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-mips-cpu.c b/drivers/irqchip/irq-mips-cpu.c index 95d4fd8f7a96..c3cf7fa76424 100644 --- a/drivers/irqchip/irq-mips-cpu.c +++ b/drivers/irqchip/irq-mips-cpu.c @@ -251,7 +251,7 @@ static void __init __mips_cpu_irq_init(struct device_node *of_node) clear_c0_status(ST0_IM); clear_c0_cause(CAUSEF_IP); - irq_domain = irq_domain_add_legacy(of_node, 8, MIPS_CPU_IRQ_BASE, 0, + irq_domain = irq_domain_add_simple(of_node, 8, MIPS_CPU_IRQ_BASE, _cpu_intc_irq_domain_ops, NULL); if (!irq_domain) -- 2.22.0
[PATCH v1 09/18] irqchip: i8259: Add plat-poll support
For some platforms (e.g. Loongson-3), platfrom interrupt controller
supports polling interrupt vector from i8259 automaticly and generating
sepreated interrupt.
Thus we add plat-poll OF property for these platforms and setup sepreated
chained interrupt handler.
Signed-off-by: Jiaxun Yang
---
drivers/irqchip/irq-i8259.c | 47 -
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-i8259.c b/drivers/irqchip/irq-i8259.c
index d000870d9b6b..e7a9895f3b2d 100644
--- a/drivers/irqchip/irq-i8259.c
+++ b/drivers/irqchip/irq-i8259.c
@@ -40,6 +40,12 @@ static void mask_and_ack_8259A(struct irq_data *d);
static void init_8259A(int auto_eoi);
static int (*i8259_poll)(void) = i8259_irq;
+struct plat_poll_priv {
+ struct irq_domain *domain;
+ int hwirq;
+};
+static struct plat_poll_priv plat_poll_priv[16];
+
static struct irq_chip i8259A_chip = {
.name = "XT-PIC",
.irq_mask = disable_8259A_irq,
@@ -346,22 +352,51 @@ static void i8259_irq_dispatch(struct irq_desc *desc)
generic_handle_irq(irq);
}
+static void plat_poll_irq_dispatch(struct irq_desc *desc)
+{
+ struct plat_poll_priv *priv = irq_desc_get_handler_data(desc);
+ unsigned int irq;
+
+ irq = irq_linear_revmap(priv->domain, priv->hwirq);
+ generic_handle_irq(irq);
+}
+
int __init i8259_of_init(struct device_node *node, struct device_node *parent)
{
struct irq_domain *domain;
- unsigned int parent_irq;
domain = __init_i8259_irqs(node);
- parent_irq = irq_of_parse_and_map(node, 0);
- if (!parent_irq) {
- pr_err("Failed to map i8259 parent IRQ\n");
- irq_domain_remove(domain);
- return -ENODEV;
+ if (of_find_property(node, "plat-poll", NULL)) {
+ int i;
+
+ for (i = 0; i < 16; i++) {
+ int parent_irq = irq_of_parse_and_map(node, i);
+
+ if (!parent_irq) {
+ pr_err("Failed to map %d plat-poll i8259 parent
IRQ\n", i);
+ irq_domain_remove(domain);
+ return -ENODEV;
+ }
+ plat_poll_priv[i].domain = domain;
+ plat_poll_priv[i].hwirq = i;
+ irq_set_chained_handler_and_data(parent_irq,
+ plat_poll_irq_dispatch,
+ _poll_priv[i]);
+ }
+ } else {
+ unsigned int parent_irq;
+
+ parent_irq = irq_of_parse_and_map(node, 0);
+ if (!parent_irq) {
+ pr_err("Failed to map i8259 parent IRQ\n");
+ irq_domain_remove(domain);
+ return -ENODEV;
}
irq_set_chained_handler_and_data(parent_irq, i8259_irq_dispatch,
domain);
+ }
return 0;
}
IRQCHIP_DECLARE(i8259, "intel,i8259", i8259_of_init);
--
2.22.0
[PATCH V3 1/1] spi: bcm-qspi: Make BSPI default mode
The spi-nor controller defaults to BSPI mode, hence switch back to its default mode after MSPI operations (write or erase) are completed. Signed-off-by: Rayagonda Kokatanur Reviewed-by: Mark Brown Reviewed-by: Kamal Dasu --- changes from V2: - Address code review comment from Mark Brown about changelog. Changes from V1: - Address code review comment from Mark Brown. drivers/spi/spi-bcm-qspi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/spi-bcm-qspi.c b/drivers/spi/spi-bcm-qspi.c index 902bdbf..46a811a 100644 --- a/drivers/spi/spi-bcm-qspi.c +++ b/drivers/spi/spi-bcm-qspi.c @@ -897,6 +897,7 @@ static int bcm_qspi_transfer_one(struct spi_master *master, read_from_hw(qspi, slots); } + bcm_qspi_enable_bspi(qspi); return 0; } -- 1.9.1
[PATCH v1 08/18] dt-bindings: interrupt-controller: Add Loongson-3 HTINTC
Document Loongson-3 HyperTransport Interrupt controller.
Signed-off-by: Jiaxun Yang
---
.../loongson,ls3-htintc.yaml | 55 +++
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-htintc.yaml
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-htintc.yaml
b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-htintc.yaml
new file mode 100644
index ..51fee46ab060
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-htintc.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
"http://devicetree.org/schemas/interrupt-controller/loongson,ls3-htintc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Loongson-3 HyperTransport Interrupt Controller
+
+maintainers:
+ - Jiaxun Yang
+
+description: |
+ This interrupt controller is found in the Loongson-3 family of chips to
transfer
+ interrupts from PCH connected on HyperTransport bus.
+
+properties:
+ compatible:
+const: loongson,ls3-htintc
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 4
+description: |
+ Four parent interrupts that recieve chained interrupt randomly.
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+examples:
+ - |
+#include
+htintc: interrupt-controller@fb80 {
+ compatible = "loongson,ls3-htintc";
+ reg = <0xfb80 0x100>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ interrupt-parent = <>;
+ interrupts = <24 IRQ_TYPE_LEVEL_HIGH>,
+<25 IRQ_TYPE_LEVEL_HIGH>,
+<26 IRQ_TYPE_LEVEL_HIGH>,
+<27 IRQ_TYPE_LEVEL_HIGH>;
+};
+...
--
2.22.0
[PATCH v1 06/18] dt-bindings: interrupt-controller: Add Loongson-3 IOINTC
Document Loongson-3 I/O Interrupt controller.
Signed-off-by: Jiaxun Yang
---
.../loongson,ls3-iointc.yaml | 75 +++
1 file changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
new file mode 100644
index ..9aee10abd5cd
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
"http://devicetree.org/schemas/interrupt-controller/loongson,ls3-iointc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Loongson-3 I/O Interrupt Controller
+
+maintainers:
+ - Jiaxun Yang
+
+description: |
+ This interrupt controller is found in the Loongson-3 family of chips as the
primary
+ package interrupt source which can route interrupt to interrupt line of
cores.
+
+properties:
+ compatible:
+const: loongson,ls3-iointc
+
+ reg:
+maxItems: 1
+
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+description: |
+ Specifies the number of cells needed to encode an interrupt source.
+ Must be 2 or 4.
+ If the system requires describing interrupt line & core mapping, than
+ it must be 4.
+
+ The 1st cell is the hardware interrupt number.
+
+ The 2nd cell is the flags, encoded as follows:
+bits[3:0] trigger type and level flags.
+ 1 = low-to-high edge triggered
+ 2 = high-to-low edge triggered
+ 4 = active high level-sensitive
+ 8 = active low level-sensitive.
+
+ The 3rd is the parent interrupt line that interrupt would map to.
+ As the CPU preserved 4 interrupt lines for I/O, in theory any of the
iointc
+ interrupt can be chained to any interrupt lines on a core. But currently
+ we can only map all the interrupt to a single parent, so this cell must
be
+ set uniformly for all the child interrupts corresponding to the parent
+ interrupt.
+
+ The 4th is the parent core that interrupt would map to. The interrupt
+ contoller can map any of the interrupt to the specified core on a
package.
+ This cell determined the core. It must be the bootcore.
+
+ If the 3rd, 4th cell is not set, it will default to the 0# interrupt line
+ and bootcore.
+
+enum: [ 2, 4 ]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+
+examples:
+ - |
+iointc: interrupt-controller@3ff01400 {
+compatible = "loongson,ls3-io-intc";
+reg = <0x3ff01400 0x60>;
+interrupts = <2>;
+interrupt-controller;
+#interrupt-cells = <4>;
+};
+...
--
2.22.0
[PATCH v1 07/18] irqchip: Add driver for Loongson-3 HyperTransport interrupt controller
This controller appeared on Loongson-3 family of chips to receive interrupts
from PCH chip.
Signed-off-by: Jiaxun Yang
---
drivers/irqchip/Kconfig | 8 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ls3-htintc.c | 147 +++
3 files changed, 156 insertions(+)
create mode 100644 drivers/irqchip/irq-ls3-htintc.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 8d9eac5fd4a7..b3ce0f3e43ae 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -480,6 +480,14 @@ config LS3_IOINTC
help
Support for the Loongson-3 I/O Interrupt Controller.
+config LS3_HTINTC
+ bool "Loongson3 HyperTransport Interrupt Controller"
+ depends on MACH_LOONGSON64
+ default y
+ select IRQ_DOMAIN
+ select GENERIC_IRQ_CHIP
+ help
+ Support for the Loongson-3 HyperTransport Interrupt Controller.
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 49ecb8d38138..0fda94c319e9 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -103,3 +103,4 @@ obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
obj-$(CONFIG_TI_SCI_INTA_IRQCHIP) += irq-ti-sci-inta.o
obj-$(CONFIG_LS3_IOINTC) += irq-ls3-iointc.o
+obj-$(CONFIG_LS3_HTINTC) += irq-ls3-htintc.o
diff --git a/drivers/irqchip/irq-ls3-htintc.c b/drivers/irqchip/irq-ls3-htintc.c
new file mode 100644
index ..d5013606faa8
--- /dev/null
+++ b/drivers/irqchip/irq-ls3-htintc.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019, Jiaxun Yang
+ * Loongson-3 HyperTransport IRQ support
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define HTINTC_NUM_GC 4
+#define HTINTC_GC_SIZE 0x4
+#define HTINTC_NUM_HANDLER 4
+#define HTINTC_HANDLER_SIZE 0x8
+#define HTINTC_HANDLER_IRQ 64
+
+#define HTINTC_VECTOR_OFFSET 0x0
+#define HTINTC_EN_OFFSET 0x20
+
+struct htintc_handler_priv {
+ struct irq_domain *domain;
+ void __iomem*handler_base;
+};
+
+static void htintc_chained_handle_irq(struct irq_desc *desc)
+{
+ struct htintc_handler_priv *priv = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ int i;
+ bool handled = false;
+
+ chained_irq_enter(chip, desc);
+
+ for (i = 0; i < HTINTC_NUM_GC; i++) {
+ uint32_t irqs = readl(priv->handler_base + HTINTC_GC_SIZE * i);
+
+ while (irqs) {
+ int bit = __ffs(irqs);
+
+ generic_handle_irq(irq_find_mapping(priv->domain, bit +
32 * i));
+ irqs &= ~BIT(bit);
+ handled = true;
+ }
+ }
+
+ if (!handled)
+ spurious_interrupt();
+
+ chained_irq_exit(chip, desc);
+}
+
+int __init ls3_htintc_of_init(struct device_node *node,
+ struct device_node *parent)
+{
+ struct irq_chip_generic *gc;
+ struct irq_chip_type *ct;
+ struct htintc_handler_priv *priv;
+ struct irq_domain *domain;
+ void __iomem *base;
+ int parent_irq[HTINTC_NUM_HANDLER], err = 0;
+ int i;
+
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ base = of_iomap(node, 0);
+ if (!base) {
+ err = -ENODEV;
+ goto out_free_priv;
+ }
+
+ for (i = 0; i < HTINTC_NUM_HANDLER; i++) {
+ parent_irq[i] = irq_of_parse_and_map(node, i);
+ if (!parent_irq[i]) {
+ pr_err("ls3-htintc: unable to get parent irq %d\n", i);
+ err = -ENODEV;
+ goto out_iounmap;
+ }
+ }
+ /* Set up an IRQ domain */
+ domain = irq_domain_add_linear(node, 32 * HTINTC_NUM_GC,
+
_generic_chip_ops, NULL);
+ if (!domain) {
+ pr_err("ls3-htintc: cannot add IRQ domain\n");
+ err = -ENOMEM;
+ goto out_iounmap;
+ }
+
+ for (i = 0; i < HTINTC_NUM_HANDLER; i++) {
+ /* Mask all interrupts */
+ writeq(0x0, base + HTINTC_EN_OFFSET + HTINTC_HANDLER_SIZE * i);
+ }
+
+ err = irq_alloc_domain_generic_chips(domain, 32, 1,
+
node->full_name,
+
handle_edge_irq,
+
IRQ_NOPROBE, 0,
+
Re: [ext4] [confidence: ] 2f7f60cf9f: WARNING:at_lib/list_debug.c:#__list_add_valid
On Fri, Aug 30, 2019 at 11:33:22AM +0800, Shaokun Zhang wrote:
> Hi Oliver,
>
> On 2019/8/30 11:11, kernel test robot wrote:
> > FYI, we noticed the following commit (built with gcc-7):
> >
> > commit: 2f7f60cf9fbcd80200edee8c29b9b35681c63c3e ("[PATCH] ext4: change the
> > type of ext4 cache stats to percpu_counter to improve performance")
>
> Thanks for the report.
>
> This patch has been dropped and the updated patch has been sent to community.
> https://lkml.org/lkml/2019/8/28/286
Thanks for information!
>
> Thanks,
> Shaokun
>
> > url:
> > https://github.com/0day-ci/linux/commits/Shaokun-Zhang/ext4-change-the-type-of-ext4-cache-stats-to-percpu_counter-to-improve-performance/20190825-123505
> >
> >
> > in testcase: ltp
> > with following parameters:
> >
> > test: quickhit
> >
> > test-description: The LTP testsuite contains a collection of tools for
> > testing the Linux kernel and related features.
> > test-url: http://linux-test-project.github.io/
> >
> >
> > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m
> > 8G
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire
> > log/backtrace):
> >
> >
> > +-+++
> > | | e67095fd2f |
> > 2f7f60cf9f |
> > +-+++
> > | boot_successes | 25 | 12
> > |
> > | boot_failures | 0 | 17
> > |
> > | WARNING:at_lib/list_debug.c:#__list_add_valid | 0 | 17
> > |
> > | RIP:__list_add_valid| 0 | 17
> > |
> > | WARNING:at_lib/list_debug.c:#__list_del_entry_valid | 0 | 3
> > |
> > | RIP:__list_del_entry_valid | 0 | 3
> > |
> > +-+++
> >
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot
> >
> >
> > [ 62.458944] WARNING: CPU: 1 PID: 2533 at lib/list_debug.c:25
> > __list_add_valid+0x36/0x70
> > [ 62.460445] Modules linked in: fuse vfat fat btrfs xor zstd_decompress
> > zstd_compress raid6_pq xfs libcrc32c ext4 mbcache jbd2 loop intel_rapl_msr
> > intel_rapl_common crct10dif_pclmul crc32_pclmul crc32c_intel
> > ghash_clmulni_intel sr_mod bochs_drm cdrom drm_vram_helper sg ttm ppdev
> > drm_kms_helper ata_generic pata_acpi syscopyarea sysfillrect sysimgblt
> > snd_pcm fb_sys_fops drm snd_timer snd aesni_intel crypto_simd cryptd
> > glue_helper soundcore pcspkr joydev serio_raw ata_piix libata i2c_piix4
> > floppy parport_pc parport ip_tables
> > [ 62.468134] CPU: 1 PID: 2533 Comm: fsync01 Not tainted
> > 5.3.0-rc5-00283-g2f7f60cf9fbcd #1
> > [ 62.469707] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > 1.10.2-1 04/01/2014
> > [ 62.471293] RIP: 0010:__list_add_valid+0x36/0x70
> > [ 62.472332] Code: 48 8b 10 4c 39 c2 75 27 48 39 f8 74 39 48 39 fa 74 34
> > b8 01 00 00 00 c3 48 89 d1 48 c7 c7 28 ce d2 82 48 89 c2 e8 ba 47 c2 ff
> > <0f> 0b 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 a0 ce d2 82 e8 a3 47 c2
> > [ 62.475779] RSP: 0018:b815c0497cc0 EFLAGS: 00010082
> > [ 62.477028] RAX: RBX: 9ab02e61c418 RCX:
> > 0006
> > [ 62.478540] RDX: 0007 RSI: 0086 RDI:
> > 9ab0bfd17770
> > [ 62.480096] RBP: 9ab02e61c428 R08: 0510 R09:
> > 00aa
> > [ 62.481707] R10: 0007 R11: 9ab097f6b8b0 R12:
> > 9ab02e61c450
> > [ 62.483231] R13: 8314ce80 R14: 0202 R15:
> >
> > [ 62.484861] FS: 7f8b236e0500() GS:9ab0bfd0()
> > knlGS:
> > [ 62.486641] CS: 0010 DS: ES: CR0: 80050033
> > [ 62.488103] CR2: 55b3435d0a60 CR3: 00019b8d2000 CR4:
> > 000406e0
> > [ 62.489798] DR0: DR1: DR2:
> >
> > [ 62.491343] DR3: DR6: fffe0ff0 DR7:
> > 0400
> > [ 62.492925] Call Trace:
> > [ 62.494524] __percpu_counter_init+0x64/0xa0
> > [ 62.495780] ext4_es_register_shrinker+0x53/0x130 [ext4]
> > [ 62.497235] ext4_fill_super+0x1cd4/0x3ad0 [ext4]
> > [ 62.498521] ? ext4_calculate_overhead+0x4a0/0x4a0 [ext4]
> > [ 62.499946] mount_bdev+0x173/0x1b0
> > [ 62.501120] legacy_get_tree+0x27/0x40
> > [ 62.502315] vfs_get_tree+0x25/0xf0
> > [ 62.503421] do_mount+0x691/0x9c0
> > [ 62.504516] ? memdup_user+0x4b/0x70
> > [ 62.505793] ksys_mount+0x80/0xd0
> > [ 62.506858] __x64_sys_mount+0x21/0x30
> > [ 62.507979] do_syscall_64+0x5b/0x1f0
> > [ 62.509194] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [
[PATCH v1 05/18] irqchip: Add driver for Loongson-3 I/O interrupt controller
This controller appeared on Loongson-3 family of chips as the primary
package interrupt source.
Signed-off-by: Jiaxun Yang
---
drivers/irqchip/Kconfig | 9 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-ls3-iointc.c | 275 +++
3 files changed, 285 insertions(+)
create mode 100644 drivers/irqchip/irq-ls3-iointc.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 80e10f4e213a..8d9eac5fd4a7 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -471,6 +471,15 @@ config TI_SCI_INTA_IRQCHIP
If you wish to use interrupt aggregator irq resources managed by the
TI System Controller, say Y here. Otherwise, say N.
+config LS3_IOINTC
+ bool "Loongson3 I/O Interrupt Controller"
+ depends on MACH_LOONGSON64
+ default y
+ select IRQ_DOMAIN
+ select GENERIC_IRQ_CHIP
+ help
+ Support for the Loongson-3 I/O Interrupt Controller.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 8d0fcec6ab23..49ecb8d38138 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -102,3 +102,4 @@ obj-$(CONFIG_MADERA_IRQ)+= irq-madera.o
obj-$(CONFIG_LS1X_IRQ) += irq-ls1x.o
obj-$(CONFIG_TI_SCI_INTR_IRQCHIP) += irq-ti-sci-intr.o
obj-$(CONFIG_TI_SCI_INTA_IRQCHIP) += irq-ti-sci-inta.o
+obj-$(CONFIG_LS3_IOINTC) += irq-ls3-iointc.o
diff --git a/drivers/irqchip/irq-ls3-iointc.c b/drivers/irqchip/irq-ls3-iointc.c
new file mode 100644
index ..0fbff7afa43c
--- /dev/null
+++ b/drivers/irqchip/irq-ls3-iointc.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019, Jiaxun Yang
+ * Loongson-3 IOINTC IRQ support
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define LS3_CHIP_IRQ 32
+
+#define LS3_REG_INTx_MAP(x)(x * 0x1)
+#define LS3_INTC_CHIP_START0x20
+
+#define LS3_REG_INTC_STATUS(LS3_INTC_CHIP_START + 0x00)
+#define LS3_REG_INTC_EN_STATUS (LS3_INTC_CHIP_START + 0x04)
+#define LS3_REG_INTC_ENABLE(LS3_INTC_CHIP_START + 0x08)
+#define LS3_REG_INTC_DISABLE (LS3_INTC_CHIP_START + 0x0c)
+#define LS3_REG_INTC_POL (LS3_INTC_CHIP_START + 0x10)
+#define LS3_REG_INTC_EDGE (LS3_INTC_CHIP_START + 0x18)
+
+#define LS3_MAP_CORE_INT(x, y) (u8)(BIT(x) | (BIT(y) << 4))
+
+struct ls3_iointc_priv {
+ u8 map_cache[LS3_CHIP_IRQ];
+};
+
+
+static void ls3_io_chained_handle_irq(struct irq_desc *desc)
+{
+ struct irq_chip_generic *gc = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ u32 pending;
+
+ chained_irq_enter(chip, desc);
+
+ /* Check with mask_cache to prevent HW fake interrupt */
+ pending = ~gc->mask_cache &
+ readl(gc->reg_base + LS3_REG_INTC_STATUS);
+
+ if (!pending)
+ spurious_interrupt();
+
+ while (pending) {
+ int bit = __ffs(pending);
+
+ generic_handle_irq(irq_find_mapping(gc->domain, bit));
+ pending &= ~BIT(bit);
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+static void ls_intc_set_bit(struct irq_chip_generic *gc,
+ unsigned int offset,
+ u32 mask, bool set)
+{
+ if (set)
+ writel(readl(gc->reg_base + offset) | mask,
+ gc->reg_base + offset);
+ else
+ writel(readl(gc->reg_base + offset) & ~mask,
+ gc->reg_base + offset);
+}
+
+static int ls_intc_set_type(struct irq_data *data, unsigned int type)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+ u32 mask = data->mask;
+ unsigned long flags;
+
+ irq_gc_lock_irqsave(gc, flags);
+ switch (type) {
+ case IRQ_TYPE_LEVEL_HIGH:
+ ls_intc_set_bit(gc, LS3_REG_INTC_EDGE, mask, false);
+ ls_intc_set_bit(gc, LS3_REG_INTC_POL, mask, true);
+ break;
+ case IRQ_TYPE_LEVEL_LOW:
+ ls_intc_set_bit(gc, LS3_REG_INTC_EDGE, mask, false);
+ ls_intc_set_bit(gc, LS3_REG_INTC_POL, mask, false);
+ break;
+ case IRQ_TYPE_EDGE_RISING:
+ ls_intc_set_bit(gc, LS3_REG_INTC_EDGE, mask, true);
+ ls_intc_set_bit(gc, LS3_REG_INTC_POL, mask, true);
+ break;
+ case IRQ_TYPE_EDGE_FALLING:
+ ls_intc_set_bit(gc, LS3_REG_INTC_EDGE, mask, true);
+ ls_intc_set_bit(gc, LS3_REG_INTC_POL, mask, false);
+ break;
+ default:
+ return -EINVAL;
+ }
+ irq_gc_unlock_irqrestore(gc, flags);
+
+ irqd_set_trigger_type(data, type);
+ return 0;
+}
+
[PATCH v1 03/18] MAINTAINERS: Fix entries for new loongson64 path
As we sepreated the code of loongson2ef/loongson3a, they can now have their own entries. Signed-off-by: Jiaxun Yang --- MAINTAINERS | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index a2c343ee3b2c..d5d4fed632e6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10747,17 +10747,16 @@ F:arch/mips/include/asm/mach-loongson32/ F: drivers/*/*loongson1* F: drivers/*/*/*loongson1* -MIPS/LOONGSON2 ARCHITECTURE +MIPS/LOONGSON2E/F ARCHITECTURE M: Jiaxun Yang L: linux-m...@vger.kernel.org S: Maintained -F: arch/mips/loongson64/fuloong-2e/ -F: arch/mips/loongson64/lemote-2f/ -F: arch/mips/include/asm/mach-loongson64/ +F: arch/mips/loongson2ef/ +F: arch/mips/include/asm/mach-loongson2ef/ F: drivers/*/*loongson2* F: drivers/*/*/*loongson2* -MIPS/LOONGSON3 ARCHITECTURE +MIPS/LOONGSON64 ARCHITECTURE M: Huacai Chen L: linux-m...@vger.kernel.org S: Maintained -- 2.22.0
[PATCH v1 02/18] MIPS: Loongson64: separate loongson2ef/loongson64 code
As later model of GSx64 family processors including 2-series-soc have
similar design with initial loongson3a while loongson2e/f seems less
identical, we separate loongson2e/f support code out of mach-loongson64
to make our life easier.
Signed-off-by: Jiaxun Yang
---
arch/mips/Kbuild.platforms| 1 +
arch/mips/Kconfig | 51 +--
arch/mips/include/asm/bootinfo.h | 1 -
.../mach-loongson2ef/cpu-feature-overrides.h | 45 +++
.../cs5536/cs5536.h | 0
.../cs5536/cs5536_mfgpt.h | 0
.../cs5536/cs5536_pci.h | 0
.../cs5536/cs5536_vsm.h | 0
.../loongson2ef.h}| 29 +---
.../machine.h | 6 -
.../mc146818rtc.h | 5 +-
.../mem.h | 6 +-
arch/mips/include/asm/mach-loongson2ef/pci.h | 43 ++
.../include/asm/mach-loongson2ef/spaces.h | 10 ++
.../mach-loongson64/cpu-feature-overrides.h | 3 -
arch/mips/include/asm/mach-loongson64/irq.h | 7 +-
.../asm/mach-loongson64/kernel-entry-init.h | 74 --
.../include/asm/mach-loongson64/loongson64.h | 48 +++
.../mips/include/asm/mach-loongson64/mmzone.h | 16 ---
arch/mips/include/asm/mach-loongson64/pci.h | 41 +-
.../include/asm/mach-loongson64/workarounds.h | 4 +-
arch/mips/loongson2ef/Kconfig | 93 +
arch/mips/loongson2ef/Makefile| 18 +++
arch/mips/loongson2ef/Platform| 32 +
.../common/Makefile | 0
.../common/bonito-irq.c | 2 +-
.../common/cmdline.c | 2 +-
.../common/cs5536/Makefile| 0
.../common/cs5536/cs5536_acc.c| 0
.../common/cs5536/cs5536_ehci.c | 0
.../common/cs5536/cs5536_ide.c| 0
.../common/cs5536/cs5536_isa.c| 0
.../common/cs5536/cs5536_mfgpt.c | 0
.../common/cs5536/cs5536_ohci.c | 0
.../common/cs5536/cs5536_pci.c| 0
.../common/early_printk.c | 2 +-
arch/mips/loongson2ef/common/env.c| 71 ++
.../{loongson64 => loongson2ef}/common/init.c | 7 +-
.../{loongson64 => loongson2ef}/common/irq.c | 2 +-
.../common/machtype.c | 3 +-
.../{loongson64 => loongson2ef}/common/mem.c | 40 +-
.../{loongson64 => loongson2ef}/common/pci.c | 11 +-
.../common/platform.c | 0
.../{loongson64 => loongson2ef}/common/pm.c | 2 +-
.../common/reset.c| 23 +---
.../{loongson64 => loongson2ef}/common/rtc.c | 0
.../common/serial.c | 37 +
.../common/setup.c| 2 +-
.../{loongson64 => loongson2ef}/common/time.c | 2 +-
.../common/uart_base.c| 10 +-
.../fuloong-2e/Makefile | 0
.../fuloong-2e/dma.c | 0
.../fuloong-2e/irq.c | 2 +-
.../fuloong-2e/reset.c| 2 +-
.../lemote-2f/Makefile| 0
.../lemote-2f/clock.c | 2 +-
.../lemote-2f/dma.c | 0
.../lemote-2f/ec_kb3310b.c| 0
.../lemote-2f/ec_kb3310b.h| 0
.../lemote-2f/irq.c | 2 +-
.../lemote-2f/machtype.c | 2 +-
.../lemote-2f/pm.c| 2 +-
.../lemote-2f/reset.c | 2 +-
arch/mips/loongson64/Kconfig | 126 +-
arch/mips/loongson64/Makefile | 23 +---
arch/mips/loongson64/Platform | 26 +---
.../loongson64/{loongson-3 => }/acpi_init.c | 3 +-
.../loongson64/{loongson-3 => }/cop2-ex.c | 5 +-
arch/mips/loongson64/{loongson-3 => }/dma.c | 6 +-
arch/mips/loongson64/{common => }/env.c | 72 +++---
arch/mips/loongson64/{loongson-3 => }/hpet.c | 0
arch/mips/loongson64/{loongson-3 => }/irq.c | 40 +-
arch/mips/loongson64/loongson-3/Makefile | 11 --
arch/mips/loongson64/{loongson-3 => }/numa.c | 4 +-
arch/mips/loongson64/pci.c| 45 +++
.../loongson64/{loongson-3 => }/platform.c| 0
arch/mips/loongson64/reset.c | 58
arch/mips/loongson64/setup.c | 92 +
arch/mips/loongson64/{loongson-3 => }/smp.c | 4 +-
arch/mips/loongson64/{loongson-3 => }/smp.h | 0
arch/mips/oprofile/op_model_loongson2.c | 2 +-
arch/mips/oprofile/op_model_loongson3.c | 2 +-
arch/mips/pci/Makefile| 2 +-
arch/mips/pci/fixup-fuloong2e.c
[PATCH v1 06/18] dt-bindings: interrupt-controller: Add Loongson-3 IOINTC
Document Loongson-3 I/O Interrupt controller.
Signed-off-by: Jiaxun Yang
---
.../loongson,ls3-iointc.yaml | 75 +++
1 file changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
new file mode 100644
index ..9aee10abd5cd
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/loongson,ls3-iointc.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
"http://devicetree.org/schemas/interrupt-controller/loongson,ls3-iointc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Loongson-3 I/O Interrupt Controller
+
+maintainers:
+ - Jiaxun Yang
+
+description: |
+ This interrupt controller is found in the Loongson-3 family of chips as the
primary
+ package interrupt source which can route interrupt to interrupt line of
cores.
+
+properties:
+ compatible:
+const: loongson,ls3-iointc
+
+ reg:
+maxItems: 1
+
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+description: |
+ Specifies the number of cells needed to encode an interrupt source.
+ Must be 2 or 4.
+ If the system requires describing interrupt line & core mapping, than
+ it must be 4.
+
+ The 1st cell is the hardware interrupt number.
+
+ The 2nd cell is the flags, encoded as follows:
+bits[3:0] trigger type and level flags.
+ 1 = low-to-high edge triggered
+ 2 = high-to-low edge triggered
+ 4 = active high level-sensitive
+ 8 = active low level-sensitive.
+
+ The 3rd is the parent interrupt line that interrupt would map to.
+ As the CPU preserved 4 interrupt lines for I/O, in theory any of the
iointc
+ interrupt can be chained to any interrupt lines on a core. But currently
+ we can only map all the interrupt to a single parent, so this cell must
be
+ set uniformly for all the child interrupts corresponding to the parent
+ interrupt.
+
+ The 4th is the parent core that interrupt would map to. The interrupt
+ contoller can map any of the interrupt to the specified core on a
package.
+ This cell determined the core. It must be the bootcore.
+
+ If the 3rd, 4th cell is not set, it will default to the 0# interrupt line
+ and bootcore.
+
+enum: [ 2, 4 ]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-controller
+ - '#interrupt-cells'
+
+
+examples:
+ - |
+iointc: interrupt-controller@3ff01400 {
+compatible = "loongson,ls3-io-intc";
+reg = <0x3ff01400 0x60>;
+interrupts = <2>;
+interrupt-controller;
+#interrupt-cells = <4>;
+};
+...
--
2.22.0
[PATCH v1 04/18] irqchip: Export generic chip domain map/unmap functions
Export irq_map_generic_chip, irq_unmap_generic_chip so drivers
can use them to construct their own generic chip domain ops.
Signed-off-by: Jiaxun Yang
---
include/linux/irq.h | 1 +
kernel/irq/generic-chip.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index fb301cf29148..3637c24046e1 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -1060,6 +1060,7 @@ int irq_gc_set_wake(struct irq_data *d, unsigned int on);
/* Setup functions for irq_chip_generic */
int irq_map_generic_chip(struct irq_domain *d, unsigned int virq,
irq_hw_number_t hw_irq);
+void irq_unmap_generic_chip(struct irq_domain *d, unsigned int virq);
struct irq_chip_generic *
irq_alloc_generic_chip(const char *name, int nr_ct, unsigned int irq_base,
void __iomem *reg_base, irq_flow_handler_t handler);
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index e2999a070a99..211b15c0d647 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -423,8 +423,9 @@ int irq_map_generic_chip(struct irq_domain *d, unsigned int
virq,
irq_modify_status(virq, dgc->irq_flags_to_clear, dgc->irq_flags_to_set);
return 0;
}
+EXPORT_SYMBOL_GPL(irq_map_generic_chip);
-static void irq_unmap_generic_chip(struct irq_domain *d, unsigned int virq)
+void irq_unmap_generic_chip(struct irq_domain *d, unsigned int virq)
{
struct irq_data *data = irq_domain_get_irq_data(d, virq);
struct irq_domain_chip_generic *dgc = d->gc;
@@ -443,6 +444,7 @@ static void irq_unmap_generic_chip(struct irq_domain *d,
unsigned int virq)
NULL);
}
+EXPORT_SYMBOL_GPL(irq_unmap_generic_chip);
struct irq_domain_ops irq_generic_chip_ops = {
.map= irq_map_generic_chip,
--
2.22.0
[PATCH v1 00/18] Modernize Loongson64 Machine
v1: - dt-bindings fixup according to Rob's comments - irqchip fixup according to Marc's comments - ls3-iointc: Make Core map per-IRQ - Regenerate kconfigs - Typo & style improvements Jiaxun Yang (18): MIPS: Loongson64: Rename CPU TYPES MIPS: Loongson64: separate loongson2ef/loongson64 code MAINTAINERS: Fix entries for new loongson64 path irqchip: Export generic chip domain map/unmap functions irqchip: Add driver for Loongson-3 I/O interrupt controller dt-bindings: interrupt-controller: Add Loongson-3 IOINTC irqchip: Add driver for Loongson-3 HyperTransport interrupt controller dt-bindings: interrupt-controller: Add Loongson-3 HTINTC irqchip: i8259: Add plat-poll support irqchip: mips-cpu: Convert to simple domain MIPS: Loongson64: Drop legacy IRQ code dt-bindings: mips: Add loongson cpus & boards dt-bindings: Document loongson vendor-prefix MIPS: Loongson64: Add generic dts MIPS: Loongson64: Load built-in dtbs MIPS: Loongson: Regenerate defconfigs MAINTAINERS: Add new pathes to LOONGSON64 ARCHITECTURE MAINTAINERS: Add myself as maintainer of LOONGSON64 .../loongson,ls3-htintc.yaml | 55 .../loongson,ls3-iointc.yaml | 75 + .../bindings/mips/loongson/cpus.yaml | 38 +++ .../bindings/mips/loongson/devices.yaml | 64 .../devicetree/bindings/vendor-prefixes.yaml | 2 + MAINTAINERS | 13 +- arch/mips/Kbuild.platforms| 1 + arch/mips/Kconfig | 83 -- arch/mips/boot/dts/Makefile | 1 + arch/mips/boot/dts/loongson/Makefile | 8 + arch/mips/boot/dts/loongson/ls3-2nodes.dtsi | 8 + arch/mips/boot/dts/loongson/ls3-4nodes.dtsi | 15 + arch/mips/boot/dts/loongson/ls3-cpus.dtsi | 150 ++ arch/mips/boot/dts/loongson/ls3-gs464.dtsi| 18 ++ arch/mips/boot/dts/loongson/ls3-gs464e.dtsi | 18 ++ .../boot/dts/loongson/ls3-rs780e-pch.dtsi | 35 +++ arch/mips/boot/dts/loongson/ls3a-package.dtsi | 59 .../boot/dts/loongson/ls3a1000_780e_1way.dts | 12 + .../boot/dts/loongson/ls3a1000_780e_2way.dts | 13 + .../boot/dts/loongson/ls3a1000_780e_4way.dts | 13 + .../boot/dts/loongson/ls3a2000_780e_1way.dts | 12 + .../boot/dts/loongson/ls3a2000_780e_2way.dts | 13 + .../boot/dts/loongson/ls3a2000_780e_4way.dts | 13 + .../boot/dts/loongson/ls3a3000_780e_1way.dts | 12 + .../boot/dts/loongson/ls3a3000_780e_2way.dts | 13 + .../boot/dts/loongson/ls3a3000_780e_4way.dts | 13 + arch/mips/boot/dts/loongson/ls3b-package.dtsi | 59 .../mips/boot/dts/loongson/ls3b_780e_1way.dts | 13 + .../mips/boot/dts/loongson/ls3b_780e_2way.dts | 13 + arch/mips/configs/fuloong2e_defconfig | 8 +- arch/mips/configs/lemote2f_defconfig | 8 +- arch/mips/configs/loongson3_defconfig | 12 +- arch/mips/include/asm/bootinfo.h | 1 - arch/mips/include/asm/cop2.h | 2 +- arch/mips/include/asm/cpu-type.h | 6 +- arch/mips/include/asm/cpu.h | 4 +- arch/mips/include/asm/hazards.h | 2 +- arch/mips/include/asm/io.h| 2 +- arch/mips/include/asm/irqflags.h | 2 +- .../mach-loongson2ef/cpu-feature-overrides.h | 45 +++ .../cs5536/cs5536.h | 0 .../cs5536/cs5536_mfgpt.h | 0 .../cs5536/cs5536_pci.h | 0 .../cs5536/cs5536_vsm.h | 0 .../loongson2ef.h}| 31 +- .../machine.h | 6 - .../mc146818rtc.h | 5 +- .../mem.h | 6 +- arch/mips/include/asm/mach-loongson2ef/pci.h | 43 +++ .../include/asm/mach-loongson2ef/spaces.h | 10 + .../asm/mach-loongson64/builtin_dtbs.h| 26 ++ .../mach-loongson64/cpu-feature-overrides.h | 3 - arch/mips/include/asm/mach-loongson64/irq.h | 6 +- .../asm/mach-loongson64/kernel-entry-init.h | 74 - .../include/asm/mach-loongson64/loongson64.h | 50 .../mips/include/asm/mach-loongson64/mmzone.h | 16 - arch/mips/include/asm/mach-loongson64/pci.h | 41 +-- .../include/asm/mach-loongson64/workarounds.h | 4 +- arch/mips/include/asm/module.h| 8 +- arch/mips/include/asm/pgtable-bits.h | 2 +- arch/mips/include/asm/processor.h | 2 +- arch/mips/include/asm/r4kcache.h | 4 +- arch/mips/kernel/cpu-probe.c | 14 +- arch/mips/kernel/idle.c | 2 +- arch/mips/kernel/perf_event_mipsxx.c | 4 +- arch/mips/kernel/setup.c | 2 +- arch/mips/kernel/traps.c | 2 +- arch/mips/lib/csum_partial.S | 4 +- arch/mips/loongson2ef/Kconfig | 93 ++
[PATCH v1 01/18] MIPS: Loongson64: Rename CPU TYPES
CPU_LOONGSON2 -> CPU_LOONGSON2EF CPU_LOONGSON3 -> CPU_LOONGSON64 As newer loongson-2 products (2G/2H/2K1000) can share kernel implementation with loongson-3 while 2E/2F are less similar with other LOONGSON64 products. Signed-off-by: Jiaxun Yang --- arch/mips/Kconfig | 28 arch/mips/include/asm/cop2.h | 2 +- arch/mips/include/asm/cpu-type.h | 6 ++-- arch/mips/include/asm/cpu.h | 4 +-- arch/mips/include/asm/hazards.h | 2 +- arch/mips/include/asm/io.h| 2 +- arch/mips/include/asm/irqflags.h | 2 +- .../mach-loongson64/cpu-feature-overrides.h | 2 +- arch/mips/include/asm/mach-loongson64/irq.h | 2 +- .../asm/mach-loongson64/kernel-entry-init.h | 4 +-- .../include/asm/mach-loongson64/loongson.h| 2 +- arch/mips/include/asm/mach-loongson64/pci.h | 2 +- arch/mips/include/asm/module.h| 8 ++--- arch/mips/include/asm/pgtable-bits.h | 2 +- arch/mips/include/asm/processor.h | 2 +- arch/mips/include/asm/r4kcache.h | 4 +-- arch/mips/kernel/cpu-probe.c | 14 arch/mips/kernel/idle.c | 2 +- arch/mips/kernel/perf_event_mipsxx.c | 4 +-- arch/mips/kernel/setup.c | 2 +- arch/mips/kernel/traps.c | 2 +- arch/mips/lib/csum_partial.S | 4 +-- arch/mips/loongson64/Kconfig | 2 +- arch/mips/loongson64/Makefile | 2 +- arch/mips/loongson64/Platform | 12 +++ arch/mips/loongson64/common/pci.c | 2 +- arch/mips/mm/c-r4k.c | 32 +-- arch/mips/mm/page.c | 2 +- arch/mips/mm/tlb-r4k.c| 4 +-- arch/mips/mm/tlbex.c | 6 ++-- arch/mips/oprofile/Makefile | 4 +-- arch/mips/oprofile/common.c | 4 +-- drivers/gpio/Kconfig | 2 +- drivers/gpio/gpio-loongson.c | 2 +- include/drm/drm_cache.h | 2 +- 35 files changed, 89 insertions(+), 89 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index d50fafd7bf3a..cbc76f00d1fc 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1367,9 +1367,9 @@ choice prompt "CPU type" default CPU_R4X00 -config CPU_LOONGSON3 - bool "Loongson 3 CPU" - depends on SYS_HAS_CPU_LOONGSON3 +config CPU_LOONGSON64 + bool "Loongson GSx64 Family CPU" + depends on SYS_HAS_CPU_LOONGSON64 select ARCH_HAS_PHYS_TO_DMA select CPU_SUPPORTS_64BIT_KERNEL select CPU_SUPPORTS_HIGHMEM @@ -1382,15 +1382,15 @@ config CPU_LOONGSON3 select GPIOLIB select SWIOTLB help - The Loongson 3 processor implements the MIPS64R2 instruction - set with many extensions. + The Loongson GSx64 Family cores including Loongson-3A/3B/2series-soc + implements the MIPS64R2 instruction set with many extensions. config LOONGSON3_ENHANCEMENT bool "New Loongson 3 CPU Enhancements" default n select CPU_MIPSR2 select CPU_HAS_PREFETCH - depends on CPU_LOONGSON3 + depends on CPU_LOONGSON64 help New Loongson 3 CPU (since Loongson-3A R2, as opposed to Loongson-3A R1, Loongson-3B R1 and Loongson-3B R2) has many enhancements, such as @@ -1406,7 +1406,7 @@ config LOONGSON3_ENHANCEMENT config CPU_LOONGSON3_WORKAROUNDS bool "Old Loongson 3 LLSC Workarounds" default y if SMP - depends on CPU_LOONGSON3 + depends on CPU_LOONGSON64 help Loongson 3 processors have the llsc issues which require workarounds. Without workarounds the system may hang unexpectedly. @@ -1421,7 +1421,7 @@ config CPU_LOONGSON3_WORKAROUNDS config CPU_LOONGSON2E bool "Loongson 2E" depends on SYS_HAS_CPU_LOONGSON2E - select CPU_LOONGSON2 + select CPU_LOONGSON2EF help The Loongson 2E processor implements the MIPS III instruction set with many extensions. @@ -1432,7 +1432,7 @@ config CPU_LOONGSON2E config CPU_LOONGSON2F bool "Loongson 2F" depends on SYS_HAS_CPU_LOONGSON2F - select CPU_LOONGSON2 + select CPU_LOONGSON2EF select GPIOLIB help The Loongson 2F processor implements the MIPS III instruction set @@ -1870,7 +1870,7 @@ config SYS_SUPPORTS_ZBOOT_UART_PROM bool select SYS_SUPPORTS_ZBOOT -config CPU_LOONGSON2 +config CPU_LOONGSON2EF bool select CPU_SUPPORTS_32BIT_KERNEL select CPU_SUPPORTS_64BIT_KERNEL @@ -1913,7 +1913,7 @@ config CPU_BMIPS5000 select SYS_SUPPORTS_HOTPLUG_CPU select CPU_HAS_RIXI -config
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/usb/r8152.c
between commits:
49d4b14113ca ("Revert "r8152: napi hangup fix after disconnect"")
973dc6cfc0e2 ("r8152: remove calling netif_napi_del")
from the net tree and commit:
d2187f8e4454 ("r8152: divide the tx and rx bottom functions")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/usb/r8152.c
index 04137ac373b0,c6fa0c17c13d..
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@@ -4021,7 -4214,9 +4214,8 @@@ static int rtl8152_close(struct net_dev
#ifdef CONFIG_PM_SLEEP
unregister_pm_notifier(>pm_notifier);
#endif
+ tasklet_disable(>tx_tl);
- if (!test_bit(RTL8152_UNPLUG, >flags))
- napi_disable(>napi);
+ napi_disable(>napi);
clear_bit(WORK_ENABLE, >flags);
usb_kill_urb(tp->intr_urb);
cancel_delayed_work_sync(>schedule);
@@@ -5352,6 -5604,8 +5603,7 @@@ static int rtl8152_probe(struct usb_int
return 0;
out1:
- netif_napi_del(>napi);
+ tasklet_kill(>tx_tl);
usb_set_intfdata(intf, NULL);
out:
free_netdev(netdev);
@@@ -5366,7 -5620,9 +5618,8 @@@ static void rtl8152_disconnect(struct u
if (tp) {
rtl_set_unplug(tp);
- netif_napi_del(>napi);
unregister_netdev(tp->netdev);
+ tasklet_kill(>tx_tl);
cancel_delayed_work_sync(>hw_phy_work);
tp->rtl_ops.unload(tp);
free_netdev(tp->netdev);
pgpwHbitcc0w0.pgp
Description: OpenPGP digital signature
RE: [PATCH internal net-next 0/2] Minor refactor in devlink
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Parav Pandit > Sent: Friday, August 30, 2019 9:41 AM > To: linux-kernel@vger.kernel.org; Jiri Pirko > Cc: Parav Pandit > Subject: [PATCH internal net-next 0/2] Minor refactor in devlink > > Two minor refactors in devlink. > > Patch-1 Explicitly defines devlink port index as unsigned int > Patch-2 Uses switch-case to handle different port flavours attributes > > Parav Pandit (2): > devlink: Make port index data type as unsigned int > devlink: Use switch-case instead of if-else > > include/net/devlink.h | 2 +- > net/core/devlink.c| 44 --- > 2 files changed, 26 insertions(+), 20 deletions(-) > > -- > 2.19.2 I am sorry for noise. By mistake send to wrong list.
[PATCH internal net-next 0/2] Minor refactor in devlink
Two minor refactors in devlink. Patch-1 Explicitly defines devlink port index as unsigned int Patch-2 Uses switch-case to handle different port flavours attributes Parav Pandit (2): devlink: Make port index data type as unsigned int devlink: Use switch-case instead of if-else include/net/devlink.h | 2 +- net/core/devlink.c| 44 --- 2 files changed, 26 insertions(+), 20 deletions(-) -- 2.19.2
[PATCH internal net-next 1/2] devlink: Make port index data type as unsigned int
Devlink port index attribute is returned to users as u32 through
netlink response.
Change index data type from 'unsigned' to 'unsigned int' to avoid any
size ambiguity and to avoid below checkpatch.pl warning.
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
81: FILE: include/net/devlink.h:81:
+ unsigned index;
Signed-off-by: Parav Pandit
---
include/net/devlink.h | 2 +-
net/core/devlink.c| 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 7f43c48f54cd..13523b0a0642 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -75,7 +75,7 @@ struct devlink_port {
struct list_head list;
struct list_head param_list;
struct devlink *devlink;
- unsigned index;
+ unsigned int index;
bool registered;
spinlock_t type_lock; /* Protects type and type_dev
* pointer consistency.
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 650f36379203..b7091329987a 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -136,7 +136,7 @@ static struct devlink *devlink_get_from_info(struct
genl_info *info)
}
static struct devlink_port *devlink_port_get_by_index(struct devlink *devlink,
- int port_index)
+ unsigned int port_index)
{
struct devlink_port *devlink_port;
@@ -147,7 +147,8 @@ static struct devlink_port
*devlink_port_get_by_index(struct devlink *devlink,
return NULL;
}
-static bool devlink_port_index_exists(struct devlink *devlink, int port_index)
+static bool devlink_port_index_exists(struct devlink *devlink,
+ unsigned int port_index)
{
return devlink_port_get_by_index(devlink, port_index);
}
--
2.19.2
Re: mmotm 2019-08-27-20-39 uploaded (objtool: xen)
On Fri, Aug 30, 2019 at 1:38 AM Josh Poimboeuf wrote:
>
> On Thu, Aug 29, 2019 at 10:24:45AM +0200, Peter Zijlstra wrote:
> > On Wed, Aug 28, 2019 at 03:01:34PM -0500, Josh Poimboeuf wrote:
> > > On Wed, Aug 28, 2019 at 10:56:25AM -0700, Randy Dunlap wrote:
> > > > >> drivers/xen/gntdev.o: warning: objtool: gntdev_copy()+0x229: call to
> > > > >> __ubsan_handle_out_of_bounds() with UACCESS enabled
> > > > >
> > > > > Easy one :-)
> > > > >
> > > > > diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> > > > > index 0c8e17f946cd..6a935ab93149 100644
> > > > > --- a/tools/objtool/check.c
> > > > > +++ b/tools/objtool/check.c
> > > > > @@ -483,6 +483,7 @@ static const char *uaccess_safe_builtin[] = {
> > > > > "ubsan_type_mismatch_common",
> > > > > "__ubsan_handle_type_mismatch",
> > > > > "__ubsan_handle_type_mismatch_v1",
> > > > > + "__ubsan_handle_out_of_bounds",
> > > > > /* misc */
> > > > > "csum_partial_copy_generic",
> > > > > "__memcpy_mcsafe",
> > > > >
> > > >
> > > >
> > > > then I get this one:
> > > >
> > > > lib/ubsan.o: warning: objtool: __ubsan_handle_out_of_bounds()+0x5d:
> > > > call to ubsan_prologue() with UACCESS enabled
> > >
> > > And of course I jinxed it by calling it easy.
> > >
> > > Peter, how do you want to handle this?
> > >
> > > Should we just disable UACCESS checking in lib/ubsan.c?
> >
> > No, that is actually unsafe and could break things (as would you patch
> > above).
>
> Oops. -EFIXINGTOOMANYOBJTOOLISSUESATONCE
>
> > I'm thinking the below patch ought to cure things:
> >
> > ---
> > Subject: x86/uaccess: Don't leak the AC flags into __get_user() argument
> > evalidation
>
> s/evalidation/evaluation
>
> > Identical to __put_user(); the __get_user() argument evalution will too
> > leak UBSAN crud into the __uaccess_begin() / __uaccess_end() region.
> > While uncommon this was observed to happen for:
> >
> > drivers/xen/gntdev.c: if (__get_user(old_status, batch->status[i]))
> >
> > where UBSAN added array bound checking.
> >
> > This complements commit:
> >
> > 6ae865615fc4 ("x86/uaccess: Dont leak the AC flag into __put_user()
> > argument evaluation")
> >
> > Reported-by: Randy Dunlap
> > Signed-off-by: Peter Zijlstra (Intel)
> > Cc: l...@kernel.org
> > ---
> > arch/x86/include/asm/uaccess.h | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> > index 9c4435307ff8..35c225ede0e4 100644
> > --- a/arch/x86/include/asm/uaccess.h
> > +++ b/arch/x86/include/asm/uaccess.h
> > @@ -444,8 +444,10 @@ __pu_label:
> > \
> > ({ \
> > int __gu_err; \
> > __inttype(*(ptr)) __gu_val; \
> > + __typeof__(ptr) __gu_ptr = (ptr); \
> > + __typeof__(size) __gu_size = (size);\
> > __uaccess_begin_nospec(); \
> > - __get_user_size(__gu_val, (ptr), (size), __gu_err, -EFAULT);\
> > + __get_user_size(__gu_val, __gu_ptr, __gu_size, __gu_err, -EFAULT);
> > \
> > __uaccess_end();\
> > (x) = (__force __typeof__(*(ptr)))__gu_val; \
> > __builtin_expect(__gu_err, 0); \
>
> Reviewed-by: Josh Poimboeuf
>
Tested-by Sedat Dilek
- Sedat -
[PATCH internal net-next 2/2] devlink: Use switch-case instead of if-else
Make core more readable with switch-case for various port flavours.
Signed-off-by: Parav Pandit
---
net/core/devlink.c | 39 ++-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/net/core/devlink.c b/net/core/devlink.c
index b7091329987a..6e52d639dac6 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -510,32 +510,37 @@ static int devlink_nl_port_attrs_put(struct sk_buff *msg,
return 0;
if (nla_put_u16(msg, DEVLINK_ATTR_PORT_FLAVOUR, attrs->flavour))
return -EMSGSIZE;
- if (devlink_port->attrs.flavour == DEVLINK_PORT_FLAVOUR_PCI_PF) {
+ switch (devlink_port->attrs.flavour) {
+ case DEVLINK_PORT_FLAVOUR_PCI_PF:
if (nla_put_u16(msg, DEVLINK_ATTR_PORT_PCI_PF_NUMBER,
attrs->pci_pf.pf))
return -EMSGSIZE;
- } else if (devlink_port->attrs.flavour == DEVLINK_PORT_FLAVOUR_PCI_VF) {
+ break;
+ case DEVLINK_PORT_FLAVOUR_PCI_VF:
if (nla_put_u16(msg, DEVLINK_ATTR_PORT_PCI_PF_NUMBER,
attrs->pci_vf.pf) ||
nla_put_u16(msg, DEVLINK_ATTR_PORT_PCI_VF_NUMBER,
attrs->pci_vf.vf))
return -EMSGSIZE;
+ break;
+ case DEVLINK_PORT_FLAVOUR_PHYSICAL:
+ case DEVLINK_PORT_FLAVOUR_CPU:
+ case DEVLINK_PORT_FLAVOUR_DSA:
+ if (nla_put_u32(msg, DEVLINK_ATTR_PORT_NUMBER,
+ attrs->phys.port_number))
+ return -EMSGSIZE;
+ if (!attrs->split)
+ return 0;
+ if (nla_put_u32(msg, DEVLINK_ATTR_PORT_SPLIT_GROUP,
+ attrs->phys.port_number))
+ return -EMSGSIZE;
+ if (nla_put_u32(msg, DEVLINK_ATTR_PORT_SPLIT_SUBPORT_NUMBER,
+ attrs->phys.split_subport_number))
+ return -EMSGSIZE;
+ break;
+ default:
+ break;
}
- if (devlink_port->attrs.flavour != DEVLINK_PORT_FLAVOUR_PHYSICAL &&
- devlink_port->attrs.flavour != DEVLINK_PORT_FLAVOUR_CPU &&
- devlink_port->attrs.flavour != DEVLINK_PORT_FLAVOUR_DSA)
- return 0;
- if (nla_put_u32(msg, DEVLINK_ATTR_PORT_NUMBER,
- attrs->phys.port_number))
- return -EMSGSIZE;
- if (!attrs->split)
- return 0;
- if (nla_put_u32(msg, DEVLINK_ATTR_PORT_SPLIT_GROUP,
- attrs->phys.port_number))
- return -EMSGSIZE;
- if (nla_put_u32(msg, DEVLINK_ATTR_PORT_SPLIT_SUBPORT_NUMBER,
- attrs->phys.split_subport_number))
- return -EMSGSIZE;
return 0;
}
--
2.19.2
[PATCH v7 07/11] dt-bindings: pwm: pwm-mediatek: add a property "num-pwms"
From: Ryder Lee
This adds a property "num-pwms" in example so that we could
specify the number of PWM channels via device tree.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Reviewed-by: Matthias Brugger
Acked-by: Uwe Kleine-König
---
Changes since v6:
Follow reviewers's comments:
- The subject should indicate this is for Mediatek
Changes since v5:
- Add an Acked-by tag
- This file is original v4 patch 5/10
(https://patchwork.kernel.org/patch/11102577/)
---
Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
index 991728cb46cb..ea95b490a913 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
@@ -14,12 +14,12 @@ Required properties:
has no clocks
- "top": the top clock generator
- "main": clock used by the PWM core
- - "pwm1-8": the eight per PWM clocks for mt2712
- - "pwm1-6": the six per PWM clocks for mt7622
- - "pwm1-5": the five per PWM clocks for mt7623
+ - "pwm1-N": the PWM clocks for each channel
+ where N starting from 1 to the maximum number of PWM channels
- pinctrl-names: Must contain a "default" entry.
- pinctrl-0: One property must exist for each entry in pinctrl-names.
See pinctrl/pinctrl-bindings.txt for details of the property values.
+ - num-pwms: the number of PWM channels.
Example:
pwm0: pwm@11006000 {
@@ -37,4 +37,5 @@ Example:
"pwm3", "pwm4", "pwm5";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
+ num-pwms = <5>;
};
--
2.17.1
Re: [PATCH 1/2] perf top: Decay all events in the evlist
Hi Arnaldo, On Wed, Aug 28, 2019 at 9:49 PM Arnaldo Carvalho de Melo wrote: > > Em Wed, Aug 28, 2019 at 08:15:54AM +0900, Namhyung Kim escreveu: > > Currently perf top only decays entries in a selected evsel. I don't > > know whether it's intended (maybe due to performance reason?) but > > anyway it might show incorrect output when event group is used since > > users will see leader event is decayed but others are not. > > > > This patch moves the decay code into evlist__resort_hists() so that > > stdio and tui code shared the logic. > > > > Signed-off-by: Namhyung Kim > > --- > > tools/perf/builtin-top.c | 38 +- > > 1 file changed, 13 insertions(+), 25 deletions(-) > > > > diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c > > index 5970723cd55a..9d3059d2029d 100644 > > --- a/tools/perf/builtin-top.c > > +++ b/tools/perf/builtin-top.c > > @@ -264,13 +264,23 @@ static void perf_top__show_details(struct perf_top > > *top) > > pthread_mutex_unlock(>lock); > > } > > > > -static void evlist__resort_hists(struct evlist *evlist) > > +static void evlist__resort_hists(struct perf_top *t) > > Since this now operates on the perf_top struct, I'll rename it to > perf_top__resort_hists(), ok? No need to send an updated patch. Right. Thanks for doing this! Namhyung
[PATCH v7 08/11] arm64: dts: mt7622: add a property "num-pwms" for PWM
From: Ryder Lee This adds a property "num-pwms" for PWM controller. Signed-off-by: Ryder Lee Signed-off-by: Sam Shih --- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi b/arch/arm64/boot/dts/mediatek/mt7622.dtsi index d1e13d340e26..9a043938881f 100644 --- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi @@ -439,6 +439,7 @@ < CLK_PERI_PWM6_PD>; clock-names = "top", "main", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5", "pwm6"; + num-pwms = <6>; status = "disabled"; }; -- 2.17.1
[PATCH v7 05/11] pwm: mediatek: use pwm_mediatek as common prefix
Use pwm_mediatek as common prefix to match the filename.
No functional change intended.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Acked-by: Uwe Kleine-König
---
Changes since v6:
Add an Acked-by tag
Changes since v5:
- Follow reviewers's comments
The license stuff is a separate change
---
drivers/pwm/pwm-mediatek.c | 116 +++--
1 file changed, 59 insertions(+), 57 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 71bfab7e2e19..11f9cc446f14 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -34,14 +34,13 @@
#define PWM45THRES_FIXUP 0x34
#define PWM_CLK_DIV_MAX7
-
-struct mtk_pwm_platform_data {
+struct pwm_mediatek_of_data {
unsigned int fallback_npwms;
bool pwm45_fixup;
};
/**
- * struct mtk_pwm_chip - struct representing PWM chip
+ * struct pwm_mediatek_chip - struct representing PWM chip
* @chip: linux PWM chip representation
* @regs: base address of PWM chip
* @clk_top: the top clock generator
@@ -49,27 +48,29 @@ struct mtk_pwm_platform_data {
* @clk_pwms: the clock used by each PWM channel
* @clk_freq: the fix clock frequency of legacy MIPS SoC
*/
-struct mtk_pwm_chip {
+struct pwm_mediatek_chip {
struct pwm_chip chip;
void __iomem *regs;
struct clk *clk_top;
struct clk *clk_main;
struct clk **clk_pwms;
- const struct mtk_pwm_platform_data *soc;
+ const struct pwm_mediatek_of_data *soc;
};
-static const unsigned int mtk_pwm_reg_offset[] = {
+static const unsigned int pwm_mediatek_reg_offset[] = {
0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
};
-static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct pwm_chip *chip)
+static inline struct pwm_mediatek_chip *
+to_pwm_mediatek_chip(struct pwm_chip *chip)
{
- return container_of(chip, struct mtk_pwm_chip, chip);
+ return container_of(chip, struct pwm_mediatek_chip, chip);
}
-static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+static int pwm_mediatek_clk_enable(struct pwm_chip *chip,
+ struct pwm_device *pwm)
{
- struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+ struct pwm_mediatek_chip *pc = to_pwm_mediatek_chip(chip);
int ret;
ret = clk_prepare_enable(pc->clk_top);
@@ -94,45 +95,46 @@ static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
return ret;
}
-static void mtk_pwm_clk_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+static void pwm_mediatek_clk_disable(struct pwm_chip *chip,
+struct pwm_device *pwm)
{
- struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+ struct pwm_mediatek_chip *pc = to_pwm_mediatek_chip(chip);
clk_disable_unprepare(pc->clk_pwms[pwm->hwpwm]);
clk_disable_unprepare(pc->clk_main);
clk_disable_unprepare(pc->clk_top);
}
-static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
- unsigned int offset)
+static inline u32 pwm_mediatek_readl(struct pwm_mediatek_chip *chip,
+unsigned int num, unsigned int offset)
{
- return readl(chip->regs + mtk_pwm_reg_offset[num] + offset);
+ return readl(chip->regs + pwm_mediatek_reg_offset[num] + offset);
}
-static inline void mtk_pwm_writel(struct mtk_pwm_chip *chip,
- unsigned int num, unsigned int offset,
- u32 value)
+static inline void pwm_mediatek_writel(struct pwm_mediatek_chip *chip,
+ unsigned int num, unsigned int offset,
+ u32 value)
{
- writel(value, chip->regs + mtk_pwm_reg_offset[num] + offset);
+ writel(value, chip->regs + pwm_mediatek_reg_offset[num] + offset);
}
-static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- int duty_ns, int period_ns)
+static int pwm_mediatek_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
{
- struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
- struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
+ struct pwm_mediatek_chip *pc = to_pwm_mediatek_chip(chip);
u32 clkdiv = 0, cnt_period, cnt_duty, reg_width = PWMDWIDTH,
reg_thres = PWMTHRES;
u64 resolution;
int ret;
- ret = mtk_pwm_clk_enable(chip, pwm);
+ ret = pwm_mediatek_clk_enable(chip, pwm);
+
if (ret < 0)
return ret;
/* Using resolution in picosecond gets accuracy higher */
resolution = (u64)NSEC_PER_SEC * 1000;
- do_div(resolution, clk_get_rate(clk));
+ do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));
cnt_period =
[PATCH v7 11/11] arm: dts: mediatek: add mt7629 pwm support
This adds pwm support for MT7629.
Signed-off-by: Sam Shih
---
arch/arm/boot/dts/mt7629.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/mt7629.dtsi b/arch/arm/boot/dts/mt7629.dtsi
index 9608bc2ccb3f..493be9a9453b 100644
--- a/arch/arm/boot/dts/mt7629.dtsi
+++ b/arch/arm/boot/dts/mt7629.dtsi
@@ -241,6 +241,22 @@
status = "disabled";
};
+ pwm: pwm@11006000 {
+ compatible = "mediatek,mt7629-pwm",
+"mediatek,mt7622-pwm";
+ reg = <0 0x11006000 0 0x1000>;
+ interrupts = ;
+ clocks = < CLK_TOP_PWM_SEL>,
+< CLK_PERI_PWM_PD>,
+< CLK_PERI_PWM1_PD>;
+ clock-names = "top", "main", "pwm1";
+ assigned-clocks = < CLK_TOP_PWM_SEL>;
+ assigned-clock-parents =
+ < CLK_TOP_UNIVPLL2_D4>;
+ num-pwms = <1>;
+ status = "disabled";
+ };
+
i2c: i2c@11007000 {
compatible = "mediatek,mt7629-i2c",
"mediatek,mt2712-i2c";
--
2.17.1
[PATCH v7 10/11] dt-bindings: pwm: update bindings for MT7629 SoC
From: Ryder Lee This updates bindings for MT7629 pwm controller. Signed-off-by: Ryder Lee Signed-off-by: Sam Shih Reviewed-by: Rob Herring Reviewed-by: Matthias Brugger --- Changes since v7: - add a missed Reviewed-by tag back from v1: https://patchwork.kernel.org/patch/10769381/ Changes since v1: - add a Reviewed-by tag --- Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt index ea95b490a913..c7bd5633d1eb 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt @@ -6,6 +6,7 @@ Required properties: - "mediatek,mt7622-pwm": found on mt7622 SoC. - "mediatek,mt7623-pwm": found on mt7623 SoC. - "mediatek,mt7628-pwm": found on mt7628 SoC. + - "mediatek,mt7629-pwm", "mediatek,mt7622-pwm": found on mt7629 SoC. - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.txt in this directory for a description of the cell format. -- 2.17.1
[PATCH v7 06/11] pwm: mediatek: update license and switch to SPDX tag
Add SPDX identifiers to pwm-mediatek.c
Update license to GNU General Public License v2.0
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Reviewed-by: Uwe Kleine-König
---
Changes since v6:
Add a Reviewed-by tag
Changes since v5:
- Follow reviewers's comments
The license stuff is a separate change
---
drivers/pwm/pwm-mediatek.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 11f9cc446f14..9a61829766fc 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -1,12 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
/*
- * Mediatek Pulse Width Modulator driver
+ * MediaTek Pulse Width Modulator driver
*
* Copyright (C) 2015 John Crispin
* Copyright (C) 2017 Zhi Mao
*
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
*/
#include
@@ -331,4 +329,4 @@ static struct platform_driver pwm_mediatek_driver = {
module_platform_driver(pwm_mediatek_driver);
MODULE_AUTHOR("John Crispin ");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
--
2.17.1
[PATCH v7 09/11] arm: dts: mt7623: add a property "num-pwms" for PWM
From: Ryder Lee This adds a property "num-pwms" for PWM controller. Signed-off-by: Ryder Lee Signed-off-by: Sam Shih --- arch/arm/boot/dts/mt7623.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi index a79f0b6c3429..208e0d19a575 100644 --- a/arch/arm/boot/dts/mt7623.dtsi +++ b/arch/arm/boot/dts/mt7623.dtsi @@ -452,6 +452,7 @@ < CLK_PERI_PWM5>; clock-names = "top", "main", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5"; + num-pwms = <5>; status = "disabled"; }; -- 2.17.1
[PATCH v7 04/11] pwm: mediatek: allocate the clks array dynamically
Instead of using fixed size of arrays, allocate the memory for them
based on the information we get from the DT.
Also remove the check for num_pwms, due to dynamically allocate pwm
should not cause array index out of bound.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Reviewed-by: Uwe Kleine-König
---
Changes since v6:
- Add a Reviewed-by tag
Changes since v5:
- Follow reviewers's comments
Make the changes of allocate the clks array dynamically as a single patch
Changes since v4:
- Follow reviewers's comments
1. use pc->soc->has_clks to check clocks exist or not.
2. Add error message when probe() unable to get clks
- Fixes bug when SoC is old mips which has no complex clock tree.
if clocks not exist, use the new property from DT to apply period caculation;
otherwise, use clk_get_rate to get clock frequency and apply period caculation.
---
drivers/pwm/pwm-mediatek.c | 84 +++---
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 07e843aeddb1..71bfab7e2e19 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -35,25 +35,6 @@
#define PWM_CLK_DIV_MAX7
-enum {
- MTK_CLK_MAIN = 0,
- MTK_CLK_TOP,
- MTK_CLK_PWM1,
- MTK_CLK_PWM2,
- MTK_CLK_PWM3,
- MTK_CLK_PWM4,
- MTK_CLK_PWM5,
- MTK_CLK_PWM6,
- MTK_CLK_PWM7,
- MTK_CLK_PWM8,
- MTK_CLK_MAX,
-};
-
-static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
- "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5", "pwm6", "pwm7",
- "pwm8"
-};
-
struct mtk_pwm_platform_data {
unsigned int fallback_npwms;
bool pwm45_fixup;
@@ -63,12 +44,17 @@ struct mtk_pwm_platform_data {
* struct mtk_pwm_chip - struct representing PWM chip
* @chip: linux PWM chip representation
* @regs: base address of PWM chip
- * @clks: list of clocks
+ * @clk_top: the top clock generator
+ * @clk_main: the clock used by PWM core
+ * @clk_pwms: the clock used by each PWM channel
+ * @clk_freq: the fix clock frequency of legacy MIPS SoC
*/
struct mtk_pwm_chip {
struct pwm_chip chip;
void __iomem *regs;
- struct clk *clks[MTK_CLK_MAX];
+ struct clk *clk_top;
+ struct clk *clk_main;
+ struct clk **clk_pwms;
const struct mtk_pwm_platform_data *soc;
};
@@ -86,24 +72,24 @@ static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
int ret;
- ret = clk_prepare_enable(pc->clks[MTK_CLK_TOP]);
+ ret = clk_prepare_enable(pc->clk_top);
if (ret < 0)
return ret;
- ret = clk_prepare_enable(pc->clks[MTK_CLK_MAIN]);
+ ret = clk_prepare_enable(pc->clk_main);
if (ret < 0)
goto disable_clk_top;
- ret = clk_prepare_enable(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+ ret = clk_prepare_enable(pc->clk_pwms[pwm->hwpwm]);
if (ret < 0)
goto disable_clk_main;
return 0;
disable_clk_main:
- clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+ clk_disable_unprepare(pc->clk_main);
disable_clk_top:
- clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+ clk_disable_unprepare(pc->clk_top);
return ret;
}
@@ -112,9 +98,9 @@ static void mtk_pwm_clk_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
{
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
- clk_disable_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
- clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
- clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+ clk_disable_unprepare(pc->clk_pwms[pwm->hwpwm]);
+ clk_disable_unprepare(pc->clk_main);
+ clk_disable_unprepare(pc->clk_top);
}
static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
@@ -222,7 +208,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct mtk_pwm_chip *pc;
struct resource *res;
- unsigned int i, npwms;
+ unsigned int npwms;
int ret;
pc = devm_kzalloc(>dev, sizeof(*pc), GFP_KERNEL);
@@ -248,21 +234,35 @@ static int mtk_pwm_probe(struct platform_device *pdev)
}
}
- /* MAIN + TOP + NPWM < MTK_CLK_MAX */
- if ((npwms + 2) > MTK_CLK_MAX) {
- dev_warn(>dev, "number of PWMs is larger than %d\n",
-MTK_CLK_MAX - 2);
- npwms = MTK_CLK_MAX - 2;
+ int i;
+
+ pc->clk_pwms = devm_kcalloc(>dev, npwms,
+ sizeof(*pc->clk_pwms), GFP_KERNEL);
+ if (!pc->clk_pwms)
+ return -ENOMEM;
+
+ pc->clk_top = devm_clk_get(>dev, "top");
+ if (IS_ERR(pc->clk_top)) {
+ dev_err(>dev, "clock: top fail: %ld\n",
+
[PATCH v7 02/11] pwm: mediatek: droping the check for of_device_get_match_data
This patch drop the check for of_device_get_match_data.
Due to the only way call driver probe is compatible match.
The .data pointer which point to the SoC specify data is
directly set by driver, and it should not be NULL in our case.
We can safety remove the check for of_device_get_match_data.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Acked-by: Uwe Kleine-König
---
Used:
https://patchwork.kernel.org/patch/11096905/
Changes since v6:
Add an Acked-by tag
Changes since v4:
Follow reviewer's comments:
Move the changes of droping the check for of_device_get_match_data
returning non-NULL to this patch
---
drivers/pwm/pwm-mediatek.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index e214f4f57107..ebd62629e3fe 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -226,7 +226,6 @@ static const struct pwm_ops mtk_pwm_ops = {
static int mtk_pwm_probe(struct platform_device *pdev)
{
- const struct mtk_pwm_platform_data *data;
struct device_node *np = pdev->dev.of_node;
struct mtk_pwm_chip *pc;
struct resource *res;
@@ -237,10 +236,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
if (!pc)
return -ENOMEM;
- data = of_device_get_match_data(>dev);
- if (data == NULL)
- return -EINVAL;
- pc->soc = data;
+ pc->soc = of_device_get_match_data(>dev);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pc->regs = devm_ioremap_resource(>dev, res);
--
2.17.1
[PATCH v7 01/11] pwm: mediatek: add a property "num-pwms"
From: Ryder Lee
This adds a property "num-pwms" to avoid having an endless
list of compatibles with no differences for the same driver.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
Reviewed-by: Uwe Kleine-König
---
Changes since v6:
Add a Reviewed-by tag
Changes since v5:
Check num-pwms value is no more than MTK_CLK_MAX - 2 (MAIN + TOP)
Changes since v4:
Follow reviewer's comments:
Move the changes of droping the check for of_device_get_match_data returning
non-NULL to next patch
---
drivers/pwm/pwm-mediatek.c | 36
1 file changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index eb6674ce995f..e214f4f57107 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -55,7 +55,7 @@ static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
};
struct mtk_pwm_platform_data {
- unsigned int num_pwms;
+ unsigned int fallback_npwms;
bool pwm45_fixup;
bool has_clks;
};
@@ -227,9 +227,10 @@ static const struct pwm_ops mtk_pwm_ops = {
static int mtk_pwm_probe(struct platform_device *pdev)
{
const struct mtk_pwm_platform_data *data;
+ struct device_node *np = pdev->dev.of_node;
struct mtk_pwm_chip *pc;
struct resource *res;
- unsigned int i;
+ unsigned int i, npwms;
int ret;
pc = devm_kzalloc(>dev, sizeof(*pc), GFP_KERNEL);
@@ -246,7 +247,26 @@ static int mtk_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pc->regs))
return PTR_ERR(pc->regs);
- for (i = 0; i < data->num_pwms + 2 && pc->soc->has_clks; i++) {
+ ret = of_property_read_u32(np, "num-pwms", );
+ if (ret < 0) {
+ /* It's deprecated, we should specify num_pwms via DT now. */
+ if (pc->soc->fallback_npwms) {
+ npwms = pc->soc->fallback_npwms;
+ dev_warn(>dev, "DT is outdated, please update
it\n");
+ } else {
+ dev_err(>dev, "failed to get number of PWMs\n");
+ return ret;
+ }
+ }
+
+ /* MAIN + TOP + NPWM < MTK_CLK_MAX */
+ if ((npwms + 2) > MTK_CLK_MAX) {
+ dev_warn(>dev, "number of PWMs is larger than %d\n",
+MTK_CLK_MAX - 2);
+ npwms = MTK_CLK_MAX - 2;
+ }
+
+ for (i = 0; i < npwms + 2 && pc->soc->has_clks; i++) {
pc->clks[i] = devm_clk_get(>dev, mtk_pwm_clk_name[i]);
if (IS_ERR(pc->clks[i])) {
dev_err(>dev, "clock: %s fail: %ld\n",
@@ -260,7 +280,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
pc->chip.dev = >dev;
pc->chip.ops = _pwm_ops;
pc->chip.base = -1;
- pc->chip.npwm = data->num_pwms;
+ pc->chip.npwm = npwms;
ret = pwmchip_add(>chip);
if (ret < 0) {
@@ -279,25 +299,25 @@ static int mtk_pwm_remove(struct platform_device *pdev)
}
static const struct mtk_pwm_platform_data mt2712_pwm_data = {
- .num_pwms = 8,
+ .fallback_npwms = 8,
.pwm45_fixup = false,
.has_clks = true,
};
static const struct mtk_pwm_platform_data mt7622_pwm_data = {
- .num_pwms = 6,
+ .fallback_npwms = 6,
.pwm45_fixup = false,
.has_clks = true,
};
static const struct mtk_pwm_platform_data mt7623_pwm_data = {
- .num_pwms = 5,
+ .fallback_npwms = 5,
.pwm45_fixup = true,
.has_clks = true,
};
static const struct mtk_pwm_platform_data mt7628_pwm_data = {
- .num_pwms = 4,
+ .fallback_npwms = 4,
.pwm45_fixup = true,
.has_clks = false,
};
--
2.17.1
[RESEND, PATCH v7 0/11] Add mt7629 and fix mt7628 pwm
Changes since v7: 1. PATCH v7 10/11: Add a missed Reviewed-by tag Changes since v6: 1. Due to we can use fixed-clock in DT We removed has_clks and fixed-clock properties Changes since v5: - Follow reviewer's comments: 1. the license stuff is a separate change 2. split fix mt7628 pwm into a single patch 3. to ensure to not use mtk_pwm_clk_name[10] (After dynamic allocate clock array patch, this is no need to check) 4. Use clock-frequency property to replace the use of has_clks Changes since v4: - Follow reviewer's comments (v3: pwm: mediatek: add a property "num-pwms") Move the changes of droping the check for of_device_get_match_data returning non-NULL to next patch - Follow reviewers's comments (v3: pwm: mediatek: allocate the clks array dynamically) 1. use pc->soc->has_clks to check clocks exist or not. 2. Add error message when probe() unable to get clks - Fixes bug when SoC is old mips which has no complex clock tree. if clocks not exist, use the new property from DT to apply period calculation; otherwise, use clk_get_rate to get clock frequency and apply period calculation. Changes since v3: - add a new property "clock-frequency" and fix mt7628 pwm - add mt7629 pwm support Changes since v2: - use num-pwms instead of mediatek,num-pwms. - rename the member from num_pwms to fallback_num_pwms to make it more obvious that it doesn't represent the actually used value. - add a dev_warn and a expressive comment to help other developers to not start adding num_pwms in the compatible_data. Changes since v1: - add some checks for backwards compatibility. Ryder Lee (5): pwm: mediatek: add a property "num-pwms" dt-bindings: pwm: add a property "num-pwms" arm64: dts: mt7622: add a property "num-pwms" for PWM arm: dts: mt7623: add a property "num-pwms" for PWM dt-bindings: pwm: update bindings for MT7629 SoC Sam Shih (6): pwm: mediatek: droping the check for of_device_get_match_data pwm: mediatek: remove a property "has-clks" pwm: mediatek: allocate the clks array dynamically pwm: mediatek: use pwm_mediatek as common prefix pwm: mediatek: update license and switch to SPDX tag arm: dts: mediatek: add mt7629 pwm support .../devicetree/bindings/pwm/pwm-mediatek.txt | 8 +- arch/arm/boot/dts/mt7623.dtsi | 1 + arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 + drivers/pwm/pwm-mediatek.c| 245 +- arch/arm/boot/dts/mt7629.dtsi | 16 5 files changed, 149 insertions(+), 122 deletions(-) -- 2.17.1
[PATCH] mm/vmalloc: move 'area->pages' after if statement
If !area->pages statement is true where memory allocation fails,
area is freed.
In this case 'area->pages = pages' should not executed.
So move 'area->pages = pages' after if statement.
Signed-off-by: Austin Kim
---
mm/vmalloc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index b810103..af93ba6 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -2416,13 +2416,15 @@ static void *__vmalloc_area_node(struct vm_struct
*area, gfp_t gfp_mask,
} else {
pages = kmalloc_node(array_size, nested_gfp, node);
}
- area->pages = pages;
- if (!area->pages) {
+
+ if (!pages) {
remove_vm_area(area->addr);
kfree(area);
return NULL;
}
+ area->pages = pages;
+
for (i = 0; i < area->nr_pages; i++) {
struct page *page;
--
2.6.2
[PATCH v7 03/11] pwm: mediatek: remove a property "has-clks"
We can use fixed-clock to repair mt7628 pwm during configure from
userspace. The SoC is legacy MIPS and has no complex clock tree.
Due to we can get clock frequency for period calculation from DT
fixed-clock, so we can remove has-clock property, and directly
use devm_clk_get and clk_get_rate.
Signed-off-by: Ryder Lee
Signed-off-by: Sam Shih
---
Changes since v6:
Based on fixed-clock in DT, we can remove has-clks property
Changes since v5:
1. Follow reviewer's comments
Make the changes of fix mt7628 pwm as a single patch
Changes since v4:
- Follow reviewers's comments
1. use pc->soc->has_clks to check clocks exist or not.
2. Add error message when probe() unable to get clks
- Fixes bug when SoC is old mips which has no complex clock tree.
if clocks not exist, use the new property from DT to apply period caculation;
otherwise, use clk_get_rate to get clock frequency and apply period caculation.
---
drivers/pwm/pwm-mediatek.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index ebd62629e3fe..07e843aeddb1 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -57,7 +57,6 @@ static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
struct mtk_pwm_platform_data {
unsigned int fallback_npwms;
bool pwm45_fixup;
- bool has_clks;
};
/**
@@ -87,9 +86,6 @@ static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct
pwm_device *pwm)
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
int ret;
- if (!pc->soc->has_clks)
- return 0;
-
ret = clk_prepare_enable(pc->clks[MTK_CLK_TOP]);
if (ret < 0)
return ret;
@@ -116,9 +112,6 @@ static void mtk_pwm_clk_disable(struct pwm_chip *chip,
struct pwm_device *pwm)
{
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
- if (!pc->soc->has_clks)
- return;
-
clk_disable_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
@@ -262,11 +255,13 @@ static int mtk_pwm_probe(struct platform_device *pdev)
npwms = MTK_CLK_MAX - 2;
}
- for (i = 0; i < npwms + 2 && pc->soc->has_clks; i++) {
- pc->clks[i] = devm_clk_get(>dev, mtk_pwm_clk_name[i]);
+ for (i = 0; i < npwms + 2 ; i++) {
+ pc->clks[i] = devm_clk_get(>dev,
+ mtk_pwm_clk_name[i]);
if (IS_ERR(pc->clks[i])) {
dev_err(>dev, "clock: %s fail: %ld\n",
- mtk_pwm_clk_name[i], PTR_ERR(pc->clks[i]));
+ mtk_pwm_clk_name[i],
+ PTR_ERR(pc->clks[i]));
return PTR_ERR(pc->clks[i]);
}
}
@@ -297,25 +292,21 @@ static int mtk_pwm_remove(struct platform_device *pdev)
static const struct mtk_pwm_platform_data mt2712_pwm_data = {
.fallback_npwms = 8,
.pwm45_fixup = false,
- .has_clks = true,
};
static const struct mtk_pwm_platform_data mt7622_pwm_data = {
.fallback_npwms = 6,
.pwm45_fixup = false,
- .has_clks = true,
};
static const struct mtk_pwm_platform_data mt7623_pwm_data = {
.fallback_npwms = 5,
.pwm45_fixup = true,
- .has_clks = true,
};
static const struct mtk_pwm_platform_data mt7628_pwm_data = {
.fallback_npwms = 4,
.pwm45_fixup = true,
- .has_clks = false,
};
static const struct of_device_id mtk_pwm_of_match[] = {
--
2.17.1
Re: [PATCH 1/9] perf/core: Add PERF_RECORD_CGROUP event
Hi Tejun,
On Wed, Aug 28, 2019 at 11:48 PM Tejun Heo wrote:
>
> Hello, Namhyung.
>
> On Wed, Aug 28, 2019 at 04:31:22PM +0900, Namhyung Kim wrote:
> > + * struct {
> > + * struct perf_event_headerheader;
> > + * u64 ino;
> > + * u64 path_len;
> > + * charpath[];
>
> ino and path aren't great identifers for cgroups because both can get
> recycled pretty quickly. Can you please take a look at
> KERNFS_ROOT_SUPPORT_EXPORTOP? That's the fhandle that cgroup uses,
> currently the standard ino+gen which isn't ideal but good enough.
> Another benefit is that the path can also be resolved efficiently from
> userspace given the handle.
Thanks for the info, I'll take a look at it.
Namhyung
[RESEND PATCH v7 0/11] Add mt7629 and fix mt7628 pwm
Changes since v7: 1. PATCH v7 10/100: Add a missed Reviewed-by tag back Changes since v6: 1. Due to we can use fixed-clock in DT We removed has_clks and fixed-clock properties Changes since v5: - Follow reviewer's comments: 1. the license stuff is a separate change 2. split fix mt7628 pwm into a single patch 3. to ensure to not use mtk_pwm_clk_name[10] (After dynamic allocate clock array patch, this is no need to check) 4. Use clock-frequency property to replace the use of has_clks Changes since v4: - Follow reviewer's comments (v3: pwm: mediatek: add a property "num-pwms") Move the changes of droping the check for of_device_get_match_data returning non-NULL to next patch - Follow reviewers's comments (v3: pwm: mediatek: allocate the clks array dynamically) 1. use pc->soc->has_clks to check clocks exist or not. 2. Add error message when probe() unable to get clks - Fixes bug when SoC is old mips which has no complex clock tree. if clocks not exist, use the new property from DT to apply period calculation; otherwise, use clk_get_rate to get clock frequency and apply period calculation. Changes since v3: - add a new property "clock-frequency" and fix mt7628 pwm - add mt7629 pwm support Changes since v2: - use num-pwms instead of mediatek,num-pwms. - rename the member from num_pwms to fallback_num_pwms to make it more obvious that it doesn't represent the actually used value. - add a dev_warn and a expressive comment to help other developers to not start adding num_pwms in the compatible_data. Changes since v1: - add some checks for backwards compatibility. Ryder Lee (5): pwm: mediatek: add a property "num-pwms" dt-bindings: pwm: add a property "num-pwms" arm64: dts: mt7622: add a property "num-pwms" for PWM arm: dts: mt7623: add a property "num-pwms" for PWM dt-bindings: pwm: update bindings for MT7629 SoC Sam Shih (6): pwm: mediatek: droping the check for of_device_get_match_data pwm: mediatek: remove a property "has-clks" pwm: mediatek: allocate the clks array dynamically pwm: mediatek: use pwm_mediatek as common prefix pwm: mediatek: update license and switch to SPDX tag arm: dts: mediatek: add mt7629 pwm support .../devicetree/bindings/pwm/pwm-mediatek.txt | 8 +- arch/arm/boot/dts/mt7623.dtsi | 1 + arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 + drivers/pwm/pwm-mediatek.c| 245 +- arch/arm/boot/dts/mt7629.dtsi | 16 5 files changed, 149 insertions(+), 122 deletions(-) -- 2.17.1
[RESEND PATCH v7 0/11] Add mt7629 and fix mt7628 pwm
Changes since v6: 1. Due to we can use fixed-clock in DT We removed has_clks and fixed-clock properties Changes since v5: - Follow reviewer's comments: 1. the license stuff is a separate change 2. split fix mt7628 pwm into a single patch 3. to ensure to not use mtk_pwm_clk_name[10] (After dynamic allocate clock array patch, this is no need to check) 4. Use clock-frequency property to replace the use of has_clks Changes since v4: - Follow reviewer's comments (v3: pwm: mediatek: add a property "num-pwms") Move the changes of droping the check for of_device_get_match_data returning non-NULL to next patch - Follow reviewers's comments (v3: pwm: mediatek: allocate the clks array dynamically) 1. use pc->soc->has_clks to check clocks exist or not. 2. Add error message when probe() unable to get clks - Fixes bug when SoC is old mips which has no complex clock tree. if clocks not exist, use the new property from DT to apply period calculation; otherwise, use clk_get_rate to get clock frequency and apply period calculation. Changes since v3: - add a new property "clock-frequency" and fix mt7628 pwm - add mt7629 pwm support Changes since v2: - use num-pwms instead of mediatek,num-pwms. - rename the member from num_pwms to fallback_num_pwms to make it more obvious that it doesn't represent the actually used value. - add a dev_warn and a expressive comment to help other developers to not start adding num_pwms in the compatible_data. Changes since v1: - add some checks for backwards compatibility. Ryder Lee (5): pwm: mediatek: add a property "num-pwms" dt-bindings: pwm: add a property "num-pwms" arm64: dts: mt7622: add a property "num-pwms" for PWM arm: dts: mt7623: add a property "num-pwms" for PWM dt-bindings: pwm: update bindings for MT7629 SoC Sam Shih (6): pwm: mediatek: droping the check for of_device_get_match_data pwm: mediatek: remove a property "has-clks" pwm: mediatek: allocate the clks array dynamically pwm: mediatek: use pwm_mediatek as common prefix pwm: mediatek: update license and switch to SPDX tag arm: dts: mediatek: add mt7629 pwm support .../devicetree/bindings/pwm/pwm-mediatek.txt | 8 +- arch/arm/boot/dts/mt7623.dtsi | 1 + arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 + drivers/pwm/pwm-mediatek.c| 245 +- arch/arm/boot/dts/mt7629.dtsi | 16 5 files changed, 149 insertions(+), 122 deletions(-) -- 2.17.1
[PATCH v7 0/11] Add mt7629 and fix mt7628 pwm
Changes since v6: 1. Due to we can use fixed-clock in DT We removed has_clks and fixed-clock properties Changes since v5: - Follow reviewer's comments: 1. the license stuff is a separate change 2. split fix mt7628 pwm into a single patch 3. to ensure to not use mtk_pwm_clk_name[10] (After dynamic allocate clock array patch, this is no need to check) 4. Use clock-frequency property to replace the use of has_clks Changes since v4: - Follow reviewer's comments (v3: pwm: mediatek: add a property "num-pwms") Move the changes of droping the check for of_device_get_match_data returning non-NULL to next patch - Follow reviewers's comments (v3: pwm: mediatek: allocate the clks array dynamically) 1. use pc->soc->has_clks to check clocks exist or not. 2. Add error message when probe() unable to get clks - Fixes bug when SoC is old mips which has no complex clock tree. if clocks not exist, use the new property from DT to apply period calculation; otherwise, use clk_get_rate to get clock frequency and apply period calculation. Changes since v3: - add a new property "clock-frequency" and fix mt7628 pwm - add mt7629 pwm support Changes since v2: - use num-pwms instead of mediatek,num-pwms. - rename the member from num_pwms to fallback_num_pwms to make it more obvious that it doesn't represent the actually used value. - add a dev_warn and a expressive comment to help other developers to not start adding num_pwms in the compatible_data. Changes since v1: - add some checks for backwards compatibility. Ryder Lee (5): pwm: mediatek: add a property "num-pwms" dt-bindings: pwm: add a property "num-pwms" arm64: dts: mt7622: add a property "num-pwms" for PWM arm: dts: mt7623: add a property "num-pwms" for PWM dt-bindings: pwm: update bindings for MT7629 SoC Sam Shih (6): pwm: mediatek: droping the check for of_device_get_match_data pwm: mediatek: remove a property "has-clks" pwm: mediatek: allocate the clks array dynamically pwm: mediatek: use pwm_mediatek as common prefix pwm: mediatek: update license and switch to SPDX tag arm: dts: mediatek: add mt7629 pwm support .../devicetree/bindings/pwm/pwm-mediatek.txt | 8 +- arch/arm/boot/dts/mt7623.dtsi | 1 + arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 + drivers/pwm/pwm-mediatek.c| 245 +- arch/arm/boot/dts/mt7629.dtsi | 16 5 files changed, 149 insertions(+), 122 deletions(-) -- 2.17.1
Re: [PATCH] virtio: Change typecasts in vring_init()
On 2019/8/27 下午11:20, Matej Genci wrote:
> Compilers such as g++ 7.3 complain about assigning void* variable to
> a non-void* variable (like struct pointers) and pointer arithmetics
> on void*.
>
> Signed-off-by: Matej Genci
> ---
> include/uapi/linux/virtio_ring.h | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/virtio_ring.h
> b/include/uapi/linux/virtio_ring.h
> index 4c4e24c291a5..2c339b9e2923 100644
> --- a/include/uapi/linux/virtio_ring.h
> +++ b/include/uapi/linux/virtio_ring.h
> @@ -168,10 +168,11 @@ static inline void vring_init(struct vring *vr,
> unsigned int num, void *p,
> unsigned long align)
> {
> vr->num = num;
> - vr->desc = p;
> - vr->avail = p + num*sizeof(struct vring_desc);
> - vr->used = (void *)(((uintptr_t)>avail->ring[num] +
> sizeof(__virtio16)
> - + align-1) & ~(align - 1));
> + vr->desc = (struct vring_desc *)p;
> + vr->avail = (struct vring_avail *)((uintptr_t)p
> + + num*sizeof(struct vring_desc));
It's better to let the code pass checkpath.pl here.
Other looks good.
Thanks
> + vr->used = (struct vring_used *)(((uintptr_t)>avail->ring[num]
> + + sizeof(__virtio16) + align-1) & ~(align - 1));
> }
>
> static inline unsigned vring_size(unsigned int num, unsigned long align)
Re: [PATCH 1/9] perf/core: Add PERF_RECORD_CGROUP event
Hi Peter, On Wed, Aug 28, 2019 at 6:45 PM Peter Zijlstra wrote: > > On Wed, Aug 28, 2019 at 04:31:22PM +0900, Namhyung Kim wrote: > > To support cgroup tracking, add CGROUP event to save a link between > > cgroup path and inode number. The attr.cgroup bit was also added to > > enable cgroup tracking from userspace. > > > > This event will be generated when a new cgroup becomes active. > > Userspace might need to synthesize those events for existing cgroups. > > > > As aux_output change is also going on, I just added the bit here as > > well to remove possible conflicts later. > > Why do we want this? I saw below [1] and thought you have the patch introduced aux_output and it's gonna to be merged soon. Also the tooling patches are already in the acme/perf/core so I just wanted to avoid conflicts. Anyway, I'm ok with changing it. Will remove in v2. Thanks Namhyung [1] https://lkml.org/lkml/2019/8/6/586
Re: [RFD] x86/tsc: Loosen the requirements for watchdog - (was x86/hpet: Disable HPET on Intel Coffe Lake)
Hi Thomas, On Fri, Aug 30, 2019 at 5:38 AM Thomas Gleixner wrote: > So if we have to disable the HPET on Kaby Lake alltogether unless Intel > comes up with the clever fix, i.e. poking at the right registers, then I > think we should also lift the TSC watchdog restrictions on these machines > if they are single socket, which they are as the affected CPUs so far are > mobile and client types. > > Also given the fact that we get more and more 'reduced' hardware exposed > via ACPI and we already dealt with quite some fallout with various related > issues due to that, I fear we need to bite this bullet anyway anytime soon. Thanks for the explanation here! My experience in this area is basically limited to the clock-related issues that I've sent your way recently, so I don't have deep wisdom to draw upon, but what you wrote here makes sense to me. If you can outline a testing procedure, we can test upcoming patches on Coffee Lake and Kaby Lake consumer laptops. Thanks, Daniel
[PATCH net-next, 1/2] hv_netvsc: Allow scatter-gather feature to be tunable
In a previous patch, the NETIF_F_SG was missing after the code changes.
That caused the SG feature to be "fixed". This patch includes it into
hw_features, so it is tunable again.
Fixes: 23312a3be999 ("netvsc: negotiate checksum and segmentation parameters")
Signed-off-by: Haiyang Zhang
---
drivers/net/hyperv/hyperv_net.h | 2 +-
drivers/net/hyperv/netvsc_drv.c | 4 ++--
drivers/net/hyperv/rndis_filter.c | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index ecc9af0..670ef68 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -822,7 +822,7 @@ struct nvsp_message {
#define NETVSC_SUPPORTED_HW_FEATURES (NETIF_F_RXCSUM | NETIF_F_IP_CSUM | \
NETIF_F_TSO | NETIF_F_IPV6_CSUM | \
- NETIF_F_TSO6 | NETIF_F_LRO)
+ NETIF_F_TSO6 | NETIF_F_LRO | NETIF_F_SG)
#define VRSS_SEND_TAB_SIZE 16 /* must be power of 2 */
#define VRSS_CHANNEL_MAX 64
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 0a6cd2f..1f1192e 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -2313,8 +2313,8 @@ static int netvsc_probe(struct hv_device *dev,
/* hw_features computed in rndis_netdev_set_hwcaps() */
net->features = net->hw_features |
- NETIF_F_HIGHDMA | NETIF_F_SG |
- NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX;
+ NETIF_F_HIGHDMA | NETIF_F_HW_VLAN_CTAG_TX |
+ NETIF_F_HW_VLAN_CTAG_RX;
net->vlan_features = net->features;
netdev_lockdep_set_classes(net);
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 317dbe9..abaf815 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1207,6 +1207,7 @@ static int rndis_netdev_set_hwcaps(struct rndis_device
*rndis_device,
/* Compute tx offload settings based on hw capabilities */
net->hw_features |= NETIF_F_RXCSUM;
+ net->hw_features |= NETIF_F_SG;
if ((hwcaps.csum.ip4_txcsum & NDIS_TXCSUM_ALL_TCP4) ==
NDIS_TXCSUM_ALL_TCP4) {
/* Can checksum TCP */
--
1.8.3.1
[PATCH net-next, 0/2] Enable sg as tunable, sync offload settings to VF NIC
This patch set fixes an issue in SG tuning, and sync offload settings from synthetic NIC to VF NIC. Haiyang Zhang (2): hv_netvsc: hv_netvsc: Allow scatter-gather feature to be tunable hv_netvsc: Sync offloading features to VF NIC drivers/net/hyperv/hyperv_net.h | 2 +- drivers/net/hyperv/netvsc_drv.c | 26 ++ drivers/net/hyperv/rndis_filter.c | 1 + 3 files changed, 24 insertions(+), 5 deletions(-) -- 1.8.3.1
[PATCH net-next, 2/2] hv_netvsc: Sync offloading features to VF NIC
VF NIC may go down then come up during host servicing events. This causes the VF NIC offloading feature settings to roll back to the defaults. This patch can synchronize features from synthetic NIC to the VF NIC during ndo_set_features (ethtool -K), and netvsc_register_vf when VF comes back after host events. Signed-off-by: Haiyang Zhang Cc: Mark Bloch --- drivers/net/hyperv/netvsc_drv.c | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index 1f1192e..39dddcd 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -1785,13 +1785,15 @@ static int netvsc_set_features(struct net_device *ndev, netdev_features_t change = features ^ ndev->features; struct net_device_context *ndevctx = netdev_priv(ndev); struct netvsc_device *nvdev = rtnl_dereference(ndevctx->nvdev); + struct net_device *vf_netdev = rtnl_dereference(ndevctx->vf_netdev); struct ndis_offload_params offloads; + int ret = 0; if (!nvdev || nvdev->destroy) return -ENODEV; if (!(change & NETIF_F_LRO)) - return 0; + goto syncvf; memset(, 0, sizeof(struct ndis_offload_params)); @@ -1803,7 +1805,19 @@ static int netvsc_set_features(struct net_device *ndev, offloads.rsc_ip_v6 = NDIS_OFFLOAD_PARAMETERS_RSC_DISABLED; } - return rndis_filter_set_offload_params(ndev, nvdev, ); + ret = rndis_filter_set_offload_params(ndev, nvdev, ); + + if (ret) + features ^= NETIF_F_LRO; + +syncvf: + if (!vf_netdev) + return ret; + + vf_netdev->wanted_features = features; + netdev_update_features(vf_netdev); + + return ret; } static u32 netvsc_get_msglevel(struct net_device *ndev) @@ -2181,6 +2195,10 @@ static int netvsc_register_vf(struct net_device *vf_netdev) dev_hold(vf_netdev); rcu_assign_pointer(net_device_ctx->vf_netdev, vf_netdev); + + vf_netdev->wanted_features = ndev->features; + netdev_update_features(vf_netdev); + return NOTIFY_OK; } -- 1.8.3.1
[PATCH] compiler: enable CONFIG_OPTIMIZE_INLINING forcibly
Commit 9012d011660e ("compiler: allow all arches to enable
CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
this option. A couple of build errors were reported by randconfig,
but all of them have been ironed out.
Towards the goal of removing CONFIG_OPTIMIZE_INLINING entirely
(and it will simplify the 'inline' macro in compiler_types.h),
this commit changes it to always-on option. Going forward, the
compiler will always be allowed to not inline functions marked
'inline'.
This is not a problem for x86 since it has been long used by
arch/x86/configs/{x86_64,i386}_defconfig.
I am keeping the config option just in case any problem crops up for
other architectures.
The code clean-up will be done after confirming this is solid.
Signed-off-by: Masahiro Yamada
---
lib/Kconfig.debug | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5960e2980a8a..e25493811df8 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -327,7 +327,7 @@ config HEADERS_CHECK
relevant for userspace, say 'Y'.
config OPTIMIZE_INLINING
- bool "Allow compiler to uninline functions marked 'inline'"
+ def_bool y
help
This option determines if the kernel forces gcc to inline the
functions
developers have marked 'inline'. Doing so takes away freedom from gcc
to
@@ -338,8 +338,6 @@ config OPTIMIZE_INLINING
decision will become the default in the future. Until then this option
is there to test gcc for this.
- If unsure, say N.
-
config DEBUG_SECTION_MISMATCH
bool "Enable full Section mismatch analysis"
help
--
2.17.1
Re: [PATCH 2/2] vhost/test: fix build for vhost test
On 2019/8/28 下午1:37, Tiwei Bie wrote:
> Since vhost_exceeds_weight() was introduced, callers need to specify
> the packet weight and byte weight in vhost_dev_init(). Note that, the
> packet weight isn't counted in this patch to keep the original behavior
> unchanged.
>
> Fixes: e82b9b0727ff ("vhost: introduce vhost_exceeds_weight()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Tiwei Bie
> ---
> drivers/vhost/test.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
> index ac4f762c4f65..7804869c6a31 100644
> --- a/drivers/vhost/test.c
> +++ b/drivers/vhost/test.c
> @@ -22,6 +22,12 @@
> * Using this limit prevents one virtqueue from starving others. */
> #define VHOST_TEST_WEIGHT 0x8
>
> +/* Max number of packets transferred before requeueing the job.
> + * Using this limit prevents one virtqueue from starving others with
> + * pkts.
> + */
> +#define VHOST_TEST_PKT_WEIGHT 256
> +
> enum {
> VHOST_TEST_VQ = 0,
> VHOST_TEST_VQ_MAX = 1,
> @@ -80,10 +86,8 @@ static void handle_vq(struct vhost_test *n)
> }
> vhost_add_used_and_signal(>dev, vq, head, 0);
> total_len += len;
> - if (unlikely(total_len >= VHOST_TEST_WEIGHT)) {
> - vhost_poll_queue(>poll);
> + if (unlikely(vhost_exceeds_weight(vq, 0, total_len)))
> break;
> - }
> }
>
> mutex_unlock(>mutex);
> @@ -115,7 +119,8 @@ static int vhost_test_open(struct inode *inode, struct
> file *f)
> dev = >dev;
> vqs[VHOST_TEST_VQ] = >vqs[VHOST_TEST_VQ];
> n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
> - vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV);
> + vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV,
> +VHOST_TEST_PKT_WEIGHT, VHOST_TEST_WEIGHT);
>
> f->private_data = n;
>
Acked-by: Jason Wang
Re: [PATCH 1/2] vhost/test: fix build for vhost test
On 2019/8/28 下午1:36, Tiwei Bie wrote:
> Since below commit, callers need to specify the iov_limit in
> vhost_dev_init() explicitly.
>
> Fixes: b46a0bf78ad7 ("vhost: fix OOB in get_rx_bufs()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Tiwei Bie
> ---
> drivers/vhost/test.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/test.c b/drivers/vhost/test.c
> index 9e90e969af55..ac4f762c4f65 100644
> --- a/drivers/vhost/test.c
> +++ b/drivers/vhost/test.c
> @@ -115,7 +115,7 @@ static int vhost_test_open(struct inode *inode, struct
> file *f)
> dev = >dev;
> vqs[VHOST_TEST_VQ] = >vqs[VHOST_TEST_VQ];
> n->vqs[VHOST_TEST_VQ].handle_kick = handle_vq_kick;
> - vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX);
> + vhost_dev_init(dev, vqs, VHOST_TEST_VQ_MAX, UIO_MAXIOV);
>
> f->private_data = n;
>
Acked-by: Jason Wang
pEpkey.asc
Description: application/pgp-keys
Re: [ext4] [confidence: ] 2f7f60cf9f: WARNING:at_lib/list_debug.c:#__list_add_valid
Hi Oliver,
On 2019/8/30 11:11, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 2f7f60cf9fbcd80200edee8c29b9b35681c63c3e ("[PATCH] ext4: change the
> type of ext4 cache stats to percpu_counter to improve performance")
Thanks for the report.
This patch has been dropped and the updated patch has been sent to community.
https://lkml.org/lkml/2019/8/28/286
Thanks,
Shaokun
> url:
> https://github.com/0day-ci/linux/commits/Shaokun-Zhang/ext4-change-the-type-of-ext4-cache-stats-to-percpu_counter-to-improve-performance/20190825-123505
>
>
> in testcase: ltp
> with following parameters:
>
> test: quickhit
>
> test-description: The LTP testsuite contains a collection of tools for
> testing the Linux kernel and related features.
> test-url: http://linux-test-project.github.io/
>
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
> +-+++
> | | e67095fd2f |
> 2f7f60cf9f |
> +-+++
> | boot_successes | 25 | 12
> |
> | boot_failures | 0 | 17
> |
> | WARNING:at_lib/list_debug.c:#__list_add_valid | 0 | 17
> |
> | RIP:__list_add_valid| 0 | 17
> |
> | WARNING:at_lib/list_debug.c:#__list_del_entry_valid | 0 | 3
> |
> | RIP:__list_del_entry_valid | 0 | 3
> |
> +-+++
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
>
>
> [ 62.458944] WARNING: CPU: 1 PID: 2533 at lib/list_debug.c:25
> __list_add_valid+0x36/0x70
> [ 62.460445] Modules linked in: fuse vfat fat btrfs xor zstd_decompress
> zstd_compress raid6_pq xfs libcrc32c ext4 mbcache jbd2 loop intel_rapl_msr
> intel_rapl_common crct10dif_pclmul crc32_pclmul crc32c_intel
> ghash_clmulni_intel sr_mod bochs_drm cdrom drm_vram_helper sg ttm ppdev
> drm_kms_helper ata_generic pata_acpi syscopyarea sysfillrect sysimgblt
> snd_pcm fb_sys_fops drm snd_timer snd aesni_intel crypto_simd cryptd
> glue_helper soundcore pcspkr joydev serio_raw ata_piix libata i2c_piix4
> floppy parport_pc parport ip_tables
> [ 62.468134] CPU: 1 PID: 2533 Comm: fsync01 Not tainted
> 5.3.0-rc5-00283-g2f7f60cf9fbcd #1
> [ 62.469707] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [ 62.471293] RIP: 0010:__list_add_valid+0x36/0x70
> [ 62.472332] Code: 48 8b 10 4c 39 c2 75 27 48 39 f8 74 39 48 39 fa 74 34 b8
> 01 00 00 00 c3 48 89 d1 48 c7 c7 28 ce d2 82 48 89 c2 e8 ba 47 c2 ff <0f> 0b
> 31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 a0 ce d2 82 e8 a3 47 c2
> [ 62.475779] RSP: 0018:b815c0497cc0 EFLAGS: 00010082
> [ 62.477028] RAX: RBX: 9ab02e61c418 RCX:
> 0006
> [ 62.478540] RDX: 0007 RSI: 0086 RDI:
> 9ab0bfd17770
> [ 62.480096] RBP: 9ab02e61c428 R08: 0510 R09:
> 00aa
> [ 62.481707] R10: 0007 R11: 9ab097f6b8b0 R12:
> 9ab02e61c450
> [ 62.483231] R13: 8314ce80 R14: 0202 R15:
>
> [ 62.484861] FS: 7f8b236e0500() GS:9ab0bfd0()
> knlGS:
> [ 62.486641] CS: 0010 DS: ES: CR0: 80050033
> [ 62.488103] CR2: 55b3435d0a60 CR3: 00019b8d2000 CR4:
> 000406e0
> [ 62.489798] DR0: DR1: DR2:
>
> [ 62.491343] DR3: DR6: fffe0ff0 DR7:
> 0400
> [ 62.492925] Call Trace:
> [ 62.494524] __percpu_counter_init+0x64/0xa0
> [ 62.495780] ext4_es_register_shrinker+0x53/0x130 [ext4]
> [ 62.497235] ext4_fill_super+0x1cd4/0x3ad0 [ext4]
> [ 62.498521] ? ext4_calculate_overhead+0x4a0/0x4a0 [ext4]
> [ 62.499946] mount_bdev+0x173/0x1b0
> [ 62.501120] legacy_get_tree+0x27/0x40
> [ 62.502315] vfs_get_tree+0x25/0xf0
> [ 62.503421] do_mount+0x691/0x9c0
> [ 62.504516] ? memdup_user+0x4b/0x70
> [ 62.505793] ksys_mount+0x80/0xd0
> [ 62.506858] __x64_sys_mount+0x21/0x30
> [ 62.507979] do_syscall_64+0x5b/0x1f0
> [ 62.509194] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 62.510491] RIP: 0033:0x7f8b2320f48a
> [ 62.511589] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e
> 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 8b 0d de f9 2a 00 f7 d8 64 89 01 48
> [ 62.515429] RSP: 002b:7ffdcb5920e8 EFLAGS: 0206
Re: [PATCH v4 1/2] drivers: hv: vmbus: Introduce latency testing
Hi Branden, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc6 next-20190829] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Branden-Bonaby/drivers-hv-vmbus-Introduce-latency-testing/20190830-032123 config: i386-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.4.0-11) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): >> ERROR: "hv_debug_add_dev_dir" [drivers/hv/hv_vmbus.ko] undefined! >> ERROR: "hv_debug_init" [drivers/hv/hv_vmbus.ko] undefined! >> ERROR: "hv_debug_delay_test" [drivers/hv/hv_vmbus.ko] undefined! >> ERROR: "hv_debug_rm_all_dir" [drivers/hv/hv_vmbus.ko] undefined! >> ERROR: "hv_debug_rm_dev_dir" [drivers/hv/hv_vmbus.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] powerpc: Replace GPL boilerplate with SPDX identifiers
On Wed, 2019-08-28 at 08:07 +0200, Thomas Huth wrote: > The FSF does not reside in "675 Mass Ave, Cambridge" anymore... > let's simply use proper SPDX identifiers instead. > > Signed-off-by: Thomas Huth Acked-by: Russell Currey
linux-next: build failure after merge of the pci tree
Hi all,
After merging the pci tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/pci/controller/dwc/pcie-tegra194.c:24:10: fatal error:
linux/pci-aspm.h: No such file or directory
24 | #include
| ^~
Caused by commit
81564976b1a9 ("PCI: tegra: Add Tegra194 PCIe support")
I have reverted that commit for todat.
--
Cheers,
Stephen Rothwell
pgpTO6q3ysoHS.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 2/2] reset: Reset controller driver for Intel LGM SoC
Hi Martin,
On 8/30/2019 5:40 AM, Martin Blumenstingl wrote:
Hi,
On Thu, Aug 29, 2019 at 4:51 AM Chuan Hua, Lei
wrote:
I'm not surprised that we got some of the IP block layout for the
VRX200 RCU "wrong" - all "documentation" we have is the old Lantiq UGW
(BSP).
with proper documentation (as in a "public datasheet for the SoC") it
would be easy to spot these mistakes (at least I assume that the
quality of the Infineon / Lantiq datasheets is excellent).
back to reset-intel-syscon:
assigning only one job to the RCU hardware is a good idea (in my opinion).
that brings up a question: why do we need the "syscon" compatible for
the RCU node?
this is typically used when registers are accessed by another IP block
and the other driver has to access these registers as well. does this
mean that there's more hidden in the RCU registers?
As I mentioned, some other misc registers are put into RCU even they
don't belong to reset functions.
OK, just be aware that there are also rules for syscon compatible
drivers, see for example: [0]
if Rob (dt-bindings maintainer) is happy with the documentation in
patch 1 then I'm fine with it as well.
for my own education I would appreciate if you could describe these
"other misc registers" with a few sentences (I assume that this can
also help Rob)
For LGM, RCU is clean. There would be no MISC register after software's
feedback. These misc registers will be moved to chiptop/misc
groups(implemented by syscon). For legacy SoC, we do have a lot MISC
registers for different SoCs.
[...]
4. Code not optimized and intel internal review not assessed.
insights from you (like the issue with the reset callback) are very
valuable - this shows that we should focus on having one driver.
Based on the above findings, I would suggest reset-lantiq.c to move to
reset-intel-syscon.c
my concern with having two separate drivers is that it will be hard to
migrate from reset-lantiq to the "optimized" reset-intel-syscon
driver.
I don't have access to the datasheets for the any Lantiq/Intel SoC
(VRX200 and even older).
so debugging issues after switching from one driver to another is
tedious because I cannot tell which part of the driver is causing a
problem (it's either "all code from driver A" vs "all code from driver
B", meaning it's hard to narrow it down).
with separate commits/patches that are improving the reset-lantiq
driver I can do git bisect to find the cause of a problem on the older
SoCs (VRX200 for example)
Our internal version supports XRX350/XRX500/PRX300(MIPS based) and
latest Lighting Mountain(X86 based). Migration to reset-intel-syscon.c
should be straight forward.
what about the _reset callback on the XRX350/XRX500/PRX300 SoCs - do
they only use level resets (_assert and _deassert) or are some reset
lines using reset pulses (_reset)?
when we wanted to switch from reset-lantiq.c to reset-intel-syscon.c
we still had to add support for the _reset callback as this is missing
in reset-intel-syscon.c currently
Yes. We have reset pulse(assert, then check the reset status).
only now I realized that the reset-intel-syscon driver does not seem
to use the status registers (instead it's looking at the reset
registers when checking the status).
what happened to the status registers - do they still exist in newer
SoCs (like LGM)? why are they not used?
Reset status check is there. regmap_read_poll_timeout to check status
big. Status register offset <4) from request register. For legacy, there
is one exception, we can add soc specific data to handle it.
I see, thank you for the explanation
this won't work on VRX200 for example because the status register is
not always at (reset register - 0x4)
As I mentioned, VRX200 and all legacy SoCs (MIPS based) can be solved
with one soc data in the compatible array.
For example(not same as upstream, but idea is similar)
static u32 intel_stat_reg_off(struct intel_reset_data *data, u32 req_off)
{
if (data->soc_data->legacy && req_off == RCU_RST_REQ)
return RCU_RST_STAT;
else
return req_off + 0x4;
}
on VRX200 for example there seem to be some cases where the bits in
the reset and status registers are different (for example: the first
GPHY seems to use reset bit 31 but status bit 30)
this is currently not supported in reset-intel-syscon
This is most tricky and ugly part for VRX200/Danube. Do you have any
idea to handle this nicely?
with reset-lantiq we have the following register information:
a) reset offset: first reg property
b) status offset: second reg property
c) reset bit: first #reset-cell
d) status bit: second #reset-cell
reset-intel-syscon derives half of this information from the two #reset-cells:
a) reset offset: first #reset-cell
b) status offset: reset offset - 0x4
c) reset bit: second #reset-cell
d) status bit: same as reset bit
I cannot make any suggestion (yet) how to handle VRX200 and LGM in one
driver because I don't know enough about LGM (yet).
on VRX200 my understanding is that we have
linux-next: manual merge of the vfs tree with the fuse tree
Hi all,
Today's linux-next merge of the vfs tree got a conflict in:
fs/fuse/inode.c
between commit:
1458e5e9f99a ("fuse: extract fuse_fill_super_common()")
from the fuse tree and commit:
2ad9ab0f7429 ("vfs: Convert fuse to use the new mount API")
48ceb15f98c8 ("vfs: Move the subtype parameter into fuse")
from the vfs tree.
This is too much to work out, so I have effectively reverted the 2 vfs
tree commits.
I fixed it up (see above) 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
pgpqULAcaMWqP.pgp
Description: OpenPGP digital signature
Re: [PATCH] __div64_const32(): improve the generic C version
Ping.
On Tue, 20 Aug 2019, Nicolas Pitre wrote:
> Let's rework that code to avoid large immediate values and convert some
> 64-bit variables to 32-bit ones when possible. This allows gcc to
> produce smaller and better code. This even produces optimal code on
> RISC-V.
>
> Signed-off-by: Nicolas Pitre
>
> diff --git a/include/asm-generic/div64.h b/include/asm-generic/div64.h
> index dc9726fdac..33358245b4 100644
> --- a/include/asm-generic/div64.h
> +++ b/include/asm-generic/div64.h
> @@ -178,7 +178,8 @@ static inline uint64_t __arch_xprod_64(const uint64_t m,
> uint64_t n, bool bias)
> uint32_t m_hi = m >> 32;
> uint32_t n_lo = n;
> uint32_t n_hi = n >> 32;
> - uint64_t res, tmp;
> + uint64_t res;
> + uint32_t res_lo, res_hi, tmp;
>
> if (!bias) {
> res = ((uint64_t)m_lo * n_lo) >> 32;
> @@ -187,8 +188,9 @@ static inline uint64_t __arch_xprod_64(const uint64_t m,
> uint64_t n, bool bias)
> res = (m + (uint64_t)m_lo * n_lo) >> 32;
> } else {
> res = m + (uint64_t)m_lo * n_lo;
> - tmp = (res < m) ? (1ULL << 32) : 0;
> - res = (res >> 32) + tmp;
> + res_lo = res >> 32;
> + res_hi = (res_lo < m_hi);
> + res = res_lo | ((uint64_t)res_hi << 32);
> }
>
> if (!(m & ((1ULL << 63) | (1ULL << 31 {
> @@ -197,10 +199,12 @@ static inline uint64_t __arch_xprod_64(const uint64_t
> m, uint64_t n, bool bias)
> res += (uint64_t)m_hi * n_lo;
> res >>= 32;
> } else {
> - tmp = res += (uint64_t)m_lo * n_hi;
> + res += (uint64_t)m_lo * n_hi;
> + tmp = res >> 32;
> res += (uint64_t)m_hi * n_lo;
> - tmp = (res < tmp) ? (1ULL << 32) : 0;
> - res = (res >> 32) + tmp;
> + res_lo = res >> 32;
> + res_hi = (res_lo < tmp);
> + res = res_lo | ((uint64_t)res_hi << 32);
> }
>
> res += (uint64_t)m_hi * n_hi;
>
RE: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
> Subject: Re: [PATCH v5 2/2] mailbox: introduce ARM SMC based mailbox
>
> On Wed, Aug 28, 2019 at 03:03:02AM +, Peng Fan wrote:
> > From: Peng Fan
> >
> > This mailbox driver implements a mailbox which signals transmitted
> > data via an ARM smc (secure monitor call) instruction. The mailbox
> > receiver is implemented in firmware and can synchronously return data
> > when it returns execution to the non-secure world again.
> > An asynchronous receive path is not implemented.
> > This allows the usage of a mailbox to trigger firmware actions on SoCs
> > which either don't have a separate management processor or on which
> > such a core is not available. A user of this mailbox could be the SCP
> > interface.
> >
> > Modified from Andre Przywara's v2 patch
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Fpatchwork%2Fpatch%2F812999%2Fdata=02%7C01%7
> Cpeng.fa
> >
> n%40nxp.com%7Ca1e96c6b782d43b2cfb208d72bc05898%7C686ea1d3bc2b
> 4c6fa92cd
> >
> 99c5c301635%7C0%7C0%7C637025977487779923sdata=rzC%2B4Y1c
> q9Y3tSDFR
> > %2Fsvf5ktk7INP2rwXN%2BXdWCVjNs%3Dreserved=0
> >
> > Cc: Andre Przywara
> > Signed-off-by: Peng Fan
> > ---
> > drivers/mailbox/Kconfig | 7 ++
> > drivers/mailbox/Makefile | 2 +
> > drivers/mailbox/arm-smc-mailbox.c | 215
> > ++
> > 3 files changed, 224 insertions(+)
> > create mode 100644 drivers/mailbox/arm-smc-mailbox.c
> >
>
> [...]
>
> > +static int arm_smc_mbox_probe(struct platform_device *pdev) {
> > + struct device *dev = >dev;
> > + struct mbox_controller *mbox;
> > + struct arm_smc_chan_data *chan_data;
> > + const char *method;
> > + bool mem_trans = false;
> > + int ret, i;
> > + u32 val;
> > +
> > + if (!of_property_read_u32(dev->of_node, "arm,num-chans", )) {
> > + if (!val) {
> > + dev_err(dev, "invalid arm,num-chans value %u\n", val);
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_property_read_string(dev->of_node, "transports", )) {
> > + if (!strcmp("mem", method)) {
> > + mem_trans = true;
> > + } else if (!strcmp("reg", method)) {
> > + mem_trans = false;
> > + } else {
> > + dev_warn(dev, "invalid \"transports\" property: %s\n",
> > +method);
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + if (!of_property_read_string(dev->of_node, "method", )) {
> > + if (!strcmp("hvc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_hvc;
> > + } else if (!strcmp("smc", method)) {
> > + invoke_smc_mbox_fn = __invoke_fn_smc;
> > + } else {
> > + dev_warn(dev, "invalid \"method\" property: %s\n",
> > +method);
> > +
> > + return -EINVAL;
> > + }
> > + } else {
> > + return -EINVAL;
> > + }
> > +
> > + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> > + if (!mbox)
> > + return -ENOMEM;
> > +
> > + mbox->num_chans = val;
> > + mbox->chans = devm_kcalloc(dev, mbox->num_chans,
> sizeof(*mbox->chans),
> > + GFP_KERNEL);
> > + if (!mbox->chans)
> > + return -ENOMEM;
> > +
> > + chan_data = devm_kcalloc(dev, mbox->num_chans, sizeof(*chan_data),
> > +GFP_KERNEL);
> > + if (!chan_data)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < mbox->num_chans; i++) {
> > + u32 function_id;
> > +
> > + ret = of_property_read_u32_index(dev->of_node,
> > +"arm,func-ids", i,
> > +_id);
>
> I missed it in binding but I thought we agreed to make this "arm,func-ids"
> a required property and not optional ?
Not sure Jassi is fine with it being a required property, but I could convert
it to a required property in V6.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
RE: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
> Subject: Re: [PATCH v5 1/2] dt-bindings: mailbox: add binding doc for the ARM > SMC/HVC mailbox > > On Wed, Aug 28, 2019 at 03:02:58AM +, Peng Fan wrote: > > From: Peng Fan > > > > The ARM SMC/HVC mailbox binding describes a firmware interface to > > trigger actions in software layers running in the EL2 or EL3 exception > > levels. > > The term "ARM" here relates to the SMC instruction as part of the ARM > > instruction set, not as a standard endorsed by ARM Ltd. > > > > Signed-off-by: Peng Fan > > --- > > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 > + > > 1 file changed, 125 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > > > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > new file mode 100644 > > index ..f8eb28d5e307 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml > > @@ -0,0 +1,125 @@ > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 > > +--- > > +$id: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fschemas%2Fmailbox%2Farm-smc.yaml%23data=02%7 > C01%7Cp > > > +eng.fan%40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1 > d3bc2b4c > > > +6fa92cd99c5c301635%7C0%7C1%7C637025974936865698sdata=Inp > %2FLs39m > > +Gv1fe3dZMSaGmgmyWPT6awPh47s3mEtQ%2BQ%3Dreserved=0 > > +$schema: > > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi > > > +cetree.org%2Fmeta-schemas%2Fcore.yaml%23data=02%7C01%7Cpe > ng.fan% > > > +40nxp.com%7C37aa729c94944730868b08d72bbfc121%7C686ea1d3bc2b4c > 6fa92cd9 > > > +9c5c301635%7C0%7C1%7C637025974936865698sdata=jmoR1Qqm7 > 6N5NwDbgFE > > +Fm8cpdW%2B%2FgqmG9mSGz9mXv58%3Dreserved=0 > > + > > +title: ARM SMC Mailbox Interface > > + > > +maintainers: > > + - Peng Fan > > + > > +description: | > > + This mailbox uses the ARM smc (secure monitor call) and hvc > > +(hypervisor > > + call) instruction to trigger a mailbox-connected activity in > > +firmware, > > + executing on the very same core as the caller. By nature this > > +operation > > + is synchronous and this mailbox provides no way for asynchronous > > +messages > > + to be delivered the other way round, from firmware to the OS, but > > > > + asynchronous notification could also be supported. > > What do you mean by that ? I would prefer to drop the above line unless I am Ok. Dropped it in v6. > missing something. IMO it contradicts the previous statement less you > elaborate more on this. > > > However the value of > > + r0/w0/x0 the firmware returns after the smc call is delivered as a > > + received message to the mailbox framework, so a synchronous > > + communication can be established, for a asynchronous notification, no > value will be returned. > > I assume you refer to asynchronous communication from OS to firmware in > the above statement and "not asynchronous notification" from firmware to > OS. Since asynchronous notification dropped, so it should only be synchronous communication could be established. So I'll modify it as below: r0/w0/x0 the firmware returns after the smc call is delivered as a received message to the mailbox framework, so synchronous communication can be established > > > + The exact meaning of both the action the mailbox triggers as well > > + as the return value is defined by their users and is not subject to this > binding. > > + > > + One use case of this mailbox is the SCMI interface, which uses > > + shared memory to transfer commands and parameters, and a mailbox > to > > + trigger a function call. This allows SoCs without a separate > > + management processor (or when such a processor is not available or > > + used) to use this standardized interface anyway. > > + > > Not sure if reference to SCMI is needed at all but I don't have any objections > to it, just thought worth mentioning. > > > + This binding describes no hardware, but establishes a firmware > interface. > > + Upon receiving an SMC using one of the described SMC function > > + identifiers, the firmware is expected to trigger some mailbox connected > functionality. > > + The communication follows the ARM SMC calling convention. > > + Firmware expects an SMC function identifier in r0 or w0. The > > + supported identifiers are passed from consumers, or listed in the > > + the arm,func-ids properties as described below. The firmware can > > + return one value in the first SMC result register, it is expected > > + to be an error value, which shall be propagated to the mailbox client. > > + > > + Any core which supports the SMC or HVC instruction can be used, as > > + long as a firmware component running in EL3 or EL2 is handling these > calls. > > + > > > Other than the above points, I am fine with it. Once fixed, > > Reviewed-by: Sudeep Holla Thanks, Peng. > > Note I haven't
RE: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias
> -Original Message-
> From: Yunsheng Lin
> Sent: Thursday, August 29, 2019 5:57 PM
> To: Parav Pandit ; alex.william...@redhat.com; Jiri
> Pirko ; kwankh...@nvidia.com; coh...@redhat.com;
> da...@davemloft.net
> Cc: k...@vger.kernel.org; linux-kernel@vger.kernel.org;
> net...@vger.kernel.org
> Subject: Re: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias
>
> On 2019/8/29 19:18, Parav Pandit wrote:
> > Some vendor drivers want an identifier for an mdev device that is
> > shorter than the UUID, due to length restrictions in the consumers of
> > that identifier.
> >
> > Add a callback that allows a vendor driver to request an alias of a
> > specified length to be generated for an mdev device. If generated,
> > that alias is checked for collisions.
> >
> > It is an optional attribute.
> > mdev alias is generated using sha1 from the mdev name.
> >
> > Signed-off-by: Parav Pandit
> >
> > ---
> > Changelog:
> > v1->v2:
> > - Kept mdev_device naturally aligned
> > - Added error checking for crypt_*() calls
> > - Corrected a typo from 'and' to 'an'
> > - Changed return type of generate_alias() from int to char*
> > v0->v1:
> > - Moved alias length check outside of the parent lock
> > - Moved alias and digest allocation from kvzalloc to kzalloc
> > - [0] changed to alias
> > - alias_length check is nested under get_alias_length callback check
> > - Changed comments to start with an empty line
> > - Fixed cleaunup of hash if mdev_bus_register() fails
> > - Added comment where alias memory ownership is handed over to mdev
> > device
> > - Updated commit log to indicate motivation for this feature
> > ---
> > drivers/vfio/mdev/mdev_core.c| 123
> ++-
> > drivers/vfio/mdev/mdev_private.h | 5 +-
> > drivers/vfio/mdev/mdev_sysfs.c | 13 ++--
> > include/linux/mdev.h | 4 +
> > 4 files changed, 135 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/vfio/mdev/mdev_core.c
> > b/drivers/vfio/mdev/mdev_core.c index b558d4cfd082..3bdff0469607
> > 100644
> > --- a/drivers/vfio/mdev/mdev_core.c
> > +++ b/drivers/vfio/mdev/mdev_core.c
> > @@ -10,9 +10,11 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "mdev_private.h"
> >
> > @@ -27,6 +29,8 @@ static struct class_compat *mdev_bus_compat_class;
> > static LIST_HEAD(mdev_list); static DEFINE_MUTEX(mdev_list_lock);
> >
> > +static struct crypto_shash *alias_hash;
> > +
> > struct device *mdev_parent_dev(struct mdev_device *mdev) {
> > return mdev->parent->dev;
> > @@ -150,6 +154,16 @@ int mdev_register_device(struct device *dev, const
> struct mdev_parent_ops *ops)
> > if (!ops || !ops->create || !ops->remove || !ops-
> >supported_type_groups)
> > return -EINVAL;
> >
> > + if (ops->get_alias_length) {
> > + unsigned int digest_size;
> > + unsigned int aligned_len;
> > +
> > + aligned_len = roundup(ops->get_alias_length(), 2);
> > + digest_size = crypto_shash_digestsize(alias_hash);
> > + if (aligned_len / 2 > digest_size)
> > + return -EINVAL;
> > + }
> > +
> > dev = get_device(dev);
> > if (!dev)
> > return -EINVAL;
> > @@ -259,6 +273,7 @@ static void mdev_device_free(struct mdev_device
> *mdev)
> > mutex_unlock(_list_lock);
> >
> > dev_dbg(>dev, "MDEV: destroying\n");
> > + kfree(mdev->alias);
> > kfree(mdev);
> > }
> >
> > @@ -269,18 +284,101 @@ static void mdev_device_release(struct device
> *dev)
> > mdev_device_free(mdev);
> > }
> >
> > -int mdev_device_create(struct kobject *kobj,
> > - struct device *dev, const guid_t *uuid)
> > +static const char *
> > +generate_alias(const char *uuid, unsigned int max_alias_len) {
> > + struct shash_desc *hash_desc;
> > + unsigned int digest_size;
> > + unsigned char *digest;
> > + unsigned int alias_len;
> > + char *alias;
> > + int ret;
> > +
> > + /*
> > +* Align to multiple of 2 as bin2hex will generate
> > +* even number of bytes.
> > +*/
> > + alias_len = roundup(max_alias_len, 2);
> > + alias = kzalloc(alias_len + 1, GFP_KERNEL);
>
> It seems the mtty_alias_length in mtty.c can be set from module parameter,
> and user can set a very large number, maybe limit the max of the alias_len
> before calling kzalloc?
This is already guarded in mdev_register_device().
User cannot request alias length bigger than the digest size of sha1 (which is
20 bytes).
[PATCH] arm64: numa: check the node id before accessing node_to_cpumask_map
Some buggy bios may not set the device' numa id, and dev_to_node
will return -1, which may cause global-out-of-bounds error
detected by KASAN.
This patch changes cpumask_of_node to return cpu_none_mask if the
node is not valid, and sync the cpumask_of_node between the
cpumask_of_node function in numa.h and numa.c.
Signed-off-by: Yunsheng Lin
---
arch/arm64/include/asm/numa.h | 6 ++
arch/arm64/mm/numa.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 626ad01..da891ed 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -25,6 +25,12 @@ const struct cpumask *cpumask_of_node(int node);
/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
static inline const struct cpumask *cpumask_of_node(int node)
{
+ if (node >= nr_node_ids || node < 0)
+ return cpu_none_mask;
+
+ if (!node_to_cpumask_map[node])
+ return cpu_online_mask;
+
return node_to_cpumask_map[node];
}
#endif
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 4f241cc..3846313 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -46,7 +46,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
*/
const struct cpumask *cpumask_of_node(int node)
{
- if (WARN_ON(node >= nr_node_ids))
+ if (WARN_ON(node >= nr_node_ids || node < 0))
return cpu_none_mask;
if (WARN_ON(node_to_cpumask_map[node] == NULL))
--
2.8.1
