Re: [RFC/PATCH 0/5] DVFS in the OPP core
Quoting Viresh Kumar (2019-01-31 01:23:49) > Adding few folks to the thread who might be interested in this stuff. > > On 28-01-19, 17:55, Stephen Boyd wrote: > > This patch series is an RFC around how we can implement DVFS for devices > > that aren't your typical OPPish device (i.e. GPU/CPU). They don't have a > > strict set of frequencies that they have been tested at to derive some > > operating performance point. Instead they have a coarser set of > > frequency max or 'fmax' OPPs that describe the maiximum frequency the > > device can operate at with a given voltage. > > > > The approach we take is to let the devm_pm_opp_set_rate() API accept 0 > > as a valid frequency indicating the frequency isn't required anymore and > > to make the same API use the clk framework to round the frequency passed > > in instead of relying on the OPP table to specify each frequency that > > can be used. Once we have these two patches in place, we can use the OPP > > API to change clk rates instead of clk_set_rate() and use all the recent > > OPP enhancements that have been made around required-opps and genpd > > performance states to do DVFS for all devices. > > Generally speaking I am fine with such an approach but I am not sure > about what others would say on this as they had objections to using > OPP core for setting the rate itself. > > FWIW, I suggested exactly this solution sometime back [1] > > - Drivers need to use two API sets to change clock rate (OPP helpers) > and enable/disable them (CLK framework helpers) and this leads us to > exactly that combination. Is that acceptable ? It doesn't look great > to me as well.. Agreed. I don't think anyone thinks this looks great, but I'll argue that it's improving OPP for devices that already use it so that we can remove voltage requirements when their clk is off. Think about CPUs that are in their own clk domain where we want to remove the voltage requirement when those CPUs are offline, or a GPU that wants to remove its voltage requirement when it turns off clks. The combination is already out there, just OPP hasn't solved this problem. The only other plan I had was to implement another API like dev_pm_set_state() or something like that and have that do something like what the OPP rate API does right now. The main difference being that the argument to the function would be some opaque u64 that's converted by the bus/class/genpd attached to the device into whatever frequency/voltage/performance state is desired (and sequenced in the right order too). And then I was thinking that runtime PM or explicit dev_pm_set_state() calls would be used to tell this new layer that the device was going to a lower power mode with some other number (sub-kHz integer?) and have that be translated again into some frequency/voltage/performance state. Either way, each driver will have to change from using the clk APIs to changes rates to something else like one of these APIs, so I don't see a huge difference. Drivers will have to change. > > - Do we expect the callers will disable clk before calling > opp-set-rate with 0 ? We should remove the regulator requirements as > well along with perf-state. Yes, that's the plan. Problems come along with this though, like shared resource constraints and actually knowing the clk on/off state, frequency, voltage, etc. at boot time and making sure to keep those constraints satisfied during normal operation. > > - What about enabling/disabling clock as well from OPP framework. We > can enable it on the very first call to opp-set-rate and disable > when freq is 0. That will simplify the drivers as well. It works when those drivers aren't calling clk_disable() directly from some irq handler. I don't think that's very common, but in those cases we would probably want to allow drivers to quickly gate and ungate their clks but then defer the sleeping stuff (voltages and off chip clks) to the schedulable contexts. We'll still be left with a small number of drivers that want to only call clk_prepare() and clk_unprepare() from within OPP and keep calling clk_enable() and clk_disable() from their driver. So introduce different APIs for those drivers to indicate this to OPP? And only do that when it becomes a requirement? Otherwise I don't really see a problem with the OPP call handling the enable state of the clk as well. > > > One nice feature of this approach is that we don't need to change the > > OPP binding to support this. We can specify only the max frequencies and > > the voltage requirements in DT with the existing binding and slightly > > tweak the OPP code to achieve these results. > > > > This series includes a conversion of the uart and spi drivers on > > qcom sdm845 where these patches are being developed. It shows how a > > driver is converted from the clk APIs to the OPP APIs and how > > enable/disable state of the clk is communicated to the OPP layer. > > > > Some open topics and initial points for discussion
Re: [PATCH 2/2] mfd: at91-usart: No need to copy mfd_cell in probe
On Thu, 31 Jan 2019, Axel Lin wrote: > Use pointer instead. > > Signed-off-by: Axel Lin > --- > drivers/mfd/at91-usart.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] mfd: at91-usart: Constify at91_usart_spi_subdev and at91_usart_serial_subdev
On Thu, 31 Jan 2019, Axel Lin wrote: > They are never get changed, make them constant. > While at it, fix indent as well. > > Signed-off-by: Axel Lin > --- > drivers/mfd/at91-usart.c | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v3] dt-bindings: aspeed-lpc: Make parameter optional
On Tue, 29 Jan 2019, Vijay Khemka wrote: > Memory-region and flash phandle is not a required parameter, it is > optional to describe in device tree and needed only use basis. > > Signed-off-by: Vijay Khemka > --- > Documentation/devicetree/bindings/mfd/aspeed-lpc.txt | 2 ++ > 1 file changed, 2 insertions(+) Applied, thanks. -- Lee Jones [李琼斯] Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH net-next 1/2] net: Move all TC actions identifiers to one place
Move all the TC identifiers to one place, to the same enum that defines
the identifier of police action. This makes it easier choose numbers for
new actions since they are now defined in one place. We preserve the
original values for binary compatibility. New IDs should be added inside
the enum.
Signed-off-by: Eli Cohen
Acked-by: Jiri Pirko
---
include/uapi/linux/pkt_cls.h | 43 ---
include/uapi/linux/tc_act/tc_bpf.h| 2 --
include/uapi/linux/tc_act/tc_connmark.h | 2 --
include/uapi/linux/tc_act/tc_csum.h | 2 --
include/uapi/linux/tc_act/tc_gact.h | 1 -
include/uapi/linux/tc_act/tc_ife.h| 1 -
include/uapi/linux/tc_act/tc_ipt.h| 3 ---
include/uapi/linux/tc_act/tc_mirred.h | 1 -
include/uapi/linux/tc_act/tc_nat.h| 2 --
include/uapi/linux/tc_act/tc_pedit.h | 2 --
include/uapi/linux/tc_act/tc_sample.h | 2 --
include/uapi/linux/tc_act/tc_skbedit.h| 2 --
include/uapi/linux/tc_act/tc_skbmod.h | 2 --
include/uapi/linux/tc_act/tc_tunnel_key.h | 2 --
include/uapi/linux/tc_act/tc_vlan.h | 2 --
tools/include/uapi/linux/tc_act/tc_bpf.h | 2 --
16 files changed, 40 insertions(+), 31 deletions(-)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index 02ac251be8c4..7ab55f97e7c4 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -63,12 +63,49 @@ enum {
#define TC_ACT_GOTO_CHAIN __TC_ACT_EXT(2)
#define TC_ACT_EXT_OPCODE_MAX TC_ACT_GOTO_CHAIN
+/* These macros are put here for binary compatibility with userspace apps that
+ * make use of them. For kernel code and new userspace apps, use the TCA_ID_*
+ * versions.
+ */
+#define TCA_ACT_GACT 5
+#define TCA_ACT_IPT 6
+#define TCA_ACT_PEDIT 7
+#define TCA_ACT_MIRRED 8
+#define TCA_ACT_NAT 9
+#define TCA_ACT_XT 10
+#define TCA_ACT_SKBEDIT 11
+#define TCA_ACT_VLAN 12
+#define TCA_ACT_BPF 13
+#define TCA_ACT_CONNMARK 14
+#define TCA_ACT_SKBMOD 15
+#define TCA_ACT_CSUM 16
+#define TCA_ACT_TUNNEL_KEY 17
+#define TCA_ACT_SIMP 22
+#define TCA_ACT_IFE 25
+#define TCA_ACT_SAMPLE 26
+
/* Action type identifiers*/
enum {
- TCA_ID_UNSPEC=0,
- TCA_ID_POLICE=1,
+ TCA_ID_UNSPEC = 0,
+ TCA_ID_POLICE = 1,
+ TCA_ID_GACT = TCA_ACT_GACT,
+ TCA_ID_IPT = TCA_ACT_IPT,
+ TCA_ID_PEDIT = TCA_ACT_PEDIT,
+ TCA_ID_MIRRED = TCA_ACT_MIRRED,
+ TCA_ID_NAT = TCA_ACT_NAT,
+ TCA_ID_XT = TCA_ACT_XT,
+ TCA_ID_SKBEDIT = TCA_ACT_SKBEDIT,
+ TCA_ID_VLAN = TCA_ACT_VLAN,
+ TCA_ID_BPF = TCA_ACT_BPF,
+ TCA_ID_CONNMARK = TCA_ACT_CONNMARK,
+ TCA_ID_SKBMOD = TCA_ACT_SKBMOD,
+ TCA_ID_CSUM = TCA_ACT_CSUM,
+ TCA_ID_TUNNEL_KEY = TCA_ACT_TUNNEL_KEY,
+ TCA_ID_SIMP = TCA_ACT_SIMP,
+ TCA_ID_IFE = TCA_ACT_IFE,
+ TCA_ID_SAMPLE = TCA_ACT_SAMPLE,
/* other actions go here */
- __TCA_ID_MAX=255
+ __TCA_ID_MAX = 255
};
#define TCA_ID_MAX __TCA_ID_MAX
diff --git a/include/uapi/linux/tc_act/tc_bpf.h
b/include/uapi/linux/tc_act/tc_bpf.h
index 6e89a5df49a4..653c4f94f76e 100644
--- a/include/uapi/linux/tc_act/tc_bpf.h
+++ b/include/uapi/linux/tc_act/tc_bpf.h
@@ -13,8 +13,6 @@
#include
-#define TCA_ACT_BPF 13
-
struct tc_act_bpf {
tc_gen;
};
diff --git a/include/uapi/linux/tc_act/tc_connmark.h
b/include/uapi/linux/tc_act/tc_connmark.h
index 80caa47b1933..9f8f6f709feb 100644
--- a/include/uapi/linux/tc_act/tc_connmark.h
+++ b/include/uapi/linux/tc_act/tc_connmark.h
@@ -5,8 +5,6 @@
#include
#include
-#define TCA_ACT_CONNMARK 14
-
struct tc_connmark {
tc_gen;
__u16 zone;
diff --git a/include/uapi/linux/tc_act/tc_csum.h
b/include/uapi/linux/tc_act/tc_csum.h
index 0ecf4d29e2f3..94b2044929de 100644
--- a/include/uapi/linux/tc_act/tc_csum.h
+++ b/include/uapi/linux/tc_act/tc_csum.h
@@ -5,8 +5,6 @@
#include
#include
-#define TCA_ACT_CSUM 16
-
enum {
TCA_CSUM_UNSPEC,
TCA_CSUM_PARMS,
diff --git a/include/uapi/linux/tc_act/tc_gact.h
b/include/uapi/linux/tc_act/tc_gact.h
index 94273c3b81b0..37e5392e02c7 100644
--- a/include/uapi/linux/tc_act/tc_gact.h
+++ b/include/uapi/linux/tc_act/tc_gact.h
@@ -5,7 +5,6 @@
#include
#include
-#define TCA_ACT_GACT 5
struct tc_gact {
tc_gen;
diff --git a/include/uapi/linux/tc_act/tc_ife.h
b/include/uapi/linux/tc_act/tc_ife.h
index 2f48490ef386..8c401f185675 100644
--- a/include/uapi/linux/tc_act/tc_ife.h
+++ b/include/uapi/linux/tc_act/tc_ife.h
@@ -6,7 +6,6 @@
#include
#include
-#define TCA_ACT_IFE 25
/* Flag bits for now just encoding/decoding; mutually exclusive */
#define IFE_ENCODE 1
#define IFE_DECODE 0
diff --git a/include/uapi/linux/tc_act/tc_ipt.h
b/include/uapi/linux/tc_act/tc_ipt.h
index b743c8bddd13..c48d7da6750d 100644
--- a/include/uapi/linux/tc_act/tc_ipt.h
+++ b/include/uapi/linux/tc_act/tc_ipt.h
@@ -4,9 +4,6 @@
#include
-#define TCA_ACT_IPT 6
-#define TCA_ACT_XT 10
-
[PATCH net-next 2/2] net: Change TCA_ACT_* to TCA_ID_* to match that of TCA_ID_POLICE
Modify the kernel users of the TCA_ACT_* macros to use TCA_ID_*. For
example, use TCA_ID_GACT instead of TCA_ACT_GACT. This will align with
TCA_ID_POLICE and also differentiates these identifier, used in struct
tc_action_ops type field, from other macros starting with TCA_ACT_.
To make things clearer, we name the enum defining the TCA_ID_*
identifiers and also change the "type" field of struct tc_action to
id.
Signed-off-by: Eli Cohen
Acked-by: Jiri Pirko
---
include/net/act_api.h | 2 +-
include/net/tc_act/tc_csum.h | 2 +-
include/net/tc_act/tc_gact.h | 2 +-
include/net/tc_act/tc_mirred.h | 4 ++--
include/net/tc_act/tc_pedit.h | 2 +-
include/net/tc_act/tc_sample.h | 2 +-
include/net/tc_act/tc_skbedit.h| 2 +-
include/net/tc_act/tc_tunnel_key.h | 4 ++--
include/net/tc_act/tc_vlan.h | 2 +-
include/uapi/linux/pkt_cls.h | 2 +-
net/sched/act_api.c| 2 +-
net/sched/act_bpf.c| 2 +-
net/sched/act_connmark.c | 2 +-
net/sched/act_csum.c | 2 +-
net/sched/act_gact.c | 2 +-
net/sched/act_ife.c| 2 +-
net/sched/act_ipt.c| 4 ++--
net/sched/act_mirred.c | 2 +-
net/sched/act_nat.c| 2 +-
net/sched/act_pedit.c | 2 +-
net/sched/act_police.c | 2 +-
net/sched/act_sample.c | 2 +-
net/sched/act_simple.c | 4 +---
net/sched/act_skbedit.c| 2 +-
net/sched/act_skbmod.c | 2 +-
net/sched/act_tunnel_key.c | 2 +-
net/sched/act_vlan.c | 2 +-
27 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/include/net/act_api.h b/include/net/act_api.h
index dbc795ec659e..c745e9ccfab2 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -80,7 +80,7 @@ static inline void tcf_tm_dump(struct tcf_t *dtm, const
struct tcf_t *stm)
struct tc_action_ops {
struct list_head head;
charkind[IFNAMSIZ];
- __u32 type; /* TBD to match kind */
+ enum tca_id id; /* identifier should match kind */
size_t size;
struct module *owner;
int (*act)(struct sk_buff *, const struct tc_action *,
diff --git a/include/net/tc_act/tc_csum.h b/include/net/tc_act/tc_csum.h
index 32d2454c0479..68269e4581b7 100644
--- a/include/net/tc_act/tc_csum.h
+++ b/include/net/tc_act/tc_csum.h
@@ -21,7 +21,7 @@ struct tcf_csum {
static inline bool is_tcf_csum(const struct tc_action *a)
{
#ifdef CONFIG_NET_CLS_ACT
- if (a->ops && a->ops->type == TCA_ACT_CSUM)
+ if (a->ops && a->ops->id == TCA_ID_CSUM)
return true;
#endif
return false;
diff --git a/include/net/tc_act/tc_gact.h b/include/net/tc_act/tc_gact.h
index ef8dd0db70ce..ee8d005f56fc 100644
--- a/include/net/tc_act/tc_gact.h
+++ b/include/net/tc_act/tc_gact.h
@@ -22,7 +22,7 @@ static inline bool __is_tcf_gact_act(const struct tc_action
*a, int act,
#ifdef CONFIG_NET_CLS_ACT
struct tcf_gact *gact;
- if (a->ops && a->ops->type != TCA_ACT_GACT)
+ if (a->ops && a->ops->id != TCA_ID_GACT)
return false;
gact = to_gact(a);
diff --git a/include/net/tc_act/tc_mirred.h b/include/net/tc_act/tc_mirred.h
index a2e9cbca5c9e..c757585a05b0 100644
--- a/include/net/tc_act/tc_mirred.h
+++ b/include/net/tc_act/tc_mirred.h
@@ -17,7 +17,7 @@ struct tcf_mirred {
static inline bool is_tcf_mirred_egress_redirect(const struct tc_action *a)
{
#ifdef CONFIG_NET_CLS_ACT
- if (a->ops && a->ops->type == TCA_ACT_MIRRED)
+ if (a->ops && a->ops->id == TCA_ID_MIRRED)
return to_mirred(a)->tcfm_eaction == TCA_EGRESS_REDIR;
#endif
return false;
@@ -26,7 +26,7 @@ static inline bool is_tcf_mirred_egress_redirect(const struct
tc_action *a)
static inline bool is_tcf_mirred_egress_mirror(const struct tc_action *a)
{
#ifdef CONFIG_NET_CLS_ACT
- if (a->ops && a->ops->type == TCA_ACT_MIRRED)
+ if (a->ops && a->ops->id == TCA_ID_MIRRED)
return to_mirred(a)->tcfm_eaction == TCA_EGRESS_MIRROR;
#endif
return false;
diff --git a/include/net/tc_act/tc_pedit.h b/include/net/tc_act/tc_pedit.h
index fac3ad4a86de..748cf87a4d7e 100644
--- a/include/net/tc_act/tc_pedit.h
+++ b/include/net/tc_act/tc_pedit.h
@@ -23,7 +23,7 @@ struct tcf_pedit {
static inline bool is_tcf_pedit(const struct tc_action *a)
{
#ifdef CONFIG_NET_CLS_ACT
- if (a->ops && a->ops->type == TCA_ACT_PEDIT)
+ if (a->ops && a->ops->id == TCA_ID_PEDIT)
return true;
#endif
return false;
diff --git a/include/net/tc_act/tc_sample.h b/include/net/tc_act/tc_sample.h
index 01dbfea32672..0a559d4b6f0f 100644
--- a/include/net/tc_act/tc_sample.h
+++ b/include/net/tc_act/tc_sample.h
@@ -20,7 +20,7 @@ struct tcf_sample {
static inline bool is_tcf_sample(const struct tc_action *a)
{
#ifdef CONFIG_NET_CLS_ACT
- return a->ops &&
[PATCH net-next 0/2] Change tc action identifiers to be more consistent
This two patch series modifies TC actions identifiers to be more consistent and also puts them in one place so new identifiers numbers can be chosen more easily. Eli Cohen (2): net: Move all TC actions identifiers to one place net: Change TCA_ACT_* to TCA_ID_* to match that of TCA_ID_POLICE include/net/act_api.h | 2 +- include/net/tc_act/tc_csum.h | 2 +- include/net/tc_act/tc_gact.h | 2 +- include/net/tc_act/tc_mirred.h| 4 +-- include/net/tc_act/tc_pedit.h | 2 +- include/net/tc_act/tc_sample.h| 2 +- include/net/tc_act/tc_skbedit.h | 2 +- include/net/tc_act/tc_tunnel_key.h| 4 +-- include/net/tc_act/tc_vlan.h | 2 +- include/uapi/linux/pkt_cls.h | 45 --- include/uapi/linux/tc_act/tc_bpf.h| 2 -- include/uapi/linux/tc_act/tc_connmark.h | 2 -- include/uapi/linux/tc_act/tc_csum.h | 2 -- include/uapi/linux/tc_act/tc_gact.h | 1 - include/uapi/linux/tc_act/tc_ife.h| 1 - include/uapi/linux/tc_act/tc_ipt.h| 3 --- include/uapi/linux/tc_act/tc_mirred.h | 1 - include/uapi/linux/tc_act/tc_nat.h| 2 -- include/uapi/linux/tc_act/tc_pedit.h | 2 -- include/uapi/linux/tc_act/tc_sample.h | 2 -- include/uapi/linux/tc_act/tc_skbedit.h| 2 -- include/uapi/linux/tc_act/tc_skbmod.h | 2 -- include/uapi/linux/tc_act/tc_tunnel_key.h | 2 -- include/uapi/linux/tc_act/tc_vlan.h | 2 -- net/sched/act_api.c | 2 +- net/sched/act_bpf.c | 2 +- net/sched/act_connmark.c | 2 +- net/sched/act_csum.c | 2 +- net/sched/act_gact.c | 2 +- net/sched/act_ife.c | 2 +- net/sched/act_ipt.c | 4 +-- net/sched/act_mirred.c| 2 +- net/sched/act_nat.c | 2 +- net/sched/act_pedit.c | 2 +- net/sched/act_police.c| 2 +- net/sched/act_sample.c| 2 +- net/sched/act_simple.c| 4 +-- net/sched/act_skbedit.c | 2 +- net/sched/act_skbmod.c| 2 +- net/sched/act_tunnel_key.c| 2 +- net/sched/act_vlan.c | 2 +- tools/include/uapi/linux/tc_act/tc_bpf.h | 2 -- 42 files changed, 70 insertions(+), 63 deletions(-) -- 1.8.3.1
[Patch v2 2/4] x86/platform/UV: kill uv_bios_call_reentrant() as it has no callers
uv_bios_call_reentrant() has no callers nor is it exported, kill it.
Cc: Russ Anderson
Cc: Mike Travis
Cc: Dimitri Sivanich
Cc: Steve Wahl
Cc: sta...@vger.kernel.org
Signed-off-by: Hedi Berriche
---
arch/x86/include/asm/uv/bios.h | 1 -
arch/x86/platform/uv/bios_uv.c | 12
2 files changed, 13 deletions(-)
diff --git a/arch/x86/include/asm/uv/bios.h b/arch/x86/include/asm/uv/bios.h
index e652a7cc6186..4eee646544b2 100644
--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -140,7 +140,6 @@ enum uv_memprotect {
*/
extern s64 uv_bios_call(enum uv_bios_cmd, u64, u64, u64, u64, u64);
extern s64 uv_bios_call_irqsave(enum uv_bios_cmd, u64, u64, u64, u64, u64);
-extern s64 uv_bios_call_reentrant(enum uv_bios_cmd, u64, u64, u64, u64, u64);
extern s64 uv_bios_get_sn_info(int, int *, long *, long *, long *, long *);
extern s64 uv_bios_freq_base(u64, u64 *);
diff --git a/arch/x86/platform/uv/bios_uv.c b/arch/x86/platform/uv/bios_uv.c
index 4a6a5a26c582..cd05af157763 100644
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -66,18 +66,6 @@ s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1, u64
a2, u64 a3,
return ret;
}
-s64 uv_bios_call_reentrant(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
- u64 a4, u64 a5)
-{
- s64 ret;
-
- preempt_disable();
- ret = uv_bios_call(which, a1, a2, a3, a4, a5);
- preempt_enable();
-
- return ret;
-}
-
long sn_partition_id;
EXPORT_SYMBOL_GPL(sn_partition_id);
--
2.20.1
Re: [PATCH 1/2] xsk: do not use mmap_sem
Den tors 7 feb. 2019 kl 06:38 skrev Davidlohr Bueso :
>
> Holding mmap_sem exclusively for a gup() is an overkill.
> Lets replace the call for gup_fast() and let the mm take
> it if necessary.
>
> Cc: David S. Miller
> Cc: Bjorn Topel
> Cc: Magnus Karlsson
> CC: net...@vger.kernel.org
> Signed-off-by: Davidlohr Bueso
> ---
> net/xdp/xdp_umem.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> index 5ab236c5c9a5..25e1e76654a8 100644
> --- a/net/xdp/xdp_umem.c
> +++ b/net/xdp/xdp_umem.c
> @@ -265,10 +265,8 @@ static int xdp_umem_pin_pages(struct xdp_umem *umem)
> if (!umem->pgs)
> return -ENOMEM;
>
> - down_write(>mm->mmap_sem);
> - npgs = get_user_pages(umem->address, umem->npgs,
> - gup_flags, >pgs[0], NULL);
> - up_write(>mm->mmap_sem);
> + npgs = get_user_pages_fast(umem->address, umem->npgs,
> + gup_flags, >pgs[0]);
>
Thanks for the patch!
The lifetime of the pinning is similar to RDMA umem mapping, so isn't
gup_longterm preferred?
Björn
> if (npgs != umem->npgs) {
> if (npgs >= 0) {
> --
> 2.16.4
>
[PATCH v8 8/8] watchdog: bd70528: Initial support for ROHM BD70528 watchdog block
Initial support for watchdog block included in ROHM BD70528
power management IC.
Configurations for low power states are still to be checked.
Signed-off-by: Matti Vaittinen
Acked-by: Guenter Roeck
---
drivers/watchdog/Kconfig | 12 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/bd70528_wdt.c | 190 +
3 files changed, 203 insertions(+)
create mode 100644 drivers/watchdog/bd70528_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 57f017d74a97..f30e3a3e886e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -90,6 +90,18 @@ config SOFT_WATCHDOG_PRETIMEOUT
watchdog. Be aware that governors might affect the watchdog because it
is purely software, e.g. the panic governor will stall it!
+config BD70528_WATCHDOG
+ tristate "ROHM BD70528 PMIC Watchdog"
+ depends on MFD_ROHM_BD70528
+ select WATCHDOG_CORE
+ help
+ Support for the watchdog in the ROHM BD70528 PMIC. Watchdog trigger
+ cause system reset.
+
+ Say Y here to include support for the ROHM BD70528 watchdog.
+ Alternatively say M to compile the driver as a module,
+ which will be called bd70528_wdt.
+
config DA9052_WATCHDOG
tristate "Dialog DA9052 Watchdog"
depends on PMIC_DA9052 || COMPILE_TEST
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a0917ef28e07..1ce87a3b1172 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -204,6 +204,7 @@ obj-$(CONFIG_WATCHDOG_SUN4V)+= sun4v_wdt.o
obj-$(CONFIG_XEN_WDT) += xen_wdt.o
# Architecture Independent
+obj-$(CONFIG_BD70528_WATCHDOG) += bd70528_wdt.o
obj-$(CONFIG_DA9052_WATCHDOG) += da9052_wdt.o
obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
obj-$(CONFIG_DA9062_WATCHDOG) += da9062_wdt.o
diff --git a/drivers/watchdog/bd70528_wdt.c b/drivers/watchdog/bd70528_wdt.c
new file mode 100644
index ..cab802ddde06
--- /dev/null
+++ b/drivers/watchdog/bd70528_wdt.c
@@ -0,0 +1,190 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 ROHM Semiconductors
+// ROHM BD70528MWV watchdog driver
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Max time we can set is 1 hour, 59 minutes and 59 seconds
+ * and Minimum time is 1 second
+ */
+#define WDT_MAX_MS ((2 * 60 * 60 - 1) * 1000)
+#define WDT_MIN_MS 1000
+#define DEFAULT_TIMEOUT60
+
+struct wdtbd70528 {
+ struct device *dev;
+ struct regmap *regmap;
+ struct mutex *rtc_lock;
+ struct watchdog_device wdt;
+};
+
+static int bd70528_wdt_set_locked(struct wdtbd70528 *w, int enable)
+{
+ struct bd70528 *bd70528;
+
+ bd70528 = container_of(w->rtc_lock, struct bd70528, rtc_timer_lock);
+ return bd70528->wdt_set(bd70528, enable, NULL);
+}
+
+static int bd70528_wdt_set(struct wdtbd70528 *w, int enable)
+{
+ int ret;
+
+ mutex_lock(w->rtc_lock);
+ ret = bd70528_wdt_set_locked(w, enable);
+ mutex_unlock(w->rtc_lock);
+
+ return ret;
+}
+
+static int bd70528_wdt_start(struct watchdog_device *wdt)
+{
+ struct wdtbd70528 *w = watchdog_get_drvdata(wdt);
+
+ dev_dbg(w->dev, "WDT ping...\n");
+ return bd70528_wdt_set(w, 1);
+}
+
+static int bd70528_wdt_stop(struct watchdog_device *wdt)
+{
+ struct wdtbd70528 *w = watchdog_get_drvdata(wdt);
+
+ dev_dbg(w->dev, "WDT stopping...\n");
+ return bd70528_wdt_set(w, 0);
+}
+
+static int bd70528_wdt_set_timeout(struct watchdog_device *wdt,
+ unsigned int timeout)
+{
+ unsigned int hours;
+ unsigned int minutes;
+ unsigned int seconds;
+ int ret;
+ struct wdtbd70528 *w = watchdog_get_drvdata(wdt);
+
+ seconds = timeout;
+ hours = timeout / (60 * 60);
+ /* Maximum timeout is 1h 59m 59s => hours is 1 or 0 */
+ if (hours)
+ seconds -= (60 * 60);
+ minutes = seconds / 60;
+ seconds = seconds % 60;
+
+ mutex_lock(w->rtc_lock);
+
+ ret = bd70528_wdt_set_locked(w, 0);
+ if (ret)
+ goto out_unlock;
+
+ ret = regmap_update_bits(w->regmap, BD70528_REG_WDT_HOUR,
+BD70528_MASK_WDT_HOUR, hours);
+ if (ret) {
+ dev_err(w->dev, "Failed to set WDT hours\n");
+ goto out_en_unlock;
+ }
+ ret = regmap_update_bits(w->regmap, BD70528_REG_WDT_MINUTE,
+BD70528_MASK_WDT_MINUTE, bin2bcd(minutes));
+ if (ret) {
+ dev_err(w->dev, "Failed to set WDT minutes\n");
+ goto out_en_unlock;
+ }
+ ret = regmap_update_bits(w->regmap, BD70528_REG_WDT_SEC,
+BD70528_MASK_WDT_SEC, bin2bcd(seconds));
+ if (ret)
+ dev_err(w->dev, "Failed to set WDT seconds\n");
+ else
+
[PATCH v8 7/8] power: supply: Initial support for ROHM BD70528 PMIC charger block
ROHM BD70528 PMIC includes battery charger block. Support charger staus queries and doing few basic settings like input current limit and charging current. Signed-off-by: Matti Vaittinen --- drivers/power/supply/Kconfig | 9 + drivers/power/supply/Makefile | 1 + drivers/power/supply/bd70528-charger.c | 745 + 3 files changed, 755 insertions(+) create mode 100644 drivers/power/supply/bd70528-charger.c diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig index e901b9879e7e..903c97a67bf0 100644 --- a/drivers/power/supply/Kconfig +++ b/drivers/power/supply/Kconfig @@ -660,4 +660,13 @@ config FUEL_GAUGE_SC27XX Say Y here to enable support for fuel gauge with SC27XX PMIC chips. +config CHARGER_BD70528 + tristate "ROHM bd70528 charger driver" + depends on MFD_ROHM_BD70528 + default n + help +Say Y here to enable support for getting battery status +information and altering charger configurations from charger +block of the ROHM BD70528 Power Management IC. + endif # POWER_SUPPLY diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile index b731c2a9b695..c60387b04bfa 100644 --- a/drivers/power/supply/Makefile +++ b/drivers/power/supply/Makefile @@ -87,3 +87,4 @@ obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o obj-$(CONFIG_CHARGER_CROS_USBPD) += cros_usbpd-charger.o obj-$(CONFIG_CHARGER_SC2731) += sc2731_charger.o obj-$(CONFIG_FUEL_GAUGE_SC27XX)+= sc27xx_fuel_gauge.o +obj-$(CONFIG_CHARGER_BD70528) += bd70528-charger.o diff --git a/drivers/power/supply/bd70528-charger.c b/drivers/power/supply/bd70528-charger.c new file mode 100644 index ..5abc5ba97ee7 --- /dev/null +++ b/drivers/power/supply/bd70528-charger.c @@ -0,0 +1,745 @@ +// SPDX-License-Identifier: GPL-2.0-or-later +// +// Copyright (C) 2018 ROHM Semiconductors +// +// power-supply driver for ROHM BD70528 PMIC + +/* + * BD70528 charger HW state machine. + * + * The thermal shutdown state is not drawn. From any other state but + * battery error and suspend it is possible to go to TSD/TMP states + * if temperature is out of bounds. + * + * CHG_RST = H + * or CHG_EN=L + * or (DCIN2_UVLO=L && DCIN1_UVLO=L) + * or (DCIN2_OVLO=H & DCIN1_UVKLO=L) + * + * +--+ +--+ + * | | | | + * | Any state +---> |Suspend | + * | | | | + * +--+ +--+---+ + * | + * CHG_EN = H && BAT_DET = H &&| + * No errors (temp, bat_ov, UVLO, | + * OVLO...)| + * | + * BAT_OV or +-v--+ + * (DBAT && TTRI)|| + * +-+ Trickle Charge | <---+ + * | || | + * | +---++ | + * | | | + * | | ^| + * |V_BAT > VTRI_TH | | VBAT < VTRI_TH - 50mV | + * | | || + * | v || + * | || + * | BAT_OV or +--++ | + * | (DBAT && TFST) | | | + * | ++ Fast Charge | | + * | || | | + * v v++--+ | + *| | + *++ ILIM_DET=L |^ ILIM_DET| + *|| & CV_DET=H || or CV_DET=L | + *| Battery Error | & VBAT > || or VBAT < VRECHG_TH | + *|| VRECHG_TH || or IBAT > IFST/x | + *++ & IBAT < || | + * IFST/x v| | + * ^ | | + * | +-+-+ | + * | | | | + * +---+ Top OFF | | + * BAT_OV = H or| | | + * (DBAT && TFST) +-+-+ | + * | | + * Stay top-off for 15s | | + * v | + * | + *
[PATCH v8 5/8] gpio: Initial support for ROHM bd70528 GPIO block
ROHM BD70528 PMIC has 4 GPIO pins. Allow them to be
controlled by GPIO framework.
IRQs are handled by regmap-irq and GPIO driver is not
aware of the irq usage.
Signed-off-by: Matti Vaittinen
Reviewed-by: Linus Walleij
---
drivers/gpio/Kconfig| 11 +++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-bd70528.c | 232
3 files changed, 244 insertions(+)
create mode 100644 drivers/gpio/gpio-bd70528.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b5a2845347ec..c82187648630 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -962,6 +962,17 @@ config GPIO_ARIZONA
help
Support for GPIOs on Wolfson Arizona class devices.
+config GPIO_BD70528
+ tristate "ROHM BD70528 GPIO support"
+ depends on MFD_ROHM_BD70528
+ help
+ Support for GPIOs on ROHM BD70528 PMIC. There are four GPIOs
+ available on the ROHM PMIC in total. The GPIOs can also
+ generate interrupts.
+
+ This driver can also be built as a module. If so, the module
+ will be called gpio-bd70528.
+
config GPIO_BD9571MWV
tristate "ROHM BD9571 GPIO support"
depends on MFD_BD9571MWV
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 37628f8dbf70..6f12c83598fc 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_GPIO_ATH79) += gpio-ath79.o
obj-$(CONFIG_GPIO_ASPEED) += gpio-aspeed.o
obj-$(CONFIG_GPIO_RASPBERRYPI_EXP) += gpio-raspberrypi-exp.o
obj-$(CONFIG_GPIO_BCM_KONA)+= gpio-bcm-kona.o
+obj-$(CONFIG_GPIO_BD70528) += gpio-bd70528.o
obj-$(CONFIG_GPIO_BD9571MWV) += gpio-bd9571mwv.o
obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
diff --git a/drivers/gpio/gpio-bd70528.c b/drivers/gpio/gpio-bd70528.c
new file mode 100644
index ..c00d5d67dd74
--- /dev/null
+++ b/drivers/gpio/gpio-bd70528.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 ROHM Semiconductors
+// gpio-bd70528.c ROHM BD70528MWV gpio driver
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GPIO_IN_REG(offset) (BD70528_REG_GPIO1_IN + offset*2)
+#define GPIO_OUT_REG(offset) (BD70528_REG_GPIO1_OUT + offset*2)
+
+struct bd70528_gpio {
+ struct rohm_regmap_dev chip;
+ struct gpio_chip gpio;
+};
+
+static int bd70528_set_debounce(struct bd70528_gpio *bdgpio,
+ unsigned int offset, unsigned int debounce)
+{
+ u8 val;
+
+ switch (debounce) {
+ case 0:
+ val = BD70528_DEBOUNCE_DISABLE;
+ break;
+ case 1 ... 15:
+ val = BD70528_DEBOUNCE_15MS;
+ break;
+ case 16 ... 30:
+ val = BD70528_DEBOUNCE_30MS;
+ break;
+ case 31 ... 50:
+ val = BD70528_DEBOUNCE_50MS;
+ break;
+ default:
+ dev_err(bdgpio->chip.dev,
+ "Invalid debouce value %u\n", debounce);
+ return -EINVAL;
+ }
+ return regmap_update_bits(bdgpio->chip.regmap, GPIO_IN_REG(offset),
+BD70528_DEBOUNCE_MASK, val);
+}
+
+static int bd70528_get_direction(struct gpio_chip *chip, unsigned int offset)
+{
+ struct bd70528_gpio *bdgpio = gpiochip_get_data(chip);
+ int val, ret;
+
+ /* Do we need to do something to IRQs here? */
+ ret = regmap_read(bdgpio->chip.regmap, GPIO_OUT_REG(offset), );
+ if (ret) {
+ dev_err(bdgpio->chip.dev, "Could not read gpio direction\n");
+ return ret;
+ }
+
+ return !(val & BD70528_GPIO_OUT_EN_MASK);
+}
+
+static int bd70528_gpio_set_config(struct gpio_chip *chip, unsigned int offset,
+ unsigned long config)
+{
+ struct bd70528_gpio *bdgpio = gpiochip_get_data(chip);
+
+ switch (pinconf_to_config_param(config)) {
+ case PIN_CONFIG_DRIVE_OPEN_DRAIN:
+ return regmap_update_bits(bdgpio->chip.regmap,
+ GPIO_OUT_REG(offset),
+ BD70528_GPIO_DRIVE_MASK,
+ BD70528_GPIO_OPEN_DRAIN);
+ break;
+ case PIN_CONFIG_DRIVE_PUSH_PULL:
+ return regmap_update_bits(bdgpio->chip.regmap,
+ GPIO_OUT_REG(offset),
+ BD70528_GPIO_DRIVE_MASK,
+ BD70528_GPIO_PUSH_PULL);
+ break;
+ case PIN_CONFIG_INPUT_DEBOUNCE:
+ return bd70528_set_debounce(bdgpio, offset,
+ pinconf_to_config_argument(config));
+ break;
+ default:
+ break;
+ }
+ return -ENOTSUPP;
+}
+
+static int
[PATCH v8 6/8] rtc: bd70528: Initial support for ROHM bd70528 RTC
Support RTC block in ROHM bd70528 power management IC. Support
getting and setting the time and date as well as arming an alarm
which can also be used to wake the PMIC from standby state.
HW supports wake interrupt only for the next 24 hours (sec, minute
and hour information only) so we limit also the alarm interrupt to
this 24 hours for the sake of consistency.
Signed-off-by: Matti Vaittinen
Acked-by: Alexandre Belloni
---
drivers/rtc/Kconfig | 8 +
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-bd70528.c | 500 ++
3 files changed, 509 insertions(+)
create mode 100644 drivers/rtc/rtc-bd70528.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 225b0b8516f3..df6211cbd83f 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -487,6 +487,14 @@ config RTC_DRV_M41T80_WDT
help
If you say Y here you will get support for the
watchdog timer in the ST M41T60 and M41T80 RTC chips series.
+config RTC_DRV_BD70528
+ tristate "ROHM BD70528 PMIC RTC"
+ help
+ If you say Y here you will get support for the RTC
+ on ROHM BD70528 Power Management IC.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-bd70528.
config RTC_DRV_BQ32K
tristate "TI BQ32000"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index df022d820bee..740b13840913 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_RTC_DRV_ASM9260) += rtc-asm9260.o
obj-$(CONFIG_RTC_DRV_AT91RM9200)+= rtc-at91rm9200.o
obj-$(CONFIG_RTC_DRV_AT91SAM9) += rtc-at91sam9.o
obj-$(CONFIG_RTC_DRV_AU1XXX) += rtc-au1xxx.o
+obj-$(CONFIG_RTC_DRV_BD70528) += rtc-bd70528.o
obj-$(CONFIG_RTC_DRV_BQ32K)+= rtc-bq32k.o
obj-$(CONFIG_RTC_DRV_BQ4802) += rtc-bq4802.o
obj-$(CONFIG_RTC_DRV_BRCMSTB) += rtc-brcmstb-waketimer.o
diff --git a/drivers/rtc/rtc-bd70528.c b/drivers/rtc/rtc-bd70528.c
new file mode 100644
index ..2917a2fe685e
--- /dev/null
+++ b/drivers/rtc/rtc-bd70528.c
@@ -0,0 +1,500 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Copyright (C) 2018 ROHM Semiconductors
+//
+// RTC driver for ROHM BD70528 PMIC
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * We read regs RTC_SEC => RTC_YEAR
+ * this struct is ordered according to chip registers.
+ * Keep it u8 only to avoid padding issues.
+ */
+struct bd70528_rtc_day {
+ u8 sec;
+ u8 min;
+ u8 hour;
+} __packed;
+
+struct bd70528_rtc_data {
+ struct bd70528_rtc_day time;
+ u8 week;
+ u8 day;
+ u8 month;
+ u8 year;
+} __packed;
+
+struct bd70528_rtc_wake {
+ struct bd70528_rtc_day time;
+ u8 ctrl;
+} __packed;
+
+struct bd70528_rtc_alm {
+ struct bd70528_rtc_data data;
+ u8 alm_mask;
+ u8 alm_repeat;
+} __packed;
+
+struct bd70528_rtc {
+ struct bd70528 *mfd;
+ struct device *dev;
+};
+
+static int bd70528_set_wake(struct bd70528 *bd70528,
+ int enable, int *old_state)
+{
+ int ret;
+ unsigned int ctrl_reg;
+
+ ret = regmap_read(bd70528->chip.regmap, BD70528_REG_WAKE_EN, _reg);
+ if (ret)
+ return ret;
+
+ if (old_state) {
+ if (ctrl_reg & BD70528_MASK_WAKE_EN)
+ *old_state |= BD70528_WAKE_STATE_BIT;
+ else
+ *old_state &= ~BD70528_WAKE_STATE_BIT;
+
+ if (!enable == !(*old_state & BD70528_WAKE_STATE_BIT))
+ return 0;
+ }
+
+ if (enable)
+ ctrl_reg |= BD70528_MASK_WAKE_EN;
+ else
+ ctrl_reg &= ~BD70528_MASK_WAKE_EN;
+
+ return regmap_write(bd70528->chip.regmap, BD70528_REG_WAKE_EN,
+ ctrl_reg);
+}
+
+static int bd70528_set_elapsed_tmr(struct bd70528 *bd70528,
+ int enable, int *old_state)
+{
+ int ret;
+ unsigned int ctrl_reg;
+
+ /*
+* TBD
+* What is the purpose of elapsed timer ?
+* Is the timeout registers counting down, or is the disable - re-enable
+* going to restart the elapsed-time counting? If counting is restarted
+* the timeout should be decreased by the amount of time that has
+* elapsed since starting the timer. Maybe we should store the monotonic
+* clock value when timer is started so that if RTC is set while timer
+* is armed we could do the compensation. This is a hack if RTC/system
+* clk are drifting. OTOH, RTC controlled via I2C is in any case
+* inaccurate...
+*/
+ ret = regmap_read(bd70528->chip.regmap, BD70528_REG_ELAPSED_TIMER_EN,
+ _reg);
+ if (ret)
+ return ret;
+
+ if (old_state) {
+ if (ctrl_reg & BD70528_MASK_ELAPSED_TIMER_EN)
+
[PATCH v8 4/8] devicetree: bindings: Document first ROHM BD70528 bindings
Document bindings for regulators (3 bucks, 3 LDOs and 2 LED
drivers) and 4 GPIO pins which can be configured for I/O or
as interrupt sources withe configurable trigger levels.
Signed-off-by: Matti Vaittinen
Reviewed-by: Rob Herring
Acked-by: Linus Walleij
---
.../devicetree/bindings/mfd/rohm,bd70528-pmic.txt | 102 +
1 file changed, 102 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt
diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt
b/Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt
new file mode 100644
index ..f80be7e40184
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt
@@ -0,0 +1,102 @@
+* ROHM BD70528 Power Management Integrated Circuit bindings
+
+BD70528MWV is an ultra-low Iq general purpose single-chip power management IC
+for battery-powered portable devices. The IC integrates 3 ultra-low current
+consumption buck converters, 3 LDOs and 2 LED Drivers. Also included are 4
+GPIOs, a real-time clock (RTC), a 32kHz clock gate, high-accuracy VREF
+for use with an external ADC, flexible dual-input power path, 10 bits SAR ADC
+for battery temperature monitor and 1S battery charger with scalable charge
+currents.
+
+Required properties:
+ - compatible : Should be "rohm,bd70528"
+ - reg : I2C slave address.
+ - interrupts : The interrupt line the device is connected to.
+ - interrupt-controller: To indicate bd70528 acts as an interrupt
controller.
+ - #interrupt-cells: Should be 2. usage is compliant to the 2 cells
+ variant of ../interrupt-controller/interrupts.txt
+ - gpio-controller : To indicate bd70528 acts as a gpio controller.
+ - #gpio-cells : Should be 2. The first cell is the pin number and
+ the second cell is used to specify flags. See
+ ../gpio/gpio.txt for more information.
+ - #clock-cells: Should be 0.
+ - regulators: : List of child nodes that specify the regulators.
+ Please see ../regulator/rohm,bd70528-regulator.txt
+
+Optional properties:
+ - clock-output-names : Should contain name for output clock.
+
+Example:
+/* external oscillator */
+osc: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <1>;
+ clock-frequency = <32768>;
+ clock-output-names = "osc";
+};
+
+pmic: pmic@4b {
+ compatible = "rohm,bd70528";
+ reg = <0x4b>;
+ interrupt-parent = <>;
+ interrupts = <29 GPIO_ACTIVE_LOW>;
+ clocks = < 0>;
+ #clock-cells = <0>;
+ clock-output-names = "bd70528-32k-out";
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <340>;
+ regulator-boot-on;
+ regulator-ramp-delay = <125>;
+ };
+ buck2: BUCK2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-ramp-delay = <125>;
+ };
+ buck3: BUCK3 {
+ regulator-name = "buck3";
+ regulator-min-microvolt = <80>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-ramp-delay = <250>;
+ };
+ ldo1: LDO1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <165>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ };
+ ldo2: LDO2 {
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <165>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ };
+
+ ldo3: LDO3 {
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <165>;
+ regulator-max-microvolt = <330>;
+ };
+ led_ldo1: LED_LDO1 {
+ regulator-name = "led_ldo1";
+ regulator-min-microvolt = <20>;
+ regulator-max-microvolt = <30>;
+ };
+ led_ldo2: LED_LDO2 {
+ regulator-name = "led_ldo2";
+ regulator-min-microvolt = <20>;
+ regulator-max-microvolt
[PATCH v8 2/8] mfd: bd70528: Support ROHM bd70528 PMIC - core
ROHM BD70528MWV is an ultra-low quiescent current general
purpose single-chip power management IC for battery-powered
portable devices.
Add MFD core which enables chip access for following subdevices:
- regulators/LED drivers
- battery-charger
- gpios
- 32.768kHz clk
- RTC
- watchdog
Signed-off-by: Matti Vaittinen
---
drivers/mfd/Kconfig | 17 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/rohm-bd70528.c | 410 +++
include/linux/mfd/rohm-bd70528.h | 392 +
4 files changed, 820 insertions(+)
create mode 100644 drivers/mfd/rohm-bd70528.c
create mode 100644 include/linux/mfd/rohm-bd70528.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f461460a2aeb..f1a0574cebb1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1847,6 +1847,23 @@ config MFD_ROHM_BD718XX
NXP i.MX8. It contains 8 BUCK outputs and 7 LDOs, voltage monitoring
and emergency shut down as well as 32,768KHz clock output.
+config MFD_ROHM_BD70528
+ tristate "ROHM BD70528 Power Management IC"
+ depends on I2C=y
+ depends on OF
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ select MFD_CORE
+ help
+ Select this option to get support for the ROHM BD70528 Power
+ Management IC. BD71837 is general purpose single-chip power
+ management IC for battery-powered portable devices. It contains
+ 3 ultra-low current consumption buck converters, 3 LDOs and 2 LED
+ Drivers. Also included are 4 GPIOs, a real-time clock (RTC), a 32kHz
+ crystal oscillator, high-accuracy VREF for use with an external ADC,
+ 10 bits SAR ADC for battery temperature monitor and 1S battery
+ charger.
+
config MFD_STM32_LPTIMER
tristate "Support for STM32 Low-Power Timer"
depends on (ARCH_STM32 && OF) || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 12980a4ad460..fc9b1408e39b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -241,4 +241,5 @@ obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o
obj-$(CONFIG_MFD_SC27XX_PMIC) += sprd-sc27xx-spi.o
obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o
obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
+obj-$(CONFIG_MFD_ROHM_BD70528) += rohm-bd70528.o
diff --git a/drivers/mfd/rohm-bd70528.c b/drivers/mfd/rohm-bd70528.c
new file mode 100644
index ..580164addeeb
--- /dev/null
+++ b/drivers/mfd/rohm-bd70528.c
@@ -0,0 +1,410 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+//
+// Copyright (C) 2018 ROHM Semiconductors
+//
+// ROHM BD70528 PMIC driver
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BD70528_INT_RES(_reg, _name) \
+ { \
+ .start = (_reg),\
+ .end = (_reg), \
+ .name = (_name),\
+ .flags = IORESOURCE_IRQ,\
+ }
+
+static const struct resource rtc_irqs[] = {
+ BD70528_INT_RES(BD70528_INT_RTC_ALARM, "bd70528-rtc-alm"),
+ BD70528_INT_RES(BD70528_INT_ELPS_TIM, "bd70528-elapsed-timer"),
+};
+
+static const struct resource charger_irqs[] = {
+ BD70528_INT_RES(BD70528_INT_BAT_OV_RES, "bd70528-bat-ov-res"),
+ BD70528_INT_RES(BD70528_INT_BAT_OV_DET, "bd70528-bat-ov-det"),
+ BD70528_INT_RES(BD70528_INT_DBAT_DET, "bd70528-bat-dead"),
+ BD70528_INT_RES(BD70528_INT_BATTSD_COLD_RES, "bd70528-bat-warmed"),
+ BD70528_INT_RES(BD70528_INT_BATTSD_COLD_DET, "bd70528-bat-cold"),
+ BD70528_INT_RES(BD70528_INT_BATTSD_HOT_RES, "bd70528-bat-cooled"),
+ BD70528_INT_RES(BD70528_INT_BATTSD_HOT_DET, "bd70528-bat-hot"),
+ BD70528_INT_RES(BD70528_INT_CHG_TSD, "bd70528-chg-tshd"),
+ BD70528_INT_RES(BD70528_INT_BAT_RMV, "bd70528-bat-removed"),
+ BD70528_INT_RES(BD70528_INT_BAT_DET, "bd70528-bat-detected"),
+ BD70528_INT_RES(BD70528_INT_DCIN2_OV_RES, "bd70528-dcin2-ov-res"),
+ BD70528_INT_RES(BD70528_INT_DCIN2_OV_DET, "bd70528-dcin2-ov-det"),
+ BD70528_INT_RES(BD70528_INT_DCIN2_RMV, "bd70528-dcin2-removed"),
+ BD70528_INT_RES(BD70528_INT_DCIN2_DET, "bd70528-dcin2-detected"),
+ BD70528_INT_RES(BD70528_INT_DCIN1_RMV, "bd70528-dcin1-removed"),
+ BD70528_INT_RES(BD70528_INT_DCIN1_DET, "bd70528-dcin1-detected"),
+};
+
+static struct mfd_cell bd70528_mfd_cells[] = {
+ { .name = "bd70528-pmic", },
+ { .name = "bd70528-gpio", },
+ /*
+* We use BD71837 driver to drive the clk block. Only differences to
+* BD70528 clock gate are the register address and mask.
+*/
+ { .name = "bd718xx-clk", },
+ { .name = "bd70528-wdt", },
+ {
+ .name = "bd70528-power",
+ .resources = _irqs[0],
+
[PATCH v8 3/8] clk: bd718x7: Support ROHM BD70528 clk block
ROHM BD70528 is an ultra low power PMIC with similar 32K clk as
bd718x7. Only difference (from clk perspective) is register address.
Add support for controlling BD70528 clk using bd718x7 driver.
Signed-off-by: Matti Vaittinen
---
drivers/clk/Kconfig | 6 +++---
drivers/clk/clk-bd718x7.c | 20
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index e5b2fe80eab4..992cfb86f2ca 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -285,10 +285,10 @@ config COMMON_CLK_STM32H7
config COMMON_CLK_BD718XX
tristate "Clock driver for ROHM BD718x7 PMIC"
- depends on MFD_ROHM_BD718XX
+ depends on MFD_ROHM_BD718XX || MFD_ROHM_BD70528
help
- This driver supports ROHM BD71837 and ROHM BD71847
- PMICs clock gates.
+ This driver supports ROHM BD71837, ROHM BD71847 and
+ ROHM BD70528 PMICs clock gates.
source "drivers/clk/actions/Kconfig"
source "drivers/clk/bcm/Kconfig"
diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-bd718x7.c
index 461228ebf703..ae6e5baee330 100644
--- a/drivers/clk/clk-bd718x7.c
+++ b/drivers/clk/clk-bd718x7.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -86,9 +87,20 @@ static int bd71837_clk_probe(struct platform_device *pdev)
dev_err(>dev, "No parent clk found\n");
return -EINVAL;
}
-
- c->reg = BD718XX_REG_OUT32K;
- c->mask = BD718XX_OUT32K_EN;
+ switch (mfd->chip_type) {
+ case ROHM_CHIP_TYPE_BD71837:
+ case ROHM_CHIP_TYPE_BD71847:
+ c->reg = BD718XX_REG_OUT32K;
+ c->mask = BD718XX_OUT32K_EN;
+ break;
+ case ROHM_CHIP_TYPE_BD70528:
+ c->reg = BD70528_REG_CLK_OUT;
+ c->mask = BD70528_CLK_OUT_EN_MASK;
+ break;
+ default:
+ dev_err(>dev, "Unknown clk chip\n");
+ return -EINVAL;
+ }
c->mfd = mfd;
c->pdev = pdev;
c->hw.init =
@@ -119,5 +131,5 @@ static struct platform_driver bd71837_clk = {
module_platform_driver(bd71837_clk);
MODULE_AUTHOR("Matti Vaittinen ");
-MODULE_DESCRIPTION("BD71837/BD71847 chip clk driver");
+MODULE_DESCRIPTION("BD71837/BD71847/BD70528 chip clk driver");
MODULE_LICENSE("GPL");
--
2.14.3
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
[PATCH v8 1/8] mfd: regulator: clk: split rohm-bd718x7.h
Split the bd718x7.h to ROHM common and bd718x7 specific parts
so that we do not need to add same things in every new ROHM
PMIC header. Please note that this change requires changes also
in bd718x7 sub-device drivers for regulators and clk.
Signed-off-by: Matti Vaittinen
Acked-by: Mark Brown
Acked-by: Stephen Boyd
---
Please note that I maintained the acks from Mark and Stephen even
though this is a squash of 3 commits and both Mark and Stephen had
only acked one of the patches. (The patch which touched their area
clk for Stephen, regulators for Mark). I interpreted their acks as
'the split is in general Ok and portion I am interested in is fine'
and thus maintained the acks. Please let me know if this is not Ok.
drivers/clk/clk-bd718x7.c | 6 +++---
drivers/mfd/rohm-bd718x7.c| 23 ---
drivers/regulator/bd718x7-regulator.c | 24
include/linux/mfd/rohm-bd718x7.h | 22 --
include/linux/mfd/rohm-generic.h | 20
5 files changed, 55 insertions(+), 40 deletions(-)
create mode 100644 include/linux/mfd/rohm-generic.h
diff --git a/drivers/clk/clk-bd718x7.c b/drivers/clk/clk-bd718x7.c
index 60422c72d142..461228ebf703 100644
--- a/drivers/clk/clk-bd718x7.c
+++ b/drivers/clk/clk-bd718x7.c
@@ -17,7 +17,7 @@ struct bd718xx_clk {
u8 reg;
u8 mask;
struct platform_device *pdev;
- struct bd718xx *mfd;
+ struct rohm_regmap_dev *mfd;
};
static int bd71837_clk_set(struct clk_hw *hw, int status)
@@ -68,7 +68,7 @@ static int bd71837_clk_probe(struct platform_device *pdev)
int rval = -ENOMEM;
const char *parent_clk;
struct device *parent = pdev->dev.parent;
- struct bd718xx *mfd = dev_get_drvdata(parent);
+ struct rohm_regmap_dev *mfd = dev_get_drvdata(parent);
struct clk_init_data init = {
.name = "bd718xx-32k-out",
.ops = _clk_ops,
@@ -119,5 +119,5 @@ static struct platform_driver bd71837_clk = {
module_platform_driver(bd71837_clk);
MODULE_AUTHOR("Matti Vaittinen ");
-MODULE_DESCRIPTION("BD71837 chip clk driver");
+MODULE_DESCRIPTION("BD71837/BD71847 chip clk driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/rohm-bd718x7.c b/drivers/mfd/rohm-bd718x7.c
index a29d529a96f4..7beb444a57cb 100644
--- a/drivers/mfd/rohm-bd718x7.c
+++ b/drivers/mfd/rohm-bd718x7.c
@@ -98,18 +98,19 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
return -ENOMEM;
bd718xx->chip_irq = i2c->irq;
- bd718xx->chip_type = (unsigned int)(uintptr_t)
+ bd718xx->chip.chip_type = (unsigned int)(uintptr_t)
of_device_get_match_data(>dev);
- bd718xx->dev = >dev;
+ bd718xx->chip.dev = >dev;
dev_set_drvdata(>dev, bd718xx);
- bd718xx->regmap = devm_regmap_init_i2c(i2c, _regmap_config);
- if (IS_ERR(bd718xx->regmap)) {
+ bd718xx->chip.regmap = devm_regmap_init_i2c(i2c,
+ _regmap_config);
+ if (IS_ERR(bd718xx->chip.regmap)) {
dev_err(>dev, "regmap initialization failed\n");
- return PTR_ERR(bd718xx->regmap);
+ return PTR_ERR(bd718xx->chip.regmap);
}
- ret = devm_regmap_add_irq_chip(>dev, bd718xx->regmap,
+ ret = devm_regmap_add_irq_chip(>dev, bd718xx->chip.regmap,
bd718xx->chip_irq, IRQF_ONESHOT, 0,
_irq_chip, >irq_data);
if (ret) {
@@ -118,7 +119,7 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
}
/* Configure short press to 10 milliseconds */
- ret = regmap_update_bits(bd718xx->regmap,
+ ret = regmap_update_bits(bd718xx->chip.regmap,
BD718XX_REG_PWRONCONFIG0,
BD718XX_PWRBTN_PRESS_DURATION_MASK,
BD718XX_PWRBTN_SHORT_PRESS_10MS);
@@ -129,7 +130,7 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
}
/* Configure long press to 10 seconds */
- ret = regmap_update_bits(bd718xx->regmap,
+ ret = regmap_update_bits(bd718xx->chip.regmap,
BD718XX_REG_PWRONCONFIG1,
BD718XX_PWRBTN_PRESS_DURATION_MASK,
BD718XX_PWRBTN_LONG_PRESS_10S);
@@ -149,7 +150,7 @@ static int bd718xx_i2c_probe(struct i2c_client *i2c,
button.irq = ret;
- ret = devm_mfd_add_devices(bd718xx->dev, PLATFORM_DEVID_AUTO,
+ ret = devm_mfd_add_devices(bd718xx->chip.dev, PLATFORM_DEVID_AUTO,
bd718xx_mfd_cells,
ARRAY_SIZE(bd718xx_mfd_cells), NULL, 0,
regmap_irq_get_domain(bd718xx->irq_data));
@@ -162,11 +163,11 @@ static int bd718xx_i2c_probe(struct i2c_client
Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API
On Tue, Feb 5, 2019 at 7:35 PM Hans Verkuil wrote: > > On 2/5/19 10:31 AM, Tomasz Figa wrote: > > On Tue, Feb 5, 2019 at 6:00 PM Hans Verkuil wrote: > >> > >> On 2/5/19 7:26 AM, Tomasz Figa wrote: > >>> On Fri, Feb 1, 2019 at 12:18 AM Nicolas Dufresne > >>> wrote: > > Le jeudi 31 janvier 2019 à 22:34 +0900, Tomasz Figa a écrit : > > On Thu, Jan 31, 2019 at 9:42 PM Philipp Zabel > > wrote: > >> Hi Nicolas, > >> > >> On Wed, 2019-01-30 at 10:32 -0500, Nicolas Dufresne wrote: > >>> Le mercredi 30 janvier 2019 à 15:17 +0900, Tomasz Figa a écrit : > > I don't remember saying that, maybe I meant to say there might be a > > workaround ? > > > > For the fact, here we queue the headers (or first frame): > > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2videodec.c#L624 > > > > Then few line below this helper does G_FMT internally: > > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2videodec.c#L634 > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2object.c#L3907 > > > > And just plainly fails if G_FMT returns an error of any type. This > > was > > how Kamil designed it initially for MFC driver. There was no other > > alternative back then (no EAGAIN yet either). > > Hmm, was that ffmpeg then? > > So would it just set the OUTPUT width and height to 0? Does it mean > that gstreamer doesn't work with coda and mtk-vcodec, which don't > have > such wait in their g_fmt implementations? > >>> > >>> I don't know for MTK, I don't have the hardware and didn't integrate > >>> their vendor pixel format. For the CODA, I know it works, if there is > >>> no wait in the G_FMT, then I suppose we are being really lucky with > >>> the > >>> timing (it would be that the drivers process the SPS/PPS > >>> synchronously, > >>> and a simple lock in the G_FMT call is enough to wait). Adding Philipp > >>> in CC, he could explain how this works, I know they use GStreamer in > >>> production, and he would have fixed GStreamer already if that was > >>> causing important issue. > >> > >> CODA predates the width/height=0 rule on the coded/OUTPUT queue. > >> It currently behaves more like a traditional mem2mem device. > > > > The rule in the latest spec is that if width/height is 0 then CAPTURE > > format is determined only after the stream is parsed. Otherwise it's > > instantly deduced from the OUTPUT resolution. > > > >> When width/height is set via S_FMT(OUT) or output crop selection, the > >> driver will believe it and set the same (rounded up to macroblock > >> alignment) on the capture queue without ever having seen the SPS. > > > > That's why I asked whether gstreamer sets width and height of OUTPUT > > to non-zero values. If so, there is no regression, as the specs mimic > > the coda behavior. > > I see, with Philipp's answer it explains why it works. Note that > GStreamer sets the display size on the OUTPUT format (in fact we pass > as much information as we have, because a) it's generic code and b) it > will be needed someday when we enable pre-allocation (REQBUFS before > SPS/PPS is passed, to avoid the setup delay introduce by allocation, > mostly seen with CMA base decoder). In any case, the driver reported > display size should always be ignored in GStreamer, the only > information we look at is the G_SELECTION for the case the x/y or the > cropping rectangle is non-zero. > > Note this can only work if the capture queue is not affected by the > coded size, or if the round-up made by the driver is bigger or equal to > that coded size. I believe CODA falls into the first category, since > the decoding happens in a separate set of buffers and are then de-tiled > into the capture buffers (if understood correctly). > >>> > >>> Sounds like it would work only if coded size is equal to the visible > >>> size (that GStreamer sets) rounded up to full macroblocks. Non-zero x > >>> or y in the crop could be problematic too. > >>> > >>> Hans, what's your view on this? Should we require G_FMT(CAPTURE) to > >>> wait until a format becomes available or the OUTPUT queue runs out of > >> > >> You mean CAPTURE queue? If not, then I don't understand that part. > > > > No, I exactly meant the OUTPUT queue. The behavior of s5p-mfc in case > > of the format not being detected yet is to waits for any pending > > bitstream buffers to be processed by the decoder before returning an > > error. > > > > See > > https://elixir.bootlin.com/linux/v5.0-rc5/source/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#L329 > > It blocks?!
Re: [Linaro-mm-sig] [PATCH 2/4] staging: android: ion: Restrict cache maintenance to dma mapped memory
The CPU may only access DMA mapped memory if ownership has been
transferred back to the CPU using dma_sync_{single,sg}_to_cpu, and then
before the device can access it again ownership needs to be transferred
back to the device using dma_sync_{single,sg}_to_device.
> I've run some testing, and this patch does indeed fix the crash in
> dma_sync_sg_for_cpu when it tried to use the 0 dma_address from the sg
> list.
>
> Tested-by: Ørjan Eide
>
> I tested this on an older kernel, v4.14, since the dma-mapping code
> moved, in v4.19, to ignore the dma_address and instead use sg_phys() to
> get a valid address from the page, which is always valid in the ion sg
> lists. While this wouldn't crash on newer kernels, it's still good to
> avoid the unnecessary work when no CMO is needed.
Can you also test is with CONFIG_DMA_API_DEBUG enabled, as that should
catch all the usual mistakes in DMA API usage, including the one found?
[ANNOUNCE] Git v2.21.0-rc0
An early preview release Git v2.21.0-rc0 is now available for testing at the usual places. It is comprised of 426 non-merge commits since v2.20.0, contributed by 57 people, 13 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.21.0-rc0' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://github.com/gitster/git New contributors whose contributions weren't in v2.20.0 are as follows. Welcome to the Git development community! Arti Zirk, Brandon Richardson, Chayoung You, Denis Ovsienko, Erin Dahlgren, Force Charlie, Frank Dana, Issac Trotts, Laura Abbott, Patrick Hogg, Peter Osterlund, Shahzad Lone, and Slavica Djukic. Returning contributors who helped this release are as follows. Thanks for your continued support. Ævar Arnfjörð Bjarmason, Ben Peart, Brandon Williams, brian m. carlson, Carlo Marcelo Arenas Belón, Christian Couder, David Turner, Derrick Stolee, Elijah Newren, Eric Sunshine, Eric Wong, Jean-Noël Avila, Jeff King, Johannes Schindelin, Jonathan Nieder, Jonathan Tan, Josh Steadmon, Junio C Hamano, Kim Gybels, Kyle Meyer, Linus Torvalds, Luke Diamand, Martin Ågren, Masaya Suzuki, Matthew DeVore, Matthieu Moy, Max Kirillov, Nguyễn Thái Ngọc Duy, Olga Telezhnaya, Orgad Shaneh, Phillip Wood, Pranit Bauva, Ramsay Jones, Randall S. Becker, René Scharfe, Sebastian Staudt, Sergey Organov, Stefan Beller, Stephen P. Smith, Sven van Haastregt, SZEDER Gábor, Thomas Braun, Thomas Gummerer, and Torsten Bögershausen. Git 2.21 Release Notes (draft) == Backward Compatibility Notes * Historically, the "-m" (mainline) option can only be used for "git cherry-pick" and "git revert" when working with a merge commit. This version of Git no longer warns or errors out when working with a single-parent commit, as long as the argument to the "-m" option is 1 (i.e. it has only one parent, and the request is to pick or revert relative to that first parent). Scripts that relied on the behaviour may get broken with this change. Updates since v2.20 --- UI, Workflows & Features * The "http.version" configuration variable can be used with recent enough versions of cURL library to force the version of HTTP used to talk when fetching and pushing. * Small fixes and features for fast-export and fast-import, mostly on the fast-export side has been made. * "git push $there $src:$dst" rejects when $dst is not a fully qualified refname and not clear what the end user meant. The codepath has been taught to give a clearer error message, and also guess where the push should go by taking the type of the pushed object into account (e.g. a tag object would want to go under refs/tags/). * "git checkout [] path..." learned to report the number of paths that have been checked out of the index or the tree-ish, which gives it the same degree of noisy-ness as the case in which the command checks out a branch. * "git quiltimport" learned "--keep-non-patch" option. * "git worktree remove" and "git worktree move" refused to work when there is a submodule involved. This has been loosened to ignore uninitialized submodules. * "git cherry-pick -m1" was forbidden when picking a non-merge commit, even though there _is_ parent number 1 for such a commit. This was done to avoid mistakes back when "cherry-pick" was about picking a single commit, but is no longer useful with "cherry-pick" that can pick a range of commits. Now the "-m$num" option is allowed when picking any commit, as long as $num names an existing parent of the commit. * Update "git multimail" from the upstream. * "git p4" update. * The "--format=" option of for-each-ref, branch and tag learned to show a few more traits of objects that can be learned by the object_info API. * "git rebase -i" learned to re-execute a command given with 'exec' to run after it failed the last time. * "git diff --color-moved-ws" updates. * Custom userformat "log --format" learned %S atom that stands for the tip the traversal reached the commit from, i.e. --source. * "git instaweb" learned to drive http.server that comes with "batteries included" Python installation (both Python2 & 3). * A new encoding UTF-16LE-BOM has been invented to force encoding to UTF-16 with BOM in little endian byte order, which cannot be directly generated by using iconv. * A new date format "--date=human" that morphs its output depending on how far the time is from the current time has been introduced. "--date=auto" can be used to use this new format when the output is going to the pager or to the
[PATCH v8 0/8] support ROHM BD70528 PMIC
Patch series introducing support for ROHM BD70528 PMIC ROHM BD70528 is a programmable Power Management IC for battery powered 'ultra low power' systems like the pre-announced NXP i.MX7 ULP. This patch series introduces support for the PMIC. Please note that this driver only supports HW setup where PMIC is connected to I2C on A7 core. The other scenario is to use M4 as a power manager and connect pmic to M4. On such setups the A7 can only access pmic via M4 core using RPMSG virtio. Such setup depends on RPMSG implementation on M4 core and is currently not supported by this patch series. RTC block of the bd70528 can support 'wake' irq which wakes PMIC from standby state. Wake irq's can be armed to wake up system up to 24 hours from arming. bd70528 can also generate alarm interrupts which can be armed to occur years after triggering. The RTC driver does always arm both the waker and alarm irqs and does not utilize longer period of alarm interrupts. All the RTC timers are limited to occur within the next 24 hours. Any suggestions on more elegant timer support are welcome =) GPIO portion of bd70528 driver adds I/O support for driving GPIO pins or reading the state. The interrupt functionality is provided by regmap-irq. Current GPIO driver is not aware of whether the pin(s) are used for I/O or interrupts and it is up-to driver user to ensure there is no misconfiguration or "double use". The power-supply patch included in series is only poorly tested as I lack of hardware with real battery connected. Reset and ADC are not supported by this series. Changelog v8: - regulators(*), wdt, gpio, rtc, mfd(*) and dt-bindings unchanged. (*)Patches 1-3 squashed to not break bisecting. - removed unnecessary newline from clk - fixed possible use of uninitialized 'reg' from power-supply. Found by 0-day tests and reported by Dan Carpenter. Changelog v7: Only patch 2 changed. - Avoid out-of-array-bounds access at regulator probe if unsupported chip type is passed to bd718x7 regulator driver. Changelog v6: Only patch 10 changed. - styling fixes pointed by Gunter Roeck - dropped RFC tag Changelog v5 (RFC): Only patch 7 changed. - Explained why lock is not needed at GPIO value getting - removed ampersands from function pointer assignments. Changelog v4 (RFC): patches 1,2,3,4,5,10 are unchanged from v3 DT-binding fixes suggested by Rob Herring: - drop interrupt-parent - drop clock-frequency - change pmic node name to a generic one RTC: - enable RTC block's irqs before registering rtc GPIO fixes after initial testing: - fix getting GPIO value when direction is output POWER: - Add ASCII art intended to clarify the charger HW state machine Changelog v3 (RFC): patches 1,2,3,4,5,6,7,8 and 10 are unchanged from v2 RTC fixups suggested by Guenter Roeck: - create bd70528_set_time_locked function in order to simplify error handling and to make mutex lock/unlock path more obvious - don't ignore errors on bd70528_set_time_locked - simplify bd70528_read_alarm enabled condition setting - add __packed to structs where members are mapped to HW registers - remove unnecessary brackets from enable condition in set_wake RTC: fixups suggested by Alessandro Belloni - don't use deprecated devm_rtc_device_register - add alarm_irq_enable callback - add range_min and range_max WDT: - add regmap and mutex pointers to WDT data so that they can be accessed without dereferencing the parent data - remove parent data pointer from WDT data - embed struct watchdog_device into WDT data in order to avoid double allocation. GPIO: - remove unused header as pointed by Linus Walleij POWER: - do not copy the whole MFD data (especially the mutex to avoid all possibilities of accidentally using the copy of a mutex) Changelog v2 (RFC): Mainly feedback from Guenter Roeck: - patches 1, 2, 3, 4, 5, 9 are unchanged. - mfd: own mutex for each bd70528 instance - embed in struct bd70528 - watchdog: do not copy parent device data - watchdog: fix deadlock caused by double locked mutex - watchdog: set initial timeouts and WDT parent information - watchdog: remove unnecessary ping function from ops - watchdog: and the comment regarding it - watchdog: allocate watchdog struct in order to allow multiple WDG instances - rtc: bd70528 fix the order of mutex unlock and re-enabling RTC based timers - rtc: fix the irq mask register address - power: fix the irq mask register address - regulator/regmap-irq: Drop the patches 1, 8 and 9 from original series as those were already applied by Mark Patch 1: split the bd718x7.h to generic and chip specific portions. (breaks compilation without patch 2 and 3) - adapt bd718x7.h changes to bd718x7 regulator driver - adapt bd718x7.h changes to bd718x7 clk driver Patch 2: add MFD core support for bd70528 Patch 3: support bd70528 clk using bd718x7 clk driver Patch 4: document DT bindings for BD70528 Patch 5: support BD70528 GPIO block Patch 6: support
linux-next: Tree for Feb 7
Hi all, Changes since 20190206: The compiler-attributes tree gained a build failure so I used the version from next-20190206. The tegra tree gained a conflict against the imx-mxs tree. The opp tree gained a conflict against the cpufreq-arm tree. The net-next tree gained a conflict against the net tree. The nand tree gained a conflict against the mvebu tree. The scsi-mkp tree gained conflicts against Linus' and the fixes trees. Non-merge commits (relative to Linus' tree): 6151 6812 files changed, 260413 insertions(+), 172340 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 296 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (8834f5600cf3 Linux 5.0-rc5) Merging fixes/master (d8d0c3a7f601 x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (6db2983cd806 kallsyms: Handle too long symbols in kallsyms.c) Merging arc-current/for-curr (3e45ea2a074f ARCv2: entry: exception prologue freeing up reg improvement) Merging arm-current/fixes (1b5ba3507842 ARM: 8824/1: fix a migrating irq bug when hotplug cpu) Merging arm64-fixes/for-next/fixes (f7daa9c8fd19 arm64: hibernate: Clean the __hyp_text to PoC after resume) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (5a3840a470c4 powerpc/papr_scm: Use the correct bind address) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (2b1f86bf741a MAINTAINERS: add maintainer for SFF/SFP/SFP+ support) Merging bpf/master (0429f237ce08 Merge branch 's390-qeth-fixes') Merging ipsec/master (f75a2804da39 xfrm: destroy xfrm_state synchronously on net exit path) Merging netfilter/master (bdcc5bc25548 mISDN: fix a race in dev_expire_timer()) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (8c22d81d5535 MAINTAINERS: add entry for redpine wireless driver) Merging mac80211/master (73350424bec9 cfg80211: pmsr: fix abort locking) Merging rdma-fixes/for-rc (48396e80fb65 RDMA/srp: Rework SCSI device reset handling) Merging sound-current/for-linus (c97617a81a76 ALSA: hda/ca0132 - Fix build error without CONFIG_PCI) Merging sound-asoc-fixes/for-linus (9cc17038ee1f Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (6e1e06b5f354 Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (89b331ebf161 Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f14bcc0add3a Revert "PCI: armada8k: Add support for gpio controlled reset signal") Merging driver-core.current/driver-core-linus (36991ca68db9 blk-mq: protect debugfs_create_files() from failures) Merging tty.current/tty-linus (fedb5760648a serial: fix race between flush_to_ldisc and tty_open) Merging usb.current/usb-linus (a07ddce4df80 usb: typec: tcpm: Correct the PPS out_volt calculation) Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy: am335x: fix race condition in _probe) Merging usb-serial-fixes/usb-linus (f17b5
Re: [PATCH] staging: vt6656: Use the correct style for SPDX license Identifier
On Wed, 2019-02-06 at 17:25 +0100, Greg Kroah-Hartman wrote:
> On Tue, Feb 05, 2019 at 10:59:40AM -0800, Joe Perches wrote:
> > On Tue, 2019-02-05 at 19:44 +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Feb 05, 2019 at 08:36:24PM +0530, Nishad Kamdar wrote:
> > > > This patch corrects the style for SPDX license Identifier in mac.h
> > > > by using "/* */" in place of "//" as per Linux kernel licensing rules.
> > > > Issue found by checkpatch.
> > > >
> > > > Signed-off-by: Nishad Kamdar
> > > > ---
> > > > drivers/staging/vt6656/mac.h | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/vt6656/mac.h b/drivers/staging/vt6656/mac.h
> > > > index 94e700fcd0b6..75166020f7c6 100644
> > > > --- a/drivers/staging/vt6656/mac.h
> > > > +++ b/drivers/staging/vt6656/mac.h
> > > > @@ -1,5 +1,5 @@
> > > > -// SPDX-License-Identifier: GPL-2.0+
> > > > -/*
> > > > +/* SPDX-License-Identifier: GPL-2.0+
> > >
> > > Should really be:
> > >
> > > /* SPDX-License-Identifier: GPL-2.0+ */
> >
> > There's a fair number of style inconsistencies in the kernel
> > sources for that already.
> >
> > ~8% of the .h files that have an 'SPDX-License-Identifier:'
> > don't use the recommended style.
> >
> > $ git grep -h "SPDX-License" -- '*.h' | \
> > perl -p -e 's@Identifier:.*\*/*@Identifier: ... */@; s@Identifier:
> > [^\.].*@Identifier:@' | \
> > sort | uniq -c | sort -rn
> >8506 /* SPDX-License-Identifier: ... */
> > 593 // SPDX-License-Identifier:
> > 154 /* SPDX-License-Identifier:
> > 53 * SPDX-License-Identifier:
> > 1 * SPDX-License-Identifier: GPL-2.0
> > 1 //SPDX-License-Identifier:
> > 1 /* SPDX-License-Identifier: ... */
>
> Then let's fix them, the documentation says what the correct format is,
> there's no reason we can't actually follow what is written...
So here's a script that does most all of them except
the 50 or so that use the SPDX-License-Identifier
in the middle of a comment block.
Using:
$ git grep --name-only 'SPDX-License-Identifier:' -- '*.h' | \
xargs grep -L '/\* SPDX-License-Identifier:.*\*/'| \
while read file ; do perl -i update_spdx.perl $file ; done
produces
$ git diff --shortstat
748 files changed, 902 insertions(+), 902 deletions(-)
And
$ git grep -h "SPDX-License" -- '*.h' | \
perl -p -e 's@Identifier:.*\*/*@Identifier: ... */@; s@Identifier:
[^\.].*@Identifier:@' | \
sort | uniq -c | sort -rn
9254 /* SPDX-License-Identifier: ... */
53 * SPDX-License-Identifier:
1 * SPDX-License-Identifier: GPL-2.0
1 /* SPDX-License-Identifier: ... */
and the perl script below is also attached
$ cat update_spdx.perl
local $/;
my $file = (<>);
my $spdx_regex = '/\*[ \t]*SPDX-License-Identifier:[ \t]*';
my $spdx_actual = '/* SPDX-License-Identifier: ';
# any // use converted to /* ... */
$file =~ s@^//[ \t]*SPDX-License-Identifier:[ \t]*(.*)\n@/*
SPDX-License-Identifier: $1 */\n@;
# first line use with /* without trailing */ gets */ added and 2nd line updated
$file =~ m@^\s*${spdx_regex}([^\n]+)\n@;
if (defined $1 && $1 !~ m@\*/$@) {
$file =~ s@^[ \t]*${spdx_regex}([^\n]+)\n@${spdx_actual}$1 */\n/* @;
$file =~ s@^[ \t]*${spdx_regex}([^\n]+)\n[ \t]*/\*[
\t]+\*@${spdx_actual}$1\n/* @;
$file =~ s@^\s*${spdx_regex}([^\n]+)\n/\* \n@${spdx_actual}$1\n/*\n@;
}
print $file;
update_spdx.perl
Description: Perl program
Re: [PATCH V11 3/5] i2c: tegra: Add DMA support
On Wed, Feb 06, 2019 at 05:56:02PM +0300, Dmitry Osipenko wrote: > > We don't have an IOMMU attached to I2C or APBDMA, so this can't happen > > and even if we had an IOMMU attached, all we care about is the device's > > DMA address space, which means IOVA space, and that would still be > > guaranteed to be contiguous, according to the above. > > Yes, but doesn't T186+ have IOMMU support for the DMA controller? Even if it did, why would that matter? The device would only see IOVA space, the CPU for a normal driver only sees kernel virtual space. Forced contiguous space only makes sense when you have access by CPU physical address, which should not happen for "normal" device drivers.
[PATCH v3 3/5] powerpc/perf: Add privileged access check for thread_imc
From: Madhavan Srinivasan
Add code to restrict user access to thread_imc pmu since
some event report privilege level information.
Fixes: f74c89bd80fb3 ('powerpc/perf: Add thread IMC PMU support')
Signed-off-by: Madhavan Srinivasan
Signed-off-by: Anju T Sudhakar
---
arch/powerpc/perf/imc-pmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 3bef46f8417d..5ca80545a849 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -877,6 +877,9 @@ static int thread_imc_event_init(struct perf_event *event)
if (event->attr.type != event->pmu->type)
return -ENOENT;
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
+
/* Sampling not supported */
if (event->hw.sample_period)
return -EINVAL;
--
2.17.1
[PATCH v3 0/5] powerpc/perf: IMC trace-mode support
IMC (In-Memory collection counters) is a hardware monitoring facility
that collects large number of hardware performance events.
POWER9 support two modes for IMC which are the Accumulation mode and
Trace mode. In Accumulation mode, event counts are accumulated in system
Memory. Hypervisor then reads the posted counts periodically or when
requested. In IMC Trace mode, event counted is fixed for cycles and on
each overflow, hardware snapshots the program counter along with other
details and writes into memory pointed by LDBAR(ring buffer memory,
hardware wraps around). LDBAR has bit which indicates the IMC trace-mode.
Trace-IMC Implementation:
--
To enable trace-imc, we need to
* Add trace node in the DTS file for power9, so that the new trace node can
be discovered by the kernel.
Information included in the DTS file are as follows, (a snippet from
the ima-catalog)
TRACE_IMC: trace-events {
#address-cells = <0x1>;
#size-cells = <0x1>;
event@1020 {
event-name = "cycles" ;
reg = <0x1020 0x8>;
desc = "Reference cycles" ;
};
};
trace@0 {
compatible = "ibm,imc-counters";
events-prefix = "trace_";
reg = <0x0 0x8>;
events = < _IMC >;
type = <0x2>;
size = <0x4>;
};
OP-BUILD changes needed to include the "trace node" is already pulled in
to the ima-catalog repo.
ps://github.com/open-power/op-build/commit/d3e75dc26d1283d7d5eb444bff1ec9e40d5dfc07
* Enchance the opal_imc_counters_* calls to support this new trace mode
in imc. Add support to initialize the trace-mode scom.
TRACE_IMC_SCOM bit representation:
0:1 : SAMPSEL
2:33: CPMC_LOAD
34:40 : CPMC1SEL
41:47 : CPMC2SEL
48:50 : BUFFERSIZE
51:63 : RESERVED
CPMC_LOAD contains the sampling duration. SAMPSEL and CPMC*SEL determines
the event to count. BUFFRSIZE indicates the memory range. On each overflow,
hardware snapshots program counter along with other details and update the
memory and reloads the CMPC_LOAD value for the next sampling duration.
IMC hardware does not support exceptions, so it quietly wraps around if
memory buffer reaches the end.
Link to the skiboot patches to enhance the opal_imc_counters_* calls:
https://lists.ozlabs.org/pipermail/skiboot/2018-December/012878.html
https://lists.ozlabs.org/pipermail/skiboot/2018-December/012879.html
https://lists.ozlabs.org/pipermail/skiboot/2018-December/012882.html
https://lists.ozlabs.org/pipermail/skiboot/2018-December/012880.html
https://lists.ozlabs.org/pipermail/skiboot/2018-December/012881.html
https://lists.ozlabs.org/pipermail/skiboot/2018-December/012883.html
* Set LDBAR spr to enable imc-trace mode.
[PATCH v3 5/5] powerpc/perf: Trace imc PMU functions
Add PMU functions to support trace-imc and define the format for
trace-imc events.
Signed-off-by: Anju T Sudhakar
Reviewed-by: Madhavan Srinivasan
---
arch/powerpc/perf/imc-pmu.c | 197 +++-
1 file changed, 196 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 1f09265c8fb0..0f1a30f11f6a 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -52,7 +52,7 @@ static struct imc_pmu *imc_event_to_pmu(struct perf_event
*event)
return container_of(event->pmu, struct imc_pmu, pmu);
}
-PMU_FORMAT_ATTR(event, "config:0-40");
+PMU_FORMAT_ATTR(event, "config:0-61");
PMU_FORMAT_ATTR(offset, "config:0-31");
PMU_FORMAT_ATTR(rvalue, "config:32");
PMU_FORMAT_ATTR(mode, "config:33-40");
@@ -69,6 +69,25 @@ static struct attribute_group imc_format_group = {
.attrs = imc_format_attrs,
};
+/* Format attribute for imc trace-mode */
+PMU_FORMAT_ATTR(cpmc_reserved, "config:0-19");
+PMU_FORMAT_ATTR(cpmc_event, "config:20-27");
+PMU_FORMAT_ATTR(cpmc_samplesel, "config:28-29");
+PMU_FORMAT_ATTR(cpmc_load, "config:30-61");
+static struct attribute *trace_imc_format_attrs[] = {
+ _attr_event.attr,
+ _attr_cpmc_reserved.attr,
+ _attr_cpmc_event.attr,
+ _attr_cpmc_samplesel.attr,
+ _attr_cpmc_load.attr,
+ NULL,
+};
+
+static struct attribute_group trace_imc_format_group = {
+ .name = "format",
+ .attrs = trace_imc_format_attrs,
+};
+
/* Get the cpumask printed to a buffer "buf" */
static ssize_t imc_pmu_cpumask_get_attr(struct device *dev,
struct device_attribute *attr,
@@ -1120,6 +1139,173 @@ static int trace_imc_cpu_init(void)
ppc_trace_imc_cpu_offline);
}
+static u64 get_trace_imc_event_base_addr(void)
+{
+ return (u64)per_cpu(trace_imc_mem, smp_processor_id());
+}
+
+/*
+ * Function to parse trace-imc data obtained
+ * and to prepare the perf sample.
+ */
+static int trace_imc_prepare_sample(struct trace_imc_data *mem,
+ struct perf_sample_data *data,
+ u64 *prev_tb,
+ struct perf_event_header *header,
+ struct perf_event *event)
+{
+ /* Sanity checks for a valid record */
+ if (be64_to_cpu(READ_ONCE(mem->tb1)) > *prev_tb)
+ *prev_tb = be64_to_cpu(READ_ONCE(mem->tb1));
+ else
+ return -EINVAL;
+
+ if ((be64_to_cpu(READ_ONCE(mem->tb1)) & IMC_TRACE_RECORD_TB1_MASK) !=
+be64_to_cpu(READ_ONCE(mem->tb2)))
+ return -EINVAL;
+
+ /* Prepare perf sample */
+ data->ip = be64_to_cpu(READ_ONCE(mem->ip));
+ data->period = event->hw.last_period;
+
+ header->type = PERF_RECORD_SAMPLE;
+ header->size = sizeof(*header) + event->header_size;
+ header->misc = 0;
+
+ if (is_kernel_addr(data->ip))
+ header->misc |= PERF_RECORD_MISC_KERNEL;
+ else
+ header->misc |= PERF_RECORD_MISC_USER;
+
+ perf_event_header__init_id(header, data, event);
+
+ return 0;
+}
+
+static void dump_trace_imc_data(struct perf_event *event)
+{
+ struct trace_imc_data *mem;
+ int i, ret;
+ u64 prev_tb = 0;
+
+ mem = (struct trace_imc_data *)get_trace_imc_event_base_addr();
+ for (i = 0; i < (trace_imc_mem_size / sizeof(struct trace_imc_data));
+ i++, mem++) {
+ struct perf_sample_data data;
+ struct perf_event_header header;
+
+ ret = trace_imc_prepare_sample(mem, , _tb, ,
event);
+ if (ret) /* Exit, if not a valid record */
+ break;
+ else {
+ /* If this is a valid record, create the sample */
+ struct perf_output_handle handle;
+
+ if (perf_output_begin(, event, header.size))
+ return;
+
+ perf_output_sample(, , , event);
+ perf_output_end();
+ }
+ }
+}
+
+static int trace_imc_event_add(struct perf_event *event, int flags)
+{
+ /* Enable the sched_task to start the engine */
+ perf_sched_cb_inc(event->ctx->pmu);
+ return 0;
+}
+
+static void trace_imc_event_read(struct perf_event *event)
+{
+ dump_trace_imc_data(event);
+}
+
+static void trace_imc_event_stop(struct perf_event *event, int flags)
+{
+ trace_imc_event_read(event);
+}
+
+static void trace_imc_event_start(struct perf_event *event, int flags)
+{
+ return;
+}
+
+static void trace_imc_event_del(struct perf_event *event, int flags)
+{
+ perf_sched_cb_dec(event->ctx->pmu);
+}
+
+void trace_imc_pmu_sched_task(struct perf_event_context *ctx,
+ bool sched_in)
+{
+ int core_id =
[PATCH v3 4/5] powerpc/perf: Trace imc events detection and cpuhotplug
Patch detects trace-imc events, does memory initilizations for each online
cpu, and registers cpuhotplug call-backs.
Signed-off-by: Anju T Sudhakar
Reviewed-by: Madhavan Srinivasan
---
arch/powerpc/perf/imc-pmu.c | 91 +++
arch/powerpc/platforms/powernv/opal-imc.c | 3 +
include/linux/cpuhotplug.h| 1 +
3 files changed, 95 insertions(+)
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 5ca80545a849..1f09265c8fb0 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -43,6 +43,10 @@ static DEFINE_PER_CPU(u64 *, thread_imc_mem);
static struct imc_pmu *thread_imc_pmu;
static int thread_imc_mem_size;
+/* Trace IMC data structures */
+static DEFINE_PER_CPU(u64 *, trace_imc_mem);
+static int trace_imc_mem_size;
+
static struct imc_pmu *imc_event_to_pmu(struct perf_event *event)
{
return container_of(event->pmu, struct imc_pmu, pmu);
@@ -1068,6 +1072,54 @@ static void thread_imc_event_del(struct perf_event
*event, int flags)
imc_event_update(event);
}
+/*
+ * Allocate a page of memory for each cpu, and load LDBAR with 0.
+ */
+static int trace_imc_mem_alloc(int cpu_id, int size)
+{
+ u64 *local_mem = per_cpu(trace_imc_mem, cpu_id);
+ int phys_id = cpu_to_node(cpu_id), rc = 0;
+
+ if (!local_mem) {
+ local_mem = page_address(alloc_pages_node(phys_id,
+ GFP_KERNEL | __GFP_ZERO |
__GFP_THISNODE |
+ __GFP_NOWARN, get_order(size)));
+ if (!local_mem)
+ return -ENOMEM;
+ per_cpu(trace_imc_mem, cpu_id) = local_mem;
+
+ /* Initialise the counters for trace mode */
+ rc = opal_imc_counters_init(OPAL_IMC_COUNTERS_TRACE, __pa((void
*)local_mem),
+ get_hard_smp_processor_id(cpu_id));
+ if (rc) {
+ pr_info("IMC:opal init failed for trace imc\n");
+ return rc;
+ }
+ }
+
+ mtspr(SPRN_LDBAR, 0);
+ return 0;
+}
+
+static int ppc_trace_imc_cpu_online(unsigned int cpu)
+{
+ return trace_imc_mem_alloc(cpu, trace_imc_mem_size);
+}
+
+static int ppc_trace_imc_cpu_offline(unsigned int cpu)
+{
+ mtspr(SPRN_LDBAR, 0);
+ return 0;
+}
+
+static int trace_imc_cpu_init(void)
+{
+ return cpuhp_setup_state(CPUHP_AP_PERF_POWERPC_TRACE_IMC_ONLINE,
+ "perf/powerpc/imc_trace:online",
+ ppc_trace_imc_cpu_online,
+ ppc_trace_imc_cpu_offline);
+}
+
/* update_pmu_ops : Populate the appropriate operations for "pmu" */
static int update_pmu_ops(struct imc_pmu *pmu)
{
@@ -1189,6 +1241,17 @@ static void cleanup_all_thread_imc_memory(void)
}
}
+static void cleanup_all_trace_imc_memory(void)
+{
+ int i, order = get_order(trace_imc_mem_size);
+
+ for_each_online_cpu(i) {
+ if (per_cpu(trace_imc_mem, i))
+ free_pages((u64)per_cpu(trace_imc_mem, i), order);
+
+ }
+}
+
/* Function to free the attr_groups which are dynamically allocated */
static void imc_common_mem_free(struct imc_pmu *pmu_ptr)
{
@@ -1230,6 +1293,11 @@ static void imc_common_cpuhp_mem_free(struct imc_pmu
*pmu_ptr)
cpuhp_remove_state(CPUHP_AP_PERF_POWERPC_THREAD_IMC_ONLINE);
cleanup_all_thread_imc_memory();
}
+
+ if (pmu_ptr->domain == IMC_DOMAIN_TRACE) {
+ cpuhp_remove_state(CPUHP_AP_PERF_POWERPC_TRACE_IMC_ONLINE);
+ cleanup_all_trace_imc_memory();
+ }
}
/*
@@ -1312,6 +1380,21 @@ static int imc_mem_init(struct imc_pmu *pmu_ptr, struct
device_node *parent,
thread_imc_pmu = pmu_ptr;
break;
+ case IMC_DOMAIN_TRACE:
+ /* Update the pmu name */
+ pmu_ptr->pmu.name = kasprintf(GFP_KERNEL, "%s%s", s, "_imc");
+ if (!pmu_ptr->pmu.name)
+ return -ENOMEM;
+
+ trace_imc_mem_size = pmu_ptr->counter_mem_size;
+ for_each_online_cpu(cpu) {
+ res = trace_imc_mem_alloc(cpu, trace_imc_mem_size);
+ if (res) {
+ cleanup_all_trace_imc_memory();
+ goto err;
+ }
+ }
+ break;
default:
return -EINVAL;
}
@@ -1384,6 +1467,14 @@ int init_imc_pmu(struct device_node *parent, struct
imc_pmu *pmu_ptr, int pmu_id
goto err_free_mem;
}
+ break;
+ case IMC_DOMAIN_TRACE:
+ ret = trace_imc_cpu_init();
+ if (ret) {
+ cleanup_all_trace_imc_memory();
+ goto err_free_mem;
+ }
+
[PATCH v3 2/5] powerpc/perf: Rearrange setting of ldbar for thread-imc
LDBAR holds the memory address allocated for each cpu. For thread-imc
the mode bit (i.e bit 1) of LDBAR is set to accumulation.
Currently, ldbar is loaded with per cpu memory address and mode set to
accumulation at boot time.
To enable trace-imc, the mode bit of ldbar should be set to 'trace'. So to
accommodate trace-mode of IMC, reposition setting of ldbar for thread-imc
to thread_imc_event_add(). Also reset ldbar at thread_imc_event_del().
Signed-off-by: Anju T Sudhakar
Reviewed-by: Madhavan Srinivasan
---
arch/powerpc/perf/imc-pmu.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index f292a3f284f1..3bef46f8417d 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -806,8 +806,11 @@ static int core_imc_event_init(struct perf_event *event)
}
/*
- * Allocates a page of memory for each of the online cpus, and write the
- * physical base address of that page to the LDBAR for that cpu.
+ * Allocates a page of memory for each of the online cpus, and load
+ * LDBAR with 0.
+ * The physical base address of the page allocated for a cpu will be
+ * written to the LDBAR for that cpu, when the thread-imc event
+ * is added.
*
* LDBAR Register Layout:
*
@@ -825,7 +828,7 @@ static int core_imc_event_init(struct perf_event *event)
*/
static int thread_imc_mem_alloc(int cpu_id, int size)
{
- u64 ldbar_value, *local_mem = per_cpu(thread_imc_mem, cpu_id);
+ u64 *local_mem = per_cpu(thread_imc_mem, cpu_id);
int nid = cpu_to_node(cpu_id);
if (!local_mem) {
@@ -842,9 +845,7 @@ static int thread_imc_mem_alloc(int cpu_id, int size)
per_cpu(thread_imc_mem, cpu_id) = local_mem;
}
- ldbar_value = ((u64)local_mem & THREAD_IMC_LDBAR_MASK) |
THREAD_IMC_ENABLE;
-
- mtspr(SPRN_LDBAR, ldbar_value);
+ mtspr(SPRN_LDBAR, 0);
return 0;
}
@@ -995,6 +996,7 @@ static int thread_imc_event_add(struct perf_event *event,
int flags)
{
int core_id;
struct imc_pmu_ref *ref;
+ u64 ldbar_value, *local_mem = per_cpu(thread_imc_mem,
smp_processor_id());
if (flags & PERF_EF_START)
imc_event_start(event, flags);
@@ -1003,6 +1005,9 @@ static int thread_imc_event_add(struct perf_event *event,
int flags)
return -EINVAL;
core_id = smp_processor_id() / threads_per_core;
+ ldbar_value = ((u64)local_mem & THREAD_IMC_LDBAR_MASK) |
THREAD_IMC_ENABLE;
+ mtspr(SPRN_LDBAR, ldbar_value);
+
/*
* imc pmus are enabled only when it is used.
* See if this is triggered for the first time.
@@ -1034,11 +1039,7 @@ static void thread_imc_event_del(struct perf_event
*event, int flags)
int core_id;
struct imc_pmu_ref *ref;
- /*
-* Take a snapshot and calculate the delta and update
-* the event counter values.
-*/
- imc_event_update(event);
+ mtspr(SPRN_LDBAR, 0);
core_id = smp_processor_id() / threads_per_core;
ref = _imc_refc[core_id];
@@ -1057,6 +1058,11 @@ static void thread_imc_event_del(struct perf_event
*event, int flags)
ref->refc = 0;
}
mutex_unlock(>lock);
+ /*
+* Take a snapshot and calculate the delta and update
+* the event counter values.
+*/
+ imc_event_update(event);
}
/* update_pmu_ops : Populate the appropriate operations for "pmu" */
--
2.17.1
[PATCH v3 1/5] powerpc/include: Add data structures and macros for IMC trace mode
Add the macros needed for IMC (In-Memory Collection Counters) trace-mode
and data structure to hold the trace-imc record data.
Also, add the new type "OPAL_IMC_COUNTERS_TRACE" in 'opal-api.h', since
there is a new switch case added in the opal-calls for IMC.
Signed-off-by: Anju T Sudhakar
Reviewed-by: Madhavan Srinivasan
---
arch/powerpc/include/asm/imc-pmu.h | 39 +
arch/powerpc/include/asm/opal-api.h | 1 +
2 files changed, 40 insertions(+)
diff --git a/arch/powerpc/include/asm/imc-pmu.h
b/arch/powerpc/include/asm/imc-pmu.h
index 69f516ecb2fd..7c2ef0e42661 100644
--- a/arch/powerpc/include/asm/imc-pmu.h
+++ b/arch/powerpc/include/asm/imc-pmu.h
@@ -33,6 +33,7 @@
*/
#define THREAD_IMC_LDBAR_MASK 0x0003e000ULL
#define THREAD_IMC_ENABLE 0x8000ULL
+#define TRACE_IMC_ENABLE 0x4000ULL
/*
* For debugfs interface for imc-mode and imc-command
@@ -59,6 +60,34 @@ struct imc_events {
char *scale;
};
+/*
+ * Trace IMC hardware updates a 64bytes record on
+ * Core Performance Monitoring Counter (CPMC)
+ * overflow. Here is the layout for the trace imc record
+ *
+ * DW 0 : Timebase
+ * DW 1 : Program Counter
+ * DW 2 : PIDR information
+ * DW 3 : CPMC1
+ * DW 4 : CPMC2
+ * DW 5 : CPMC3
+ * Dw 6 : CPMC4
+ * DW 7 : Timebase
+ * .
+ *
+ * The following is the data structure to hold trace imc data.
+ */
+struct trace_imc_data {
+ u64 tb1;
+ u64 ip;
+ u64 val;
+ u64 cpmc1;
+ u64 cpmc2;
+ u64 cpmc3;
+ u64 cpmc4;
+ u64 tb2;
+};
+
/* Event attribute array index */
#define IMC_FORMAT_ATTR0
#define IMC_EVENT_ATTR 1
@@ -68,6 +97,13 @@ struct imc_events {
/* PMU Format attribute macros */
#define IMC_EVENT_OFFSET_MASK 0xULL
+/*
+ * Macro to mask bits 0:21 of first double word(which is the timebase) to
+ * compare with 8th double word (timebase) of trace imc record data.
+ */
+#define IMC_TRACE_RECORD_TB1_MASK 0x3ffULL
+
+
/*
* Device tree parser code detects IMC pmu support and
* registers new IMC pmus. This structure will hold the
@@ -113,6 +149,7 @@ struct imc_pmu_ref {
enum {
IMC_TYPE_THREAD = 0x1,
+ IMC_TYPE_TRACE = 0x2,
IMC_TYPE_CORE = 0x4,
IMC_TYPE_CHIP = 0x10,
};
@@ -123,6 +160,8 @@ enum {
#define IMC_DOMAIN_NEST1
#define IMC_DOMAIN_CORE2
#define IMC_DOMAIN_THREAD 3
+/* For trace-imc the domain is still thread but it operates in trace-mode */
+#define IMC_DOMAIN_TRACE 4
extern int init_imc_pmu(struct device_node *parent,
struct imc_pmu *pmu_ptr, int pmu_id);
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
index 870fb7b239ea..a4130b21b159 100644
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -1118,6 +1118,7 @@ enum {
enum {
OPAL_IMC_COUNTERS_NEST = 1,
OPAL_IMC_COUNTERS_CORE = 2,
+ OPAL_IMC_COUNTERS_TRACE = 3,
};
--
2.17.1
Re: [RFC/PATCH 0/5] DVFS in the OPP core
3) How do we handle devices that already have power-domains specified in DT? The opp binding for required-opps doesn't let us specify the power domain to target, instead it assumes that whatever power domain is attached to a device is the one that OPP needs to use to change the genpd performance state. Do we need a dev_pm_opp_set_required_opps_name() or something to be explicit about this? Can we have some way for the power domain that required-opps correspond to be expressed in the OPP tables themselves? I was converting a few more drivers to use the proposed approach in this RFC, in order to identify all outstanding issues we need to deal with, and specifically for UFS, I end up with this exact scenario where UFS already has an existing power domain (gdsc) and I need to add another one (rpmhpd) for setting the performance state. If I use dev_pm_opp_of_add_table() to add the opp table from DT, the opp layer assumes its the same device on which it can do a dev_pm_genpd_set_performance_state() with, however the device that's actually associated with the pm_domain when we have multiple power domains is infact the one (dummy) that we create when the driver makes a call to dev_pm_domain_attach_by_name/id(). Any thoughts on whats a good way to handle this? -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[RFT PATCH 0/9] ARM: sun8i: a83t: Enable USB OTG
Hi everyone, This series enables USB OTG on the A83T boards. The AXP813/AXP818 PMICs used with the A83T have the same behavior as the AXP221 and AXP223, where if the N_VBUSEN pin is driven high, the VBUS sensing interrupts stop working. In the past Hans made a polling workaround in the USB PHY driver. In this series polling is added to the power supply driver. The power supply driver work was started by Quentin, and shared with me when I expressed interest in getting USB OTG to work some time ago. Neither of us got around to finishing it, until now that is. Patch 1 adds a new compatible string for the AXP813 VBUS power supply part. Patch 2 is a bit of cleanup work for the driver. Patch 3 allows disabling VBUS input current limiting on the AXP20x / AXP22x PMICs. While not strictly related to this series, I found it easier to just send everything together. This patch depends on the previous one. Patch 4 adds the VBUS status polling feature. This is enabled on AXP221 and all later PMICs. Patch 5 factors out code to read out the configured input current limit for the AXP20x and AXP22x PMICs. As the AXP813 uses different values, factoring out the code based on model will make the main function more readable. Patch 6 adds support for the AXP813 VBUS power supply. checkpatch.pl reports a few warnings for this patch: WARNING: Possible switch case/default not preceded by break or fallthrough comment #100: FILE: drivers/power/supply/axp20x_usb_power.c:306: + case 150: WARNING: Possible switch case/default not preceded by break or fallthrough comment #101: FILE: drivers/power/supply/axp20x_usb_power.c:307: + case 200: WARNING: Possible switch case/default not preceded by break or fallthrough comment #102: FILE: drivers/power/supply/axp20x_usb_power.c:308: + case 250: However they seem to be a false positive. The preceding line of the reported lines is a return statement, which is definitely not a fallthrough. Patch 7 adds an mfd cell for the newly supported VBUS power supply. Patch 8 adds a device node for the VBUS power supply to the common axp81x dtsi file. Patch 9 enables USB OTG on the Cubietruck Plus and Bananapi M3. Please have a look, and also test it on boards you have, and don't limit it to just the A83T ones. As mentioned above, the polling feature affects all boards that have an AXP221 or newer PMIC. I haven't removed the polling workaround from the USB PHY driver yet. That would be the next step after this series is merged, and preferrably a release has passed. Regards ChenYu Chen-Yu Tsai (5): dt-bindings: power: supply: axp20x_usb_power: add axp813 compatible power: supply: axp20x_usb_power: Fix typo in VBUS current limit macros power: supply: axp20x_usb_power: allow disabling input current limiting power: supply: axp20x_usb_power: use polling to detect vbus status change ARM: dts: sun8i: a83t: Enable USB OTG controller on some boards Quentin Schulz (4): power: supply: axp20x_usb_power: add function to get max current power: supply: axp20x_usb_power: add support for AXP813 mfd: axp20x: add USB power supply mfd cell to AXP813 ARM: dtsi: axp81x: add USB power supply node .../power/supply/axp20x_usb_power.txt | 1 + arch/arm/boot/dts/axp81x.dtsi | 4 + arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 12 ++ .../boot/dts/sun8i-a83t-cubietruck-plus.dts | 12 ++ drivers/mfd/axp20x.c | 11 ++ drivers/power/supply/axp20x_usb_power.c | 184 +++--- 6 files changed, 197 insertions(+), 27 deletions(-) -- 2.20.1
[RFT PATCH 8/9] ARM: dtsi: axp81x: add USB power supply node
From: Quentin Schulz
The AXP813/818 has a VBUS power input. Add a device node for it, now
that we support it.
Signed-off-by: Quentin Schulz
[w...@csie.org: Add commit message]
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/axp81x.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
index bd83962d3627..1dfeeceabf4c 100644
--- a/arch/arm/boot/dts/axp81x.dtsi
+++ b/arch/arm/boot/dts/axp81x.dtsi
@@ -171,4 +171,8 @@
status = "disabled";
};
};
+
+ usb_power_supply: usb-power-supply {
+ compatible = "x-powers,axp813-usb-power-supply";
+ };
};
--
2.20.1
[RFT PATCH 7/9] mfd: axp20x: add USB power supply mfd cell to AXP813
From: Quentin Schulz
The AXP813 has a VBUS power input. Now that the axp20x_usb_power driver
supports this variant, we can add an mfd cell for it to use it.
Signed-off-by: Quentin Schulz
[w...@csie.org: add commit message]
Signed-off-by: Chen-Yu Tsai
---
drivers/mfd/axp20x.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3c97f2c0fdfe..17b115845993 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -198,6 +198,12 @@ static const struct resource
axp22x_usb_power_supply_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
};
+/* AXP803 and AXP813/AXP818 share the same interrupts */
+static struct resource axp803_usb_power_supply_resources[] = {
+ DEFINE_RES_IRQ_NAMED(AXP803_IRQ_VBUS_PLUGIN, "VBUS_PLUGIN"),
+ DEFINE_RES_IRQ_NAMED(AXP803_IRQ_VBUS_REMOVAL, "VBUS_REMOVAL"),
+};
+
static const struct resource axp22x_pek_resources[] = {
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
DEFINE_RES_IRQ_NAMED(AXP22X_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
@@ -793,6 +799,11 @@ static const struct mfd_cell axp813_cells[] = {
.of_compatible = "x-powers,axp813-ac-power-supply",
.num_resources = ARRAY_SIZE(axp20x_ac_power_supply_resources),
.resources = axp20x_ac_power_supply_resources,
+ }, {
+ .name = "axp20x-usb-power-supply",
+ .num_resources = ARRAY_SIZE(axp803_usb_power_supply_resources),
+ .resources = axp803_usb_power_supply_resources,
+ .of_compatible = "x-powers,axp813-usb-power-supply",
},
};
--
2.20.1
[RFT PATCH 4/9] power: supply: axp20x_usb_power: use polling to detect vbus status change
On AXP221 and later AXP PMICs that have the N_VBUSEN pin, when this pin
is high, either due to the PMIC driving it high or as an input, the VBUS
detection related interrupt mechanisms are disabled.
Previously this was worked around in the phy-sun4i-usb driver, which
needed to sense VBUS changes and report them to the musb driver in a
timely matter. However this workaround was only for the A31 and A33 type
USB PHYs. To support newer platforms we would have to enable it for
almost all the post-A31 SoCs.
However, since this is actually the result of the PMIC's behavior, the
workaround would be better if done in the PMIC driver, in this case the
VBUS power supply driver.
Add the same workqueue-based polling to the VBUS power supply driver.
The polling interval is chosen to be the debounce interval from the USB
PHY driver, as this short interval is needed in some cases, but the
power supply driver would not know when.
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 53 +
1 file changed, 53 insertions(+)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index e2f353906bb1..ac061bcdc056 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#define DRVNAME "axp20x-usb-power-supply"
@@ -46,6 +47,12 @@
#define AXP20X_VBUS_MON_VBUS_VALID BIT(3)
+/*
+ * Note do not raise the debounce time, we must report Vusb high within
+ * 100ms otherwise we get Vbus errors in musb.
+ */
+#define DEBOUNCE_TIME msecs_to_jiffies(50)
+
struct axp20x_usb_power {
struct device_node *np;
struct regmap *regmap;
@@ -53,6 +60,8 @@ struct axp20x_usb_power {
enum axp20x_variants axp20x_id;
struct iio_channel *vbus_v;
struct iio_channel *vbus_i;
+ struct delayed_work vbus_detect;
+ unsigned int old_status;
};
static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
@@ -64,6 +73,35 @@ static irqreturn_t axp20x_usb_power_irq(int irq, void *devid)
return IRQ_HANDLED;
}
+static void axp20x_usb_power_poll_vbus(struct work_struct *work)
+{
+ struct axp20x_usb_power *power =
+ container_of(work, struct axp20x_usb_power, vbus_detect.work);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(power->regmap, AXP20X_PWR_INPUT_STATUS, );
+ if (ret)
+ goto out;
+
+ val &= (AXP20X_PWR_STATUS_VBUS_PRESENT | AXP20X_PWR_STATUS_VBUS_USED);
+ if (val != power->old_status)
+ power_supply_changed(power->supply);
+
+ power->old_status = val;
+
+out:
+ mod_delayed_work(system_wq, >vbus_detect, DEBOUNCE_TIME);
+}
+
+static bool axp20x_usb_vbus_needs_polling(struct axp20x_usb_power *power)
+{
+ if (power->axp20x_id >= AXP221_ID)
+ return true;
+
+ return false;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -362,6 +400,7 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
if (!power)
return -ENOMEM;
+ platform_set_drvdata(pdev, power);
power->axp20x_id = (enum axp20x_variants)of_device_get_match_data(
>dev);
@@ -420,6 +459,19 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
irq_names[i], ret);
}
+ INIT_DELAYED_WORK(>vbus_detect, axp20x_usb_power_poll_vbus);
+ if (axp20x_usb_vbus_needs_polling(power))
+ queue_delayed_work(system_wq, >vbus_detect, 0);
+
+ return 0;
+}
+
+static int axp20x_usb_power_remove(struct platform_device *pdev)
+{
+ struct axp20x_usb_power *power = platform_get_drvdata(pdev);
+
+ cancel_delayed_work_sync(>vbus_detect);
+
return 0;
}
@@ -439,6 +491,7 @@ MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
static struct platform_driver axp20x_usb_power_driver = {
.probe = axp20x_usb_power_probe,
+ .remove = axp20x_usb_power_remove,
.driver = {
.name = DRVNAME,
.of_match_table = axp20x_usb_power_match,
--
2.20.1
[RFT PATCH 1/9] dt-bindings: power: supply: axp20x_usb_power: add axp813 compatible
This adds the "x-powers,axp813-usb-power-supply" to the list of compatibles for AXP20X VBUS power supply driver. Signed-off-by: Chen-Yu Tsai --- .../devicetree/bindings/power/supply/axp20x_usb_power.txt| 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt index ba8d35f66cbe..b2d4968fde7d 100644 --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt @@ -4,6 +4,7 @@ Required Properties: -compatible: One of: "x-powers,axp202-usb-power-supply" "x-powers,axp221-usb-power-supply" "x-powers,axp223-usb-power-supply" +"x-powers,axp813-usb-power-supply" The AXP223 PMIC shares most of its behaviour with the AXP221 but has slight variations such as the former being able to set the VBUS power supply max -- 2.20.1
[RFT PATCH 2/9] power: supply: axp20x_usb_power: Fix typo in VBUS current limit macros
The VBUS current limit value macros have VBUS typed as VBUC, while
the bitmask macro is named correctly. Fix it.
Fixes: 69fb4dcada77 ("power: Add an axp20x-usb-power driver")
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index f52fe77edb6f..cd9b90d79839 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -36,10 +36,10 @@
#define AXP20X_VBUS_VHOLD_MASK GENMASK(5, 3)
#define AXP20X_VBUS_VHOLD_OFFSET 3
#define AXP20X_VBUS_CLIMIT_MASK3
-#define AXP20X_VBUC_CLIMIT_900mA 0
-#define AXP20X_VBUC_CLIMIT_500mA 1
-#define AXP20X_VBUC_CLIMIT_100mA 2
-#define AXP20X_VBUC_CLIMIT_NONE3
+#define AXP20X_VBUS_CLIMIT_900mA 0
+#define AXP20X_VBUS_CLIMIT_500mA 1
+#define AXP20X_VBUS_CLIMIT_100mA 2
+#define AXP20X_VBUS_CLIMIT_NONE3
#define AXP20X_ADC_EN1_VBUS_CURR BIT(2)
#define AXP20X_ADC_EN1_VBUS_VOLT BIT(3)
@@ -107,19 +107,19 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
return ret;
switch (v & AXP20X_VBUS_CLIMIT_MASK) {
- case AXP20X_VBUC_CLIMIT_100mA:
+ case AXP20X_VBUS_CLIMIT_100mA:
if (power->axp20x_id == AXP221_ID)
val->intval = -1; /* No 100mA limit */
else
val->intval = 10;
break;
- case AXP20X_VBUC_CLIMIT_500mA:
+ case AXP20X_VBUS_CLIMIT_500mA:
val->intval = 50;
break;
- case AXP20X_VBUC_CLIMIT_900mA:
+ case AXP20X_VBUS_CLIMIT_900mA:
val->intval = 90;
break;
- case AXP20X_VBUC_CLIMIT_NONE:
+ case AXP20X_VBUS_CLIMIT_NONE:
val->intval = -1;
break;
}
--
2.20.1
[RFT PATCH 5/9] power: supply: axp20x_usb_power: add function to get max current
From: Quentin Schulz
To prepare for a new PMIC, factor out the code responsible of returning
the maximum current to axp20x_get_current_max.
Signed-off-by: Quentin Schulz
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 52 ++---
1 file changed, 30 insertions(+), 22 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index ac061bcdc056..90d06027bf98 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -102,6 +102,35 @@ static bool axp20x_usb_vbus_needs_polling(struct
axp20x_usb_power *power)
return false;
}
+static int axp20x_get_current_max(struct axp20x_usb_power *power, int *val)
+{
+ unsigned int v;
+ int ret = regmap_read(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, );
+
+ if (ret)
+ return ret;
+
+ switch (v & AXP20X_VBUS_CLIMIT_MASK) {
+ case AXP20X_VBUS_CLIMIT_100mA:
+ if (power->axp20x_id == AXP221_ID)
+ *val = -1; /* No 100mA limit */
+ else
+ *val = 10;
+ break;
+ case AXP20X_VBUS_CLIMIT_500mA:
+ *val = 50;
+ break;
+ case AXP20X_VBUS_CLIMIT_900mA:
+ *val = 90;
+ break;
+ case AXP20X_VBUS_CLIMIT_NONE:
+ *val = -1;
+ break;
+ }
+
+ return 0;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -140,28 +169,7 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
val->intval = ret * 1700; /* 1 step = 1.7 mV */
return 0;
case POWER_SUPPLY_PROP_CURRENT_MAX:
- ret = regmap_read(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, );
- if (ret)
- return ret;
-
- switch (v & AXP20X_VBUS_CLIMIT_MASK) {
- case AXP20X_VBUS_CLIMIT_100mA:
- if (power->axp20x_id == AXP221_ID)
- val->intval = -1; /* No 100mA limit */
- else
- val->intval = 10;
- break;
- case AXP20X_VBUS_CLIMIT_500mA:
- val->intval = 50;
- break;
- case AXP20X_VBUS_CLIMIT_900mA:
- val->intval = 90;
- break;
- case AXP20X_VBUS_CLIMIT_NONE:
- val->intval = -1;
- break;
- }
- return 0;
+ return axp20x_get_current_max(power, >intval);
case POWER_SUPPLY_PROP_CURRENT_NOW:
if (IS_ENABLED(CONFIG_AXP20X_ADC)) {
ret = iio_read_channel_processed(power->vbus_i,
--
2.20.1
[RFT PATCH 3/9] power: supply: axp20x_usb_power: allow disabling input current limiting
The AXP PMICs allow the user to disable current limiting on the VBUS input. While read-out of this setting was already supported by the driver, it did not allow the user to configure the PMIC to disable current limiting. Add support for this. Signed-off-by: Chen-Yu Tsai --- drivers/power/supply/axp20x_usb_power.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c index cd9b90d79839..e2f353906bb1 100644 --- a/drivers/power/supply/axp20x_usb_power.c +++ b/drivers/power/supply/axp20x_usb_power.c @@ -230,6 +230,11 @@ static int axp20x_usb_power_set_current_max(struct axp20x_usb_power *power, return regmap_update_bits(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_CLIMIT_MASK, val); + case -1: + return regmap_update_bits(power->regmap, + AXP20X_VBUS_IPSOUT_MGMT, + AXP20X_VBUS_CLIMIT_MASK, + AXP20X_VBUS_CLIMIT_NONE); default: return -EINVAL; } -- 2.20.1
[RFT PATCH 6/9] power: supply: axp20x_usb_power: add support for AXP813
From: Quentin Schulz
This adds support for AXP813 PMIC. It is almost the same as AXP22X but
has a different current limit.
Signed-off-by: Quentin Schulz
Signed-off-by: Chen-Yu Tsai
---
drivers/power/supply/axp20x_usb_power.c | 66 -
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index 90d06027bf98..d39c450b14c6 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -42,6 +42,11 @@
#define AXP20X_VBUS_CLIMIT_100mA 2
#define AXP20X_VBUS_CLIMIT_NONE3
+#define AXP813_VBUS_CLIMIT_900mA 0
+#define AXP813_VBUS_CLIMIT_1500mA 1
+#define AXP813_VBUS_CLIMIT_2000mA 2
+#define AXP813_VBUS_CLIMIT_2500mA 3
+
#define AXP20X_ADC_EN1_VBUS_CURR BIT(2)
#define AXP20X_ADC_EN1_VBUS_VOLT BIT(3)
@@ -131,6 +136,31 @@ static int axp20x_get_current_max(struct axp20x_usb_power
*power, int *val)
return 0;
}
+static int axp813_get_current_max(struct axp20x_usb_power *power, int *val)
+{
+ unsigned int v;
+ int ret = regmap_read(power->regmap, AXP20X_VBUS_IPSOUT_MGMT, );
+
+ if (ret)
+ return ret;
+
+ switch (v & AXP20X_VBUS_CLIMIT_MASK) {
+ case AXP813_VBUS_CLIMIT_900mA:
+ *val = 90;
+ break;
+ case AXP813_VBUS_CLIMIT_1500mA:
+ *val = 150;
+ break;
+ case AXP813_VBUS_CLIMIT_2000mA:
+ *val = 200;
+ break;
+ case AXP813_VBUS_CLIMIT_2500mA:
+ *val = 250;
+ break;
+ }
+ return 0;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -169,6 +199,8 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
val->intval = ret * 1700; /* 1 step = 1.7 mV */
return 0;
case POWER_SUPPLY_PROP_CURRENT_MAX:
+ if (power->axp20x_id == AXP813_ID)
+ return axp813_get_current_max(power, >intval);
return axp20x_get_current_max(power, >intval);
case POWER_SUPPLY_PROP_CURRENT_NOW:
if (IS_ENABLED(CONFIG_AXP20X_ADC)) {
@@ -260,6 +292,31 @@ static int axp20x_usb_power_set_voltage_min(struct
axp20x_usb_power *power,
return -EINVAL;
}
+static int axp813_usb_power_set_current_max(struct axp20x_usb_power *power,
+ int intval)
+{
+ int val;
+
+ switch (intval) {
+ case 90:
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_CLIMIT_MASK,
+ AXP813_VBUS_CLIMIT_900mA);
+ case 150:
+ case 200:
+ case 250:
+ val = (intval - 100) / 50;
+ return regmap_update_bits(power->regmap,
+ AXP20X_VBUS_IPSOUT_MGMT,
+ AXP20X_VBUS_CLIMIT_MASK, val);
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
static int axp20x_usb_power_set_current_max(struct axp20x_usb_power *power,
int intval)
{
@@ -299,6 +356,9 @@ static int axp20x_usb_power_set_property(struct
power_supply *psy,
return axp20x_usb_power_set_voltage_min(power, val->intval);
case POWER_SUPPLY_PROP_CURRENT_MAX:
+ if (power->axp20x_id == AXP813_ID)
+ return axp813_usb_power_set_current_max(power,
+ val->intval);
return axp20x_usb_power_set_current_max(power, val->intval);
default:
@@ -434,7 +494,8 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
usb_power_desc = _usb_power_desc;
irq_names = axp20x_irq_names;
} else if (power->axp20x_id == AXP221_ID ||
- power->axp20x_id == AXP223_ID) {
+ power->axp20x_id == AXP223_ID ||
+ power->axp20x_id == AXP813_ID) {
usb_power_desc = _usb_power_desc;
irq_names = axp22x_irq_names;
} else {
@@ -493,6 +554,9 @@ static const struct of_device_id axp20x_usb_power_match[] =
{
}, {
.compatible = "x-powers,axp223-usb-power-supply",
.data = (void *)AXP223_ID,
+ }, {
+ .compatible = "x-powers,axp813-usb-power-supply",
+ .data = (void *)AXP813_ID,
}, { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, axp20x_usb_power_match);
--
2.20.1
[RFT PATCH 9/9] ARM: dts: sun8i: a83t: Enable USB OTG controller on some boards
The Bananapi M3 and Cubietruck Plus both have USB OTG ports wired to the
SoC and PMIC in the same way, with the N_VBUSEN pin on the PMIC
controlling VBUS output, the PMIC's VBUS input for sensing VBUS, and
PH11 on the SoC for sensing the ID pin.
Enable OTG on both boards.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 12
arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 12
2 files changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 838be7b3715f..9d34eabba121 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -389,7 +389,19 @@
};
};
+_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+_power_supply {
+ status = "okay";
+};
+
{
+ usb0_id_det-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
+ usb0_vbus_power-supply = <_power_supply>;
+ usb0_vbus-supply = <_drivevbus>;
usb1_vbus-supply = <_usb1_vbus>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
index fcbec3d7ccd7..ea299d3d84d0 100644
--- a/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts
@@ -420,7 +420,19 @@
};
};
+_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+_power_supply {
+ status = "okay";
+};
+
{
+ usb0_id_det-gpios = < 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
+ usb0_vbus_power-supply = <_power_supply>;
+ usb0_vbus-supply = <_drivevbus>;
usb1_vbus-supply = <_usb1_vbus>;
usb2_vbus-supply = <_usb2_vbus>;
status = "okay";
--
2.20.1
[PATCH 2/2] signal: Better detection of synchronous signals
Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER. Ultimately causing a loop failing
to deliver SIGHUP but always trying.
When the stack overflows delivery of SIGHUP fails and force_sigsegv is
called. Unfortunately because SIGSEGV is numerically higher than
SIGHUP next_signal tries again to deliver a SIGHUP.
>From a quality of implementation standpoint attempting to deliver the
timer SIGHUP signal is wrong. We should attempt to deliver the
synchronous SIGSEGV signal we just forced.
We can make that happening in a fairly straight forward manner by
instead of just looking at the signal number we also look at the
si_code. In particular for exceptions (aka synchronous signals) the
si_code is always greater than 0.
That still has the potential to pick up a number of asynchronous
signals as in a few cases the same si_codes that are used
for synchronous signals are also used for asynchronous signals,
and SI_KERNEL is also included in the list of possible si_codes.
Still the heuristic is much better and timer signals are definitely
excluded. Which is enough to prevent all known ways for someone
sending a process signals fast enough to cause unexpected and
arguably incorrect behavior.
Cc: sta...@vger.kernel.org
Fixes: a27341cd5fcb ("Prioritize synchronous signals over 'normal' signals")
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 52 -
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 5424cb0006bc..99fa8ff06fd9 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -688,6 +688,48 @@ int dequeue_signal(struct task_struct *tsk, sigset_t
*mask, kernel_siginfo_t *in
}
EXPORT_SYMBOL_GPL(dequeue_signal);
+static int dequeue_synchronous_signal(kernel_siginfo_t *info)
+{
+ struct task_struct *tsk = current;
+ struct sigpending *pending = >pending;
+ struct sigqueue *q, *sync = NULL;
+
+ /*
+* Might a synchronous signal be in the queue?
+*/
+ if (!((pending->signal.sig[0] & ~tsk->blocked.sig[0]) &
SYNCHRONOUS_MASK))
+ return 0;
+
+ /*
+* Return the first synchronous signal in the queue.
+*/
+ list_for_each_entry(q, >list, list) {
+ /* Synchronous signals have a postive si_code */
+ if ((q->info.si_code > SI_USER) &&
+ (sigmask(q->info.si_signo) & SYNCHRONOUS_MASK)) {
+ sync = q;
+ goto next;
+ }
+ }
+ return 0;
+next:
+ /*
+* Check if there is another siginfo for the same signal.
+*/
+ list_for_each_entry_continue(q, >list, list) {
+ if (q->info.si_signo == sync->info.si_signo)
+ goto still_pending;
+ }
+
+ sigdelset(>signal, sync->info.si_signo);
+ recalc_sigpending();
+still_pending:
+ list_del_init(>list);
+ copy_siginfo(info, >info);
+ __sigqueue_free(sync);
+ return info->si_signo;
+}
+
/*
* Tell a process that it has a new active signal..
*
@@ -2411,7 +2453,15 @@ bool get_signal(struct ksignal *ksig)
goto relock;
}
- signr = dequeue_signal(current, >blocked, >info);
+ /*
+* Signals generated by the execution of an instruction
+* need to be delivered before any other pending signals
+* so that the instruction pointer in the signal stack
+* frame points to the faulting instruction.
+*/
+ signr = dequeue_synchronous_signal(>info);
+ if (!signr)
+ signr = dequeue_signal(current, >blocked,
>info);
if (!signr)
break; /* will return 0 */
--
2.17.1
[PATCH 1/2] signal: Always notice exiting tasks
Recently syzkaller was able to create unkillablle processes by
creating a timer that is delivered as a thread local signal on SIGHUP,
and receiving SIGHUP SA_NODEFERER. Ultimately causing a loop
failing to deliver SIGHUP but always trying.
Upon examination it turns out part of the problem is actually most of
the solution. Since 2.5 signal delivery has found all fatal signals,
marked the signal group for death, and queued SIGKILL in every threads
thread queue relying on signal->group_exit_code to preserve the
information of which was the actual fatal signal.
The conversion of all fatal signals to SIGKILL results in the
synchronous signal heuristic in next_signal kicking in and preferring
SIGHUP to SIGKILL. Which is especially problematic as all
fatal signals have already been transformed into SIGKILL.
Instead of dequeueing signals and depending upon SIGKILL to
be the first signal dequeued, first test if the signal group
has already been marked for death. This guarantees that
nothing in the signal queue can prevent a process that needs
to exit from exiting.
Cc: sta...@vger.kernel.org
Reported-by: Dmitry Vyukov
Ref: ebf5ebe31d2c ("[PATCH] signal-fixes-2.5.59-A4")
History Tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Signed-off-by: "Eric W. Biederman"
---
kernel/signal.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index 9ca8e5278c8e..5424cb0006bc 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2393,6 +2393,11 @@ bool get_signal(struct ksignal *ksig)
goto relock;
}
+ /* Has this task already been marked for death? */
+ ksig->info.si_signo = signr = SIGKILL;
+ if (signal_group_exit(signal))
+ goto fatal;
+
for (;;) {
struct k_sigaction *ka;
@@ -2488,6 +2493,7 @@ bool get_signal(struct ksignal *ksig)
continue;
}
+ fatal:
spin_unlock_irq(>siglock);
/*
--
2.17.1
[PATCH 0/2]: Fixing unkillable processes caused by SIGHUP timers
Dmitry, Can you please verify the follow two patches. The first one is a simplification of the one you have already tested and makes the processes killable. The second patch improves our heuristic for detecting synchronous like SIGSEGV when the stack overflows allowing us to process them before SIGHUP. Eric W. Biederman (2): signal: Always notice exiting tasks signal: Better detection of synchronous signals
Re: [PATCH 05/32] timerfd/timens: Take into account ns clock offsets
On Wed, Feb 06, 2019 at 11:52:03AM +0300, Cyrill Gorcunov wrote:
> On Wed, Feb 06, 2019 at 12:10:39AM +, Dmitry Safonov wrote:
> > From: Andrei Vagin
> >
> > Make timerfd respect timens offsets.
> > Provide two helpers timens_clock_to_host() timens_clock_from_host() that
> > are useful to wire up timens to different kernel subsystems.
> > Following patches will use timens_clock_from_host(), added here for
> > completeness.
> >
> > Signed-off-by: Andrei Vagin
> > Co-developed-by: Dmitry Safonov
> > Signed-off-by: Dmitry Safonov
> > ---
> > fs/timerfd.c | 16 +++-
> > 1 file changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/fs/timerfd.c b/fs/timerfd.c
> > index 803ca070d42e..c7ae1e371912 100644
> > --- a/fs/timerfd.c
> > +++ b/fs/timerfd.c
> > @@ -26,6 +26,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > struct timerfd_ctx {
> > union {
> > @@ -433,22 +434,27 @@ SYSCALL_DEFINE2(timerfd_create, int, clockid, int,
> > flags)
> > }
> >
> > static int do_timerfd_settime(int ufd, int flags,
> > - const struct itimerspec64 *new,
> > + struct itimerspec64 *new,
> > struct itimerspec64 *old)
> > {
> > struct fd f;
> > struct timerfd_ctx *ctx;
> > int ret;
> >
> > - if ((flags & ~TFD_SETTIME_FLAGS) ||
> > -!itimerspec64_valid(new))
> > - return -EINVAL;
>
> Please don't defer this early test of a @flags value. Otherwise
> if @flags is invalid you continue fget/put/clock-to-host even
> if result will be dropped out then.
Cyrill, you are right. I moved this check together with
itimerspec64_valid(). The idea was to call itimerspec64_valid() after
applying clock offsets but for that, we need to know clockid.
Let's wait a bit for other comments to this patch set and then we will
fix all things what will be found.
Thanks,
Andrei
Re: [PATCH] ipmr: ip6mr: Create new sockopt to clear mfc cache only
On 07/02/2019 04:08, Callum Sinclair wrote:
> Currently the only way to clear the mfc cache was to delete the entries
> one by one using the MRT_DEL_MFC socket option or to destroy and
> recreate the socket.
>
> Create a new socket option which will clear the multicast forwarding
> cache on the socket without destroying the socket.
>
> Signed-off-by: Callum Sinclair
> ---
> include/uapi/linux/mroute.h | 7 +++-
> include/uapi/linux/mroute6.h | 7 +++-
> net/ipv4/ipmr.c | 69 +-
> net/ipv6/ip6mr.c | 73 ++--
> 4 files changed, 99 insertions(+), 57 deletions(-)
>
Hi,
Thanks for working on this. I think you missed one comment, this still seems
to clean all tables even though the socket has a table assigned. Could it
act only on that table ? All of the MRT calls besides the init act only on
the initialized table.
Also you're not checking if optlen is proper size, and I wonder which kernel is
this
based on ? Because in net-next ip_mroute_setsockopt() takes rtnl in the
beginning
and releases it in the end with the exception of MRT_DONE which needs to
release it
earlier, the code below would cause a deadlock trying to get rtnl again in
MRT_FLUSH.
This patch should be targeted at net-next, please indicate that also in your
subject:
e.g. [PATCH net-next].
Thanks,
Nik
> diff --git a/include/uapi/linux/mroute.h b/include/uapi/linux/mroute.h
> index 5d37a9ccce63..2d475edc3ec3 100644
> --- a/include/uapi/linux/mroute.h
> +++ b/include/uapi/linux/mroute.h
> @@ -28,12 +28,17 @@
> #define MRT_TABLE(MRT_BASE+9)/* Specify mroute table ID
> */
> #define MRT_ADD_MFC_PROXY(MRT_BASE+10) /* Add a (*,*|G) mfc entry
> */
> #define MRT_DEL_MFC_PROXY(MRT_BASE+11) /* Del a (*,*|G) mfc entry
> */
> -#define MRT_MAX (MRT_BASE+11)
> +#define MRT_FLUSH(MRT_BASE+12) /* Flush all multicast entries and vifs
> */
> +#define MRT_MAX (MRT_BASE+12)
>
> #define SIOCGETVIFCNTSIOCPROTOPRIVATE/* IP protocol privates
> */
> #define SIOCGETSGCNT (SIOCPROTOPRIVATE+1)
> #define SIOCGETRPF (SIOCPROTOPRIVATE+2)
>
> +/* Flags used for MRT_FLUSH */
> +#define MRT_FLUSH_ENTRIES1 /* For flushing all multicast entries */
> +#define MRT_FLUSH_VIFS 2 /* For flushing all multicast
> vifs */
> +
> #define MAXVIFS 32
> typedef unsigned long vifbitmap_t; /* User mode code depends on this lot */
> typedef unsigned short vifi_t;
> diff --git a/include/uapi/linux/mroute6.h b/include/uapi/linux/mroute6.h
> index cc006390..b04094d997c8 100644
> --- a/include/uapi/linux/mroute6.h
> +++ b/include/uapi/linux/mroute6.h
> @@ -31,12 +31,17 @@
> #define MRT6_TABLE (MRT6_BASE+9) /* Specify mroute table ID
> */
> #define MRT6_ADD_MFC_PROXY (MRT6_BASE+10) /* Add a (*,*|G) mfc entry
> */
> #define MRT6_DEL_MFC_PROXY (MRT6_BASE+11) /* Del a (*,*|G) mfc entry
> */
> -#define MRT6_MAX (MRT6_BASE+11)
> +#define MRT6_FLUSH (MRT6_BASE+12) /* Flush all multicast entries and vifs
> */
> +#define MRT6_MAX (MRT6_BASE+12)
>
> #define SIOCGETMIFCNT_IN6SIOCPROTOPRIVATE/* IP protocol privates
> */
> #define SIOCGETSGCNT_IN6 (SIOCPROTOPRIVATE+1)
> #define SIOCGETRPF (SIOCPROTOPRIVATE+2)
>
> +/* Flags used for MRT6_FLUSH*/
> +#define MRT6_FLUSH_ENTRIES 1 /* For flushing all multicast entries */
> +#define MRT6_FLUSH_VIFS 2 /* For flushing all multicast
> vifs */
> +
> #define MAXMIFS 32
> typedef unsigned long mifbitmap_t; /* User mode code depends on this lot */
> typedef unsigned short mifi_t;
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index ddbf8c9a1abb..2eb569138569 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -416,7 +416,7 @@ static struct mr_table *ipmr_new_table(struct net *net,
> u32 id)
> static void ipmr_free_table(struct mr_table *mrt)
> {
> del_timer_sync(>ipmr_expire_timer);
> - mroute_clean_tables(mrt, true);
> + mroute_clean_tables(mrt, true, MRT_FLUSH_VIFS | MRT_FLUSH_ENTRIES);
> rhltable_destroy(>mfc_hash);
> kfree(mrt);
> }
> @@ -1299,44 +1299,48 @@ static int ipmr_mfc_add(struct net *net, struct
> mr_table *mrt,
> }
>
> /* Close the multicast socket, and clear the vif tables etc */
> -static void mroute_clean_tables(struct mr_table *mrt, bool all)
> +static void mroute_clean_tables(struct mr_table *mrt, bool all, int flags)
> {
> struct net *net = read_pnet(>net);
> - struct mr_mfc *c, *tmp;
> struct mfc_cache *cache;
> + struct mr_mfc *c, *tmp;
> LIST_HEAD(list);
> int i;
>
> /* Shut down all active vif entries */
> - for (i = 0; i < mrt->maxvif; i++) {
> - if (!all && (mrt->vif_table[i].flags & VIFF_STATIC))
> - continue;
> - vif_delete(mrt, i, 0,
Re: [PATCH v2 2/2] x86/xen: dont add memory above max allowed allocation
On 01/02/2019 19:46, Boris Ostrovsky wrote: > On 1/30/19 3:22 AM, Juergen Gross wrote: >> Don't allow memory to be added above the allowed maximum allocation >> limit set by Xen. >> >> Trying to do so would result in cases like the following: >> >> [ 584.559652] [ cut here ] >> [ 584.564897] WARNING: CPU: 2 PID: 1 at ../arch/x86/xen/multicalls.c:129 >> xen_alloc_pte+0x1c7/0x390() >> [ 584.575151] Modules linked in: >> [ 584.578643] Supported: Yes >> [ 584.581750] CPU: 2 PID: 1 Comm: swapper/0 Not tainted >> 4.4.120-92.70-default #1 >> [ 584.59] Hardware name: Cisco Systems Inc UCSC-C460-M4/UCSC-C460-M4, >> BIOS C460M4.4.0.1b.0.0629181419 06/29/2018 >> [ 584.601862] 813175a0 >> 8184777c >> [ 584.610200] 8107f4e1 880487eb7000 8801862b79c0 >> 88048608d290 >> [ 584.618537] 00487eb7 ea000201 81009de7 >> 81068561 >> [ 584.626876] Call Trace: >> [ 584.629699] [] dump_trace+0x59/0x340 >> [ 584.635645] [] show_stack_log_lvl+0xea/0x170 >> [ 584.642391] [] show_stack+0x21/0x40 >> [ 584.648238] [] dump_stack+0x5c/0x7c >> [ 584.654085] [] warn_slowpath_common+0x81/0xb0 >> [ 584.660932] [] xen_alloc_pte+0x1c7/0x390 >> [ 584.667289] [] >> pmd_populate_kernel.constprop.6+0x40/0x80 >> [ 584.675241] [] phys_pmd_init+0x210/0x255 >> [ 584.681587] [] phys_pud_init+0x1da/0x247 >> [ 584.687931] [] kernel_physical_mapping_init+0xf5/0x1d4 >> [ 584.695682] [] init_memory_mapping+0x18d/0x380 >> [ 584.702631] [] arch_add_memory+0x59/0xf0 >> >> Signed-off-by: Juergen Gross >> --- >> arch/x86/xen/setup.c | 10 ++ >> drivers/xen/xen-balloon.c | 6 ++ >> 2 files changed, 16 insertions(+) >> >> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c >> index d5f303c0e656..fdb184cadaf5 100644 >> --- a/arch/x86/xen/setup.c >> +++ b/arch/x86/xen/setup.c >> @@ -12,6 +12,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include >> @@ -825,6 +826,15 @@ char * __init xen_memory_setup(void) >> xen_max_p2m_pfn = pfn_s + n_pfns; >> } else >> discard = true; >> +#ifdef CONFIG_MEMORY_HOTPLUG >> +/* >> + * Don't allow adding memory not in E820 map while >> + * booting the system. Once the balloon driver is up >> + * it will remove that restriction again. >> + */ >> +max_mem_size = xen_e820_table.entries[i].addr + >> + xen_e820_table.entries[i].size; >> +#endif >> } >> >> if (!discard) >> diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c >> index 2acbfe104e46..2a960fcc812e 100644 >> --- a/drivers/xen/xen-balloon.c >> +++ b/drivers/xen/xen-balloon.c >> @@ -37,6 +37,7 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include >> @@ -63,6 +64,11 @@ static void watch_target(struct xenbus_watch *watch, >> static bool watch_fired; >> static long target_diff; >> >> +#ifdef CONFIG_MEMORY_HOTPLUG >> +/* The balloon driver will take care of adding memory now. */ >> +max_mem_size = U64_MAX; >> +#endif > > > I don't think I understand this. Are you saying the guest should ignore > 'mem' boot option? No, I just managed to forget thinking about that possibility. I need to save the old max_mem_size setting in setup.c and restore it here. Juergen
[PATCH] Input: ili210x - switch to using devm_device_add_group()
By switching to devm_device_add_group() we can complete driver conversion
to using managed resources and get rid of ili210x_i2c_remove().
Signed-off-by: Dmitry Torokhov
---
drivers/input/touchscreen/ili210x.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/input/touchscreen/ili210x.c
b/drivers/input/touchscreen/ili210x.c
index 6cfe463ac118..af1dd9cff12a 100644
--- a/drivers/input/touchscreen/ili210x.c
+++ b/drivers/input/touchscreen/ili210x.c
@@ -376,7 +376,7 @@ static int ili210x_i2c_probe(struct i2c_client *client,
return error;
}
- error = sysfs_create_group(>kobj, _attr_group);
+ error = devm_device_add_group(dev, _attr_group);
if (error) {
dev_err(dev, "Unable to create sysfs attributes, err: %d\n",
error);
@@ -386,7 +386,7 @@ static int ili210x_i2c_probe(struct i2c_client *client,
error = input_register_device(priv->input);
if (error) {
dev_err(dev, "Cannot register input device, err: %d\n", error);
- goto err_remove_sysfs;
+ return error;
}
device_init_wakeup(dev, 1);
@@ -396,17 +396,6 @@ static int ili210x_i2c_probe(struct i2c_client *client,
client->irq, firmware.id, firmware.major, firmware.minor);
return 0;
-
-err_remove_sysfs:
- sysfs_remove_group(>kobj, _attr_group);
- return error;
-}
-
-static int ili210x_i2c_remove(struct i2c_client *client)
-{
- sysfs_remove_group(>dev.kobj, _attr_group);
-
- return 0;
}
static int __maybe_unused ili210x_i2c_suspend(struct device *dev)
@@ -454,7 +443,6 @@ static struct i2c_driver ili210x_ts_driver = {
},
.id_table = ili210x_i2c_id,
.probe = ili210x_i2c_probe,
- .remove = ili210x_i2c_remove,
};
module_i2c_driver(ili210x_ts_driver);
--
2.20.1.611.gfbb209baf1-goog
--
Dmitry
Re: linux-next: manual merge of the scsi-mkp tree with the fixes tree
Hi all,
On Thu, 7 Feb 2019 16:51:34 +1100 Stephen Rothwell
wrote:
>
> On Thu, 7 Feb 2019 15:47:47 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the scsi-mkp tree got a conflict in:
> >
> > drivers/scsi/osd/osd_initiator.c
> >
> > between commit:
> >
> > 24648908acac ("scsi: osd: osd_initiator: mark expected switch
> > fall-throughs")
>
> I will remove that from my fixes tree for tomorrow.
And that same patch appears in the kspp-gustavo tree as well ...
--
Cheers,
Stephen Rothwell
pgp22KW65uefo.pgp
Description: OpenPGP digital signature
[PATCH 1/1] docs: powerpc: Convert to RST format
The PowerPC docs have yet to be converted to RST format. Let's kick it
off by doing all the files that _don't_ contain ASCII art.
- Add SPDX license identifier to each new RST file.
.. SPDX-License-Identifier: GPL-2.0
- User correct heading adornments.
- Make all lines < 72 characters in width.
- Use correct indentation for code blocks, add syntax highlighting
- Sparingly use double ticks if it makes the files easier to parse
both in text and on the web.
- Fix any super obvious typos (lean towards not making changes so that
we don't introduce errors).
Edited as text files (obviously) and formatted as HTML to verify
rendering, no other formats verified.
Convert docs to RST format, adding license.
Signed-off-by: Tobin C. Harding
---
Documentation/index.rst | 1 +
Documentation/powerpc/DAWR-POWER9.rst | 60
Documentation/powerpc/DAWR-POWER9.txt | 58 ---
Documentation/powerpc/bootwrapper.rst | 140
Documentation/powerpc/bootwrapper.txt | 141
Documentation/powerpc/conf.py | 10 +
Documentation/powerpc/cpu_features.rst| 62
Documentation/powerpc/cpu_features.txt| 56 ---
.../powerpc/eeh-pci-error-recovery.rst| 319 +
.../powerpc/eeh-pci-error-recovery.txt| 334 --
Documentation/powerpc/index.rst | 21 ++
Documentation/powerpc/isa-versions.rst| 234
Documentation/powerpc/mpc52xx.rst | 52 +++
Documentation/powerpc/mpc52xx.txt | 39 --
Documentation/powerpc/pmu-ebb.rst | 148
Documentation/powerpc/pmu-ebb.txt | 137 ---
Documentation/powerpc/ptrace.rst | 177 ++
Documentation/powerpc/ptrace.txt | 151
.../{syscall64-abi.txt => syscall64-abi.rst} | 80 +++--
.../powerpc/transactional_memory.rst | 259 ++
.../powerpc/transactional_memory.txt | 244 -
21 files changed, 1460 insertions(+), 1263 deletions(-)
create mode 100644 Documentation/powerpc/DAWR-POWER9.rst
delete mode 100644 Documentation/powerpc/DAWR-POWER9.txt
create mode 100644 Documentation/powerpc/bootwrapper.rst
delete mode 100644 Documentation/powerpc/bootwrapper.txt
create mode 100644 Documentation/powerpc/conf.py
create mode 100644 Documentation/powerpc/cpu_features.rst
delete mode 100644 Documentation/powerpc/cpu_features.txt
create mode 100644 Documentation/powerpc/eeh-pci-error-recovery.rst
delete mode 100644 Documentation/powerpc/eeh-pci-error-recovery.txt
create mode 100644 Documentation/powerpc/index.rst
create mode 100644 Documentation/powerpc/mpc52xx.rst
delete mode 100644 Documentation/powerpc/mpc52xx.txt
create mode 100644 Documentation/powerpc/pmu-ebb.rst
delete mode 100644 Documentation/powerpc/pmu-ebb.txt
create mode 100644 Documentation/powerpc/ptrace.rst
delete mode 100644 Documentation/powerpc/ptrace.txt
rename Documentation/powerpc/{syscall64-abi.txt => syscall64-abi.rst} (58%)
create mode 100644 Documentation/powerpc/transactional_memory.rst
delete mode 100644 Documentation/powerpc/transactional_memory.txt
diff --git a/Documentation/index.rst b/Documentation/index.rst
index c858c2e66e36..e0cf2e4a78cf 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -101,6 +101,7 @@ implementation.
:maxdepth: 2
sh/index
+ powerpc/index
Filesystem Documentation
diff --git a/Documentation/powerpc/DAWR-POWER9.rst
b/Documentation/powerpc/DAWR-POWER9.rst
new file mode 100644
index ..0af7c9567931
--- /dev/null
+++ b/Documentation/powerpc/DAWR-POWER9.rst
@@ -0,0 +1,60 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+DAWR issues on POWER9
+=
+
+On POWER9 the DAWR can cause a checkstop if it points to cache inhibited
+(CI) memory. Currently Linux has no way to disinguish CI memory when
+configuring the DAWR, so (for now) the DAWR is disabled by this commit::
+
+commit 9654153158d3e0684a1bdb76dbababdb7111d5a0
+Author: Michael Neuling
+Date: Tue Mar 27 15:37:24 2018 +1100
+powerpc: Disable DAWR in the base POWER9 CPU features
+
+Technical details
+=
+
+DAWR has 6 different ways of being set.
+
+1. ptrace
+2. h_set_mode(DAWR)
+3. h_set_dabr()
+4. kvmppc_set_one_reg()
+5. xmon
+
+For ptrace, we now advertise zero breakpoints on POWER9 via the
+PPC_PTRACE_GETHWDBGINFO call. This results in GDB falling back to
+software emulation of the watchpoint (which is slow).
+
+h_set_mode(DAWR) and h_set_dabr() will now return an error to the guest
+on a POWER9 host. Current Linux guests ignore this error, so they will
+silently not get the DAWR.
+
+kvmppc_set_one_reg() will store the value in the vcpu but won't actually
+set it on POWER9 hardware. This is done so we don't break migration from
+POWER8 to POWER9, at the cost of silently losing
[PATCH 0/1] Start conversion of PowerPC docs
Hi Michael,
As discussed at LCA here is the start to the docs conversion for PowerPC
to RST.
This applies cleanly on top of the mainline (5.20-rc5) and Jon's tree
(docs-next branch).
I'm guessing it should go in through the PowerPC tree because I doubt
you want to review this Jon, it's one big single patch (all blame for
that falls on mpe ;)
This patch converts all the files that do _not_ contain ASCII art - I'm
not sure how to go about doing those, suggestions please.
>From the commit message:
- Add SPDX license identifier to each new RST file.
.. SPDX-License-Identifier: GPL-2.0
- User correct heading adornments.
- Make all lines < 72 characters in width.
- Use correct indentation for code blocks, add syntax highlighting
- Sparingly use double ticks if it makes the files easier to parse
both in text and on the web.
- Fix any super obvious typos (lean towards not making changes so that
we don't introduce errors).
Edited as text files (obviously) and formatted as HTML to verify
rendering, no other formats verified.
thanks,
Tobin.
Tobin C. Harding (1):
docs: powerpc: Convert docs to RST format.
Documentation/index.rst | 1 +
Documentation/powerpc/DAWR-POWER9.rst | 60
Documentation/powerpc/DAWR-POWER9.txt | 58 ---
Documentation/powerpc/bootwrapper.rst | 140
Documentation/powerpc/bootwrapper.txt | 141
Documentation/powerpc/conf.py | 10 +
Documentation/powerpc/cpu_features.rst| 62
Documentation/powerpc/cpu_features.txt| 56 ---
.../powerpc/eeh-pci-error-recovery.rst| 319 +
.../powerpc/eeh-pci-error-recovery.txt| 334 --
Documentation/powerpc/index.rst | 21 ++
Documentation/powerpc/isa-versions.rst| 234
Documentation/powerpc/mpc52xx.rst | 52 +++
Documentation/powerpc/mpc52xx.txt | 39 --
Documentation/powerpc/pmu-ebb.rst | 148
Documentation/powerpc/pmu-ebb.txt | 137 ---
Documentation/powerpc/ptrace.rst | 177 ++
Documentation/powerpc/ptrace.txt | 151
.../{syscall64-abi.txt => syscall64-abi.rst} | 80 +++--
.../powerpc/transactional_memory.rst | 259 ++
.../powerpc/transactional_memory.txt | 244 -
21 files changed, 1460 insertions(+), 1263 deletions(-)
create mode 100644 Documentation/powerpc/DAWR-POWER9.rst
delete mode 100644 Documentation/powerpc/DAWR-POWER9.txt
create mode 100644 Documentation/powerpc/bootwrapper.rst
delete mode 100644 Documentation/powerpc/bootwrapper.txt
create mode 100644 Documentation/powerpc/conf.py
create mode 100644 Documentation/powerpc/cpu_features.rst
delete mode 100644 Documentation/powerpc/cpu_features.txt
create mode 100644 Documentation/powerpc/eeh-pci-error-recovery.rst
delete mode 100644 Documentation/powerpc/eeh-pci-error-recovery.txt
create mode 100644 Documentation/powerpc/index.rst
create mode 100644 Documentation/powerpc/mpc52xx.rst
delete mode 100644 Documentation/powerpc/mpc52xx.txt
create mode 100644 Documentation/powerpc/pmu-ebb.rst
delete mode 100644 Documentation/powerpc/pmu-ebb.txt
create mode 100644 Documentation/powerpc/ptrace.rst
delete mode 100644 Documentation/powerpc/ptrace.txt
rename Documentation/powerpc/{syscall64-abi.txt => syscall64-abi.rst} (58%)
create mode 100644 Documentation/powerpc/transactional_memory.rst
delete mode 100644 Documentation/powerpc/transactional_memory.txt
--
2.20.1
hi
Please get back to me My name is Sgt.Sherri Gallagher,
Re: [PATCH v7 05/10] clk: bd718x7: Support ROHM BD70528 clk block
On Wed, Feb 06, 2019 at 09:31:27AM -0800, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2019-02-06 01:39:38)
> > @@ -86,9 +87,21 @@ static int bd71837_clk_probe(struct platform_device
> > *pdev)
> > dev_err(>dev, "No parent clk found\n");
> > return -EINVAL;
> > }
> > -
> > - c->reg = BD718XX_REG_OUT32K;
> > - c->mask = BD718XX_OUT32K_EN;
> > + switch (mfd->chip_type) {
> > + case ROHM_CHIP_TYPE_BD71837:
> > + case ROHM_CHIP_TYPE_BD71847:
> > +
>
> Nitpick: why the extra newline above?
For no obvious reason. I'll fix this as I need to create new version
anyways. I'll squash the first 3 patches and fix some issues pointed out
by the 0-Day test suite.
Br,
Matti Vaittinen
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA
On Wed, Feb 6, 2019 at 9:23 PM Jason Gunthorpe wrote: > > On Thu, Feb 07, 2019 at 02:52:58PM +1100, Dave Chinner wrote: > > On Wed, Feb 06, 2019 at 05:24:50PM -0500, Doug Ledford wrote: > > > On Wed, 2019-02-06 at 15:08 -0700, Jason Gunthorpe wrote: > > > > On Thu, Feb 07, 2019 at 08:03:56AM +1100, Dave Chinner wrote: > > > > > On Wed, Feb 06, 2019 at 07:16:21PM +, Christopher Lameter wrote: > > > > > > On Wed, 6 Feb 2019, Doug Ledford wrote: > > > > > > > > > > > > > > Most of the cases we want revoke for are things like truncate(). > > > > > > > > Shouldn't happen with a sane system, but we're trying to avoid > > > > > > > > users > > > > > > > > doing awful things like being able to DMA to pages that are now > > > > > > > > part of > > > > > > > > a different file. > > > > > > > > > > > > > > Why is the solution revoke then? Is there something besides > > > > > > > truncate > > > > > > > that we have to worry about? I ask because EBUSY is not currently > > > > > > > listed as a return value of truncate, so extending the API to > > > > > > > include > > > > > > > EBUSY to mean "this file has pinned pages that can not be freed" > > > > > > > is not > > > > > > > (or should not be) totally out of the question. > > > > > > > > > > > > > > Admittedly, I'm coming in late to this conversation, but did I > > > > > > > miss the > > > > > > > portion where that alternative was ruled out? > > > > > > > > > > > > Coming in late here too but isnt the only DAX case that we are > > > > > > concerned > > > > > > about where there was an mmap with the O_DAX option to do direct > > > > > > write > > > > > > though? If we only allow this use case then we may not have to > > > > > > worry about > > > > > > long term GUP because DAX mapped files will stay in the physical > > > > > > location > > > > > > regardless. > > > > > > > > > > No, that is not guaranteed. Soon as we have reflink support on XFS, > > > > > writes will physically move the data to a new physical location. > > > > > This is non-negotiatiable, and cannot be blocked forever by a gup > > > > > pin. > > > > > > > > > > IOWs, DAX on RDMA requires a) page fault capable hardware so that > > > > > the filesystem can move data physically on write access, and b) > > > > > revokable file leases so that the filesystem can kick userspace out > > > > > of the way when it needs to. > > > > > > > > Why do we need both? You want to have leases for normal CPU mmaps too? > > > > We don't need them for normal CPU mmaps because that's locally > > addressable page fault capable hardware. i.e. if we need to > > serialise something, we just use kernel locks, etc. When it's a > > remote entity (such as RDMA) we have to get that remote entity to > > release it's reference/access so the kernel has exclusive access > > to the resource it needs to act on. > > Why can't DAX follow the path of GPU? Jerome has been working on > patches that let GPU do page migrations and other activities and > maintain full sync with ODP MRs. > > I don't know of a reason why DAX migration would be different from GPU > migration. I don't think we need leases in the ODP case. > The ODP RDMA HW does support halting RDMA access and interrupting the > CPU to re-establish access, so you can get your locks/etc as. With > today's implemetnation DAX has to trigger all the needed MM notifier > call backs to make this work. Tomorrow it will have to interact with > the HMM mirror API. > > Jerome is already demoing this for the GPU case, so the RDMA ODP HW is > fine. > > Is DAX migration different in some way from GPU's migration that it > can't use this flow and needs a lease to??? This would be a big > surprise to me. Agree, I see no need for leases in the ODP case the mmu_notifier is already fulfilling the same role as a lease notification. > > If your argument is that "existing RDMA apps don't have a recall > > mechanism" then that's what they are going to need to implement to > > work with DAX+RDMA. Reliable remote access arbitration is required > > for DAX+RDMA, regardless of what filesysetm the data is hosted on. > > My argument is that is a toy configuration that no production user > would use. It either has the ability to wait for the lease to revoke > 'forever' without consequence or the application will be critically > de-stablized by the kernel's escalation to time bound the response. > (or production systems never get revoke) I think we're off track on the need for leases for anything other than non-ODP hardware. Otherwise this argument seems to be saying there is absolutely no safe way to recall a memory registration from hardware, which does not make sense because SIGKILL needs to work as a last resort. > > Anything less is a potential security hole. > > How does it get to a security hole? Obviously the pages under DMA > can't be re-used for anything.. Writes to storage outside the security domain they were intended due to the filesystem reallocating the physical blocks. > >
Re: [PATCH v7 00/10] support ROHM BD70528 PMIC
Moro Kalle, On Wed, Feb 06, 2019 at 08:31:32PM +0200, Kalle Valo wrote: > Matti Vaittinen writes: > > > Patch series introducing support for ROHM BD70528 PMIC > > > > Please note that patch 1 breaks compilation without patches 2 and 3 > > Knowing the bd718x7 driver is already in upstream, it might be good > > if this change went through single tree, right? > > That would break bisect, please avoid that. So after applying patches > from a patchset one by one the compilation should always succeed. Right. Thanks for the reminder. Mark did also ask about this earlier. This split was originally done to clearly point out changes impacting in-tree drivers on separate subsystems/trees (mfd, clk and regulators). But you are right, these should be squashed before applying. I have now received acks from Mark and Stephen so I guess I can squash them even though Lee has not yet commented anything yet. I guess that 7 previous versions do already clearly enough point out these changes =) I will squash them in next version. Thanks for the reminder. > > -- > Kalle Valo -- Matti Vaittinen, Linux device drivers ROHM Semiconductors, Finland SWDC Kiviharjunlenkki 1E 90220 OULU FINLAND ~~~ "I don't think so," said Rene Descartes. Just then, he vanished ~~~
[PATCH] arm64: dts: rockchip: Add on-board WiFi/BT support for Rock960 boards
Add on-board WiFi/BT support for Rock960 boards such as Rock960 based
on AP6356S and Ficus based on AP6354 wireless modules.
Firmwares for the respective boards are available here:
http://people.linaro.org/~manivannan.sadhasivam/rock960_wifi/
http://people.linaro.org/~manivannan.sadhasivam/ficus_wifi/
Signed-off-by: Manivannan Sadhasivam
---
.../boot/dts/rockchip/rk3399-rock960.dtsi | 96 ++-
1 file changed, 95 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
index 56abbb08c133..1b2f7cd82244 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
@@ -9,6 +9,15 @@
#include "rk3399-opp.dtsi"
/ {
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = < 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ reset-gpios = < RK_PB2 GPIO_ACTIVE_LOW>;
+ };
+
vcc1v8_s0: vcc1v8-s0 {
compatible = "regulator-fixed";
regulator-name = "vcc1v8_s0";
@@ -362,6 +371,20 @@
};
{
+ bt {
+ bt_enable_h: bt-enable-h {
+ rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO _pull_none>;
+ };
+
+ bt_host_wake_l: bt-host-wake-l {
+ rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO _pull_none>;
+ };
+
+ bt_wake_l: bt-wake-l {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
sdmmc {
sdmmc_bus1: sdmmc-bus1 {
rockchip,pins =
@@ -387,6 +410,26 @@
};
};
+ sdio0 {
+ sdio0_bus4: sdio0-bus4 {
+ rockchip,pins =
+ <2 20 RK_FUNC_1 _pull_up_20ma>,
+ <2 21 RK_FUNC_1 _pull_up_20ma>,
+ <2 22 RK_FUNC_1 _pull_up_20ma>,
+ <2 23 RK_FUNC_1 _pull_up_20ma>;
+ };
+
+ sdio0_cmd: sdio0-cmd {
+ rockchip,pins =
+ <2 24 RK_FUNC_1 _pull_up_20ma>;
+ };
+
+ sdio0_clk: sdio0-clk {
+ rockchip,pins =
+ <2 25 RK_FUNC_1 _pull_none_20ma>;
+ };
+ };
+
pmic {
pmic_int_l: pmic-int-l {
rockchip,pins =
@@ -403,6 +446,19 @@
<1 14 RK_FUNC_GPIO _pull_down>;
};
};
+
+ sdio-pwrseq {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins =
+ <0 RK_PB2 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_host_wake_l: wifi-host-wake-l {
+ rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO _pull_none>;
+ };
+ };
};
{
@@ -413,6 +469,33 @@
status = "okay";
};
+ {
+ clock-frequency = <5000>;
+ bus-width = <4>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ no-emmc;
+ keep-power-in-suspend;
+ mmc-pwrseq = <_pwrseq>;
+ non-removable;
+ num-slots = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_bus4 _cmd _clk>;
+ sd-uhs-sdr104;
+
+ status = "okay";
+
+ brcmf: wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ interrupt-names = "host-wake";
+ pinctrl-names = "default";
+ pinctrl-0 = <_host_wake_l>;
+ };
+};
+
{
bus-width = <8>;
mmc-hs400-1_8v;
@@ -439,8 +522,19 @@
{
pinctrl-names = "default";
- pinctrl-0 = <_xfer _cts>;
+ pinctrl-0 = <_xfer _cts _rts>;
status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = < 1>;
+ clock-names = "ext_clock";
+ device-wakeup-gpios = < RK_PD3 GPIO_ACTIVE_HIGH>;
+ host-wakeup-gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
+ shutdown-gpios = < RK_PB1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_host_wake_l _wake_l _enable_h>;
+ };
};
{
--
2.17.1
Re: [PATCH] net: stmmac: Variable "val" in function sun8i_dwmac_set_syscon() could be uninitialized
Thanks, but why initialization matters here? Is performance the main concern?
On Wed, Feb 6, 2019 at 9:52 PM Yizhuo Zhai wrote:
>
> Thanks, but why initialization matters here? Is performance the main concern?
>
> On Wed, Feb 6, 2019 at 8:17 PM David Miller wrote:
>>
>> From: Yizhuo
>> Date: Tue, 5 Feb 2019 14:15:59 -0800
>>
>> > @@ -639,9 +639,14 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv
>> > *priv)
>> > struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
>> > struct device_node *node = priv->device->of_node;
>> > int ret;
>> > - u32 reg, val;
>> > + u32 reg, val = 0;
>> > +
>> > + ret = regmap_read(gmac->regmap, SYSCON_EMAC_REG, );
>> > + if (ret) {
>> > + dev_err(priv->device, "Fail to read SYSCON_EMAC_REG.\n");
>> > + return ret;
>> > + }
>>
>> I agree with the other reviewer that since you check 'ret' the
>> initialization of
>> 'val' is no longer needed.
>
>
>
> --
> Kind Regards,
>
> Yizhuo Zhai
>
> Computer Science, Graduate Student
> University of California, Riverside
--
Kind Regards,
Yizhuo Zhai
Computer Science, Graduate Student
University of California, Riverside
Re: linux-next: manual merge of the scsi-mkp tree with the fixes tree
Hi all,
On Thu, 7 Feb 2019 15:47:47 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the scsi-mkp tree got a conflict in:
>
> drivers/scsi/osd/osd_initiator.c
>
> between commit:
>
> 24648908acac ("scsi: osd: osd_initiator: mark expected switch
> fall-throughs")
I will remove that from my fixes tree for tomorrow.
--
Cheers,
Stephen Rothwell
pgpb43Fyw5oWv.pgp
Description: OpenPGP digital signature
Re: [PATCH -tip 0/2] more get_user_pages mmap_sem cleanups
Unlike what the subject says, this is not against -tip, it applies on today's -next. On Wed, 06 Feb 2019, Davidlohr Bueso wrote: Hi, Here are two more patchlets that cleanup mmap_sem and gup abusers. The second is also a fixlet. Compile-tested only. Please consider for v5.1 Thanks! Davidlohr Bueso (2): xsk: do not use mmap_sem MIPS/c-r4k: do no use mmap_sem for gup_fast() arch/mips/mm/c-r4k.c | 6 +- net/xdp/xdp_umem.c | 6 ++ 2 files changed, 3 insertions(+), 9 deletions(-) -- 2.16.4
[PATCH v2 net-next] net: phy: fixed_phy: Fix fixed_phy not checking GPIO
Fix fixed_phy not checking GPIO if no link_update callback
is registered.
In the original version all users registered a link_update
callback so the issue was masked.
Fixes: a5597008dbc2 ("phy: fixed_phy: Add gpio to determine link up/down.")
Reviewed-by: Andrew Lunn
Signed-off-by: Moritz Fischer
---
Changes from v1:
- Added Andrew's Reviewed-by: tag
- Added Fixes: tag (Thanks for digging, Andrew!)
---
drivers/net/phy/fixed_phy.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index f136a23c1a35..d810f914aaa4 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -85,11 +85,11 @@ static int fixed_mdio_read(struct mii_bus *bus, int
phy_addr, int reg_num)
s = read_seqcount_begin(>seqcount);
fp->status.link = !fp->no_carrier;
/* Issue callback if user registered it. */
- if (fp->link_update) {
+ if (fp->link_update)
fp->link_update(fp->phydev->attached_dev,
>status);
- fixed_phy_update(fp);
- }
+ /* Check the GPIO for change in status */
+ fixed_phy_update(fp);
state = fp->status;
} while (read_seqcount_retry(>seqcount, s));
--
2.20.1
[PATCH -tip 0/2] more get_user_pages mmap_sem cleanups
Hi, Here are two more patchlets that cleanup mmap_sem and gup abusers. The second is also a fixlet. Compile-tested only. Please consider for v5.1 Thanks! Davidlohr Bueso (2): xsk: do not use mmap_sem MIPS/c-r4k: do no use mmap_sem for gup_fast() arch/mips/mm/c-r4k.c | 6 +- net/xdp/xdp_umem.c | 6 ++ 2 files changed, 3 insertions(+), 9 deletions(-) -- 2.16.4
[PATCH 1/2] xsk: do not use mmap_sem
Holding mmap_sem exclusively for a gup() is an overkill.
Lets replace the call for gup_fast() and let the mm take
it if necessary.
Cc: David S. Miller
Cc: Bjorn Topel
Cc: Magnus Karlsson
CC: net...@vger.kernel.org
Signed-off-by: Davidlohr Bueso
---
net/xdp/xdp_umem.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 5ab236c5c9a5..25e1e76654a8 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -265,10 +265,8 @@ static int xdp_umem_pin_pages(struct xdp_umem *umem)
if (!umem->pgs)
return -ENOMEM;
- down_write(>mm->mmap_sem);
- npgs = get_user_pages(umem->address, umem->npgs,
- gup_flags, >pgs[0], NULL);
- up_write(>mm->mmap_sem);
+ npgs = get_user_pages_fast(umem->address, umem->npgs,
+ gup_flags, >pgs[0]);
if (npgs != umem->npgs) {
if (npgs >= 0) {
--
2.16.4
[PATCH 2/2] MIPS/c-r4k: do no use mmap_sem for gup_fast()
It is well known that because the mm can internally call the regular gup_unlocked if the lockless approach fails and take the sem there, the caller must not hold the mmap_sem already. Fixes: e523f289fe4d (MIPS: c-r4k: Fix sigtramp SMP call to use kmap) Cc: Ralf Baechle Cc: Paul Burton Cc: James Hogan Cc: linux-m...@vger.kernel.org Signed-off-by: Davidlohr Bueso --- arch/mips/mm/c-r4k.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c index cc4e17caeb26..38fe86928837 100644 --- a/arch/mips/mm/c-r4k.c +++ b/arch/mips/mm/c-r4k.c @@ -1034,11 +1034,9 @@ static void r4k_flush_cache_sigtramp(unsigned long addr) struct flush_cache_sigtramp_args args; int npages; - down_read(>mm->mmap_sem); - npages = get_user_pages_fast(addr, 1, 0, ); if (npages < 1) - goto out; + return; args.mm = current->mm; args.addr = addr; @@ -1046,8 +1044,6 @@ static void r4k_flush_cache_sigtramp(unsigned long addr) r4k_on_each_cpu(R4K_HIT, local_r4k_flush_cache_sigtramp, ); put_page(args.page); -out: - up_read(>mm->mmap_sem); } static void r4k_flush_icache_all(void) -- 2.16.4
Re: [PATCH v2] dma-direct: do not allocate a single page from CMA area
On Wed, Feb 06, 2019 at 06:28:49PM -0800, Nicolin Chen wrote: > So we will keep allocating single pages in dev->cma_area if it's > present, in order to address your previous concern? Yes.
Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA
On Wed, Feb 06, 2019 at 04:22:16PM -0800, Dan Williams wrote: > On Wed, Feb 6, 2019 at 3:41 PM Jason Gunthorpe wrote: > [..] > > > You're describing the current situation, i.e. Linux already implements > > > this, it's called Device-DAX and some users of RDMA find it > > > insufficient. The choices are to continue to tell them "no", or say > > > "yes, but you need to submit to lease coordination". > > > > Device-DAX is not what I'm imagining when I say XFS--. > > > > I mean more like XFS with all features that require rellocation of > > blocks disabled. > > > > Forbidding hold punch, reflink, cow, etc, doesn't devolve back to > > device-dax. > > True, not all the way, but the distinction loses significance as you > lose fs features. > > Filesystems mark DAX functionality experimental [1] precisely because > it forbids otherwise typical operations that work in the nominal page > cache case. An approach that says "lets cement the list of things a > filesystem or a core-memory-mangement facility can't do because RDMA > finds it awkward" is bad precedent. I'm not saying these rules should apply globaly. I'm suggesting you could have a FS that supports gup_longterm by design, and a FS that doesn't. And that is OK. They can have different rules. Obviously the golden case here is to use ODP (which doesn't call gup_longterm at all) - that works for both. Supporting non-ODP is a trade off case - users that want to run on limited HW must accept limited functionality. Limited functionality is better than no-funtionality. Linux has many of these user-choose tradeoffs. This is how it supports such a wide range of HW capabilities. Not all HW can do all things. Some features really do need HW support. It has always been that way. Jason
Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA
On Thu, Feb 07, 2019 at 02:52:58PM +1100, Dave Chinner wrote: > On Wed, Feb 06, 2019 at 05:24:50PM -0500, Doug Ledford wrote: > > On Wed, 2019-02-06 at 15:08 -0700, Jason Gunthorpe wrote: > > > On Thu, Feb 07, 2019 at 08:03:56AM +1100, Dave Chinner wrote: > > > > On Wed, Feb 06, 2019 at 07:16:21PM +, Christopher Lameter wrote: > > > > > On Wed, 6 Feb 2019, Doug Ledford wrote: > > > > > > > > > > > > Most of the cases we want revoke for are things like truncate(). > > > > > > > Shouldn't happen with a sane system, but we're trying to avoid > > > > > > > users > > > > > > > doing awful things like being able to DMA to pages that are now > > > > > > > part of > > > > > > > a different file. > > > > > > > > > > > > Why is the solution revoke then? Is there something besides > > > > > > truncate > > > > > > that we have to worry about? I ask because EBUSY is not currently > > > > > > listed as a return value of truncate, so extending the API to > > > > > > include > > > > > > EBUSY to mean "this file has pinned pages that can not be freed" is > > > > > > not > > > > > > (or should not be) totally out of the question. > > > > > > > > > > > > Admittedly, I'm coming in late to this conversation, but did I miss > > > > > > the > > > > > > portion where that alternative was ruled out? > > > > > > > > > > Coming in late here too but isnt the only DAX case that we are > > > > > concerned > > > > > about where there was an mmap with the O_DAX option to do direct write > > > > > though? If we only allow this use case then we may not have to worry > > > > > about > > > > > long term GUP because DAX mapped files will stay in the physical > > > > > location > > > > > regardless. > > > > > > > > No, that is not guaranteed. Soon as we have reflink support on XFS, > > > > writes will physically move the data to a new physical location. > > > > This is non-negotiatiable, and cannot be blocked forever by a gup > > > > pin. > > > > > > > > IOWs, DAX on RDMA requires a) page fault capable hardware so that > > > > the filesystem can move data physically on write access, and b) > > > > revokable file leases so that the filesystem can kick userspace out > > > > of the way when it needs to. > > > > > > Why do we need both? You want to have leases for normal CPU mmaps too? > > We don't need them for normal CPU mmaps because that's locally > addressable page fault capable hardware. i.e. if we need to > serialise something, we just use kernel locks, etc. When it's a > remote entity (such as RDMA) we have to get that remote entity to > release it's reference/access so the kernel has exclusive access > to the resource it needs to act on. Why can't DAX follow the path of GPU? Jerome has been working on patches that let GPU do page migrations and other activities and maintain full sync with ODP MRs. I don't know of a reason why DAX migration would be different from GPU migration. The ODP RDMA HW does support halting RDMA access and interrupting the CPU to re-establish access, so you can get your locks/etc as. With today's implemetnation DAX has to trigger all the needed MM notifier call backs to make this work. Tomorrow it will have to interact with the HMM mirror API. Jerome is already demoing this for the GPU case, so the RDMA ODP HW is fine. Is DAX migration different in some way from GPU's migration that it can't use this flow and needs a lease to??? This would be a big surprise to me. > If your argument is that "existing RDMA apps don't have a recall > mechanism" then that's what they are going to need to implement to > work with DAX+RDMA. Reliable remote access arbitration is required > for DAX+RDMA, regardless of what filesysetm the data is hosted on. My argument is that is a toy configuration that no production user would use. It either has the ability to wait for the lease to revoke 'forever' without consequence or the application will be critically de-stablized by the kernel's escalation to time bound the response. (or production systems never get revoke) > Anything less is a potential security hole. How does it get to a security hole? Obviously the pages under DMA can't be re-used for anything.. > Once we have reflink on DAX, somebody is going to ask for > no-compromise RDMA support on these filesystems (e.g. NFSv4 file > server on pmem/FS-DAX that allows server side clones and clients use > RDMA access) and we're going to have to work out how to support it. > Rather than shouting at the messenger (XFS) that reports the hard > problems we have to solve, how about we work out exactly what we > need to do to support this functionality because it is coming and > people want it. I've thought this was basically solved - use ODP and you get full functionality. Until you just now brought up the idea that ODP is not enough.. The arguing here is that there is certainly a subset of people that don't want to use ODP. If we tell them a hard 'no' then the conversation is done. Otherwise, I like the idea
[PATCH] cdrom: Fix race condition in cdrom_sysctl_register
The following traceback is sometimes seen when booting an image in qemu:
[ 54.608293] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 54.611085] Fusion MPT base driver 3.04.20
[ 54.611877] Copyright (c) 1999-2008 LSI Corporation
[ 54.616234] Fusion MPT SAS Host driver 3.04.20
[ 54.635139] sysctl duplicate entry: /dev/cdrom//info
[ 54.639578] CPU: 0 PID: 266 Comm: kworker/u4:5 Not tainted 5.0.0-rc5 #1
[ 54.639578] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0
02/06/2015
[ 54.641273] Workqueue: events_unbound async_run_entry_fn
[ 54.641273] Call Trace:
[ 54.641273] dump_stack+0x67/0x90
[ 54.641273] __register_sysctl_table+0x50b/0x570
[ 54.641273] ? rcu_read_lock_sched_held+0x6f/0x80
[ 54.641273] ? kmem_cache_alloc_trace+0x1c7/0x1f0
[ 54.646814] __register_sysctl_paths+0x1c8/0x1f0
[ 54.646814] cdrom_sysctl_register.part.7+0xc/0x5f
[ 54.646814] register_cdrom.cold.24+0x2a/0x33
[ 54.646814] sr_probe+0x4bd/0x580
[ 54.646814] ? __driver_attach+0xd0/0xd0
[ 54.646814] really_probe+0xd6/0x260
[ 54.646814] ? __driver_attach+0xd0/0xd0
[ 54.646814] driver_probe_device+0x4a/0xb0
[ 54.646814] ? __driver_attach+0xd0/0xd0
[ 54.646814] bus_for_each_drv+0x73/0xc0
[ 54.646814] __device_attach+0xd6/0x130
[ 54.646814] bus_probe_device+0x9a/0xb0
[ 54.646814] device_add+0x40c/0x670
[ 54.646814] ? __pm_runtime_resume+0x4f/0x80
[ 54.646814] scsi_sysfs_add_sdev+0x81/0x290
[ 54.646814] scsi_probe_and_add_lun+0x888/0xc00
[ 54.646814] ? scsi_autopm_get_host+0x21/0x40
[ 54.646814] __scsi_add_device+0x116/0x130
[ 54.646814] ata_scsi_scan_host+0x93/0x1c0
[ 54.646814] async_run_entry_fn+0x34/0x100
[ 54.646814] process_one_work+0x237/0x5e0
[ 54.646814] worker_thread+0x37/0x380
[ 54.646814] ? rescuer_thread+0x360/0x360
[ 54.646814] kthread+0x118/0x130
[ 54.646814] ? kthread_create_on_node+0x60/0x60
[ 54.646814] ret_from_fork+0x3a/0x50
The only sensible explanation is that cdrom_sysctl_register() is called
twice, once from the module init function and once from register_cdrom().
cdrom_sysctl_register() is not mutex protected and may happily execute
twice if the second call is made before the first call is complete.
Use a static atomic to ensure that the function is executed exactly once.
Signed-off-by: Guenter Roeck
---
drivers/cdrom/cdrom.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 614ecdbb4ab7..933268b8d6a5 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -265,6 +265,7 @@
/* #define ERRLOGMASK (CD_WARNING|CD_OPEN|CD_COUNT_TRACKS|CD_CLOSE) */
/* #define ERRLOGMASK
(CD_WARNING|CD_REG_UNREG|CD_DO_IOCTL|CD_OPEN|CD_CLOSE|CD_COUNT_TRACKS) */
+#include
#include
#include
#include
@@ -3692,9 +3693,9 @@ static struct ctl_table_header *cdrom_sysctl_header;
static void cdrom_sysctl_register(void)
{
- static int initialized;
+ static atomic_t initialized = ATOMIC_INIT(0);
- if (initialized == 1)
+ if (!atomic_add_unless(, 1, 1))
return;
cdrom_sysctl_header = register_sysctl_table(cdrom_root_table);
@@ -3705,8 +3706,6 @@ static void cdrom_sysctl_register(void)
cdrom_sysctl_settings.debug = debug;
cdrom_sysctl_settings.lock = lockdoor;
cdrom_sysctl_settings.check = check_media_type;
-
- initialized = 1;
}
static void cdrom_sysctl_unregister(void)
--
2.7.4
Re: [PATCH v3 1/2] mm: add probe_user_read()
Murilo Opsfelder Araujo writes:
>> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
>> index 37b226e8df13..ef99edd63da3 100644
>> --- a/include/linux/uaccess.h
>> +++ b/include/linux/uaccess.h
>> @@ -263,6 +263,40 @@ extern long strncpy_from_unsafe(char *dst, const void
>> *unsafe_addr, long count);
>> #define probe_kernel_address(addr, retval) \
>> probe_kernel_read(, addr, sizeof(retval))
>>
>> +/**
>> + * probe_user_read(): safely attempt to read from a user location
>> + * @dst: pointer to the buffer that shall take the data
>> + * @src: address to read from
>> + * @size: size of the data chunk
>> + *
>> + * Safely read from address @src to the buffer at @dst. If a kernel fault
>> + * happens, handle that and return -EFAULT.
>> + *
>> + * We ensure that the copy_from_user is executed in atomic context so that
>> + * do_page_fault() doesn't attempt to take mmap_sem. This makes
>> + * probe_user_read() suitable for use within regions where the caller
>> + * already holds mmap_sem, or other locks which nest inside mmap_sem.
>> + *
>> + * Returns: 0 on success, -EFAULT on error.
>> + */
>> +
>> +#ifndef probe_user_read
>> +static __always_inline long probe_user_read(void *dst, const void __user
>> *src,
>> +size_t size)
>> +{
>> +long ret;
>> +
>> +if (!access_ok(src, size))
>> +return -EFAULT;
>
> Hopefully, there is still time for a minor comment.
>
> Do we need to differentiate the returned error here, e.g.: return
> -EACCES?
>
> I wonder if there will be situations where callers need to know why
> probe_user_read() failed.
It's pretty standard to return EFAULT when an access_ok() check fails,
so I think using EFAULT here is the safest option.
If we used EACCES we'd need to be more careful about converting code to
use this helper, as doing so would potentially cause the error value to
change, which in some cases is not OK.
cheers
Re: [PATCH 1/2] cpufreq: imx6q: Register an Energy Model
On 06-02-19, 23:34, Yangtao Li wrote: > Try and register an Energy Model from imx6q-cpufreq to allow > interested subsystems like the task scheduler to use the provided > information. > > Signed-off-by: Yangtao Li > --- > drivers/cpufreq/imx6q-cpufreq.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c > index 9fedf627e000..73bfd5bc3087 100644 > --- a/drivers/cpufreq/imx6q-cpufreq.c > +++ b/drivers/cpufreq/imx6q-cpufreq.c > @@ -210,6 +210,7 @@ static int imx6q_cpufreq_init(struct cpufreq_policy > *policy) > policy->clk = clks[ARM].clk; > ret = cpufreq_generic_init(policy, freq_table, transition_latency); > policy->suspend_freq = max_freq; > + dev_pm_opp_of_register_em(policy->cpus); > > return ret; > } Applied both. Thanks. -- viresh
Re: [PATCH v03] powerpc/numa: Perform full re-add of CPU for PRRN/VPHN topology update
Hi Michael,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.0-rc4 next-20190206]
[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/Michael-Bringmann/powerpc-numa-Perform-full-re-add-of-CPU-for-PRRN-VPHN-topology-update/20190207-101545
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=powerpc
All errors (new ones prefixed by >>):
arch/powerpc/mm/numa.c: In function 'numa_update_cpu_topology':
>> arch/powerpc/mm/numa.c:1361:4: error: implicit declaration of function
>> 'dlpar_cpu_readd'; did you mean 'raw_cpu_read'?
>> [-Werror=implicit-function-declaration]
dlpar_cpu_readd(cpu);
^~~
raw_cpu_read
cc1: some warnings being treated as errors
vim +1361 arch/powerpc/mm/numa.c
1298
1299 /*
1300 * Update the node maps and sysfs entries for each cpu whose home node
1301 * has changed. Returns 1 when the topology has changed, and 0
otherwise.
1302 *
1303 * readd_cpus: Also readd any CPUs that have changed affinity
1304 */
1305 static int numa_update_cpu_topology(bool readd_cpus)
1306 {
1307 unsigned int cpu, sibling, changed = 0;
1308 struct topology_update_data *updates, *ud;
1309 cpumask_t updated_cpus;
1310 struct device *dev;
1311 int weight, new_nid, i = 0;
1312
1313 if ((!prrn_enabled && !vphn_enabled && topology_inited) ||
1314 topology_update_in_progress)
1315 return 0;
1316
1317 weight = cpumask_weight(_associativity_changes_mask);
1318 if (!weight)
1319 return 0;
1320
1321 updates = kcalloc(weight, sizeof(*updates), GFP_KERNEL);
1322 if (!updates)
1323 return 0;
1324
1325 topology_update_in_progress = 1;
1326
1327 cpumask_clear(_cpus);
1328
1329 for_each_cpu(cpu, _associativity_changes_mask) {
1330 /*
1331 * If siblings aren't flagged for changes, updates list
1332 * will be too short. Skip on this update and set for
next
1333 * update.
1334 */
1335 if (!cpumask_subset(cpu_sibling_mask(cpu),
1336
_associativity_changes_mask)) {
1337 pr_info("Sibling bits not set for associativity
"
1338 "change, cpu%d\n", cpu);
1339 cpumask_or(_associativity_changes_mask,
1340 _associativity_changes_mask,
1341 cpu_sibling_mask(cpu));
1342 cpu = cpu_last_thread_sibling(cpu);
1343 continue;
1344 }
1345
1346 new_nid = find_and_online_cpu_nid(cpu);
1347
1348 if ((new_nid == numa_cpu_lookup_table[cpu]) ||
1349 !cpu_present(cpu)) {
1350 cpumask_andnot(_associativity_changes_mask,
1351 _associativity_changes_mask,
1352 cpu_sibling_mask(cpu));
1353 if (cpu_present(cpu))
1354 dbg("Assoc chg gives same node %d for
cpu%d\n",
1355 new_nid, cpu);
1356 cpu = cpu_last_thread_sibling(cpu);
1357 continue;
1358 }
1359
1360 if (readd_cpus)
> 1361 dlpar_cpu_readd(cpu);
1362
1363 for_each_cpu(sibling, cpu_sibling_mask(cpu)) {
1364 ud = [i++];
1365 ud->next = [i];
1366 ud->cpu = sibling;
1367 ud->new_nid = new_nid;
1368 ud->old_nid = numa_cpu_lookup_table[sibling];
1369 cpumask_set_cpu(sibling, _cpus);
1370 }
1371 cpu = cpu_last_thread_sibling(cpu);
1372 }
1373
1374 /*
1375 * Prevent processing of 'updates' from ove
linux-next: manual merge of the scsi-mkp tree with the fixes tree
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/osd/osd_initiator.c
between commit:
24648908acac ("scsi: osd: osd_initiator: mark expected switch fall-throughs")
from the fixes tree and commit:
19fcae3d4f2d ("scsi: remove the SCSI OSD library")
from the scsi-mkp tree.
I fixed it up (the latter removed the file) 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
pgpD_dtXrMpq9.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the scsi-mkp tree with Linus' tree
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/lpfc/lpfc_nvme.c
between commit:
7961cba6f7d8 ("scsi: lpfc: nvme: avoid hang / use-after-free when destroying
localport")
from Linus' tree and commit:
4c47efc140fa ("scsi: lpfc: Move SCSI and NVME Stats to hardware queue
structures")
from the scsi-mkp 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/scsi/lpfc/lpfc_nvme.c
index c84621a80ee5,e73895674f39..
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@@ -2592,16 -2178,14 +2180,14 @@@ lpfc_nvme_destroy_localport(struct lpfc
#if (IS_ENABLED(CONFIG_NVME_FC))
struct nvme_fc_local_port *localport;
struct lpfc_nvme_lport *lport;
- struct lpfc_nvme_ctrl_stat *cstat;
int ret;
+ DECLARE_COMPLETION_ONSTACK(lport_unreg_cmp);
if (vport->nvmei_support == 0)
return;
localport = vport->localport;
- vport->localport = NULL;
lport = (struct lpfc_nvme_lport *)localport->private;
- cstat = lport->cstat;
lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME,
"6011 Destroying NVME localport %p\n",
@@@ -2616,9 -2200,7 +2202,8 @@@
/* Wait for completion. This either blocks
* indefinitely or succeeds
*/
- lpfc_nvme_lport_unreg_wait(vport, lport);
+ lpfc_nvme_lport_unreg_wait(vport, lport, _unreg_cmp);
+ vport->localport = NULL;
- kfree(cstat);
/* Regardless of the unregister upcall response, clear
* nvmei_support. All rports are unregistered and the
pgpHlL6dt6c4Z.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 1/1] arm64: dts: sdm845: wireup the thermal trip points to cpufreq
On Thu, Feb 7, 2019 at 7:27 AM Matthias Kaehlcke wrote:
>
> On Wed, Feb 06, 2019 at 11:34:41AM -0800, Matthias Kaehlcke wrote:
> > On Wed, Feb 06, 2019 at 04:05:41PM +0530, Amit Kucheria wrote:
> > > On Sat, Jan 26, 2019 at 3:50 AM Matthias Kaehlcke
> > > wrote:
> > > > > > > trips {
> > > > > > > - cpu_alert0: trip0 {
> > > > > > > + cpu0_alert1: trip-point@0 {
> > > > > > > temperature = <75000>;
> > > > > >
> > > > > > In my observations a 'switch on/threshold' temperature of 75 degrees
> > > > > > leads to aggressive throttling with IPA when the temperature is
> > > > > > above
> > > > > > this threshold:
> > > > > >
> > > > > > [ 716.760804] cpu_cooling_ratelimit: 31 callbacks suppressed
> > > > > > [ 716.760836] cpu cpu4: Cooling state set to 10. New max freq =
> > > > > > 192
> > > > > > [ 716.773390] power_allocator_ratelimit: 15 callbacks suppressed
> > > > > > [ 716.773405] thermal thermal_zone5: Controlling power:
> > > > > > control_temp=95000 last_temp=73500, curr_temp=75200
> > > > > > total_requested_power=39025 total_granted_power=18654
> > > > > > [ 749.609336] cpu_cooling_ratelimit: 45 callbacks suppressed
> > > > > > [ 749.609371] cpu cpu4: Cooling state set to 11. New max freq =
> > > > > > 1843200
> > > > > > [ 749.624300] power_allocator_ratelimit: 24 callbacks suppressed
> > > > > > [ 749.624323] thermal thermal_zone5: Controlling power:
> > > > > > control_temp=95000 last_temp=70800, curr_temp=77200
> > > > > > total_requested_power=40136 total_granted_power=17402
> > > > > > [ 780.152633] cpu_cooling_ratelimit: 41 callbacks suppressed
> > > > > > [ 780.152666] cpu cpu4: Cooling state set to 11. New max freq =
> > > > > > 1843200
> > > > > > [ 780.165247] power_allocator_ratelimit: 21 callbacks suppressed
> > > > > > [ 780.165261] thermal thermal_zone5: Controlling power:
> > > > > > control_temp=95000 last_temp=64800, curr_temp=76900
> > > > > > total_requested_power=39719 total_granted_power=1759
> > > > > >
> > > > > > (the logs come from a local patch in our tree:
> > > > > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ec1c501a8093fed44a6697a5913ef2765f518e1f)
> > > > > >
> > > > > > At this point I don't have a clear idea what would be a reasonable
> > > > > > value for the 'switch on/threshold' temperature, but probably it
> > > > > > should to be higher than 75 degrees, at least with IPA. If there is
> > > > > > no reasonable common configuration for different thermal governors I
> > > > > > guess we'll have to target a commonly used governor and systems
> > > > > > using other 'incompatible' governors need to override the config in
> > > > > > their .dtsi.
> > > > >
> > >
> > > Thanks for the elaborate testing and for sharing the numbers. This is
> > > very useful information.
> > >
> > > > > On my system I don't see a significant delta in core temperatures for
> > > > > 'threshold' temperatures of 80, 85 or 90°C. However Dhrystone
> > > > > performance goes up by ~8% when changing the trip point from 80 to
> > > > > 85°C. For a switch from 85 to 90°C I see a ~2% performance delta. For
> > > > > all trip points the average core temperatures are ~80°C (silver) and
> > > > > ~85°C (gold). Interestingly I observed the highest average
> > > > > temperatures with the trip point at 80°C (repeated measurements were
> > > > > taken for different temperatures).
> > > > >
> > > > > Supposedly LMH throttling is disabled in the firmware I used for
> > > > > these tests, however data suggests that it is still active
> > > > > (temperature doesn't rise beyond 95°C, even without throttling in
> > > > > Linux; Dhrystone performance drops when raising the temperature beyond
> > > > > 95°C with a heat gun. I will do some more testing when I get my hands
> > > > > on a FW that effectively disables LMH (or raises the threshold to
> > > > > something like 105°C).
> > > > >
> > > > > From the data collected so far I'd suggest a 'threshold' temperature
> > > > > of 90°C or if that seems to high 85°C. Behavior might be different
> > > > > with other thermal governors or without LMH throttling..
> > > >
> > > > Some more data from measurements with different trips points, for the
> > > > IPA and the Fair Share governors, LMH throttling was enabled:
> > > >
> > > > IPA
> > > > Dhrystone Temp Silver Temp Gold
> > > > 75 6M 78.484.9
> > > > 80 6.21M 81.489.8
> > > > 85 6.74M 81.788.2
> > > > 90 6.88M 79.484.6
> > > >
> > > > Fair Share
> > > > Dhrystone Temp Silver Temp Gold
> > > > 75 6.63M 80.188.5
> > > > 80 6.71M 80.188.5
> > > > 85 6.77M 81.187.8
> > > > 90 7.12M
Re: linux-next: manual merge of the opp tree with the cpufreq-arm tree
On 07-02-19, 11:47, Stephen Rothwell wrote:
> Hi Viresh,
>
> Today's linux-next merge of the opp tree got a conflict in:
>
> drivers/cpufreq/qcom-cpufreq-hw.c
>
> between commit:
>
> 5471b2c9bd08 ("cpufreq: qcom: Read voltage LUT and populate OPP")
>
> from the cpufreq-arm tree and commit:
>
> 597457d7e054 ("cpufreq: qcom-hw: Register an Energy Model")
>
> from the opp 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/cpufreq/qcom-cpufreq-hw.c
> index 15f31e8c09c2,a16b9dca7ea3..
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@@ -224,13 -205,8 +224,15 @@@ static int qcom_cpufreq_hw_cpu_init(str
> goto error;
> }
>
> +ret = dev_pm_opp_get_opp_count(cpu_dev);
> +if (ret <= 0) {
> +dev_err(cpu_dev, "Failed to add OPPs\n");
> +ret = -ENODEV;
> +goto error;
> +}
> +
> + dev_pm_opp_of_register_em(policy->cpus);
> +
> policy->fast_switch_possible = true;
>
> return 0;
Thanks, I have taken care of it now. You shouldn't see it anymore.
--
viresh
[PATCH 2/2] cpufreq: OMAP: Register an Energy Model
Try and register an Energy Model from omap-cpufreq.c to allow
interested subsystems like the task scheduler to use the provided
information.
Signed-off-by: Yangtao Li
---
drivers/cpufreq/omap-cpufreq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 71e81bbf031b..68052b74d28f 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -133,8 +133,10 @@ static int omap_cpu_init(struct cpufreq_policy *policy)
/* FIXME: what's the actual transition time? */
result = cpufreq_generic_init(policy, freq_table, 300 * 1000);
- if (!result)
+ if (!result) {
+ dev_pm_opp_of_register_em(policy->cpus);
return 0;
+ }
freq_table_free();
fail:
--
2.17.0
Re: [PATCH v2] cpufreq: mediatek: Register an Energy Model
On 06-02-19, 10:50, Matthias Kaehlcke wrote: > Try and register an Energy Model from mediatek-cpufreq to allow > interested subsystems like the task scheduler to use the provided > information. > > Signed-off-by: Matthias Kaehlcke > --- > Changes in v2: > - register the EM after setting the cpumask > --- > drivers/cpufreq/mediatek-cpufreq.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/cpufreq/mediatek-cpufreq.c > b/drivers/cpufreq/mediatek-cpufreq.c > index eb8920d398181..5250df762814e 100644 > --- a/drivers/cpufreq/mediatek-cpufreq.c > +++ b/drivers/cpufreq/mediatek-cpufreq.c > @@ -465,6 +465,8 @@ static int mtk_cpufreq_init(struct cpufreq_policy *policy) > policy->driver_data = info; > policy->clk = info->cpu_clk; > > + dev_pm_opp_of_register_em(policy->cpus); > + > return 0; > } Applied it after rebasing over the change in cpufreq/arm/linux-next branch. Thanks. -- viresh
[PATCH 1/2] cpufreq: imx6q: Register an Energy Model
Try and register an Energy Model from imx6q-cpufreq to allow interested subsystems like the task scheduler to use the provided information. Signed-off-by: Yangtao Li --- drivers/cpufreq/imx6q-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c index 9fedf627e000..73bfd5bc3087 100644 --- a/drivers/cpufreq/imx6q-cpufreq.c +++ b/drivers/cpufreq/imx6q-cpufreq.c @@ -210,6 +210,7 @@ static int imx6q_cpufreq_init(struct cpufreq_policy *policy) policy->clk = clks[ARM].clk; ret = cpufreq_generic_init(policy, freq_table, transition_latency); policy->suspend_freq = max_freq; + dev_pm_opp_of_register_em(policy->cpus); return ret; } -- 2.17.0
Re: use generic DMA mapping code in powerpc V4
Hi Christoph,
I also didn’t notice the 32-bit DMA mask in your patch. I have to read your
patches and descriptions carefully in the future. I will test your new patch at
the weekend.
Thanks,
Christian
Sent from my iPhone
> On 6. Feb 2019, at 16:16, Christoph Hellwig wrote:
>
>> On Wed, Feb 06, 2019 at 04:15:05PM +0100, Christoph Hellwig wrote:
>> The last good one was 29e7e2287e196f48fe5d2a6e017617723ea979bf
>> ("dma-direct: we might need GFP_DMA for 32-bit dma masks"), if I
>> remember correctly. powerpc/dma: use the dma_direct mapping routines
>> was the one that you said makes the pasemi ethernet stop working.
>>
>> Can you post the dmesg from the failing runs?
>
> But I just noticed I sent you a wrong patch - the pasemi ethernet
> should set a 64-bit DMA mask, not 32-bit. Updated version below,
> 32-bit would just keep the previous status quo.
>
> commit 6c8f88045dee3597b9ce2ea5371eee37073a
> Author: Christoph Hellwig
> Date: Mon Feb 4 13:38:22 2019 +0100
>
>pasemi WIP
>
> diff --git a/drivers/net/ethernet/pasemi/pasemi_mac.c
> b/drivers/net/ethernet/pasemi/pasemi_mac.c
> index 8a31a02c9f47..2d7d1589490a 100644
> --- a/drivers/net/ethernet/pasemi/pasemi_mac.c
> +++ b/drivers/net/ethernet/pasemi/pasemi_mac.c
> @@ -1716,6 +1716,7 @@ pasemi_mac_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
>err = -ENODEV;
>goto out;
>}
> +dma_set_mask(>dma_pdev->dev, DMA_BIT_MASK(64));
>
>mac->iob_pdev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
>if (!mac->iob_pdev) {
Re: [PATCH v2] powerpc/mm: move a KERN_WARNING message to pr_debug()
Hi Laurent,
I'm not sure I'm convinced about this one. It seems like we're just
throwing away the warning because it's annoying.
Laurent Vivier writes:
> resize_hpt_for_hotplug() reports a warning when it cannot
> increase the hash page table ("Unable to resize hash page
> table to target order") but this is not blocking and
> can make user thinks something has not worked properly.
Something did not work properly, the resize didn't work properly. Right?
> As we move the message to the debug area, report again the
> ENODEV error.
>
> If the operation cannot be done the real error message
> will be reported by arch_add_memory() if create_section_mapping()
> fails.
Can you explain that more. Isn't the fact that the resize failed "the
real error message"?
> Fixes: 7339390d772dd
>powerpc/pseries: Don't give a warning when HPT resizing isn't available
This should all be on one line, and formatted as:
Fixes: 7339390d772d ("powerpc/pseries: Don't give a warning when HPT resizing
isn't available")
See Documentation/process/submitting-patches.rst for more info and how
to configure git to do it automatically for you.
cheers
[Patch v2 0/4] Protect against concurrent calls into UV BIOS
Changes since v1: Addressed comments from Bhupesh Sharma, Thomas Gleixner, and Ard Biesheuvel: * made __uv_bios_call() static * moved the efi_enabled() cleanup to its own patchlet * explained the reason for renaming the efi_runtime_lock semaphore * dropped the reviewed-bys as they should be given on the mailing list * Cc'ng sta...@vger.kernel.org given the nature of the problem addressed by the patches --- Calls into UV BIOS were not being serialised which is wrong as it violates EFI runtime rules, and bad as it does result in all sorts of potentially hard to track down hangs and panics when efi_scratch.prev_mm gets clobbered whenever efi_switch_mm() gets called concurrently from two different CPUs. Patch #1 makes the efi_runtime_lock semaphore visible to EFI runtime callers defined outside drivers/firmware/efi/runtime-wrappers.c in preparation for using it to serialise calls into UV BIOS; the lock is also renamed to efi_runtime_sem so that it can coexist with the efi_runtime_lock spinlock defined in arch/x86/platform/efi/efi_64.c when CONFIG_EFI_MIXED is enabled. Patch #2 removes uv_bios_call_reentrant() because it's dead code. Patch #3 is a cleanup that drops test_bit() in favour of the ad hoc efi_enabled(). Patch #4 makes uv_bios_call() variants use efi_runtime_sem to protect against concurrency. Cc: Russ Anderson Cc: Mike Travis Cc: Dimitri Sivanich Cc: Steve Wahl Cc: sta...@vger.kernel.org Hedi Berriche (4): efi/x86: turn EFI runtime semaphore into a global lock x86/platform/UV: kill uv_bios_call_reentrant() as it has no callers x86/platform/UV: use efi_enabled() instead of test_bit() x86/platform/UV: use efi_runtime_sem to serialise BIOS calls arch/x86/include/asm/uv/bios.h | 4 +- arch/x86/platform/uv/bios_uv.c | 33 -- drivers/firmware/efi/runtime-wrappers.c | 60 - include/linux/efi.h | 3 ++ 4 files changed, 55 insertions(+), 45 deletions(-) -- 2.20.1
[Patch v2 4/4] x86/platform/UV: use efi_runtime_sem to serialise BIOS calls
Calls into UV firmware must be protected against concurrency, use the
now visible efi_runtime_sem lock to serialise them.
Cc: Russ Anderson
Cc: Mike Travis
Cc: Dimitri Sivanich
Cc: Steve Wahl
Cc: sta...@vger.kernel.org
Signed-off-by: Hedi Berriche
---
arch/x86/include/asm/uv/bios.h | 3 ++-
arch/x86/platform/uv/bios_uv.c | 23 +--
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/uv/bios.h b/arch/x86/include/asm/uv/bios.h
index 4eee646544b2..581e2978a16c 100644
--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -48,7 +48,8 @@ enum {
BIOS_STATUS_SUCCESS = 0,
BIOS_STATUS_UNIMPLEMENTED = -ENOSYS,
BIOS_STATUS_EINVAL = -EINVAL,
- BIOS_STATUS_UNAVAIL = -EBUSY
+ BIOS_STATUS_UNAVAIL = -EBUSY,
+ BIOS_STATUS_ABORT = -EINTR,
};
/* Address map parameters */
diff --git a/arch/x86/platform/uv/bios_uv.c b/arch/x86/platform/uv/bios_uv.c
index 8bace0ca9e57..e779b2a128ea 100644
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -29,7 +29,8 @@
struct uv_systab *uv_systab;
-s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64
a5)
+static s64 __uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
+ u64 a4, u64 a5)
{
struct uv_systab *tab = uv_systab;
s64 ret;
@@ -51,6 +52,19 @@ s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64
a3, u64 a4, u64 a5)
return ret;
}
+
+s64 uv_bios_call(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3, u64 a4, u64
a5)
+{
+ s64 ret;
+
+ if (down_interruptible(_runtime_sem))
+ return BIOS_STATUS_ABORT;
+
+ ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
+ up(_runtime_sem);
+
+ return ret;
+}
EXPORT_SYMBOL_GPL(uv_bios_call);
s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1, u64 a2, u64 a3,
@@ -59,10 +73,15 @@ s64 uv_bios_call_irqsave(enum uv_bios_cmd which, u64 a1,
u64 a2, u64 a3,
unsigned long bios_flags;
s64 ret;
+ if (down_interruptible(_runtime_sem))
+ return BIOS_STATUS_ABORT;
+
local_irq_save(bios_flags);
- ret = uv_bios_call(which, a1, a2, a3, a4, a5);
+ ret = __uv_bios_call(which, a1, a2, a3, a4, a5);
local_irq_restore(bios_flags);
+ up(_runtime_sem);
+
return ret;
}
--
2.20.1
[Patch v2 1/4] efi/x86: turn EFI runtime semaphore into a global lock
Make efi_runtime_lock semaphore global so that it can be used by EFI
runtime callers that may be defined outside efi/runtime-wrappers.c.
Also now that efi_runtime_lock semaphore is no longer static, rename it
to efi_runtime_sem so it doesn't clash with the efi_runtime_lock spinlock
defined in arch/x86/platform/efi/efi_64.c when CONFIG_EFI_MIXED is
enabled.
The immediate motivation of this change is to serialise UV platform BIOS
calls using the efi_runtime_sem semaphore.
No functional changes.
Cc: Russ Anderson
Cc: Mike Travis
Cc: Dimitri Sivanich
Cc: Steve Wahl
Cc: sta...@vger.kernel.org
Signed-off-by: Hedi Berriche
---
drivers/firmware/efi/runtime-wrappers.c | 60 -
include/linux/efi.h | 3 ++
2 files changed, 33 insertions(+), 30 deletions(-)
diff --git a/drivers/firmware/efi/runtime-wrappers.c
b/drivers/firmware/efi/runtime-wrappers.c
index 8903b9ccfc2b..ec60d6227925 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -53,7 +53,7 @@ struct efi_runtime_work efi_rts_work;
* @rts_arg<1-5>: efi_runtime_service() function arguments
*
* Accesses to efi_runtime_services() are serialized by a binary
- * semaphore (efi_runtime_lock) and caller waits until the work is
+ * semaphore (efi_runtime_sem) and caller waits until the work is
* finished, hence _only_ one work is queued at a time and the caller
* thread waits for completion.
*/
@@ -144,7 +144,7 @@ void efi_call_virt_check_flags(unsigned long flags, const
char *call)
* none of the remaining functions are actually ever called at runtime.
* So let's just use a single lock to serialize all Runtime Services calls.
*/
-static DEFINE_SEMAPHORE(efi_runtime_lock);
+DEFINE_SEMAPHORE(efi_runtime_sem);
/*
* Calls the appropriate efi_runtime_service() with the appropriate
@@ -233,10 +233,10 @@ static efi_status_t virt_efi_get_time(efi_time_t *tm,
efi_time_cap_t *tc)
{
efi_status_t status;
- if (down_interruptible(_runtime_lock))
+ if (down_interruptible(_runtime_sem))
return EFI_ABORTED;
status = efi_queue_work(GET_TIME, tm, tc, NULL, NULL, NULL);
- up(_runtime_lock);
+ up(_runtime_sem);
return status;
}
@@ -244,10 +244,10 @@ static efi_status_t virt_efi_set_time(efi_time_t *tm)
{
efi_status_t status;
- if (down_interruptible(_runtime_lock))
+ if (down_interruptible(_runtime_sem))
return EFI_ABORTED;
status = efi_queue_work(SET_TIME, tm, NULL, NULL, NULL, NULL);
- up(_runtime_lock);
+ up(_runtime_sem);
return status;
}
@@ -257,11 +257,11 @@ static efi_status_t virt_efi_get_wakeup_time(efi_bool_t
*enabled,
{
efi_status_t status;
- if (down_interruptible(_runtime_lock))
+ if (down_interruptible(_runtime_sem))
return EFI_ABORTED;
status = efi_queue_work(GET_WAKEUP_TIME, enabled, pending, tm, NULL,
NULL);
- up(_runtime_lock);
+ up(_runtime_sem);
return status;
}
@@ -269,11 +269,11 @@ static efi_status_t virt_efi_set_wakeup_time(efi_bool_t
enabled, efi_time_t *tm)
{
efi_status_t status;
- if (down_interruptible(_runtime_lock))
+ if (down_interruptible(_runtime_sem))
return EFI_ABORTED;
status = efi_queue_work(SET_WAKEUP_TIME, , tm, NULL, NULL,
NULL);
- up(_runtime_lock);
+ up(_runtime_sem);
return status;
}
@@ -285,11 +285,11 @@ static efi_status_t virt_efi_get_variable(efi_char16_t
*name,
{
efi_status_t status;
- if (down_interruptible(_runtime_lock))
+ if (down_interruptible(_runtime_sem))
return EFI_ABORTED;
status = efi_queue_work(GET_VARIABLE, name, vendor, attr, data_size,
data);
- up(_runtime_lock);
+ up(_runtime_sem);
return status;
}
@@ -299,11 +299,11 @@ static efi_status_t virt_efi_get_next_variable(unsigned
long *name_size,
{
efi_status_t status;
- if (down_interruptible(_runtime_lock))
+ if (down_interruptible(_runtime_sem))
return EFI_ABORTED;
status = efi_queue_work(GET_NEXT_VARIABLE, name_size, name, vendor,
NULL, NULL);
- up(_runtime_lock);
+ up(_runtime_sem);
return status;
}
@@ -315,11 +315,11 @@ static efi_status_t virt_efi_set_variable(efi_char16_t
*name,
{
efi_status_t status;
- if (down_interruptible(_runtime_lock))
+ if (down_interruptible(_runtime_sem))
return EFI_ABORTED;
status = efi_queue_work(SET_VARIABLE, name, vendor, , _size,
data);
- up(_runtime_lock);
+ up(_runtime_sem);
return status;
}
@@ -330,12 +330,12 @@ virt_efi_set_variable_nonblocking(efi_char16_t *name,
Re: [PATCH] net: stmmac: Variable "val" in function sun8i_dwmac_set_syscon() could be uninitialized
From: Yizhuo
Date: Tue, 5 Feb 2019 14:15:59 -0800
> @@ -639,9 +639,14 @@ static int sun8i_dwmac_set_syscon(struct stmmac_priv
> *priv)
> struct sunxi_priv_data *gmac = priv->plat->bsp_priv;
> struct device_node *node = priv->device->of_node;
> int ret;
> - u32 reg, val;
> + u32 reg, val = 0;
> +
> + ret = regmap_read(gmac->regmap, SYSCON_EMAC_REG, );
> + if (ret) {
> + dev_err(priv->device, "Fail to read SYSCON_EMAC_REG.\n");
> + return ret;
> + }
I agree with the other reviewer that since you check 'ret' the initialization of
'val' is no longer needed.
Re: [PATCH 2/2] cpufreq: mediatek: Register an Energy Model
On 06-02-19, 10:16, Matthias Kaehlcke wrote: > You are prefectly right, I missed the obvious and didn't get my hands > on hardware yet for testing. > > So much for screwing up a one-liner ... I'll send a fix. > > I thought Viresh already applied the patch, however in opp/linux-next > I currently only see the other one of this series for qcom-hw, so it > seems sending a new version rather than a fix-up patch is the way to > go. Yeah, I dropped it after Quentin reported the issue. -- viresh
Re: [PATCH v2] powerpc/mm: move a KERN_WARNING message to pr_debug()
On Tue, Feb 05, 2019 at 09:21:33PM +0100, Laurent Vivier wrote:
> resize_hpt_for_hotplug() reports a warning when it cannot
> increase the hash page table ("Unable to resize hash page
> table to target order") but this is not blocking and
> can make user thinks something has not worked properly.
> As we move the message to the debug area, report again the
> ENODEV error.
>
> If the operation cannot be done the real error message
> will be reported by arch_add_memory() if create_section_mapping()
> fails.
>
> Fixes: 7339390d772dd
>powerpc/pseries: Don't give a warning when HPT resizing isn't available
> Signed-off-by: Laurent Vivier
Sorry, I'm pretty dubious about this. It's true that in the case for
which this bug was filed this is a harmless situation which deserves a
pr_debug() at most.
But that's not necessarily true in all paths leading to this message.
It will also trip if we fail to reshrink the HPT after genuinely
hotunplugging a bunch of memory, in which case failing to release
expected resources does deserve a warning.
> ---
>
> Notes:
> v2:
> - use pr_debug instead of printk(KERN_DEBUG
> - remove check for ENODEV
>
> arch/powerpc/mm/hash_utils_64.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 0cc7fbc3bd1c..6a0cc4eb2c83 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -777,10 +777,9 @@ void resize_hpt_for_hotplug(unsigned long new_mem_size)
> int rc;
>
> rc = mmu_hash_ops.resize_hpt(target_hpt_shift);
> - if (rc && (rc != -ENODEV))
> - printk(KERN_WARNING
> -"Unable to resize hash page table to target
> order %d: %d\n",
> -target_hpt_shift, rc);
> + if (rc)
> + pr_debug("Unable to resize hash page table to target
> order %d: %d\n",
> + target_hpt_shift, rc);
> }
> }
>
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v6 0/4] clk: meson-g12a: Add EE clock controller driver
Neil Armstrong writes: > Le 01/02/2019 15:53, Jerome Brunet a écrit : >> This purpose of this patchset is to the main clock controller of the >> g12a SoC family >> >> This patchset depends on the recent rework the meson clock directory [7]. [...] > Reviewed-by: Neil Armstrong > > I'm applying these to next/drivers for Linux 5.1-rc1, is it necessary to > have a tag for the headers ? Only if we have some users that we want to merge in the v5.1 cycle (which I haven't seen yet.) Kevin
Re: [PATCH 0/2] ARM: meson: do not select COMMON_CLK_AMLOGIC
Jerome Brunet writes: > The patchset remove the selection of CONFIG_COMMON_CLK_AMLOGIC. > This CONFIG symbol: > * Is already selected by controller driver which requires it. > * Is being removed by this changeset [0] > > Whether or not series [0] is merged, selecting CONFIG_COMMON_CLK_AMLOGIC > is not necessary and it is safe to remove it. > > [0]: https://lkml.kernel.org/r/20190128180430.28689-1-jbru...@baylibre.com Queued for v5.1 (branch: v5.1/soc) Kevin
Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA
On Wed, Feb 06, 2019 at 05:24:50PM -0500, Doug Ledford wrote: > On Wed, 2019-02-06 at 15:08 -0700, Jason Gunthorpe wrote: > > On Thu, Feb 07, 2019 at 08:03:56AM +1100, Dave Chinner wrote: > > > On Wed, Feb 06, 2019 at 07:16:21PM +, Christopher Lameter wrote: > > > > On Wed, 6 Feb 2019, Doug Ledford wrote: > > > > > > > > > > Most of the cases we want revoke for are things like truncate(). > > > > > > Shouldn't happen with a sane system, but we're trying to avoid users > > > > > > doing awful things like being able to DMA to pages that are now > > > > > > part of > > > > > > a different file. > > > > > > > > > > Why is the solution revoke then? Is there something besides truncate > > > > > that we have to worry about? I ask because EBUSY is not currently > > > > > listed as a return value of truncate, so extending the API to include > > > > > EBUSY to mean "this file has pinned pages that can not be freed" is > > > > > not > > > > > (or should not be) totally out of the question. > > > > > > > > > > Admittedly, I'm coming in late to this conversation, but did I miss > > > > > the > > > > > portion where that alternative was ruled out? > > > > > > > > Coming in late here too but isnt the only DAX case that we are concerned > > > > about where there was an mmap with the O_DAX option to do direct write > > > > though? If we only allow this use case then we may not have to worry > > > > about > > > > long term GUP because DAX mapped files will stay in the physical > > > > location > > > > regardless. > > > > > > No, that is not guaranteed. Soon as we have reflink support on XFS, > > > writes will physically move the data to a new physical location. > > > This is non-negotiatiable, and cannot be blocked forever by a gup > > > pin. > > > > > > IOWs, DAX on RDMA requires a) page fault capable hardware so that > > > the filesystem can move data physically on write access, and b) > > > revokable file leases so that the filesystem can kick userspace out > > > of the way when it needs to. > > > > Why do we need both? You want to have leases for normal CPU mmaps too? We don't need them for normal CPU mmaps because that's locally addressable page fault capable hardware. i.e. if we need to serialise something, we just use kernel locks, etc. When it's a remote entity (such as RDMA) we have to get that remote entity to release it's reference/access so the kernel has exclusive access to the resource it needs to act on. IOWs, file layout leases are required for remote access to local filesystem controlled storage. That's the access arbitration model the pNFS implementation hooked into XFS uses and it seems to work just fine. Local access just hooks in to the kernel XFS paths and triggers lease/delegation recalls through the NFS server when required. If your argument is that "existing RDMA apps don't have a recall mechanism" then that's what they are going to need to implement to work with DAX+RDMA. Reliable remote access arbitration is required for DAX+RDMA, regardless of what filesysetm the data is hosted on. Anything less is a potential security hole. > > > yesterday!), and that means DAX+RDMA needs to work with storage that > > > can change physical location at any time. > > > > Then we must continue to ban longterm pin with DAX.. > > > > Nobody is going to want to deploy a system where revoke can happen at > > any time and if you don't respond fast enough your system either locks > > with some kind of FS meltdown or your process gets SIGKILL. > > > > I don't really see a reason to invest so much design work into > > something that isn't production worthy. > > > > It *almost* made sense with ftruncate, because you could architect to > > avoid ftruncate.. But just any FS op might reallocate? Naw. > > > > Dave, you said the FS is responsible to arbitrate access to the > > physical pages.. > > > > Is it possible to have a filesystem for DAX that is more suited to > > this environment? Ie designed to not require block reallocation (no > > COW, no reflinks, different approach to ftruncate, etc) > > Can someone give me a real world scenario that someone is *actually* > asking for with this? Are DAX users demanding xfs, or is it just the > filesystem of convenience? I had a conference call last week with a room full of people who want reflink functionality on DAX ASAP. They have customers that are asking them to provide it, and the only vehicle they have to delivery that functionality in any reasonable timeframe is XFS. > Do they need to stick with xfs? Are they > really trying to do COW backed mappings for the RDMA targets? I have no idea if they want RDMA. It is also irrelevant to the requirement of and timeframe to support reflink on XFS w/ DAX. Especially because: # mkfs.xfs -f -m reflink=0 /dev/pmem1 And now you have an XFS fileysetm configuration that does not support dynamic moving of physical storage on write. You have to do this anyway to use DAX right now, so it's hardly an issue
Re: [PATCH] net: Don't default Cavium PTP driver to 'y'
From: Bjorn Helgaas
Date: Tue, 05 Feb 2019 14:47:21 -0600
> From: Bjorn Helgaas
>
> 8c56df372bc1 ("net: add support for Cavium PTP coprocessor") added the
> Cavium PTP coprocessor driver and enabled it by default. Remove the
> "default y" because the driver only applies to Cavium ThunderX processors.
>
> Fixes: 8c56df372bc1 ("net: add support for Cavium PTP coprocessor")
> Signed-off-by: Bjorn Helgaas
Applied.
Re: general protection fault in __bfs (2)
syzbot has found a reproducer for the following crash on: HEAD commit:8834f5600cf3 Linux 5.0-rc5 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=143fd61f40 kernel config: https://syzkaller.appspot.com/x/.config?x=8f00801d7b7c4fe6 dashboard link: https://syzkaller.appspot.com/bug?extid=c58fa3b1231d2ea0c4d3 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15bab650c0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17a331df40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c58fa3b1231d2ea0c...@syzkaller.appspotmail.com Started in network mode Own node identity 7f01, cluster identity 4711 Enabled bearer , priority 10 kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 0 PID: 7800 Comm: syz-executor309 Not tainted 5.0.0-rc5 #59 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:lock_accessed kernel/locking/lockdep.c:968 [inline] RIP: 0010:__bfs kernel/locking/lockdep.c:1035 [inline] RIP: 0010:__bfs+0x18a/0x5a0 kernel/locking/lockdep.c:989 Code: 8b 3f 4d 39 fd 0f 84 77 01 00 00 49 8d 7f 10 4c 89 f8 4c 8b 0d f7 94 fa 08 48 89 f9 48 2d a0 27 31 8a 48 c1 e9 03 48 c1 f8 06 <42> 80 3c 31 00 0f 85 db 02 00 00 49 8b 77 10 4c 8d 46 2c 4c 89 c1 RSP: 0018:8880ae807828 EFLAGS: 00010003 RAX: 01d73b61 RBX: 8880ae8078f0 RCX: 0002 RDX: RSI: 114aad54 RDI: 0010 RBP: 8880ae807890 R08: 0001 R09: 1c9c R10: ed1015d05bcf R11: R12: 0006 R13: 8a220a50 R14: dc00 R15: FS: 7f2ebceb4700() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2340 CR3: 9ad36000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __bfs_forwards kernel/locking/lockdep.c:1063 [inline] find_usage_forwards kernel/locking/lockdep.c:1363 [inline] check_usage_forwards+0x119/0x340 kernel/locking/lockdep.c:2575 mark_lock_irq kernel/locking/lockdep.c:2690 [inline] mark_lock+0x427/0x1380 kernel/locking/lockdep.c:3062 mark_irqflags kernel/locking/lockdep.c:2940 [inline] __lock_acquire+0x128f/0x4700 kernel/locking/lockdep.c:3295 lock_acquire+0x16f/0x3f0 kernel/locking/lockdep.c:3841 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x2f/0x40 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [inline] __queue_work+0x9ce/0x1180 kernel/workqueue.c:1434 delayed_work_timer_fn+0x5d/0x90 kernel/workqueue.c:1520 call_timer_fn+0x190/0x720 kernel/time/timer.c:1325 expire_timers kernel/time/timer.c:1358 [inline] __run_timers kernel/time/timer.c:1681 [inline] __run_timers kernel/time/timer.c:1649 [inline] run_timer_softirq+0x44c/0x1700 kernel/time/timer.c:1694 __do_softirq+0x266/0x95a kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x180/0x1d0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:766 [inline] RIP: 0010:console_unlock+0xc0d/0x10a0 kernel/printk/printk.c:2416 Code: fc ff df 48 c1 e8 03 80 3c 08 00 0f 85 49 04 00 00 48 83 3d 94 56 38 07 00 0f 84 af 02 00 00 e8 b9 af 15 00 48 8b 7d 98 57 9d <0f> 1f 44 00 00 e9 5f ff ff ff e8 a4 af 15 00 48 8b 7d 08 c7 05 56 RSP: 0018:88809accf1b8 EFLAGS: 0293 ORIG_RAX: ff13 RAX: 88808cc40300 RBX: 0200 RCX: dc00 RDX: RSI: 815a2b67 RDI: 0293 RBP: 88809accf248 R08: 88808cc40300 R09: 88808cc40c18 R10: R11: R12: R13: 841a1770 R14: 88f81d70 R15: 6601 vprintk_emit+0x280/0x6d0 kernel/printk/printk.c:1931 vprintk_default+0x28/0x30 kernel/printk/printk.c:1958 vprintk_func+0x7e/0x189 kernel/printk/printk_safe.c:398 printk+0xba/0xed kernel/printk/printk.c:1991 tipc_enable_bearer.cold+0x2d/0xda net/tipc/bearer.c:335 __tipc_nl_bearer_enable+0x2d1/0x3b0 net/tipc/bearer.c:899 tipc_nl_bearer_enable+0x23/0x40 net/tipc/bearer.c:907 genl_family_rcv_msg+0x6e1/0xd90 net/netlink/genetlink.c:601 genl_rcv_msg+0xca/0x16c net/netlink/genetlink.c:626 netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2477 genl_rcv+0x29/0x40 net/netlink/genetlink.c:637 netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline] netlink_unicast+0x536/0x720
Re: [PATCH v2 0/4] soc: amlogic: clk-measure: add axg and g12a support
Neil Armstrong writes: > On 18/01/2019 11:34, Jerome Brunet wrote: >> This patchset adds support for the axg and g12a SoC family in amlogic's >> clock measure driver and enable it on the related devices >> >> Changes since v1 [0]: >> * re-order node in the g12a.dtsi >> * change node name >> >> [0]: https://lkml.kernel.org/r/20190117164838.8008-1-jbru...@baylibre.com >> >> Jerome Brunet (4): >> dt-bindings: amlogic: add new compatible devices to clk_measure >> soc: amlogic: clk-measure: add axg and g12a support >> arm64: dts: meson: axg: add clk measure support >> arm64: dts: meson: g12a: add clk measure support >> >> .../bindings/soc/amlogic/clk-measure.txt | 2 + >> arch/arm64/boot/dts/amlogic/meson-axg.dtsi| 5 + >> arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 5 + >> drivers/soc/amlogic/meson-clk-measure.c | 194 ++ >> 4 files changed, 206 insertions(+) >> > > Reviewed-by: Neil Armstrong Queued for v5.1 (branch v5.1/dt64) Kevin
Re: [PATCH v2] arm64: dts: meson: fix g12a buses
Jerome Brunet writes:
> Fix apb, cbus, hiu and periph regions which are not aligned
> with the documentation and the information provided by Amlogic
>
> Fixes: 9c8c52f7cb4f ("arm64: dts: meson-g12a: add initial g12a s905d2 SoC DT
> support")
> Cc: Jianxin Pan
> Signed-off-by: Jerome Brunet
Queued for v5.1 (branch: v5.1/dt64)
Kevin
Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA
On Wed, Feb 6, 2019 at 6:42 PM Doug Ledford wrote: > > On Wed, 2019-02-06 at 14:44 -0800, Dan Williams wrote: > > On Wed, Feb 6, 2019 at 2:25 PM Doug Ledford wrote: > > > Can someone give me a real world scenario that someone is *actually* > > > asking for with this? > > > > I'll point to this example. At the 6:35 mark Kodi talks about the > > Oracle use case for DAX + RDMA. > > > > https://youtu.be/ywKPPIE8JfQ?t=395 > > I watched this, and I see that Oracle is all sorts of excited that their > storage machines can scale out, and they can access the storage and it > has basically no CPU load on the storage server while performing > millions of queries. What I didn't hear in there is why DAX has to be > in the picture, or why Oracle couldn't do the same thing with a simple > memory region exported directly to the RDMA subsystem, or why reflink or > any of the other features you talk about are needed. So, while these > things may legitimately be needed, this video did not tell me about > how/why they are needed, just that RDMA is really, *really* cool for > their use case and gets them 0% CPU utilization on their storage > servers. I didn't watch the whole thing though. Do they get into that > later on? Do they get to that level of technical discussion, or is this > all higher level? They don't. The point of sharing that video was illustrating that RDMA to persistent memory use case. That 0% cpu utilization is because the RDMA target is not page-cache / anonymous on the storage box it's directly to a file offset in DAX / persistent memory. A solution to truncate lets that use case use more than just Device-DAX or ODP capable adapters. That said, I need to let Ira jump in here because saying layout leases solves the problem is not true, it's just the start of potentially solving the problem. It's not clear to me what the long tail of work looks like once the filesystem raises a notification to the RDMA target process.
Re: [PATCH 0/3] pinctrl: meson: g12a fixes
Jerome Brunet writes: > On Mon, 2019-01-21 at 14:53 +0100, Linus Walleij wrote: >> On Thu, Jan 17, 2019 at 11:23 AM Jerome Brunet wrote: >> >> > This patchset fixes the initial pinctrl support added for th g12a SoC >> > family, which is mainly around the register regions claimed by the >> > driver. >> > >> > Linus, would it possible for you to provide a tag with these changes to >> > Kevin ? >> >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-meson-fixes >> >> > ATM, we can only use the devices for which the pinmux is already set by >> > the bootloader. Enabling the broken pinctrl driver could cause regressions >> > in kernelCI. Having a tag, would allow us to start using pinctrl on this >> > SoC in this cycle, w/o regression. It would be nice :) >> >> When you say "this cycle" do you mean I should target fixes (v5.0-rcN) >> or next (v5.1) with these patches? > > I was referring to the 5.1 release but it is a good question, I did not really > think about 5.0. > > Those changes are mainly fixes, so guess it could go in the 5.0 but support > for this SoC is still in its early stages, so either way is fine by me. > > Whatever is simpler for you I guess ;) If it's not too late, v5.0-rc is simpler for me as it means not having to deal with this as a dependency branch/tag. Kevin
Re: bcache on XFS: metadata I/O (dirent I/O?) not getting cached at all?
On Thu, Feb 07, 2019 at 10:38:58AM +0800, Coly Li wrote: > On 2019/2/7 10:26 上午, Dave Chinner wrote: > > On Thu, Feb 07, 2019 at 01:24:25AM +0100, Andre Noll wrote: > >> On Thu, Feb 07, 10:43, Dave Chinner wrote > >>> File data readahead: REQ_RAHEAD > >>> Metadata readahead: REQ_META | REQ_RAHEAD > >>> > >>> drivers/md/bcache/request.c::check_should_bypass(): > >>> > >>> /* > >>> * Flag for bypass if the IO is for read-ahead or background, > >>> * unless the read-ahead request is for metadata (eg, for gfs2). > >>> */ > >>> if (bio->bi_opf & (REQ_RAHEAD|REQ_BACKGROUND) && > >>> !(bio->bi_opf & REQ_PRIO)) > >>> goto skip; > >>> > >>> bcache needs fixing - it thinks REQ_PRIO means metadata IO. That's > >>> wrong - REQ_META means it's metadata IO, and so this is a bcache > >>> bug. > >> > >> Do you think 752f66a75abad is bad (ha!) and should be reverted? > > > > Yes, that change is just broken. From include/linux/blk_types.h: > > > > __REQ_META, /* metadata io request */ > > __REQ_PRIO, /* boost priority in cfq */ > > > > > > Hi Dave, > > > i.e. REQ_META means that it is a metadata request, REQ_PRIO means it > > is a "high priority" request. Two completely different things, often > > combined, but not interchangeable. > > I found in file system metadata IO, most of time REQ_META and REQ_PRIO > are tagged together for bio, but XFS seems not use REQ_PRIO. Yes, that's correct, because we don't specifically prioritise metadata IO over data IO. > Is there any basic principle for when should these tags to be used or > not ? Yes. > e.g. If REQ_META is enough for meta data I/O, why REQ_PRIO is used > too. REQ_META is used for metadata. REQ_PRIO is used to communicate to the lower layers that the submitter considers this IO to be more important that non REQ_PRIO IO and so dispatch should be expedited. IOWs, if the filesystem considers metadata IO to be more important that user data IO, then it will use REQ_PRIO | REQ_META rather than just REQ_META. Historically speaking, REQ_PRIO was a hack for CFQ to get it to dispatch journal IO from a different thread without waiting for a time slice to expire. In the XFs world, we just said "don't use CFQ, it's fundametnally broken for highly concurrent applications" and didn't bother trying to hack around the limitations of CFQ. These days REQ_PRIO is only used by the block layer writeback throttle, but unlike bcache it considers both REQ_META and REQ_PRIO to mean the same thing. REQ_META, OTOH, is used by BFQ and blk-cgroup to detect metadata IO and don't look at REQ_PRIO at all. So, really, REQ_META is for metadata, not REQ_PRIO. REQ_PRIO looks like it should just go away. > And if REQ_PRIO is necessary, why it is not used in fs/xfs/ code ? It's not necessary, it's just an /optimisation/ that some filesystems make and some IO schedulers used to pay attention to. It looks completely redundant now. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH v3] dt-bindings: reset: meson: add g12a bindings
Jerome Brunet writes: > Add device tree bindings for the reset controller of g12a SoC family. > > Acked-by: Neil Armstrong > Signed-off-by: Jerome Brunet Acked-by: Kevin Hilman
Re: Build regressions/improvements in v5.0-rc5
Randy Dunlap writes: > On 2/6/19 2:05 AM, Michael Ellerman wrote: >> Randy Dunlap writes: >>> On 2/4/19 9:46 AM, Randy Dunlap wrote: On 2/4/19 5:42 AM, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v5.0-rc5[1] compared to v4.20[2]. > > Summarized: > - build errors: +2/-4 > - build warnings: +113/-14843 > > JFYI, when comparing v5.0-rc5[1] to v5.0-rc4[3], the summaries are: > - build errors: +0/-0 > - build warnings: +56/-59 > > Note that there may be false regressions, as some logs are incomplete. > Still, they're build errors/warnings. > > Happy fixing! ;-) > > Thanks to the linux-next team for providing the build service. > > [1] > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8834f5600cf3c8db365e18a3d5cac2c2780c81e5/ > (238 out of 240 configs) > [2] > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8fe28cb58bcb235034b64cbbb7550a8a43fd88be/ > (all 240 configs) > [3] > http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f17b5f06cb92ef2250513a1e154c47b78df07d40/ > (238 out of 240 configs) > > > > *** WARNINGS *** > > 113 warning regressions: > + warning: unmet direct dependencies detected for PPC4xx_PCI_EXPRESS: > => N/A Hi Geert, I am trying to find the above warning (needle) in the haystack. Can you please direct me to which config/build it is in? Is there a good way for me to find it? thanks. >>> >>> Working backwards, it probably comes from this: >>> >>> config CURRITUCK >>> bool "IBM Currituck (476fpe) Support" >>> depends on PPC_47x >>> select SWIOTLB >>> select 476FPE >>> select PPC4xx_PCI_EXPRESS >>> >>> This is the only similar Kconfig segment that does not select FORCE_PCI >>> but PPC4xx_PCI_EXPRESS depends on PCI but >>> # CONFIG_PCI is not set >>> >>> This could be related to a recent series of patches that allows ACPI to >>> be built without having PCI enabled. >>> >>> Michael? >> >> There isn't really an easy way to do it sorry. >> >> If you download the page for the revision: >> >> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8834f5600cf3c8db365e18a3d5cac2c2780c81e5/ >> >> With a lot of grep/sed/awk you can get a list of the URLs for all the >> builds eg. one would be: >> >> http://kisskb.ellerman.id.au/kisskb/buildresult/13676551/ >> >> And then you can just tack on "log/" to get: >> >> http://kisskb.ellerman.id.au/kisskb/buildresult/13676551/log/ >> >> Which you can wget and grep. >> >> But that's all a bit of a pain. >> >> I have on my todo list to add json formatted build results and revision >> pages, which would make it quite a bit simpler. But of course I haven't >> had time to do it yet :/ > > No problem. > > However, I was trying to ask you about the kconfig problem above: > > + warning: unmet direct dependencies detected for PPC4xx_PCI_EXPRESS > > and not the "search the build results" problem. ;) Haha, oops :) A result of the recent rework of the PCI config symbols: eb01d42a77785ff96b6e66a2a2e7027fc6d78e4a is the first bad commit commit eb01d42a77785ff96b6e66a2a2e7027fc6d78e4a Author: Christoph Hellwig Date: Thu Nov 15 20:05:32 2018 +0100 PCI: consolidate PCI config entry in drivers/pci There is no good reason to duplicate the PCI menu in every architecture. Instead provide a selectable HAVE_PCI symbol that indicates availability of PCI support, and a FORCE_PCI symbol to for PCI on and the handle the rest in drivers/pci. Signed-off-by: Christoph Hellwig Reviewed-by: Palmer Dabbelt Acked-by: Max Filippov Acked-by: Thomas Gleixner Acked-by: Bjorn Helgaas Acked-by: Geert Uytterhoeven Acked-by: Paul Burton Signed-off-by: Masahiro Yamada But that patch really just exposed an existing problem. CURRITUCK selects PPC4xx_PCI_EXPRESS which depends on PCI, and PCI is user selectable in that config. Previously the powerpc PCI symbol was default y for CURRITUCK so it was enabled by default and we didn't see a warning. But a user could always just turn it off and then they'd get the same warning we're seeing now. I'll send a patch to force PCI on for CURRITUCK. cheers
Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA
On Wed, Feb 6, 2019 at 5:57 PM Doug Ledford wrote: [..] > > > > Dave, you said the FS is responsible to arbitrate access to the > > > > physical pages.. > > > > > > > > Is it possible to have a filesystem for DAX that is more suited to > > > > this environment? Ie designed to not require block reallocation (no > > > > COW, no reflinks, different approach to ftruncate, etc) > > > > > > Can someone give me a real world scenario that someone is *actually* > > > asking for with this? > > > > I'll point to this example. At the 6:35 mark Kodi talks about the > > Oracle use case for DAX + RDMA. > > > > https://youtu.be/ywKPPIE8JfQ?t=395 > > Thanks for the link, I'll review the panel. > > > Currently the only way to get this to work is to use ODP capable > > hardware, or Device-DAX. Device-DAX is a facility to map persistent > > memory statically through device-file. It's great for statically > > allocated use cases, but loses all the nice things (provisioning, > > permissions, naming) that a filesystem gives you. This debate is what > > to do about non-ODP capable hardware and Filesystem-DAX facility. The > > current answer is "no RDMA for you". > > > > > Are DAX users demanding xfs, or is it just the > > > filesystem of convenience? > > > > xfs is the only Linux filesystem that supports DAX and reflink. > > Is it going to be clear from the link above why reflink + DAX + RDMA is > a good/desirable thing? > No, unfortunately it will only clarify the DAX + RDMA use case, but you don't need to look very far to see that the trend for storage management is more COW / reflink / thin-provisioning etc in more places. Users want the flexibility to be able delay, change, and consolidate physical storage allocation decisions, otherwise device-dax would have solved all these problems and we would not be having this conversation. > > > Do they need to stick with xfs? > > > > Can you clarify the motivation for that question? > > I did a little googling and research before I asked that question. > According to the documentation, other FSes can work with DAX too (namely > ext2 and ext4). The question was more or less pondering whether or not > ext2 or ext4 + RDMA + DAX would solve people's problems without the > issues that xfs brings. No, ext4 also supports hole punch, and the ext2 support is a toy. We went through quite a bit of work to solve this problem for the O_DIRECT pinned page case. 6b2bb7265f0b sched/wait: Introduce wait_var_event() d6dc57e251a4 xfs, dax: introduce xfs_break_dax_layouts() 69eb5fa10eb2 xfs: prepare xfs_break_layouts() for another layout type c63a8eae63d3 xfs: prepare xfs_break_layouts() to be called with XFS_MMAPLOCK_EXCL 5fac7408d828 mm, fs, dax: handle layout changes to pinned dax mappings b1f382178d15 ext4: close race between direct IO and ext4_break_layouts() 430657b6be89 ext4: handle layout changes to pinned DAX mappings cdbf8897cb09 dax: dax_layout_busy_page() warn on !exceptional So the fs is prepared to notify RDMA applications of the need to evacuate a mapping (layout change), and the timeout to respond to that notification can be configured by the administrator. The debate is about what to do when the platform owner needs to get a mapping out of the way in bounded time. > > This problem exists > > for any filesystem that implements an mmap that where the physical > > page backing the mapping is identical to the physical storage location > > for the file data. I don't see it as an xfs specific problem. Rather, > > xfs is taking the lead in this space because it has already deployed > > and demonstrated that leases work for the pnfs4 block-server case, so > > it seems logical to attempt to extend that case for non-ODP-RDMA. > > > > > Are they > > > really trying to do COW backed mappings for the RDMA targets? Or do > > > they want a COW backed FS but are perfectly happy if the specific RDMA > > > targets are *not* COW and are statically allocated? > > > > I would expect the COW to be broken at registration time. Only ODP > > could possibly support reflink + RDMA. So I think this devolves the > > problem back to just the "what to do about truncate/punch-hole" > > problem in the specific case of non-ODP hardware combined with the > > Filesystem-DAX facility. > > If that's the case, then we are back to EBUSY *could* work (despite the > objections made so far). I linked it in my response to Jason [1], but the entire reason ext2, ext4, and xfs scream "experimental" when DAX is enabled is because DAX makes typical flows fail that used to work in the page-cache backed mmap case. The failure of a data space management command like fallocate(punch_hole) is more risky than just not allowing the memory registration to happen in the first place. Leases result in a system that has a chance at making forward progress. The current state of disallowing RDMA for FS-DAX is one of the "if (dax) goto fail;" conditions that needs to be solved before filesystem developers graduate DAX from experimental
linux-next: build warning after merge of the tpmdd tree
Hi Jarkko,
After merging the tpmdd tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/char/tpm/tpm_i2c_nuvoton.c:45: warning: "TPM_RETRY" redefined
#define TPM_RETRY 5
In file included from drivers/char/tpm/tpm_i2c_nuvoton.c:35:
drivers/char/tpm/tpm.h:43: note: this is the location of the previous definition
#define TPM_RETRY 50
drivers/char/tpm/tpm_i2c_infineon.c:30: warning: "TPM_BUFSIZE" redefined
#define TPM_BUFSIZE 1260
In file included from drivers/char/tpm/tpm_i2c_infineon.c:27:
drivers/char/tpm/tpm.h:41: note: this is the location of the previous definition
#define TPM_BUFSIZE 4096
In file included from drivers/char/tpm/st33zp24/i2c.c:30:
drivers/char/tpm/st33zp24/st33zp24.h:22: warning: "TPM_BUFSIZE" redefined
#define TPM_BUFSIZE 2048
In file included from drivers/char/tpm/st33zp24/i2c.c:29:
drivers/char/tpm/st33zp24/../tpm.h:41: note: this is the location of the
previous definition
#define TPM_BUFSIZE 4096
In file included from drivers/char/tpm/st33zp24/spi.c:30:
drivers/char/tpm/st33zp24/st33zp24.h:22: warning: "TPM_BUFSIZE" redefined
#define TPM_BUFSIZE 2048
In file included from drivers/char/tpm/st33zp24/spi.c:29:
drivers/char/tpm/st33zp24/../tpm.h:41: note: this is the location of the
previous definition
#define TPM_BUFSIZE 4096
In file included from drivers/char/tpm/st33zp24/st33zp24.c:34:
drivers/char/tpm/st33zp24/st33zp24.h:22: warning: "TPM_BUFSIZE" redefined
#define TPM_BUFSIZE 2048
In file included from drivers/char/tpm/st33zp24/st33zp24.c:33:
drivers/char/tpm/st33zp24/../tpm.h:41: note: this is the location of the
previous definition
#define TPM_BUFSIZE 4096
In file included from drivers/char/tpm/st33zp24/st33zp24.c:34:
drivers/char/tpm/st33zp24/st33zp24.h:22: warning: "TPM_BUFSIZE" redefined
#define TPM_BUFSIZE 2048
In file included from drivers/char/tpm/st33zp24/st33zp24.c:33:
drivers/char/tpm/st33zp24/../tpm.h:41: note: this is the location of the
previous definition
#define TPM_BUFSIZE 4096
Introduced by commit
569c1057f9ac ("tpm: move tpm_chip definition to include/linux/tpm.h")
--
Cheers,
Stephen Rothwell
pgpyNJPyKAYnF.pgp
Description: OpenPGP digital signature
Re: [LSF/MM TOPIC] Discuss least bad options for resolving longterm-GUP usage by RDMA
On Wed, 2019-02-06 at 14:44 -0800, Dan Williams wrote: > On Wed, Feb 6, 2019 at 2:25 PM Doug Ledford wrote: > > Can someone give me a real world scenario that someone is *actually* > > asking for with this? > > I'll point to this example. At the 6:35 mark Kodi talks about the > Oracle use case for DAX + RDMA. > > https://youtu.be/ywKPPIE8JfQ?t=395 I watched this, and I see that Oracle is all sorts of excited that their storage machines can scale out, and they can access the storage and it has basically no CPU load on the storage server while performing millions of queries. What I didn't hear in there is why DAX has to be in the picture, or why Oracle couldn't do the same thing with a simple memory region exported directly to the RDMA subsystem, or why reflink or any of the other features you talk about are needed. So, while these things may legitimately be needed, this video did not tell me about how/why they are needed, just that RDMA is really, *really* cool for their use case and gets them 0% CPU utilization on their storage servers. I didn't watch the whole thing though. Do they get into that later on? Do they get to that level of technical discussion, or is this all higher level? -- Doug Ledford GPG KeyID: B826A3330E572FDD Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD signature.asc Description: This is a digitally signed message part
