[PATCH v3 5/7] dt-bindings: power: Add qcom rpmh power domain driver bindings
Add DT bindings to describe the rpmh powerdomains found on Qualcomm
Technologies, Inc. SoCs. These power domains communicate a performance
state to RPMh, which then translates it into corresponding voltage on
a PMIC rail.
Signed-off-by: Rajendra Nayak
---
.../devicetree/bindings/power/qcom,rpmhpd.txt | 65 +++
1 file changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
new file mode 100644
index ..41ef7afa6b24
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
@@ -0,0 +1,65 @@
+Qualcomm RPMh Power domains
+
+For RPMh Power domains, we communicate a performance state to RPMh
+which then translates it into a corresponding voltage on a rail
+
+Required Properties:
+ - compatible: Should be one of the following
+ * qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
+ - power-domain-cells: number of cells in power domain specifier
+ must be 1
+ - operating-points-v2: Phandle to the OPP table for the power-domain.
+ Refer to Documentation/devicetree/bindings/power/power_domain.txt
+ and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
+
+Example:
+
+ rpmhpd: power-controller {
+ compatible = "qcom,sdm845-rpmhpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&rpmhpd_opp_table>;
+ };
+
+ rpmhpd_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ rpmhpd_opp_ret: opp1 {
+ qcom-level = <16>;
+ };
+
+ rpmhpd_opp_min_svs: opp2 {
+ qcom-level = <48>;
+ };
+
+ rpmhpd_opp_low_svs: opp3 {
+ qcom-level = <64>;
+ };
+
+ rpmhpd_opp_svs: opp4 {
+ qcom-level = <128>;
+ };
+
+ rpmhpd_opp_svs_l1: opp5 {
+ qcom-level = <192>;
+ };
+
+ rpmhpd_opp_nom: opp6 {
+ qcom-level = <256>;
+ };
+
+ rpmhpd_opp_nom_l1: opp7 {
+ qcom-level = <320>;
+ };
+
+ rpmhpd_opp_nom_l2: opp8 {
+ qcom-level = <336>;
+ };
+
+ rpmhpd_opp_turbo: opp9 {
+ qcom-level = <384>;
+ };
+
+ rpmhpd_opp_turbo_l1: opp10 {
+ qcom-level = <416>;
+ };
+ };
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v3 7/7] soc: qcom: rpmpd/rpmhpd: Add a max vote on all corners at init
As we move from no clients/consumers in kernel voting on corners,
to *some* voting and some not voting, we might end up in a situation
where the clients which remove votes can adversly impact others
who still don't have a way to vote.
To avoid this situation, have a max vote on all corners at init.
This should/can be removed once we have all clients moved to
be able to vote/unvote for themselves.
Signed-off-by: Rajendra Nayak
Acked-by: Viresh Kumar
---
drivers/soc/qcom/rpmhpd.c | 12 +++-
drivers/soc/qcom/rpmpd.c | 9 +
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
index 7083ec1590ff..3c753d33aeee 100644
--- a/drivers/soc/qcom/rpmhpd.c
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -329,7 +329,7 @@ static int rpmhpd_update_level_mapping(struct rpmhpd
*rpmhpd)
static int rpmhpd_probe(struct platform_device *pdev)
{
- int i, ret;
+ int i, ret, max_level;
size_t num;
struct genpd_onecell_data *data;
struct rpmhpd **rpmhpds;
@@ -390,6 +390,16 @@ static int rpmhpd_probe(struct platform_device *pdev)
pm_genpd_init(&rpmhpds[i]->pd, NULL, true);
data->domains[i] = &rpmhpds[i]->pd;
+
+ /*
+* Until we have all consumers voting on corners
+* just vote the max corner on all PDs
+* This should ideally be *removed* once we have
+* all (most) consumers being able to vote
+*/
+ max_level = rpmhpds[i]->level_count - 1;
+ rpmhpd_set_performance(&rpmhpds[i]->pd,
rpmhpds[i]->level[max_level]);
+ rpmhpd_power_on(&rpmhpds[i]->pd);
}
return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 53209454c1f3..6440163305e3 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -310,6 +310,15 @@ static int rpmpd_probe(struct platform_device *pdev)
pm_genpd_init(&rpmpds[i]->pd, NULL, true);
data->domains[i] = &rpmpds[i]->pd;
+
+ /*
+* Until we have all consumers voting on corners
+* just vote the max corner on all PDs
+* This should ideally be *removed* once we have
+* all (most) consumers being able to vote
+*/
+ rpmpd_set_performance(&rpmpds[i]->pd, MAX_RPMPD_STATE);
+ rpmpd_power_on(&rpmpds[i]->pd);
}
return of_genpd_add_provider_onecell(pdev->dev.of_node, data);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v3 2/7] soc: qcom: rpmpd: Add a Power domain driver to model corners
The Power domains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.
We add all Power domain data needed on msm8996 here. This driver can easily
be extended by adding data for other qualcomm SoCs as well.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
---
drivers/soc/qcom/Kconfig | 9 +
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/rpmpd.c | 301 +
include/dt-bindings/power/qcom-rpmpd.h | 16 ++
4 files changed, 327 insertions(+)
create mode 100644 drivers/soc/qcom/rpmpd.c
create mode 100644 include/dt-bindings/power/qcom-rpmpd.h
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 9dc02f390ba3..5c54931a7b99 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -74,6 +74,15 @@ config QCOM_RMTFS_MEM
Say y here if you intend to boot the modem remoteproc.
+config QCOM_RPMPD
+ tristate "Qualcomm RPM Power domain driver"
+ depends on MFD_QCOM_RPM && QCOM_SMD_RPM
+ help
+ QCOM RPM Power domain driver to support power-domains with
+ performance states. The driver communicates a performance state
+ value to RPM which then translates it into corresponding voltage
+ for the voltage rail.
+
config QCOM_SMEM
tristate "Qualcomm Shared Memory Manager (SMEM)"
depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 19dcf957cb3a..9550c170de93 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
obj-$(CONFIG_QCOM_SMSM)+= smsm.o
obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
obj-$(CONFIG_QCOM_APR) += apr.o
+obj-$(CONFIG_QCOM_RPMPD) += rpmpd.o
diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
new file mode 100644
index ..c5e7a91f278c
--- /dev/null
+++ b/drivers/soc/qcom/rpmpd.c
@@ -0,0 +1,301 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2017-2018, The Linux Foundation. All rights reserved. */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
+
+/* Resource types */
+#define RPMPD_SMPA 0x61706d73
+#define RPMPD_LDOA 0x616f646c
+
+/* Operation Keys */
+#define KEY_CORNER 0x6e726f63 /* corn */
+#define KEY_ENABLE 0x6e657773 /* swen */
+#define KEY_FLOOR_CORNER 0x636676 /* vfc */
+
+#define DEFINE_RPMPD_CORN_SMPA(_platform, _name, _active, r_id)
\
+ static struct rpmpd _platform##_##_active; \
+ static struct rpmpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .peer = &_platform##_##_active, \
+ .res_type = RPMPD_SMPA, \
+ .res_id = r_id, \
+ .key = KEY_CORNER, \
+ }; \
+ static struct rpmpd _platform##_##_active = { \
+ .pd = { .name = #_active, },\
+ .peer = &_platform##_##_name, \
+ .active_only = true,\
+ .res_type = RPMPD_SMPA, \
+ .res_id = r_id, \
+ .key = KEY_CORNER, \
+ }
+
+#define DEFINE_RPMPD_CORN_LDOA(_platform, _name, r_id) \
+ static struct rpmpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .res_type = RPMPD_LDOA, \
+ .res_id = r_id, \
+ .key = KEY_CORNER, \
+ }
+
+#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type) \
+ static struct rpmpd _platform##_##_name = { \
+ .pd = { .name = #_name, }, \
+ .res_type = r_type, \
+ .res_id = r_id, \
+ .key = KEY_FLOOR_CORNER,\
+ }
+
+#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id) \
+ DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
+
[PATCH v3 4/7] arm64: dts: msm8996: Add rpmpd device node
Add rpmpd device node and its OPP table
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 34 +++
1 file changed, 34 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 8c7f9ca25b53..404a08630ccd 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -308,6 +308,40 @@
#clock-cells = <1>;
};
+ rpmpd: power-controller {
+ compatible = "qcom,msm8996-rpmpd";
+ #power-domain-cells = <1>;
+ operating-points-v2 = <&rpmpd_opp_table>;
+ };
+
+ rpmpd_opp_table: opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ rpmpd_opp1: opp1 {
+ qcom,level = <1>;
+ };
+
+ rpmpd_opp2: opp2 {
+ qcom,level = <2>;
+ };
+
+ rpmpd_opp3: opp3 {
+ qcom,level = <3>;
+ };
+
+ rpmpd_opp4: opp4 {
+ qcom,level = <4>;
+ };
+
+ rpmpd_opp5: opp5 {
+ qcom,level = <5>;
+ };
+
+ rpmpd_opp6: opp6 {
+ qcom,level = <6>;
+ };
+ };
+
pm8994-regulators {
compatible = "qcom,rpm-pm8994-regulators";
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2 2/2] tpm: add support for nonblocking operation
On 06/11/2018 07:53 PM, kbuild test robot wrote: > Hi Tadeusz, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on char-misc/char-misc-testing] > [also build test ERROR on next-20180608] > [cannot apply to v4.17] Hi, Thanks for the report. This patch should go on top of https://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git/?h=next-tpm I will check the config tomorrow. Thanks, -- Tadeusz
[PATCH] staging: lustre: add error handling for try_module_get
When try_module_get fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling try_module_get.
Signed-off-by: Zhouyang Jia
---
drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
index 7086678..72a42bd 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
@@ -2422,7 +2422,10 @@ ksocknal_base_startup(void)
/* flag lists/ptrs/locks initialised */
ksocknal_data.ksnd_init = SOCKNAL_INIT_DATA;
- try_module_get(THIS_MODULE);
+ if (!try_module_get(THIS_MODULE)) {
+ CERROR("%s: cannot get module\n", __func__);
+ goto failed;
+ }
ksocknal_data.ksnd_sched_info = cfs_percpt_alloc(lnet_cpt_table(),
sizeof(*info));
--
2.7.4
Re: [PATCH 2/2] fs/lock: show locks taken by processes from another pidns
On Fri, Jun 08, 2018 at 05:27:12PM +0300, Konstantin Khorenko wrote:
> Currently if we face a lock taken by a process invisible in the current
> pidns we skip the lock completely, but this
>
> 1) makes the output not that nice
> (root@vz7)/: cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags: 0212
> mnt_id: 257
> lock: (root@vz7)/:
>
> 2) makes it more difficult to debug issues with leaked flocks
>if you get error on lock, but don't see any locks in /proc/$id/fdinfo/$file
3) breaks the CRIU project. criu reads fdinfo to dump file locks.
>
> Let's show information about such locks again as previously, but
> show zero in the owner pid field.
>
> After the patch:
> ===
> (root@vz7)/:cat /proc/${PID_A2}/fdinfo/3
> pos:4
> flags: 0212
> mnt_id: 295
> lock: 1: FLOCK ADVISORY WRITE 0 b6:f8a61:529946 0 EOF
>
I think initially this was broken in this commit:
Fixes: d67fd44f697d ("locks: Filter /proc/locks output on proc pid ns")
Acked-by: Andrei Vagin
Thanks,
Andrei
> Fixes: 9d5b86ac13c5 ("fs/locks: Remove fl_nspid and use fs-specific l_pid for
> remote locks")
> Signed-off-by: Konstantin Khorenko
> ---
> fs/locks.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/fs/locks.c b/fs/locks.c
> index bfee5b7f2862..e533623e2e99 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -2633,12 +2633,10 @@ static void lock_get_status(struct seq_file *f,
> struct file_lock *fl,
>
> fl_pid = locks_translate_pid(fl, proc_pidns);
> /*
> - * If there isn't a fl_pid don't display who is waiting on
> - * the lock if we are called from locks_show, or if we are
> - * called from __show_fd_info - skip lock entirely
> + * If lock owner is dead (and pid is freed) or not visible in current
> + * pidns, zero is shown as a pid value. Check lock info from
> + * init_pid_ns to get saved lock pid value.
>*/
> - if (fl_pid == 0)
> - return;
>
> if (fl->fl_file != NULL)
> inode = locks_inode(fl->fl_file);
> --
> 2.15.1
>
Re: [intel-sgx-kernel-dev] [PATCH v11 13/13] intel_sgx: in-kernel launch enclave
On Mon, Jun 11, 2018 at 4:52 AM Neil Horman wrote: > > On Sun, Jun 10, 2018 at 10:17:13PM -0700, Andy Lutomirski wrote: > > > On Jun 9, 2018, at 10:39 PM, Andy Lutomirski wrote: > > > > > > On Fri, Jun 8, 2018 at 10:32 AM Jarkko Sakkinen > > > wrote: > > >> > > >> The Launch Enclave (LE) generates cryptographic launch tokens for user > > >> enclaves. A launch token is used by EINIT to check whether the enclave > > >> is authorized to launch or not. By having its own launch enclave, Linux > > >> has full control of the enclave launch process. > > >> > > >> LE is wrapped into a user space proxy program that reads enclave > > >> signatures outputs launch tokens. The kernel-side glue code is > > >> implemented by using the user space helper framework. The IPC between > > >> the LE proxy program and kernel is handled with an anonymous inode. > > >> > > >> The commit also adds enclave signing tool that is used by kbuild to > > >> measure and sign the launch enclave. CONFIG_INTEL_SGX_SIGNING_KEY points > > >> to a PEM-file for the 3072-bit RSA key that is used as the LE public key > > >> pair. The default location is: > > >> > > >> drivers/platform/x86/intel_sgx/sgx_signing_key.pem > > >> > > >> If the default key does not exist kbuild will generate a random key and > > >> place it to this location. KBUILD_SGX_SIGN_PIN can be used to specify > > >> the passphrase for the LE public key. > > > > > > It seems to me that it might be more useful to just commit a key pair > > > into the kernel. As far as I know, there is no security whatsoever > > > gained by keeping the private key private, so why not make > > > reproducible builds easier by simply fixing the key? > > > > Having thought about this some more, I think that you should > > completely remove support for specifying a key. Provide a fixed key > > pair, hard code the cache, and call it a day. If you make the key > > configurable, every vendor that has any vendor keys (Debian, Ubuntu, > > Fedora, Red Hat, SuSE, Clear Linux, etc) will see that config option > > and set up their own key pair for no gain whatsoever. Instead, it'll > > give some illusion of security and it'll slow down operations in a VM > > guest due to swapping out the values of the MSRs. And, if the code to > > support a locked MSR that just happens to have the right value stays > > in the kernel, then we'll risk having vendors actually ship one > > distro's public key hash, and that will seriously suck. > > > If you hard code the key pair however, doesn't that imply that anyone can > sign a > user space binary as a launch enclave, and potentially gain control of the > token > granting process? Yes and no. First of all, the kernel driver shouldn't be allowing user code to launch a launch enclave regardless of signature. I haven't gotten far enough in reviewing the code to see whether that's the case, but if it's not, it should be fixed before it's merged. But keep in mind that control of the token granting process is not the same thing as control over the right to launch an enclave. On systems without the LE hash MSRs, Intel controls the token granting process and, barring some attack, an enclave that isn't blessed by Intel can't be launched. Support for that model will not be merged into upstream Linux. But on systems that have the LE hash MSRs and leave them unlocked, there is effectively no hardware-enforced launch control. Instead we have good old kernel policy. If a user wants to launch an enclave, they need to get the kernel to launch the enclave, and the kernel needs to apply its policy. The patch here (the in-kernel launch enclave) has a wide-open policy. So, as a practical matter, if every distro has their own LE key and keeps it totally safe, then a system that locks the MSRs to one distro's key makes it quite annoying to run another distro's intel_sgx driver, but there is no effect on the actual security of the system. > It was my understanding that the value of the key pair was > that the end user was guaranteed autonomy and security over which processes > could start enclaves. By publishing a fixed key pair, it seems to remove that > ability. If someone comes up with an actual machine that grants the actual end user (where the end user is the person who bought the thing, not the OEM) control over the MSRs, *and* the actual end user wants to limit what enclaves can be launched even if the kernel is compromised, *and* there is some actual argument for why this is useful (as opposed to some compliance checkbox), then Linux could reasonably consider adding support for this use case. But that would be a separate patch. > > What would be nicer (I think) would be the abilty to specify both the public > and > the private key at run time. the use case here is not one in which a vendor > or > os distribution ships a key pair, but one in which a downstream user doesn't > want a vendor/os distribution to have any cryptographic information installed > on > their sy
Re: [PATCH 2/2] arm64: dts: qcom: sdm845: Enable debug UART and I2C10 on sdm845-mtp
On Thu 07 Jun 13:46 PDT 2018, Douglas Anderson wrote:
> The debug UART is very useful to have. I2C10 is enabled as an example
> of a I2C port we can talk on for now. Eventually we'll want to put
> peripherals under it.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
Tested-by: Bjorn Andersson
Regards,
Bjorn
> ---
>
> arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 52 +
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index 979ab49913f1..e1eda143a725 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -12,4 +12,56 @@
> / {
> model = "Qualcomm Technologies, Inc. SDM845 MTP";
> compatible = "qcom,sdm845-mtp";
> +
> + aliases {
> + serial0 = &uart9;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> +&i2c10 {
> + status = "okay";
> + clock-frequency = <40>;
> +};
> +
> +&qupv3_id_1 {
> + status = "okay";
> +};
> +
> +&uart9 {
> + status = "okay";
> +};
> +
> +/* PINCTRL - additions to nodes defined in sdm845.dtsi */
> +
> +&qup_i2c10_default {
> + pinconf {
> + pins = "gpio55", "gpio56";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +};
> +
> +&qup_uart9_default {
> + pinconf-tx {
> + pins = "gpio4";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + pinconf-rx {
> + pins = "gpio5";
> + drive-strength = <2>;
> + bias-pull-up;
> + };
> +};
> +
> +&qup_uart9_sleep {
> + pinconf {
> + pins = "gpio4", "gpio5";
> + bias-pull-down;
> + };
> };
> --
> 2.17.1.1185.g55be947832-goog
>
Re: [PATCH 1/2] arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
On Thu 07 Jun 13:46 PDT 2018, Douglas Anderson wrote:
> This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI
> ports, and UART9. Note that I2C / SPI / UART are a bit strange on
> sdm845 because each "serial engine" has 4 pins associated with it and
> depending on which firmware has been loaded into the serial engine
> (loaded by the BIOS) the serial engine can behave like an I2C port, a
> SPI port, or a UART. As per the landed bindings that means that we
> need to create one node for each possible mode that the port could be
> in. With 16 serial engines that means 16 x 3 = 48 nodes.
>
> We get away with only creating 33 nodes for now because it seems very
> likely that SDM845-based boards will actually all use the same UART
> (UART 9) for debug purposes. While another UART could be used for
> something like Bluetooth communication we can cross that path when we
> come to it. Some documentation that I saw implied that using a UART
> for "high speed" communications actually needs yet another different
> serial engine firmware anyway.
>
> Note that quick measurements adding all these nodes adds ~10k of extra
> space per dtb that they're included with. If this becomes a problem
> we may need to think of a different way to structure this so that
> boards only get the nodes they need (or figure out how to get dtc to
> strip 'disabled' nodes). For now it seems OK.
>
> These nodes were programmatically generated with a fairly dumb python
> script. See http://crosreview.com/1091631 for the source.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
>
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 1013 ++
> 1 file changed, 1013 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index cdaabeb3c995..2dc5c7dcc9aa 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -5,6 +5,7 @@
> * Copyright (c) 2018, The Linux Foundation. All rights reserved.
> */
>
> +#include
> #include
>
> / {
> @@ -13,6 +14,41 @@
> #address-cells = <2>;
> #size-cells = <2>;
>
> + aliases {
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + i2c2 = &i2c2;
> + i2c3 = &i2c3;
> + i2c4 = &i2c4;
> + i2c5 = &i2c5;
> + i2c6 = &i2c6;
> + i2c7 = &i2c7;
> + i2c8 = &i2c8;
> + i2c9 = &i2c9;
> + i2c10 = &i2c10;
> + i2c11 = &i2c11;
> + i2c12 = &i2c12;
> + i2c13 = &i2c13;
> + i2c14 = &i2c14;
> + i2c15 = &i2c15;
> + spi0 = &spi0;
> + spi1 = &spi1;
> + spi2 = &spi2;
> + spi3 = &spi3;
> + spi4 = &spi4;
> + spi5 = &spi5;
> + spi6 = &spi6;
> + spi7 = &spi7;
> + spi8 = &spi8;
> + spi9 = &spi9;
> + spi10 = &spi10;
> + spi11 = &spi11;
> + spi12 = &spi12;
> + spi13 = &spi13;
> + spi14 = &spi14;
> + spi15 = &spi15;
> + };
> +
> chosen { };
>
> memory@8000 {
> @@ -206,6 +242,489 @@
> #power-domain-cells = <1>;
> };
>
> + qupv3_id_0: geniqup@8c {
> + compatible = "qcom,geni-se-qup";
> + reg = <0x8c 0x6000>;
> + clock-names = "m-ahb", "s-ahb";
> + clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
> + <&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + i2c0: i2c@88 {
> + compatible = "qcom,geni-i2c";
> + reg = <0x88 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_i2c0_default>;
> + pinctrl-1 = <&qup_i2c0_sleep>;
> + interrupts = ;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spi0: spi@88 {
> + compatible = "qcom,geni-spi";
> + reg = <0x88 0x4000>;
> + clock-names = "se";
> + clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&qup_spi0_default>;
> + pinct
Re: [PATCH 2/2] IB/mad: Use IDR for agent IDs
On Mon, 11 Jun 2018 10:19:18 -0600
Jason Gunthorpe wrote:
> On Mon, Jun 11, 2018 at 09:19:14AM +0300, jackm wrote:
> > On Sun, 10 Jun 2018 22:42:03 -0600
> > Jason Gunthorpe wrote:
> >
> > > Er, the spec has nothing to do with this. In Linux the TID is made
> > > unique because the core code provides 32 bits that are unique and
> > > the user provides another 32 bits that are unique. The driver
> > > cannot change any of those bits without risking non-uniquenes,
> > > which is exactly the bug mlx4 created when it stepped outside its
> > > bounds and improperly overrode bits in the TID for its own
> > > internal use.
> >
> > Actually, the opposite is true here. When SRIOV is active, each VM
> > generates its *own* TIDs -- with 32 bits of agent number and 32 bits
> > of counter.
>
> And it does it while re-using the LRH of the host, so all VMs and the
> host are now forced to share a TID space, yes I know.
>
> > There is a chance that two different VMs can generate the same TID!
> > Encoding the slave (VM) number in the packet actually guarantees
> > uniqueness here.
>
> Virtualizing the TID in the driver would be fine, but it must
> virtualize all the TIDs (even those generated by the HOST).
It DOES do so. The host slave id is 0. Slave numbers start with 1.
If the MS byte contains a zero after paravirtualization, the MAD
was sent by the host.
In fact, ALL mads are paravirtualized -- including those to/from the host.
>
> Just blindly assuming the host doesn't generate TID's that overlap
> with the virtualization process is a bug.
>
Not the case, host mads are also paravirtualized.
> > There is nothing wrong with modifying the TID in a reversible way in
> > order to: a. guarantee uniqueness b. identify the VM which should
> > receive the response packet
>
> Sure, as long as *all* TID's sharing a LRH are vitalized like this.
>
> > The problem was created when the agent-id numbers started to use the
> > most-significant byte (thus making the MSB slave-id addition
> > impossible).
>
> It hasn't always been this way? What commit?
>
Commit: 37bfc7c1e83f1 ("IB/mlx4: SR-IOV multiplex and demultiplex MADs"):
Code snippet which replaces the MS byte is below (file
drivers/infiniband/hw/mlx4/mad.c,
procedure mlx4_ib_multiplex_mad() ).
Just an aside: Oracle noted the problem on the *host*: The host's message log
contained the warning issued on line 1529, with slave=0 (which is the
hypervisor).
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1519) switch
(tunnel->mad.mad_hdr.method) {
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1520) case
IB_MGMT_METHOD_SET:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1521) case
IB_MGMT_METHOD_GET:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1522) case
IB_MGMT_METHOD_REPORT:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1523) case
IB_SA_METHOD_GET_TABLE:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1524) case
IB_SA_METHOD_DELETE:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1525) case
IB_SA_METHOD_GET_MULTI:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1526) case
IB_SA_METHOD_GET_TRACE_TBL:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1527)
slave_id = (u8 *) &tunnel->mad.mad_hdr.tid;
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1528)
if (*slave_id) {
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1529)
mlx4_ib_warn(ctx->ib_dev, "egress mad has non-null tid msb:%d "
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1530)
"class:%d slave:%d\n", *slave_id,
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1531)
tunnel->mad.mad_hdr.mgmt_class, slave);
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1532)
return;
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1533)
} else
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1534)
*slave_id = slave;
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1535) default:
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1536)
/* nothing */;
37bfc7c1e (Jack Morgenstein2012-08-03 08:40:44 + 1537) }
> Jason
Re: [PATCH] proc: add error handling for kmem_cache_create
On Tue, Jun 12, 2018 at 12:23:52PM +0800, Zhouyang Jia wrote:
> When kmem_cache_create fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling kmem_cache_create.
> pde_opener_cache =
> kmem_cache_create("pde_opener", sizeof(struct pde_opener), 0,
> SLAB_ACCOUNT|SLAB_PANIC, NULL);
> + if (!proc_inode_cachep || !pde_opener_cache)
> + return -ENOMEM;
SLAB_PANIC was added to not worry about error handling.
[PATCH v2 1/2] ALSA: hda: add dock and led support for HP EliteBook 830 G5
This patch adds missing initialisation for HP 2013 UltraSlim Dock
Line-In/Out PINs and activates keyboard mute/micmute leds
for HP EliteBook 830 G5
Signed-off-by: Dennis Wassenberg
---
sound/pci/hda/patch_conexant.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index 5b4dbcec6de8..bca71f35b34f 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -958,6 +958,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
SND_PCI_QUIRK(0x103c, 0x8079, "HP EliteBook 840 G3", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x807C, "HP EliteBook 820 G3", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x80FD, "HP ProBook 640 G2", CXT_FIXUP_HP_DOCK),
+ SND_PCI_QUIRK(0x103c, 0x83b3, "HP EliteBook 830 G5", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x8174, "HP Spectre x360", CXT_FIXUP_HP_SPECTRE),
SND_PCI_QUIRK(0x103c, 0x8115, "HP Z1 Gen3", CXT_FIXUP_HP_GATE_MIC),
SND_PCI_QUIRK(0x103c, 0x814f, "HP ZBook 15u G3",
CXT_FIXUP_MUTE_LED_GPIO),
--
2.17.1
[PATCH v2 2/2] ALSA: hda: add dock and led support for HP ProBook 640 G4
This patch adds missing initialisation for HP 2013 UltraSlim Dock
Line-In/Out PINs and activates keyboard mute/micmute leds
for HP ProBook 640 G4
Signed-off-by: Dennis Wassenberg
---
sound/pci/hda/patch_conexant.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c
index bca71f35b34f..ff0c52e98977 100644
--- a/sound/pci/hda/patch_conexant.c
+++ b/sound/pci/hda/patch_conexant.c
@@ -959,6 +959,7 @@ static const struct snd_pci_quirk cxt5066_fixups[] = {
SND_PCI_QUIRK(0x103c, 0x807C, "HP EliteBook 820 G3", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x80FD, "HP ProBook 640 G2", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x83b3, "HP EliteBook 830 G5", CXT_FIXUP_HP_DOCK),
+ SND_PCI_QUIRK(0x103c, 0x83d3, "HP ProBook 640 G4", CXT_FIXUP_HP_DOCK),
SND_PCI_QUIRK(0x103c, 0x8174, "HP Spectre x360", CXT_FIXUP_HP_SPECTRE),
SND_PCI_QUIRK(0x103c, 0x8115, "HP Z1 Gen3", CXT_FIXUP_HP_GATE_MIC),
SND_PCI_QUIRK(0x103c, 0x814f, "HP ZBook 15u G3",
CXT_FIXUP_MUTE_LED_GPIO),
--
2.17.1
Re: linux-next: build failure after merge of the drivers-x86 tree
On Tue, Jun 12, 2018 at 11:23:10AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drivers-x86 tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/platform/x86/silead_dmi.c:84:21: error: variable 'chuwi_vi10_data'
> has initializer but incomplete type
> static const struct ts_dmi_data chuwi_vi10_data = {
> ^~~
> drivers/platform/x86/silead_dmi.c:85:3: error: 'const struct ts_dmi_data' has
> no member named 'acpi_name'
> .acpi_name = "MSSL0002:00",
>^
> drivers/platform/x86/silead_dmi.c:85:20: warning: excess elements in struct
> initializer
> .acpi_name = "MSSL0002:00",
> ^
> drivers/platform/x86/silead_dmi.c:85:20: note: (near initialization for
> 'chuwi_vi10_data')
> drivers/platform/x86/silead_dmi.c:86:3: error: 'const struct ts_dmi_data' has
> no member named 'properties'
> .properties = chuwi_vi10_props,
>^~
> drivers/platform/x86/silead_dmi.c:86:20: warning: excess elements in struct
> initializer
> .properties = chuwi_vi10_props,
> ^~~~
> drivers/platform/x86/silead_dmi.c:86:20: note: (near initialization for
> 'chuwi_vi10_data')
> drivers/platform/x86/silead_dmi.c:84:33: error: storage size of
> 'chuwi_vi10_data' isn't known
> static const struct ts_dmi_data chuwi_vi10_data = {
> ^~~
>
> Caused by commit
>
> 2da502a0aea7 ("platform/x86: silead_dmi: Add touchscreen info for the Chuwi
> Vi10 tablet")
>
> I have reverted that commit for today. More care please.
Thank you Stephen. We caught this earlier, but failed to remove it from for-next
while repairing the series. Our apologies. I have removed this series back to
the known good patch in for-next:
26ed9d1 platform/x86: silead_dmi: Add entry for Chuwi Hi8 tablet touchscreen
Andy has this reworked already and is working on completing
testing before pushing the update to for-next.
--
Darren Hart
VMware Open Source Technology Center
[RFC PATCH 0/5] FSI scom driver overhaul
The current FSI scom driver is a bit too simplistic (and buggy). This fixes a locking bug, cleans a few things up, then overhaul the driver more thoroughly by providing proper support for the different type of SCOM accesses (direct and indirect), handling errors properly in the read/write interface, and adding a lower level ioctl interface needed by system debugger (such as cronus) that need to be able to access the raw status register content resulting from the access attempt and do their own error handling. I will send patches separately for pdbg and cronus to use the new debugger interface. Note: It is unfortunate that the read/write interface does NOT use the same addressing scheme as the host-side equivalent xscom debugfs interface. However I didn't want to change the user ABI by "fixing" this as I'm not entirely sure what other users we might have of that existing interface. The patches apply on top of the other FSI changes posted recently and at this point are meant to discuss the new user API.
[RFC PATCH 1/5] fsi/scom: Add mutex around FSI2PIB accesses
Otherwise, multiple clients can open the driver and attempt
to access the PIB at the same time, thus clobbering each other
in the process.
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-scom.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index c8eb5e5b94a7..3cba0eb645e1 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -37,6 +37,7 @@ struct scom_device {
struct list_head link;
struct fsi_device *fsi_dev;
struct miscdevice mdev;
+ struct mutex lock;
charname[32];
int idx;
};
@@ -53,21 +54,26 @@ static int put_scom(struct scom_device *scom_dev, uint64_t
value,
int rc;
uint32_t data;
+ mutex_lock(&scom_dev->lock);
+
data = cpu_to_be32((value >> 32) & 0x);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA0_REG, &data,
sizeof(uint32_t));
if (rc)
- return rc;
+ goto bail;
data = cpu_to_be32(value & 0x);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA1_REG, &data,
sizeof(uint32_t));
if (rc)
- return rc;
+ goto bail;
data = cpu_to_be32(SCOM_WRITE_CMD | addr);
- return fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
+ rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
+ bail:
+ mutex_unlock(&scom_dev->lock);
+ return rc;
}
static int get_scom(struct scom_device *scom_dev, uint64_t *value,
@@ -76,27 +82,31 @@ static int get_scom(struct scom_device *scom_dev, uint64_t
*value,
uint32_t result, data;
int rc;
+
+ mutex_lock(&scom_dev->lock);
*value = 0ULL;
data = cpu_to_be32(addr);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
if (rc)
- return rc;
+ goto bail;
rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA0_REG, &result,
sizeof(uint32_t));
if (rc)
- return rc;
+ goto bail;
*value |= (uint64_t)cpu_to_be32(result) << 32;
rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA1_REG, &result,
sizeof(uint32_t));
if (rc)
- return rc;
+ goto bail;
*value |= cpu_to_be32(result);
- return 0;
+ bail:
+ mutex_unlock(&scom_dev->lock);
+ return rc;
}
static ssize_t scom_read(struct file *filep, char __user *buf, size_t len,
@@ -183,6 +193,7 @@ static int scom_probe(struct device *dev)
if (!scom)
return -ENOMEM;
+ mutex_init(&scom->lock);
scom->idx = ida_simple_get(&scom_ida, 1, INT_MAX, GFP_KERNEL);
snprintf(scom->name, sizeof(scom->name), "scom%d", scom->idx);
scom->fsi_dev = fsi_dev;
--
2.17.0
[RFC PATCH 4/5] fsi/scom: Add register definitions
Add a few more register and bit definitions, also define and use
SCOM_READ_CMD (which is 0 but it makes the code clearer)
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-scom.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index 6ddfb6021420..e98573ecdae1 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -30,8 +30,25 @@
#define SCOM_DATA0_REG 0x00
#define SCOM_DATA1_REG 0x04
#define SCOM_CMD_REG 0x08
+#define SCOM_FSI2PIB_RESET_REG 0x18
+#define SCOM_STATUS_REG0x1C /* Read */
+#define SCOM_PIB_RESET_REG 0x1C /* Write */
+/* Command register */
#define SCOM_WRITE_CMD 0x8000
+#define SCOM_READ_CMD 0x
+
+/* Status register bits */
+#define SCOM_STATUS_ERR_SUMMARY0x8000
+#define SCOM_STATUS_PROTECTION 0x0100
+#define SCOM_STATUS_PIB_ABORT 0x0010
+#define SCOM_STATUS_PIB_RESP_MASK 0x7000
+#define SCOM_STATUS_PIB_RESP_SHIFT 12
+
+#define SCOM_STATUS_ANY_ERR(SCOM_STATUS_ERR_SUMMARY | \
+SCOM_STATUS_PROTECTION | \
+SCOM_STATUS_PIB_ABORT | \
+SCOM_STATUS_PIB_RESP_MASK)
struct scom_device {
struct list_head link;
@@ -85,7 +102,7 @@ static int get_scom(struct scom_device *scom_dev, uint64_t
*value,
mutex_lock(&scom_dev->lock);
*value = 0ULL;
- data = cpu_to_be32(addr);
+ data = cpu_to_be32(SCOM_READ_CMD | addr);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
if (rc)
--
2.17.0
[RFC PATCH 5/5] fsi/scom: Major overhaul
This was too hard to split ... this adds a number of features
to the SCOM user interface:
- Support for indirect SCOMs
- read()/write() interface now handle errors and retries
- New ioctl() "raw" interface for use by debuggers
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-scom.c | 424 ---
include/uapi/linux/fsi.h | 56 ++
2 files changed, 450 insertions(+), 30 deletions(-)
create mode 100644 include/uapi/linux/fsi.h
diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index e98573ecdae1..39c74351f1bf 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -24,6 +24,8 @@
#include
#include
+#include
+
#define FSI_ENGID_SCOM 0x5
/* SCOM engine register set */
@@ -41,14 +43,36 @@
/* Status register bits */
#define SCOM_STATUS_ERR_SUMMARY0x8000
#define SCOM_STATUS_PROTECTION 0x0100
+#define SCOM_STATUS_PARITY 0x0400
#define SCOM_STATUS_PIB_ABORT 0x0010
#define SCOM_STATUS_PIB_RESP_MASK 0x7000
#define SCOM_STATUS_PIB_RESP_SHIFT 12
#define SCOM_STATUS_ANY_ERR(SCOM_STATUS_ERR_SUMMARY | \
SCOM_STATUS_PROTECTION | \
+SCOM_STATUS_PARITY | \
SCOM_STATUS_PIB_ABORT | \
SCOM_STATUS_PIB_RESP_MASK)
+/* SCOM address encodings */
+#define XSCOM_ADDR_IND_FLAGBIT_ULL(63)
+#define XSCOM_ADDR_INF_FORM1 BIT_ULL(60)
+
+/* SCOM indirect stuff */
+#define XSCOM_ADDR_DIRECT_PART 0x7fffull
+#define XSCOM_ADDR_INDIRECT_PART 0x000full
+#define XSCOM_DATA_IND_READBIT_ULL(63)
+#define XSCOM_DATA_IND_COMPLETEBIT_ULL(31)
+#define XSCOM_DATA_IND_ERR_MASK0x7000ull
+#define XSCOM_DATA_IND_ERR_SHIFT 28
+#define XSCOM_DATA_IND_DATA0xull
+#define XSCOM_DATA_IND_FORM1_DATA 0x000full
+#define XSCOM_ADDR_FORM1_LOW 0x000ull
+#define XSCOM_ADDR_FORM1_HI0xfffull
+#define XSCOM_ADDR_FORM1_HI_SHIFT 20
+
+/* Retries */
+#define SCOM_MAX_RETRIES 100 /* Retries on busy */
+#define SCOM_MAX_IND_RETRIES 10 /* Retries indirect not ready */
struct scom_device {
struct list_head link;
@@ -56,7 +80,7 @@ struct scom_device {
struct miscdevice mdev;
struct mutex lock;
charname[32];
- int idx;
+ int idx;
};
#define to_scom_dev(x) container_of((x), struct scom_device, mdev)
@@ -65,80 +89,304 @@ static struct list_head scom_devices;
static DEFINE_IDA(scom_ida);
-static int put_scom(struct scom_device *scom_dev, uint64_t value,
- uint32_t addr)
+static int __put_scom(struct scom_device *scom_dev, uint64_t value,
+ uint32_t addr, uint32_t *status)
{
- __be32 data;
+ __be32 data, raw_status;
int rc;
- mutex_lock(&scom_dev->lock);
-
data = cpu_to_be32((value >> 32) & 0x);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA0_REG, &data,
sizeof(uint32_t));
if (rc)
- goto bail;
+ return rc;
data = cpu_to_be32(value & 0x);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_DATA1_REG, &data,
sizeof(uint32_t));
if (rc)
- goto bail;
+ return rc;
data = cpu_to_be32(SCOM_WRITE_CMD | addr);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
- bail:
- mutex_unlock(&scom_dev->lock);
- return rc;
+ if (rc)
+ return rc;
+ rc = fsi_device_read(scom_dev->fsi_dev, SCOM_STATUS_REG, &raw_status,
+sizeof(uint32_t));
+ if (rc)
+ return rc;
+ *status = be32_to_cpu(raw_status);
+
+ return 0;
}
-static int get_scom(struct scom_device *scom_dev, uint64_t *value,
- uint32_t addr)
+static int __get_scom(struct scom_device *scom_dev, uint64_t *value,
+ uint32_t addr, uint32_t *status)
{
- __be32 result, data;
+ __be32 data, raw_status;
int rc;
- mutex_lock(&scom_dev->lock);
*value = 0ULL;
data = cpu_to_be32(SCOM_READ_CMD | addr);
rc = fsi_device_write(scom_dev->fsi_dev, SCOM_CMD_REG, &data,
sizeof(uint32_t));
if (rc)
- goto bail;
+ return rc;
+ rc = fsi_device_read(scom_dev->fsi_dev, SCOM_STATUS_REG, &raw_status,
+sizeof(uint32_t));
+ if (rc)
+ return rc;
- rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA0_REG, &r
Re: linux-next: build failure after merge of the drivers-x86 tree
On June 11, 2018 6:23:10 PM PDT, Stephen Rothwell wrote:
>Hi all,
>
>After merging the drivers-x86 tree, today's linux-next build (x86_64
>allmodconfig) failed like this:
>
>drivers/platform/x86/silead_dmi.c:84:21: error: variable
>'chuwi_vi10_data' has initializer but incomplete type
> static const struct ts_dmi_data chuwi_vi10_data = {
> ^~~
...
>Caused by commit
>
>2da502a0aea7 ("platform/x86: silead_dmi: Add touchscreen info for the
>Chuwi Vi10 tablet")
>
>I have reverted that commit for today. More care please.
Grmbl. Thanks Stephen. I'll work with Andy tonight to get for-next back into
good shape.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[RFC PATCH 3/5] fsi/scom: Fixup endian annotations
Use the proper annotated type __be32 and fixup the
accessor used for get_scom()
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-scom.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index 8a608db0aa07..6ddfb6021420 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -51,8 +51,8 @@ static DEFINE_IDA(scom_ida);
static int put_scom(struct scom_device *scom_dev, uint64_t value,
uint32_t addr)
{
+ __be32 data;
int rc;
- uint32_t data;
mutex_lock(&scom_dev->lock);
@@ -79,7 +79,7 @@ static int put_scom(struct scom_device *scom_dev, uint64_t
value,
static int get_scom(struct scom_device *scom_dev, uint64_t *value,
uint32_t addr)
{
- uint32_t result, data;
+ __be32 result, data;
int rc;
@@ -96,14 +96,13 @@ static int get_scom(struct scom_device *scom_dev, uint64_t
*value,
if (rc)
goto bail;
- *value |= (uint64_t)cpu_to_be32(result) << 32;
+ *value |= (uint64_t)be32_to_cpu(result) << 32;
rc = fsi_device_read(scom_dev->fsi_dev, SCOM_DATA1_REG, &result,
sizeof(uint32_t));
if (rc)
goto bail;
- *value |= cpu_to_be32(result);
-
+ *value |= be32_to_cpu(result);
bail:
mutex_unlock(&scom_dev->lock);
return rc;
--
2.17.0
[RFC PATCH 2/5] fsi/scom: Whitespace fixes
No functional changes
Signed-off-by: Benjamin Herrenschmidt
---
drivers/fsi/fsi-scom.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/fsi/fsi-scom.c b/drivers/fsi/fsi-scom.c
index 3cba0eb645e1..8a608db0aa07 100644
--- a/drivers/fsi/fsi-scom.c
+++ b/drivers/fsi/fsi-scom.c
@@ -49,7 +49,7 @@ static struct list_head scom_devices;
static DEFINE_IDA(scom_ida);
static int put_scom(struct scom_device *scom_dev, uint64_t value,
- uint32_t addr)
+ uint32_t addr)
{
int rc;
uint32_t data;
@@ -77,7 +77,7 @@ static int put_scom(struct scom_device *scom_dev, uint64_t
value,
}
static int get_scom(struct scom_device *scom_dev, uint64_t *value,
- uint32_t addr)
+ uint32_t addr)
{
uint32_t result, data;
int rc;
@@ -110,7 +110,7 @@ static int get_scom(struct scom_device *scom_dev, uint64_t
*value,
}
static ssize_t scom_read(struct file *filep, char __user *buf, size_t len,
- loff_t *offset)
+loff_t *offset)
{
int rc;
struct miscdevice *mdev =
@@ -136,7 +136,7 @@ static ssize_t scom_read(struct file *filep, char __user
*buf, size_t len,
}
static ssize_t scom_write(struct file *filep, const char __user *buf,
- size_t len, loff_t *offset)
+ size_t len, loff_t *offset)
{
int rc;
struct miscdevice *mdev = filep->private_data;
--
2.17.0
Re: [PATCH] proc: add error handling for kmem_cache_create
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.17 next-20180608]
[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/linux-kernel-owner-vger-kernel-org/proc-add-error-handling-for-kmem_cache_create/20180612-122737
config: i386-randconfig-x012-201823 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
fs/proc/inode.c: In function 'proc_init_kmemcache':
>> fs/proc/inode.c:108:10: warning: 'return' with a value, in function
>> returning void
return -ENOMEM;
^
fs/proc/inode.c:96:13: note: declared here
void __init proc_init_kmemcache(void)
^~~
vim +/return +108 fs/proc/inode.c
95
96 void __init proc_init_kmemcache(void)
97 {
98 proc_inode_cachep = kmem_cache_create("proc_inode_cache",
99 sizeof(struct proc_inode),
100 0, (SLAB_RECLAIM_ACCOUNT|
101
SLAB_MEM_SPREAD|SLAB_ACCOUNT|
102 SLAB_PANIC),
103 init_once);
104 pde_opener_cache =
105 kmem_cache_create("pde_opener", sizeof(struct
pde_opener), 0,
106SLAB_ACCOUNT|SLAB_PANIC, NULL);
107 if (!proc_inode_cachep || !pde_opener_cache)
> 108 return -ENOMEM;
109
110 proc_dir_entry_cache = kmem_cache_create_usercopy(
111 "proc_dir_entry", sizeof(struct proc_dir_entry), 0,
SLAB_PANIC,
112 offsetof(struct proc_dir_entry, inline_name),
113 sizeof_field(struct proc_dir_entry, inline_name), NULL);
114 }
115
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 1/2] arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
Hi, On Mon, Jun 11, 2018 at 10:01 PM, Bjorn Andersson wrote: > On Thu 07 Jun 13:46 PDT 2018, Douglas Anderson wrote: > >> This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI >> ports, and UART9. Note that I2C / SPI / UART are a bit strange on >> sdm845 because each "serial engine" has 4 pins associated with it and >> depending on which firmware has been loaded into the serial engine >> (loaded by the BIOS) the serial engine can behave like an I2C port, a >> SPI port, or a UART. As per the landed bindings that means that we >> need to create one node for each possible mode that the port could be >> in. With 16 serial engines that means 16 x 3 = 48 nodes. >> >> We get away with only creating 33 nodes for now because it seems very >> likely that SDM845-based boards will actually all use the same UART >> (UART 9) for debug purposes. While another UART could be used for >> something like Bluetooth communication we can cross that path when we >> come to it. Some documentation that I saw implied that using a UART >> for "high speed" communications actually needs yet another different >> serial engine firmware anyway. >> >> Note that quick measurements adding all these nodes adds ~10k of extra >> space per dtb that they're included with. If this becomes a problem >> we may need to think of a different way to structure this so that >> boards only get the nodes they need (or figure out how to get dtc to >> strip 'disabled' nodes). For now it seems OK. >> >> These nodes were programmatically generated with a fairly dumb python >> script. See http://crosreview.com/1091631 for the source. >> >> Signed-off-by: Douglas Anderson > > Reviewed-by: Bjorn Andersson Thanks for the review! One note is that I have since come to find that it might not be so wise to define the sleep pinctrl state here. For the SPI driver at least I dug in and I saw the the sleep state is selected when we're runtime PMed. ...and with the currently posted SPI driver that can happen in some cases even when the chip select is supposed to be kept low. For now it's more prudent to keep the "sleep" state out of the device tree and we can always add it in later. I'll plan to re-spin the patch on Wednesday (I'm unavailable tomorrow). For other's reference: I chatted offline with Bjorn offline and this sounded fine to him. -Doug
[PATCH 2/2] nvmem: Add Spreadtrum SC27XX efuse support
From: Freeman Liu
This patch add the efuse driver which is embeded in Spreadtrum SC27XX
series PMICs. The sc27xx efuse contains 32 blocks and each block's
data width is 16 bits.
Signed-off-by: Freeman Liu
Signed-off-by: Baolin Wang
---
drivers/nvmem/Kconfig| 11 ++
drivers/nvmem/Makefile |3 +-
drivers/nvmem/sc27xx-efuse.c | 263 ++
3 files changed, 276 insertions(+), 1 deletion(-)
create mode 100644 drivers/nvmem/sc27xx-efuse.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 54a3c29..3dca608 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -181,4 +181,15 @@ config RAVE_SP_EEPROM
help
Say y here to enable Rave SP EEPROM support.
+config SC27XX_EFUSE
+ tristate "Spreadtrum SC27XX eFuse Support"
+ depends on MFD_SC27XX_PMIC || COMPILE_TEST
+ depends on HAS_IOMEM
+ help
+ This is a simple drive to dump specified values of Spreadtrum
+ SC27XX PMICs from eFuse.
+
+ This driver can also be built as a module. If so, the module
+ will be called nvmem-sc27xx-efuse.
+
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 27e96a8..4e8c616 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -39,4 +39,5 @@ obj-$(CONFIG_NVMEM_SNVS_LPGPR)+= nvmem_snvs_lpgpr.o
nvmem_snvs_lpgpr-y := snvs_lpgpr.o
obj-$(CONFIG_RAVE_SP_EEPROM) += nvmem-rave-sp-eeprom.o
nvmem-rave-sp-eeprom-y := rave-sp-eeprom.o
-
+obj-$(CONFIG_SC27XX_EFUSE) += nvmem-sc27xx-efuse.o
+nvmem-sc27xx-efuse-y := sc27xx-efuse.o
diff --git a/drivers/nvmem/sc27xx-efuse.c b/drivers/nvmem/sc27xx-efuse.c
new file mode 100644
index 000..07c210c
--- /dev/null
+++ b/drivers/nvmem/sc27xx-efuse.c
@@ -0,0 +1,263 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Spreadtrum Communications Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* PMIC global registers definition */
+#define SC27XX_MODULE_EN 0xc08
+#define SC27XX_EFUSE_ENBIT(6)
+
+/* Efuse controller registers definition */
+#define SC27XX_EFUSE_GLB_CTRL 0x0
+#define SC27XX_EFUSE_DATA_RD 0x4
+#define SC27XX_EFUSE_DATA_WR 0x8
+#define SC27XX_EFUSE_BLOCK_INDEX 0xc
+#define SC27XX_EFUSE_MODE_CTRL 0x10
+#define SC27XX_EFUSE_STATUS0x14
+#define SC27XX_EFUSE_WR_TIMING_CTRL0x20
+#define SC27XX_EFUSE_RD_TIMING_CTRL0x24
+#define SC27XX_EFUSE_EFUSE_DEB_CTRL0x28
+
+/* Mask definition for SC27XX_EFUSE_BLOCK_INDEX register */
+#define SC27XX_EFUSE_BLOCK_MASKGENMASK(4, 0)
+
+/* Bits definitions for SC27XX_EFUSE_MODE_CTRL register */
+#define SC27XX_EFUSE_PG_START BIT(0)
+#define SC27XX_EFUSE_RD_START BIT(1)
+#define SC27XX_EFUSE_CLR_RDDONEBIT(2)
+
+/* Bits definitions for SC27XX_EFUSE_STATUS register */
+#define SC27XX_EFUSE_PGM_BUSY BIT(0)
+#define SC27XX_EFUSE_READ_BUSY BIT(1)
+#define SC27XX_EFUSE_STANDBY BIT(2)
+#define SC27XX_EFUSE_GLOBAL_PROT BIT(3)
+#define SC27XX_EFUSE_RD_DONE BIT(4)
+
+/* Block number and block width (bytes) definitions */
+#define SC27XX_EFUSE_BLOCK_MAX 32
+#define SC27XX_EFUSE_BLOCK_WIDTH 2
+
+/* Timeout (ms) for the trylock of hardware spinlocks */
+#define SC27XX_EFUSE_HWLOCK_TIMEOUT5000
+
+/* Timeout (us) of polling the status */
+#define SC27XX_EFUSE_POLL_TIMEOUT 300
+#define SC27XX_EFUSE_POLL_DELAY_US 1
+
+struct sc27xx_efuse {
+ struct device *dev;
+ struct regmap *regmap;
+ struct hwspinlock *hwlock;
+ struct mutex mutex;
+ u32 base;
+};
+
+/*
+ * On Spreadtrum platform, we have multi-subsystems will access the unique
+ * efuse controller, so we need one hardware spinlock to synchronize between
+ * the multiple subsystems.
+ */
+static int sc27xx_efuse_lock(struct sc27xx_efuse *efuse)
+{
+ int ret;
+
+ mutex_lock(&efuse->mutex);
+
+ ret = hwspin_lock_timeout_raw(efuse->hwlock,
+ SC27XX_EFUSE_HWLOCK_TIMEOUT);
+ if (ret) {
+ dev_err(efuse->dev, "timeout to get the hwspinlock\n");
+ mutex_unlock(&efuse->mutex);
+ return ret;
+ }
+
+ return 0;
+}
+
+static void sc27xx_efuse_unlock(struct sc27xx_efuse *efuse)
+{
+ hwspin_unlock_raw(efuse->hwlock);
+ mutex_unlock(&efuse->mutex);
+}
+
+static int sc27xx_efuse_poll_status(struct sc27xx_efuse *efuse, u32 bits)
+{
+ int ret;
+ u32 val;
+
+ ret = regmap_read_poll_timeout(efuse->regmap,
+ efuse->base + SC27XX_EFUSE_STATUS,
+ val, (val & bits),
+ SC27XX_EFUSE_POLL_DELAY_US,
+ SC27XX_EFUSE_POLL_TIMEOUT);
+ if (ret
[PATCH 1/2] dt-bindings: nvmem: Add Spreadtrum SC27XX efuse controller documentation
This patch adds the binding documentation for Spreadtrum SC27XX series
PMICs efuse controller device.
Signed-off-by: Baolin Wang
---
.../devicetree/bindings/nvmem/sc27xx-efuse.txt | 52
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt
diff --git a/Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt
b/Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt
new file mode 100644
index 000..586c082
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/sc27xx-efuse.txt
@@ -0,0 +1,52 @@
+= Spreadtrum SC27XX PMIC eFuse device tree bindings =
+
+Required properties:
+- compatible: Should be one of the following.
+ "sprd,sc2720-efuse"
+ "sprd,sc2721-efuse"
+ "sprd,sc2723-efuse"
+ "sprd,sc2730-efuse"
+ "sprd,sc2731-efuse"
+- reg: Specify the address offset of efuse controller.
+- hwlocks: Reference to a phandle of a hwlock provider node.
+
+= Data cells =
+Are child nodes of eFuse, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+Example:
+
+ sc2731_pmic: pmic@0 {
+ compatible = "sprd,sc2731";
+ reg = <0>;
+ spi-max-frequency = <2600>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ efuse@380 {
+ compatible = "sprd,sc2731-efuse";
+ reg = <0x380>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ hwlocks = <&hwlock 12>;
+
+ /* Data cells */
+ thermal_calib: calib@10 {
+ reg = <0x10 0x2>;
+ };
+ };
+ };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+Example:
+
+ thermal {
+ ...
+ nvmem-cells = <&thermal_calib>;
+ nvmem-cell-names = "calibration";
+ };
--
1.7.9.5
Re: [PATCH] staging: lustre: add error handling for try_module_get
On Tue, Jun 12 2018, Zhouyang Jia wrote:
> When try_module_get fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling try_module_get.
>
> Signed-off-by: Zhouyang Jia
> ---
> drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
> b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
> index 7086678..72a42bd 100644
> --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
> +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
> @@ -2422,7 +2422,10 @@ ksocknal_base_startup(void)
>
> /* flag lists/ptrs/locks initialised */
> ksocknal_data.ksnd_init = SOCKNAL_INIT_DATA;
> - try_module_get(THIS_MODULE);
> + if (!try_module_get(THIS_MODULE)) {
> + CERROR("%s: cannot get module\n", __func__);
> + goto failed;
> + }
>
> ksocknal_data.ksnd_sched_info = cfs_percpt_alloc(lnet_cpt_table(),
>sizeof(*info));
Thanks for the patch
I agree that this is probably a bug, but the code is still buggy after
you patch, just in a different way.
Try following through the code and see what happens when you 'goto
failed'.
NeilBrown
signature.asc
Description: PGP signature
[PATCH v2 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe
This is needed in case of PROBE_DEFER if IRQ resource is not yet ready.
Signed-off-by: Keerthy
---
Tested for GPIO Interrupts on da850-lcdk and keystone-k2g-evm boards.
No Changes in v2
drivers/gpio/gpio-davinci.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 987126c..861f35b 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -55,7 +55,7 @@ static inline struct davinci_gpio_regs __iomem
*irq2regs(struct irq_data *d)
return g;
}
-static int davinci_gpio_irq_setup(struct platform_device *pdev);
+static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq);
/*--*/
@@ -168,7 +168,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
{
static int ctrl_num, bank_base;
int gpio, bank, ret = 0;
- unsigned ngpio, nbank;
+ unsigned ngpio, nbank, bank_irq;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
struct device *dev = &pdev->dev;
@@ -209,6 +209,12 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
+ bank_irq = platform_get_irq(pdev, 0);
+ if (bank_irq < 0) {
+ dev_dbg(dev, "IRQ not populated\n");
+ return bank_irq;
+ }
+
snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
chips->chip.label = devm_kstrdup(dev, label, GFP_KERNEL);
if (!chips->chip.label)
@@ -243,7 +249,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
goto err;
platform_set_drvdata(pdev, chips);
- ret = davinci_gpio_irq_setup(pdev);
+ ret = davinci_gpio_irq_setup(pdev, bank_irq);
if (ret)
goto err;
@@ -452,16 +458,15 @@ static struct irq_chip
*keystone_gpio_get_irq_chip(unsigned int irq)
* (dm6446) can be set appropriately for GPIOV33 pins.
*/
-static int davinci_gpio_irq_setup(struct platform_device *pdev)
+static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq)
{
unsignedgpio, bank;
int irq;
int ret;
struct clk *clk;
u32 binten = 0;
- unsignedngpio, bank_irq;
+ unsignedngpio;
struct device *dev = &pdev->dev;
- struct resource *res;
struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
struct davinci_gpio_platform_data *pdata = dev->platform_data;
struct davinci_gpio_regs __iomem *g;
@@ -481,18 +486,6 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
gpio_get_irq_chip = (gpio_get_irq_chip_cb_t)match->data;
ngpio = pdata->ngpio;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!res) {
- dev_err(dev, "Invalid IRQ resource\n");
- return -EBUSY;
- }
-
- bank_irq = res->start;
-
- if (!bank_irq) {
- dev_err(dev, "Invalid IRQ resource\n");
- return -ENODEV;
- }
clk = devm_clk_get(dev, "gpio");
if (IS_ERR(clk)) {
--
1.9.1
Re: [PATCH 2/2] nvmem: Add Spreadtrum SC27XX efuse support
On 06/11/2018 10:24 PM, Baolin Wang wrote: > From: Freeman Liu > > This patch add the efuse driver which is embeded in Spreadtrum SC27XX > series PMICs. The sc27xx efuse contains 32 blocks and each block's > data width is 16 bits. > > Signed-off-by: Freeman Liu > Signed-off-by: Baolin Wang > --- > drivers/nvmem/Kconfig| 11 ++ > drivers/nvmem/Makefile |3 +- > drivers/nvmem/sc27xx-efuse.c | 263 > ++ > 3 files changed, 276 insertions(+), 1 deletion(-) > create mode 100644 drivers/nvmem/sc27xx-efuse.c > > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig > index 54a3c29..3dca608 100644 > --- a/drivers/nvmem/Kconfig > +++ b/drivers/nvmem/Kconfig > @@ -181,4 +181,15 @@ config RAVE_SP_EEPROM > help > Say y here to enable Rave SP EEPROM support. > > +config SC27XX_EFUSE > + tristate "Spreadtrum SC27XX eFuse Support" > + depends on MFD_SC27XX_PMIC || COMPILE_TEST > + depends on HAS_IOMEM > + help > + This is a simple drive to dump specified values of Spreadtrum driver > + SC27XX PMICs from eFuse. > + > + This driver can also be built as a module. If so, the module > + will be called nvmem-sc27xx-efuse. > + > endif -- ~Randy
[PATCH v2 2/2] gpio: davinci: Do not assume continuous IRQ numbering
Currently the driver assumes that the interrupts are continuous
and does platform_get_irq only once and assumes the rest are continuous,
instead call platform_get_irq for all the interrupts and store them
in an array for later use.
Signed-off-by: Keerthy
---
Tested for GPIO Interrupts on da850-lcdk and keystone-k2g-evm boards.
Changes in v2:
* Extended the logic of using saved IRQs to unbanked IRQs
as per Grygorii's suggestion.
drivers/gpio/gpio-davinci.c| 53 +++---
include/linux/platform_data/gpio-davinci.h | 3 +-
2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 861f35b..b2119c0 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -55,7 +55,7 @@ static inline struct davinci_gpio_regs __iomem
*irq2regs(struct irq_data *d)
return g;
}
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq);
+static int davinci_gpio_irq_setup(struct platform_device *pdev);
/*--*/
@@ -168,7 +168,8 @@ static int davinci_gpio_probe(struct platform_device *pdev)
{
static int ctrl_num, bank_base;
int gpio, bank, ret = 0;
- unsigned ngpio, nbank, bank_irq;
+ unsigned int ngpio, nbank, nirq;
+ int i;
struct davinci_gpio_controller *chips;
struct davinci_gpio_platform_data *pdata;
struct device *dev = &pdev->dev;
@@ -197,6 +198,16 @@ static int davinci_gpio_probe(struct platform_device *pdev)
if (WARN_ON(ARCH_NR_GPIOS < ngpio))
ngpio = ARCH_NR_GPIOS;
+ /*
+* If there are unbanked interrupts then the number of
+* interrupts is equal to number of gpios else all are banked so
+* number of interrupts is equal to number of banks(each with 16 gpios)
+*/
+ if (pdata->gpio_unbanked)
+ nirq = pdata->gpio_unbanked;
+ else
+ nirq = DIV_ROUND_UP(ngpio, 16);
+
nbank = DIV_ROUND_UP(ngpio, 32);
chips = devm_kzalloc(dev,
nbank * sizeof(struct davinci_gpio_controller),
@@ -209,10 +220,13 @@ static int davinci_gpio_probe(struct platform_device
*pdev)
if (IS_ERR(gpio_base))
return PTR_ERR(gpio_base);
- bank_irq = platform_get_irq(pdev, 0);
- if (bank_irq < 0) {
- dev_dbg(dev, "IRQ not populated\n");
- return bank_irq;
+ for (i = 0; i < nirq; i++) {
+ chips->irqs[i] = platform_get_irq(pdev, i);
+ if (chips->irqs[i] < 0) {
+ dev_info(dev, "IRQ not populated, err = %d\n",
+chips->irqs[i]);
+ return chips->irqs[i];
+ }
}
snprintf(label, MAX_LABEL_SIZE, "davinci_gpio.%d", ctrl_num++);
@@ -249,7 +263,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
goto err;
platform_set_drvdata(pdev, chips);
- ret = davinci_gpio_irq_setup(pdev, bank_irq);
+ ret = davinci_gpio_irq_setup(pdev);
if (ret)
goto err;
@@ -383,7 +397,7 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip,
unsigned offset)
* can provide direct-mapped IRQs to AINTC (up to 32 GPIOs).
*/
if (offset < d->gpio_unbanked)
- return d->base_irq + offset;
+ return d->irqs[offset];
else
return -ENODEV;
}
@@ -396,7 +410,7 @@ static int gpio_irq_type_unbanked(struct irq_data *data,
unsigned trigger)
d = (struct davinci_gpio_controller
*)irq_data_get_irq_handler_data(data);
g = (struct davinci_gpio_regs __iomem *)d->regs[0];
- mask = __gpio_mask(data->irq - d->base_irq);
+ mask = __gpio_mask(data->irq - d->irqs[0]);
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -458,7 +472,7 @@ static struct irq_chip *keystone_gpio_get_irq_chip(unsigned
int irq)
* (dm6446) can be set appropriately for GPIOV33 pins.
*/
-static int davinci_gpio_irq_setup(struct platform_device *pdev, int bank_irq)
+static int davinci_gpio_irq_setup(struct platform_device *pdev)
{
unsignedgpio, bank;
int irq;
@@ -492,6 +506,7 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev, int bank_irq)
dev_err(dev, "Error %ld getting gpio clock\n", PTR_ERR(clk));
return PTR_ERR(clk);
}
+
ret = clk_prepare_enable(clk);
if (ret)
return ret;
@@ -531,12 +546,11 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev, int bank_irq)
if (pdata->gpio_unbanked) {
/* pass "bank 0" GPIO IRQs to AINTC */
chips->chip.to_irq = gpio_to_irq_unbanked;
-
Re: [PATCH] fsnotify: add error handling for kmem_cache_create
On Tue, Jun 12, 2018 at 7:16 AM, Zhouyang Jia wrote:
> When kmem_cache_create fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling kmem_cache_create.
>
> Signed-off-by: Zhouyang Jia
> ---
> fs/notify/dnotify/dnotify.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/fs/notify/dnotify/dnotify.c b/fs/notify/dnotify/dnotify.c
> index 63a1ca4..216b411 100644
> --- a/fs/notify/dnotify/dnotify.c
> +++ b/fs/notify/dnotify/dnotify.c
> @@ -387,6 +387,9 @@ static int __init dnotify_init(void)
> dnotify_struct_cache = KMEM_CACHE(dnotify_struct, SLAB_PANIC);
> dnotify_mark_cache = KMEM_CACHE(dnotify_mark, SLAB_PANIC);
>
> + if (!dnotify_struct_cache || !dnotify_mark_cache)
> + return -ENOMEM;
> +
If only one failed need to free the other.
> dnotify_group = fsnotify_alloc_group(&dnotify_fsnotify_ops);
> if (IS_ERR(dnotify_group))
> panic("unable to allocate fsnotify group for dnotify\n");
> --
> 2.7.4
>
RE: [PATCH] Input: add error handling for da9052_reg_write
On 11 June 2018 18:30 wrote Dmitry Torokhov
> Subject: Re: [PATCH] Input: add error handling for da9052_reg_write
>
> Hi Zhouyang,
>
> On Mon, Jun 11, 2018 at 01:23:39PM +0800, Zhouyang Jia wrote:
> > When da9052_reg_write fails, the lack of error-handling code may
> > cause unexpected results.
> >
> > This patch adds error-handling code after calling da9052_reg_write.
> >
> > Signed-off-by: Zhouyang Jia
> > ---
> > drivers/input/touchscreen/da9052_tsi.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/input/touchscreen/da9052_tsi.c
> b/drivers/input/touchscreen/da9052_tsi.c
> > index b5dfd594..60c82a0 100644
> > --- a/drivers/input/touchscreen/da9052_tsi.c
> > +++ b/drivers/input/touchscreen/da9052_tsi.c
> > @@ -319,8 +319,11 @@ static int da9052_ts_probe(struct platform_device
> > *pdev)
> > static int da9052_ts_remove(struct platform_device *pdev)
> > {
> > struct da9052_tsi *tsi = platform_get_drvdata(pdev);
> > + int error;
> >
> > - da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19);
> > + error = da9052_reg_write(tsi->da9052, DA9052_LDO9_REG, 0x19);
> > + if (error < 0)
> > + return error;
>
> No, this does not help anything. The remove() action must not fail
> (really, having it return an int and not void was an API mistake made
> long time ago), and thus returning early in and event of error failing
> to communicate with the device is a mistake. You really want to release
> the interrupts and memory and unregister input device before returning.
>
> >
> > da9052_free_irq(tsi->da9052, DA9052_IRQ_TSIREADY, tsi);
> > da9052_free_irq(tsi->da9052, DA9052_IRQ_PENDOWN, tsi);
> > --
> > 2.7.4
> >
script?
https://patchwork.kernel.org/project/LKML/list/?submitter=181001
Re: [PATCH] fanotify: add error handling for kmem_cache_create
On Tue, Jun 12, 2018 at 7:19 AM, Zhouyang Jia wrote:
> When kmem_cache_create fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling kmem_cache_create.
>
> Signed-off-by: Zhouyang Jia
> ---
> fs/notify/fanotify/fanotify_user.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/fs/notify/fanotify/fanotify_user.c
> b/fs/notify/fanotify/fanotify_user.c
> index ec4d8c5..e3fa861 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -959,9 +959,14 @@ static int __init fanotify_user_setup(void)
> {
> fanotify_mark_cache = KMEM_CACHE(fsnotify_mark, SLAB_PANIC);
> fanotify_event_cachep = KMEM_CACHE(fanotify_event_info, SLAB_PANIC);
> + if (!fanotify_mark_cache || !fanotify_event_cachep)
> + return -ENOMEM;
If only one failed need to free the other.
> +
> if (IS_ENABLED(CONFIG_FANOTIFY_ACCESS_PERMISSIONS)) {
> fanotify_perm_event_cachep =
> KMEM_CACHE(fanotify_perm_event_info, SLAB_PANIC);
> + if (!fanotify_perm_event_cachep)
> + return -ENOMEM;
here as well.
best implement as goto fail
> }
>
> return 0;
fail:
if (fanotify_mark_cache)
kmem_cache_destroy(fanotify_mark_cache);
...
return -ENOMEM;
Thanks,
Amir.
Re: [PATCH v3 5/7] dt-bindings: power: Add qcom rpmh power domain driver bindings
On Mon 11 Jun 21:40 PDT 2018, Rajendra Nayak wrote:
> Add DT bindings to describe the rpmh powerdomains found on Qualcomm
> Technologies, Inc. SoCs. These power domains communicate a performance
> state to RPMh, which then translates it into corresponding voltage on
> a PMIC rail.
>
> Signed-off-by: Rajendra Nayak
> ---
> .../devicetree/bindings/power/qcom,rpmhpd.txt | 65 +++
> 1 file changed, 65 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>
> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
> b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
> new file mode 100644
> index ..41ef7afa6b24
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
> @@ -0,0 +1,65 @@
> +Qualcomm RPMh Power domains
> +
> +For RPMh Power domains, we communicate a performance state to RPMh
> +which then translates it into a corresponding voltage on a rail
> +
> +Required Properties:
> + - compatible: Should be one of the following
> + * qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
Afaict this binding is identical to the one introduced in patch 1, so I
would suggest that you just add the compatible there.
Regards,
Bjorn
> + - power-domain-cells: number of cells in power domain specifier
> + must be 1
> + - operating-points-v2: Phandle to the OPP table for the power-domain.
> + Refer to Documentation/devicetree/bindings/power/power_domain.txt
> + and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
> +
> +Example:
> +
> + rpmhpd: power-controller {
> + compatible = "qcom,sdm845-rpmhpd";
> + #power-domain-cells = <1>;
> + operating-points-v2 = <&rpmhpd_opp_table>;
> + };
> +
> + rpmhpd_opp_table: opp-table {
> + compatible = "operating-points-v2-qcom-level";
> +
> + rpmhpd_opp_ret: opp1 {
> + qcom-level = <16>;
> + };
> +
> + rpmhpd_opp_min_svs: opp2 {
> + qcom-level = <48>;
> + };
> +
> + rpmhpd_opp_low_svs: opp3 {
> + qcom-level = <64>;
> + };
> +
> + rpmhpd_opp_svs: opp4 {
> + qcom-level = <128>;
> + };
> +
> + rpmhpd_opp_svs_l1: opp5 {
> + qcom-level = <192>;
> + };
> +
> + rpmhpd_opp_nom: opp6 {
> + qcom-level = <256>;
> + };
> +
> + rpmhpd_opp_nom_l1: opp7 {
> + qcom-level = <320>;
> + };
> +
> + rpmhpd_opp_nom_l2: opp8 {
> + qcom-level = <336>;
> + };
> +
> + rpmhpd_opp_turbo: opp9 {
> + qcom-level = <384>;
> + };
> +
> + rpmhpd_opp_turbo_l1: opp10 {
> + qcom-level = <416>;
> + };
> + };
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
>
[PATCH 0/7] MIPS: intel: add initial support for Intel MIPS SoCs
This patch series is for adding the support for Intel MIPS interAptiv SoC GRX500 family. It includes CCF support, serial driver optimization and DTS modification. This patch series is applied on top of v4.17.1. Basic verification is performed on GRX500 board. Any comments on this would be appreciated. We propose merging this patch series into MIPS Linux tree. Hua Ma (1): MIPS: intel: Add initial support for Intel MIPS SoCs Songjun Wu (5): MIPS: dts: Add aliases node for lantiq danube serial tty: serial: lantiq: Always use readl()/writel() tty: serial: lantiq: Convert global lock to per device lock tty: serial: lantiq: Remove unneeded header includes and macros tty: serial: lantiq: Add CCF support Yixin Zhu (1): clk: intel: Add clock driver for GRX500 SoC .../devicetree/bindings/clock/intel,grx500-clk.txt | 46 ++ .../devicetree/bindings/serial/lantiq_asc.txt | 15 + arch/mips/Kbuild.platforms | 1 + arch/mips/Kconfig | 37 +- arch/mips/boot/dts/Makefile| 1 + arch/mips/boot/dts/intel-mips/Makefile | 3 + arch/mips/boot/dts/intel-mips/easy350_anywan.dts | 20 + arch/mips/boot/dts/intel-mips/xrx500.dtsi | 196 ++ arch/mips/boot/dts/lantiq/danube.dtsi | 6 +- arch/mips/configs/grx500_defconfig | 165 + .../asm/mach-intel-mips/cpu-feature-overrides.h| 61 ++ arch/mips/include/asm/mach-intel-mips/ioremap.h| 39 ++ arch/mips/include/asm/mach-intel-mips/irq.h| 17 + .../asm/mach-intel-mips/kernel-entry-init.h| 76 +++ arch/mips/include/asm/mach-intel-mips/spaces.h | 29 + arch/mips/include/asm/mach-intel-mips/war.h| 18 + arch/mips/intel-mips/Kconfig | 22 + arch/mips/intel-mips/Makefile | 3 + arch/mips/intel-mips/Platform | 11 + arch/mips/intel-mips/irq.c | 36 ++ arch/mips/intel-mips/prom.c| 184 ++ arch/mips/intel-mips/time.c| 56 ++ drivers/clk/Kconfig| 1 + drivers/clk/Makefile | 1 + drivers/clk/intel/Kconfig | 21 + drivers/clk/intel/Makefile | 7 + drivers/clk/intel/clk-cgu-api.c| 676 + drivers/clk/intel/clk-cgu-api.h| 120 drivers/clk/intel/clk-grx500.c | 236 +++ drivers/tty/serial/Kconfig | 2 +- drivers/tty/serial/lantiq.c| 415 - include/dt-bindings/clock/intel,grx500-clk.h | 61 ++ 32 files changed, 2418 insertions(+), 164 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/intel,grx500-clk.txt create mode 100644 arch/mips/boot/dts/intel-mips/Makefile create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi create mode 100644 arch/mips/configs/grx500_defconfig create mode 100644 arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h create mode 100644 arch/mips/include/asm/mach-intel-mips/ioremap.h create mode 100644 arch/mips/include/asm/mach-intel-mips/irq.h create mode 100644 arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h create mode 100644 arch/mips/include/asm/mach-intel-mips/spaces.h create mode 100644 arch/mips/include/asm/mach-intel-mips/war.h create mode 100644 arch/mips/intel-mips/Kconfig create mode 100644 arch/mips/intel-mips/Makefile create mode 100644 arch/mips/intel-mips/Platform create mode 100644 arch/mips/intel-mips/irq.c create mode 100644 arch/mips/intel-mips/prom.c create mode 100644 arch/mips/intel-mips/time.c create mode 100644 drivers/clk/intel/Kconfig create mode 100644 drivers/clk/intel/Makefile create mode 100644 drivers/clk/intel/clk-cgu-api.c create mode 100644 drivers/clk/intel/clk-cgu-api.h create mode 100644 drivers/clk/intel/clk-grx500.c create mode 100644 include/dt-bindings/clock/intel,grx500-clk.h -- 2.11.0
[PATCH 2/7] clk: intel: Add clock driver for GRX500 SoC
From: Yixin Zhu
PLL of GRX500 provide clock to DDR, CPU, and peripherals as show below
+-+
|--->| LCPLL3 0|--PCIe clk-->
XO |+-+
+---|
|+-+
||3|--PAE clk-->
|--->| PLL0B 2|--GSWIP clk-->
||1|--DDR clk-->DDR PHY clk-->
||0|--CPU1 clk--+ +-+
|+-+|--->0|
| | MUX |--CPU clk-->
|+-+|--->1|
||0|--CPU0 clk--+ +-+
|--->| PLLOA 1|--SSX4 clk-->
|2|--NGI clk-->
|3|--CBM clk-->
+-+
VCO of all PLLs of GRX500 is not supposed to be reprogrammed.
DDR PHY clock is created to show correct clock rate in software
point of view.
CPU clock of 1Ghz from PLL0B otherwise from PLL0A.
Signed-off-by: Yixin Zhu
Signed-off-by: Songjun Wu
---
.../devicetree/bindings/clock/intel,grx500-clk.txt | 46 ++
drivers/clk/Kconfig| 1 +
drivers/clk/Makefile | 1 +
drivers/clk/intel/Kconfig | 21 +
drivers/clk/intel/Makefile | 7 +
drivers/clk/intel/clk-cgu-api.c| 676 +
drivers/clk/intel/clk-cgu-api.h| 120
drivers/clk/intel/clk-grx500.c | 236 +++
include/dt-bindings/clock/intel,grx500-clk.h | 61 ++
9 files changed, 1169 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
create mode 100644 drivers/clk/intel/Kconfig
create mode 100644 drivers/clk/intel/Makefile
create mode 100644 drivers/clk/intel/clk-cgu-api.c
create mode 100644 drivers/clk/intel/clk-cgu-api.h
create mode 100644 drivers/clk/intel/clk-grx500.c
create mode 100644 include/dt-bindings/clock/intel,grx500-clk.h
diff --git a/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
new file mode 100644
index ..dd761d900dc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/intel,grx500-clk.txt
@@ -0,0 +1,46 @@
+Device Tree Clock bindings for GRX500 PLL controller.
+
+This binding uses the common clock binding:
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+This GRX500 PLL controller provides the 5 main clock domain of the SoC:
CPU/DDR, XBAR,
+Voice, WLAN, PCIe and gate clocks for HW modules.
+
+Required properties for osc clock node
+- compatible: Should be intel,grx500-xxx-clk
+- reg: offset address of the controller memory area.
+- clocks: phandle of the external reference clock
+- #clock-cells: can be one or zero.
+- clock-output-names: Names of the output clocks.
+
+Example:
+ pll0aclk: pll0aclk {
+ #clock-cells = <1>;
+ compatible = "intel,grx500-pll0a-clk";
+ clocks = <&pll0a>;
+ reg = <0x8>;
+ clock-output-names = "cbmclk", "ngiclk", "ssx4clk", "cpu0clk";
+ };
+
+ cpuclk: cpuclk {
+ #clock-cells = <0>;
+ compatible = "intel,grx500-cpu-clk";
+ clocks = <&pll0aclk CPU0_CLK>, <&pll0bclk CPU1_CLK>;
+ reg = <0x8>;
+ clock-output-names = "cpu";
+ };
+
+Required properties for gate node:
+- compatible: Should be intel,grx500-gatex-clk
+- reg: offset address of the controller memory area.
+- #clock-cells: Should be <1>
+- clock-output-names: Names of the output clocks.
+
+Example:
+ clkgate0: clkgate0 {
+ #clock-cells = <1>;
+ compatible = "intel,grx500-gate0-clk";
+ reg = <0x114>;
+ clock-output-names = "gate_xbar0", "gate_xbar1", "gate_xbar2",
+ "gate_xbar3", "gate_xbar6", "gate_xbar7";
+ };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 34968a381d0f..9e2e19a1170a 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -280,6 +280,7 @@ config COMMON_CLK_STM32H7
source "drivers/clk/bcm/Kconfig"
source "drivers/clk/hisilicon/Kconfig"
source "drivers/clk/imgtec/Kconfig"
+source "drivers/clk/intel/Kconfig"
source "drivers/clk/keystone/Kconfig"
source "drivers/clk/mediatek/Kconfig"
source "drivers/clk/meson/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index de6d06ac790b..ef3e270005a1 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -105,3 +105,4 @@ obj-$(CONFIG_X86) += x86/
endif
obj-$(CONFIG_ARCH_ZX) += zte/
obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
+obj-$(CONFIG_COMMON_CLK_INTEL) += intel/
diff --git a/drivers/clk/intel/Kconfig b/drivers/clk/intel/Kconfig
new file mode 100644
index ..d40a92ae7462
--- /dev/null
+++ b/drive
[PATCH 1/7] MIPS: dts: Add aliases node for lantiq danube serial
Previous implementation uses a hard-coded register value to check if
the current serial entity is the console entity.
Now the lantiq serial driver uses the aliases for the index of the
serial port.
The lantiq danube serial dts are updated with aliases to support this.
Signed-off-by: Songjun Wu
---
arch/mips/boot/dts/lantiq/danube.dtsi | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/mips/boot/dts/lantiq/danube.dtsi
b/arch/mips/boot/dts/lantiq/danube.dtsi
index 2dd950181f8a..7a9e15da6bd0 100644
--- a/arch/mips/boot/dts/lantiq/danube.dtsi
+++ b/arch/mips/boot/dts/lantiq/danube.dtsi
@@ -4,6 +4,10 @@
#size-cells = <1>;
compatible = "lantiq,xway", "lantiq,danube";
+ aliases {
+ serial0 = &asc1;
+ };
+
cpus {
cpu@0 {
compatible = "mips,mips24Kc";
@@ -74,7 +78,7 @@
reg = <0xE100A00 0x100>;
};
- serial@E100C00 {
+ asc1: serial@E100C00 {
compatible = "lantiq,asc";
reg = <0xE100C00 0x400>;
interrupt-parent = <&icu0>;
--
2.11.0
[PATCH 6/7] tty: serial: lantiq: Remove unneeded header includes and macros
Update the author list with Intel Corporation. Sort the header includes in alphabetical orders. Remove unneeded header includes and macros. Signed-off-by: Songjun Wu --- drivers/tty/serial/lantiq.c | 29 +++-- 1 file changed, 11 insertions(+), 18 deletions(-) diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c index 72aab1b05265..cc33208c93ac 100644 --- a/drivers/tty/serial/lantiq.c +++ b/drivers/tty/serial/lantiq.c @@ -6,24 +6,23 @@ * Copyright (C) 2007 Felix Fietkau * Copyright (C) 2007 John Crispin * Copyright (C) 2010 Thomas Langer, + * Copyright (C) 2017 Intel Corporation. */ -#include -#include -#include +#include #include -#include #include -#include -#include -#include -#include +#include +#include +#include #include #include #include -#include -#include -#include +#include +#include +#include +#include +#include #include @@ -43,7 +42,6 @@ #define LTQ_ASC_STATE 0x0014 #define LTQ_ASC_IRNCR 0x00F8 #define LTQ_ASC_CLC0x -#define LTQ_ASC_ID 0x0008 #define LTQ_ASC_PISEL 0x0004 #define LTQ_ASC_TXFCON 0x0044 #define LTQ_ASC_RXFCON 0x0040 @@ -51,16 +49,12 @@ #define LTQ_ASC_BG 0x0050 #define LTQ_ASC_FDV0x0058 #define LTQ_ASC_IRNEN 0x00F4 - #define ASC_IRNREN_TX 0x1 #define ASC_IRNREN_RX 0x2 #define ASC_IRNREN_ERR 0x4 -#define ASC_IRNREN_TX_BUF 0x8 #define ASC_IRNCR_TIR 0x1 #define ASC_IRNCR_RIR 0x2 #define ASC_IRNCR_EIR 0x4 - -#define ASCOPT_CSIZE 0x3 #define TXFIFO_FL 1 #define RXFIFO_FL 1 #define ASCCLC_DISR0x1 @@ -71,7 +65,6 @@ #define ASCCON_M_7ASYNC0x2 #define ASCCON_ODD 0x0020 #define ASCCON_STP 0x0080 -#define ASCCON_BRS 0x0100 #define ASCCON_FDE 0x0200 #define ASCCON_R 0x8000 #define ASCCON_FEN 0x0002 @@ -80,7 +73,7 @@ #define ASCSTATE_PE0x0001 #define ASCSTATE_FE0x0002 #define ASCSTATE_ROE 0x0008 -#define ASCSTATE_ANY (ASCSTATE_ROE|ASCSTATE_PE|ASCSTATE_FE) +#define ASCSTATE_ANY (ASCSTATE_ROE | ASCSTATE_PE | ASCSTATE_FE) #define ASCWHBSTATE_CLRREN 0x0001 #define ASCWHBSTATE_SETREN 0x0002 #define ASCWHBSTATE_CLRPE 0x0004 -- 2.11.0
Re: [PATCH 2/2] nvmem: Add Spreadtrum SC27XX efuse support
Hi Randy, On 12 June 2018 at 13:27, Randy Dunlap wrote: > On 06/11/2018 10:24 PM, Baolin Wang wrote: >> From: Freeman Liu >> >> This patch add the efuse driver which is embeded in Spreadtrum SC27XX >> series PMICs. The sc27xx efuse contains 32 blocks and each block's >> data width is 16 bits. >> >> Signed-off-by: Freeman Liu >> Signed-off-by: Baolin Wang >> --- >> drivers/nvmem/Kconfig| 11 ++ >> drivers/nvmem/Makefile |3 +- >> drivers/nvmem/sc27xx-efuse.c | 263 >> ++ >> 3 files changed, 276 insertions(+), 1 deletion(-) >> create mode 100644 drivers/nvmem/sc27xx-efuse.c >> >> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig >> index 54a3c29..3dca608 100644 >> --- a/drivers/nvmem/Kconfig >> +++ b/drivers/nvmem/Kconfig >> @@ -181,4 +181,15 @@ config RAVE_SP_EEPROM >> help >> Say y here to enable Rave SP EEPROM support. >> >> +config SC27XX_EFUSE >> + tristate "Spreadtrum SC27XX eFuse Support" >> + depends on MFD_SC27XX_PMIC || COMPILE_TEST >> + depends on HAS_IOMEM >> + help >> + This is a simple drive to dump specified values of Spreadtrum > >driver Sorry for the typo and will fix in next version. Thanks. -- Baolin.wang Best Regards
[PATCH 7/7] tty: serial: lantiq: Add CCF support
Previous implementation uses platform-dependent API to get the clock.
Those functions are not available for other SoC which uses the same IP.
The CCF (Common Clock Framework) have an abstraction based APIs
for clock.
Change to use CCF APIs to get clock and rate.
So that different SoCs can use the same driver.
Clocks and clock-names are updated in device tree binding.
Signed-off-by: Songjun Wu
---
.../devicetree/bindings/serial/lantiq_asc.txt | 15 +++
drivers/tty/serial/Kconfig | 2 +-
drivers/tty/serial/lantiq.c| 101 +
3 files changed, 98 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
index 3acbd309ab9d..608f0c87a4af 100644
--- a/Documentation/devicetree/bindings/serial/lantiq_asc.txt
+++ b/Documentation/devicetree/bindings/serial/lantiq_asc.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier
depends on the interrupt-parent interrupt controller.
+Optional properties:
+- clocks: Should contain frequency clock and gate clock
+- clock-names: Should be "freq" and "asc"
+
Example:
asc1: serial@e100c00 {
@@ -14,3 +18,14 @@ asc1: serial@e100c00 {
interrupt-parent = <&icu0>;
interrupts = <112 113 114>;
};
+
+asc0: serial@60 {
+ compatible = "lantiq,asc";
+ reg = <0x60 0x10>;
+ interrupt-parent = <&gic>;
+ interrupts = ,
+ ,
+ ;
+ clocks = <&pll0aclk SSX4_CLK>, <&clkgate1 GATE_URT_CLK>;
+ clock-names = "freq", "asc";
+};
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 0f058df0b070..0f8ac5872a54 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1062,7 +1062,7 @@ config SERIAL_OMAP_CONSOLE
config SERIAL_LANTIQ
bool "Lantiq serial driver"
- depends on LANTIQ
+ depends on LANTIQ || INTEL_MIPS || COMPILE_TEST
select SERIAL_CORE
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index cc33208c93ac..fd7ba89daaa2 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -24,7 +24,9 @@
#include
#include
+#ifndef CONFIG_COMMON_CLK
#include
+#endif
#define PORT_LTQ_ASC 111
#define MAXPORTS 2
@@ -104,7 +106,7 @@ static struct uart_driver lqasc_reg;
struct ltq_uart_port {
struct uart_portport;
/* clock used to derive divider */
- struct clk *fpiclk;
+ struct clk *freqclk;
/* clock gating of the ASC core */
struct clk *clk;
unsigned inttx_irq;
@@ -120,7 +122,6 @@ static inline struct ltq_uart_port *to_ltq_uart_port(struct
uart_port *port)
static void lqasc_stop_tx(struct uart_port *port)
{
- return;
}
static void lqasc_start_tx(struct uart_port *port)
@@ -291,8 +292,7 @@ static unsigned int lqasc_tx_empty(struct uart_port *port)
return status ? 0 : TIOCSER_TEMT;
}
-static unsigned int
-lqasc_get_mctrl(struct uart_port *port)
+static unsigned int lqasc_get_mctrl(struct uart_port *port)
{
return TIOCM_CTS | TIOCM_CAR | TIOCM_DSR;
}
@@ -301,21 +301,65 @@ static void lqasc_set_mctrl(struct uart_port *port, u_int
mctrl)
{
}
-static void
-lqasc_break_ctl(struct uart_port *port, int break_state)
+static void lqasc_break_ctl(struct uart_port *port, int break_state)
{
}
-static int
-lqasc_startup(struct uart_port *port)
+static void lqasc_fdv_and_reload_get(struct ltq_uart_port *ltq_port,
+unsigned int baudrate, unsigned int *fdv,
+unsigned int *reload)
+{
+ unsigned int asc_clk = clk_get_rate(ltq_port->freqclk);
+ unsigned int baudrate1 = baudrate * 8192;
+ unsigned long long baudrate2 = (unsigned long long)baudrate * 1000;
+ unsigned long long fdv_over_bg_fpi;
+ unsigned long long fdv_over_bg;
+ unsigned long long difference;
+ unsigned long long min_difference;
+ unsigned int bg;
+
+ /* Sanity check first */
+ if (baudrate >= (asc_clk >> 4)) {
+ pr_err("%s current fpi clock %u can't provide baudrate %u!!!\n",
+ __func__, asc_clk, baudrate);
+ return;
+ }
+
+ min_difference = UINT_MAX;
+ fdv_over_bg_fpi = baudrate1;
+
+ for (bg = 1; bg <= 8192; bg++, fdv_over_bg_fpi += baudrate1) {
+ fdv_over_bg = fdv_over_bg_fpi + asc_clk / 2;
+ do_div(fdv_over_bg, asc_clk);
+ if (fdv_over_bg <= 512) {
+ difference = fdv_over_bg * asc_clk * 1000;
+ do_div(difference, 8192 * bg);
+ if (difference < baudrate2)
+
[PATCH 3/7] MIPS: intel: Add initial support for Intel MIPS SoCs
From: Hua Ma Add initial support for Intel MIPS interAptiv SoCs made by Intel. This series will add support for the GRX500 family. The series allows booting a minimal system using a initramfs. Signed-off-by: Hua ma Signed-off-by: Songjun Wu --- arch/mips/Kbuild.platforms | 1 + arch/mips/Kconfig | 36 arch/mips/boot/dts/Makefile| 1 + arch/mips/boot/dts/intel-mips/Makefile | 3 + arch/mips/boot/dts/intel-mips/easy350_anywan.dts | 20 +++ arch/mips/boot/dts/intel-mips/xrx500.dtsi | 196 + arch/mips/configs/grx500_defconfig | 165 + .../asm/mach-intel-mips/cpu-feature-overrides.h| 61 +++ arch/mips/include/asm/mach-intel-mips/ioremap.h| 39 arch/mips/include/asm/mach-intel-mips/irq.h| 17 ++ .../asm/mach-intel-mips/kernel-entry-init.h| 76 arch/mips/include/asm/mach-intel-mips/spaces.h | 29 +++ arch/mips/include/asm/mach-intel-mips/war.h| 18 ++ arch/mips/intel-mips/Kconfig | 22 +++ arch/mips/intel-mips/Makefile | 3 + arch/mips/intel-mips/Platform | 11 ++ arch/mips/intel-mips/irq.c | 36 arch/mips/intel-mips/prom.c| 184 +++ arch/mips/intel-mips/time.c| 56 ++ 19 files changed, 974 insertions(+) create mode 100644 arch/mips/boot/dts/intel-mips/Makefile create mode 100644 arch/mips/boot/dts/intel-mips/easy350_anywan.dts create mode 100644 arch/mips/boot/dts/intel-mips/xrx500.dtsi create mode 100644 arch/mips/configs/grx500_defconfig create mode 100644 arch/mips/include/asm/mach-intel-mips/cpu-feature-overrides.h create mode 100644 arch/mips/include/asm/mach-intel-mips/ioremap.h create mode 100644 arch/mips/include/asm/mach-intel-mips/irq.h create mode 100644 arch/mips/include/asm/mach-intel-mips/kernel-entry-init.h create mode 100644 arch/mips/include/asm/mach-intel-mips/spaces.h create mode 100644 arch/mips/include/asm/mach-intel-mips/war.h create mode 100644 arch/mips/intel-mips/Kconfig create mode 100644 arch/mips/intel-mips/Makefile create mode 100644 arch/mips/intel-mips/Platform create mode 100644 arch/mips/intel-mips/irq.c create mode 100644 arch/mips/intel-mips/prom.c create mode 100644 arch/mips/intel-mips/time.c diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms index ac7ad54f984f..bcd647060f3e 100644 --- a/arch/mips/Kbuild.platforms +++ b/arch/mips/Kbuild.platforms @@ -12,6 +12,7 @@ platforms += cobalt platforms += dec platforms += emma platforms += generic +platforms += intel-mips platforms += jazz platforms += jz4740 platforms += lantiq diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 225c95da23ce..c82cebeb6192 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -404,6 +404,41 @@ config LANTIQ select ARCH_HAS_RESET_CONTROLLER select RESET_CONTROLLER +config INTEL_MIPS + bool "Intel MIPS interAptiv SoC based platforms" + select ARCH_HAS_RESET_CONTROLLER + select ARCH_SUPPORTS_MSI + select BOOT_RAW + select CEVT_R4K + select COMMON_CLK + select CPU_MIPS32_3_5_EVA + select CPU_MIPS32_3_5_FEATURES + select CPU_MIPSR2_IRQ_EI + select CPU_MIPSR2_IRQ_VI + select CSRC_R4K + select DMA_NONCOHERENT + select GENERIC_ISA_DMA + select GPIOLIB + select HW_HAS_PCI + select IRQ_MIPS_CPU + select MFD_CORE + select MFD_SYSCON + select MIPS_CPU_SCACHE + select MIPS_GIC + select PCI_DRIVERS_GENERIC + select RESET_CONTROLLER + select SYS_HAS_CPU_MIPS32_R1 + select SYS_HAS_CPU_MIPS32_R2 + select SYS_HAS_CPU_MIPS32_R3_5 + select SYS_HAS_EARLY_PRINTK + select SYS_SUPPORTS_BIG_ENDIAN + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_MIPS_CPS + select SYS_SUPPORTS_MULTITHREADING + select SYS_SUPPORTS_ZBOOT + select TIMER_OF + select USE_OF + config LASAT bool "LASAT Networks platforms" select CEVT_R4K @@ -1010,6 +1045,7 @@ source "arch/mips/bcm47xx/Kconfig" source "arch/mips/bcm63xx/Kconfig" source "arch/mips/bmips/Kconfig" source "arch/mips/generic/Kconfig" +source "arch/mips/intel-mips/Kconfig" source "arch/mips/jazz/Kconfig" source "arch/mips/jz4740/Kconfig" source "arch/mips/lantiq/Kconfig" diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile index 1e79cab8e269..05f52f279047 100644 --- a/arch/mips/boot/dts/Makefile +++ b/arch/mips/boot/dts/Makefile @@ -3,6 +3,7 @@ subdir-y+= brcm subdir-y += cavium-octeon subdir-y += img subdir-y += ingenic +subdir-y += intel-mips subdir-y += lantiq subdir-y += mscc subdir-y += mti diff --git a/arch/mips/boot/dts/in
[PATCH 5/7] tty: serial: lantiq: Convert global lock to per device lock
Previous implementation uses one global lock to protect the resource.
If the serial driver have multiple entries, this kind of lock will
slow down the performance.
Add the lock at device level. This will lock only when the function
calling only to the same device.
So that it can avoid useless lock protection.
Signed-off-by: Songjun Wu
---
drivers/tty/serial/lantiq.c | 51 ++---
1 file changed, 34 insertions(+), 17 deletions(-)
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 1127586dbc94..72aab1b05265 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -107,7 +107,6 @@
static void lqasc_tx_chars(struct uart_port *port);
static struct ltq_uart_port *lqasc_port[MAXPORTS];
static struct uart_driver lqasc_reg;
-static DEFINE_SPINLOCK(ltq_asc_lock);
struct ltq_uart_port {
struct uart_portport;
@@ -118,6 +117,7 @@ struct ltq_uart_port {
unsigned inttx_irq;
unsigned intrx_irq;
unsigned interr_irq;
+ spinlock_t lock; /* exclusive access for multi core */
};
static inline struct ltq_uart_port *to_ltq_uart_port(struct uart_port *port)
@@ -133,10 +133,11 @@ static void lqasc_stop_tx(struct uart_port *port)
static void lqasc_start_tx(struct uart_port *port)
{
unsigned long flags;
- spin_lock_irqsave(lock, flags);
lqasc_tx_chars(port);
- spin_unlock_irqrestore(lock, flags);
}
static void lqasc_stop_rx(struct uart_port *port)
@@ -238,10 +239,14 @@ static irqreturn_t lqasc_tx_int(int irq, void *_port)
{
unsigned long flags;
struct uart_port *port = (struct uart_port *)_port;
- spin_lock_irqsave(lock, flags);
writel(ASC_IRNCR_TIR, port->membase + LTQ_ASC_IRNCR);
- spin_unlock_irqrestore(lock, flags);
+
lqasc_start_tx(port);
+
return IRQ_HANDLED;
}
@@ -250,8 +255,9 @@ static irqreturn_t lqasc_err_int(int irq, void *_port)
unsigned long flags;
u32 stat;
struct uart_port *port = (struct uart_port *)_port;
+ struct ltq_uart_port *ltq_port = to_ltq_uart_port(port);
- spin_lock_irqsave(lock, flags);
/* clear any pending interrupts */
writel(ASC_IRNCR_EIR, port->membase + LTQ_ASC_IRNCR);
stat = readl(port->membase + LTQ_ASC_STATE);
@@ -266,7 +272,7 @@ static irqreturn_t lqasc_err_int(int irq, void *_port)
port->icount.overrun++;
}
asc_w32_mask(0, ASCWHBSTATE_CLRALL, port->membase + LTQ_ASC_WHBSTATE);
- spin_unlock_irqrestore(lock, flags);
return IRQ_HANDLED;
}
@@ -275,10 +281,13 @@ static irqreturn_t lqasc_rx_int(int irq, void *_port)
{
unsigned long flags;
struct uart_port *port = (struct uart_port *)_port;
- spin_lock_irqsave(lock, flags);
writel(ASC_IRNCR_RIR, port->membase + LTQ_ASC_IRNCR);
lqasc_rx_chars(port);
- spin_unlock_irqrestore(lock, flags);
+
return IRQ_HANDLED;
}
@@ -309,11 +318,13 @@ lqasc_startup(struct uart_port *port)
{
struct ltq_uart_port *ltq_port = to_ltq_uart_port(port);
int retval;
+ unsigned long flags;
if (!IS_ERR(ltq_port->clk))
clk_enable(ltq_port->clk);
port->uartclk = clk_get_rate(ltq_port->fpiclk);
+ spin_lock_irqsave(lock, flags);
asc_w32_mask(ASCCLC_DISS | ASCCLC_RMCMASK, (1 << ASCCLC_RMCOFFSET),
port->membase + LTQ_ASC_CLC);
@@ -330,6 +341,7 @@ lqasc_startup(struct uart_port *port)
wmb();
asc_w32_mask(0, ASCCON_M_8ASYNC | ASCCON_FEN | ASCCON_TOEN |
ASCCON_ROEN, port->membase + LTQ_ASC_CON);
+ spin_unlock_irqrestore(lock, flags);
retval = request_irq(ltq_port->tx_irq, lqasc_tx_int,
0, "asc_tx", port);
@@ -410,6 +422,7 @@ static void lqasc_set_termios(struct uart_port *port,
unsigned long flags;
u32 fdv = 0;
u32 reload = 0;
+ struct ltq_uart_port *ltq_port = to_ltq_uart_port(port);
cflag = new->c_cflag;
iflag = new->c_iflag;
@@ -463,7 +476,7 @@ static void lqasc_set_termios(struct uart_port *port,
/* set error signals - framing,
[PATCH 4/7] tty: serial: lantiq: Always use readl()/writel()
Previous implementation uses platform-dependent functions
ltq_w32()/ltq_r32() to access registers. Those functions are not
available for other SoC which uses the same IP.
Change to OS provided readl()/writel() and readb()/writeb(), so
that different SoCs can use the same driver.
Signed-off-by: Songjun Wu
---
arch/mips/Kconfig | 1 -
drivers/tty/serial/lantiq.c | 236
2 files changed, 128 insertions(+), 109 deletions(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index c82cebeb6192..7bae259edd0b 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -395,7 +395,6 @@ config LANTIQ
select SYS_SUPPORTS_VPE_LOADER
select SYS_HAS_EARLY_PRINTK
select GPIOLIB
- select SWAP_IO_SPACE
select BOOT_RAW
select CLKDEV_LOOKUP
select USE_OF
diff --git a/drivers/tty/serial/lantiq.c b/drivers/tty/serial/lantiq.c
index 044128277248..1127586dbc94 100644
--- a/drivers/tty/serial/lantiq.c
+++ b/drivers/tty/serial/lantiq.c
@@ -49,7 +49,8 @@
#define LTQ_ASC_RXFCON 0x0040
#define LTQ_ASC_CON0x0010
#define LTQ_ASC_BG 0x0050
-#define LTQ_ASC_IRNREN 0x00F4
+#define LTQ_ASC_FDV0x0058
+#define LTQ_ASC_IRNEN 0x00F4
#define ASC_IRNREN_TX 0x1
#define ASC_IRNREN_RX 0x2
@@ -62,6 +63,7 @@
#define ASCOPT_CSIZE 0x3
#define TXFIFO_FL 1
#define RXFIFO_FL 1
+#define ASCCLC_DISR0x1
#define ASCCLC_DISS0x2
#define ASCCLC_RMCMASK 0xFF00
#define ASCCLC_RMCOFFSET 8
@@ -84,6 +86,7 @@
#define ASCWHBSTATE_CLRPE 0x0004
#define ASCWHBSTATE_CLRFE 0x0008
#define ASCWHBSTATE_CLRROE 0x0020
+#define ASCWHBSTATE_CLRALL 0x00FC
#define ASCTXFCON_TXFEN0x0001
#define ASCTXFCON_TXFFLU 0x0002
#define ASCTXFCON_TXFITLMASK 0x3F00
@@ -97,6 +100,10 @@
#define ASCFSTAT_TXFREEMASK0x3F00
#define ASCFSTAT_TXFREEOFF 24
+#define asc_w32_mask(clear, set, reg) \
+ ({ typeof(reg) reg_ = (reg);\
+ writel((readl(reg_) & ~(clear)) | (set), reg_); })
+
static void lqasc_tx_chars(struct uart_port *port);
static struct ltq_uart_port *lqasc_port[MAXPORTS];
static struct uart_driver lqasc_reg;
@@ -113,20 +120,17 @@ struct ltq_uart_port {
unsigned interr_irq;
};
-static inline struct
-ltq_uart_port *to_ltq_uart_port(struct uart_port *port)
+static inline struct ltq_uart_port *to_ltq_uart_port(struct uart_port *port)
{
return container_of(port, struct ltq_uart_port, port);
}
-static void
-lqasc_stop_tx(struct uart_port *port)
+static void lqasc_stop_tx(struct uart_port *port)
{
return;
}
-static void
-lqasc_start_tx(struct uart_port *port)
+static void lqasc_start_tx(struct uart_port *port)
{
unsigned long flags;
spin_lock_irqsave(membase + LTQ_ASC_WHBSTATE);
+ writel(ASCWHBSTATE_CLRREN, port->membase + LTQ_ASC_WHBSTATE);
}
-static int
-lqasc_rx_chars(struct uart_port *port)
+static int lqasc_rx_chars(struct uart_port *port)
{
struct tty_port *tport = &port->state->port;
unsigned int ch = 0, rsr = 0, fifocnt;
- fifocnt = ltq_r32(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_RXFFLMASK;
+ fifocnt = readl(port->membase + LTQ_ASC_FSTAT) & ASCFSTAT_RXFFLMASK;
while (fifocnt--) {
u8 flag = TTY_NORMAL;
- ch = ltq_r8(port->membase + LTQ_ASC_RBUF);
- rsr = (ltq_r32(port->membase + LTQ_ASC_STATE)
+ ch = readb(port->membase + LTQ_ASC_RBUF);
+ rsr = (readl(port->membase + LTQ_ASC_STATE)
& ASCSTATE_ANY) | UART_DUMMY_UER_RX;
tty_flip_buffer_push(tport);
port->icount.rx++;
@@ -163,16 +165,16 @@ lqasc_rx_chars(struct uart_port *port)
if (rsr & ASCSTATE_ANY) {
if (rsr & ASCSTATE_PE) {
port->icount.parity++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRPE,
+ asc_w32_mask(0, ASCWHBSTATE_CLRPE,
port->membase + LTQ_ASC_WHBSTATE);
} else if (rsr & ASCSTATE_FE) {
port->icount.frame++;
- ltq_w32_mask(0, ASCWHBSTATE_CLRFE,
+ asc_w32_mask(0, ASCWHBSTATE_CLRFE,
port->membase + LTQ_ASC_WHBSTATE);
}
if (rsr & ASCSTATE_ROE) {
port->icount.overrun++;
-
uapi headers userspace build results
Hi, Here is what I have so far. It begins with a makefile and some template files that are added to. There's a good bit of Perl also. I put all of these files in tools/uapi/ and run them from there. There is one .c file generated for each .h file in builddir/usr/include (O=builddir). Out of 889 header files, I see 45 errors. That is better than I expected. The makefiles and scripts are attached (tar), as well as the output (I used 'make -ik' so that make would keep going after errors and attempt to build all target files). have fun! -- ~Randy gcc "-I../../xx64/usr/include" -c -o drm.i810_drm.o drm.i810_drm.c gcc "-I../../xx64/usr/include" -c -o drm.drm_fourcc.o drm.drm_fourcc.c gcc "-I../../xx64/usr/include" -c -o drm.etnaviv_drm.o drm.etnaviv_drm.c gcc "-I../../xx64/usr/include" -c -o drm.i915_drm.o drm.i915_drm.c gcc "-I../../xx64/usr/include" -c -o drm.drm_mode.o drm.drm_mode.c gcc "-I../../xx64/usr/include" -c -o drm.vc4_drm.o drm.vc4_drm.c gcc "-I../../xx64/usr/include" -c -o drm.mga_drm.o drm.mga_drm.c gcc "-I../../xx64/usr/include" -c -o drm.v3d_drm.o drm.v3d_drm.c gcc "-I../../xx64/usr/include" -c -o drm.msm_drm.o drm.msm_drm.c gcc "-I../../xx64/usr/include" -c -o drm.amdgpu_drm.o drm.amdgpu_drm.c gcc "-I../../xx64/usr/include" -c -o drm.exynos_drm.o drm.exynos_drm.c gcc "-I../../xx64/usr/include" -c -o drm.sis_drm.o drm.sis_drm.c gcc "-I../../xx64/usr/include" -c -o drm.armada_drm.o drm.armada_drm.c gcc "-I../../xx64/usr/include" -c -o drm.savage_drm.o drm.savage_drm.c gcc "-I../../xx64/usr/include" -c -o drm.r128_drm.o drm.r128_drm.c gcc "-I../../xx64/usr/include" -c -o drm.qxl_drm.o drm.qxl_drm.c gcc "-I../../xx64/usr/include" -c -o drm.vmwgfx_drm.o drm.vmwgfx_drm.c gcc "-I../../xx64/usr/include" -c -o drm.drm_sarea.o drm.drm_sarea.c gcc "-I../../xx64/usr/include" -c -o drm.via_drm.o drm.via_drm.c gcc "-I../../xx64/usr/include" -c -o drm.tegra_drm.o drm.tegra_drm.c gcc "-I../../xx64/usr/include" -c -o drm.omap_drm.o drm.omap_drm.c gcc "-I../../xx64/usr/include" -c -o drm.radeon_drm.o drm.radeon_drm.c gcc "-I../../xx64/usr/include" -c -o drm.virtgpu_drm.o drm.virtgpu_drm.c gcc "-I../../xx64/usr/include" -c -o drm.vgem_drm.o drm.vgem_drm.c gcc "-I../../xx64/usr/include" -c -o drm.nouveau_drm.o drm.nouveau_drm.c gcc "-I../../xx64/usr/include" -c -o drm.drm.o drm.drm.c gcc "-I../../xx64/usr/include" -c -o mtd.mtd-user.o mtd.mtd-user.c gcc "-I../../xx64/usr/include" -c -o mtd.ubi-user.o mtd.ubi-user.c gcc "-I../../xx64/usr/include" -c -o mtd.nftl-user.o mtd.nftl-user.c gcc "-I../../xx64/usr/include" -c -o mtd.mtd-abi.o mtd.mtd-abi.c gcc "-I../../xx64/usr/include" -c -o mtd.inftl-user.o mtd.inftl-user.c gcc "-I../../xx64/usr/include" -c -o sound.emu10k1.o sound.emu10k1.c gcc "-I../../xx64/usr/include" -c -o sound.sb16_csp.o sound.sb16_csp.c gcc "-I../../xx64/usr/include" -c -o sound.firewire.o sound.firewire.c gcc "-I../../xx64/usr/include" -c -o sound.asound_fm.o sound.asound_fm.c gcc "-I../../xx64/usr/include" -c -o sound.usb_stream.o sound.usb_stream.c gcc "-I../../xx64/usr/include" -c -o sound.compress_params.o sound.compress_params.c gcc "-I../../xx64/usr/include" -c -o sound.asoc.o sound.asoc.c gcc "-I../../xx64/usr/include" -c -o sound.sfnt_info.o sound.sfnt_info.c gcc "-I../../xx64/usr/include" -c -o sound.snd_sst_tokens.o sound.snd_sst_tokens.c gcc "-I../../xx64/usr/include" -c -o sound.compress_offload.o sound.compress_offload.c gcc "-I../../xx64/usr/include" -c -o sound.asequencer.o sound.asequencer.c gcc "-I../../xx64/usr/include" -c -o sound.hdspm.o sound.hdspm.c gcc "-I../../xx64/usr/include" -c -o sound.tlv.o sound.tlv.c gcc "-I../../xx64/usr/include" -c -o sound.asound.o sound.asound.c gcc "-I../../xx64/usr/include" -c -o sound.hdsp.o sound.hdsp.c gcc "-I../../xx64/usr/include" -c -o rdma.mlx5_user_ioctl_verbs.o rdma.mlx5_user_ioctl_verbs.c gcc "-I../../xx64/usr/include" -c -o rdma.ib_user_mad.o rdma.ib_user_mad.c gcc "-I../../xx64/usr/include" -c -o rdma.rdma_user_rxe.o rdma.rdma_user_rxe.c gcc "-I../../xx64/usr/include" -c -o rdma.ocrdma-abi.o rdma.ocrdma-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.ib_user_cm.o rdma.ib_user_cm.c gcc "-I../../xx64/usr/include" -c -o rdma.ib_user_ioctl_cmds.o rdma.ib_user_ioctl_cmds.c gcc "-I../../xx64/usr/include" -c -o rdma.i40iw-abi.o rdma.i40iw-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.rdma_netlink.o rdma.rdma_netlink.c gcc "-I../../xx64/usr/include" -c -o rdma.cxgb4-abi.o rdma.cxgb4-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.ib_user_sa.o rdma.ib_user_sa.c gcc "-I../../xx64/usr/include" -c -o rdma.hns-abi.o rdma.hns-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.rdma_user_cm.o rdma.rdma_user_cm.c gcc "-I../../xx64/usr/include" -c -o rdma.bnxt_re-abi.o rdma.bnxt_re-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.mthca-abi.o rdma.mthca-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.qedr-abi.o rdma.qedr-abi.c gcc "-I../../xx64/usr/include" -c -o rdma.mlx5_use
Re: [PATCH v2 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe
On Tuesday 12 June 2018 11:15 AM, Alexander Stein wrote:
> On Tuesday, June 12, 2018, 7:27:52 AM CEST Keerthy wrote:
>> This is needed in case of PROBE_DEFER if IRQ resource is not yet ready.
>>
>> Signed-off-by: Keerthy
>> ---
>> [...]
>> --- a/drivers/gpio/gpio-davinci.c
>> +++ b/drivers/gpio/gpio-davinci.c
>> [...]
>> @@ -168,7 +168,7 @@ static int davinci_gpio_probe(struct platform_device
>> *pdev)
>> {
>> static int ctrl_num, bank_base;
>> int gpio, bank, ret = 0;
>> -unsigned ngpio, nbank;
>> +unsigned ngpio, nbank, bank_irq;
>
> bank_irq should be an int, not unsigned, no?
Yes
>
>> struct davinci_gpio_controller *chips;
>> struct davinci_gpio_platform_data *pdata;
>> struct device *dev = &pdev->dev;
>> @@ -209,6 +209,12 @@ static int davinci_gpio_probe(struct platform_device
>> *pdev)
>> if (IS_ERR(gpio_base))
>> return PTR_ERR(gpio_base);
>>
>> +bank_irq = platform_get_irq(pdev, 0);
>> +if (bank_irq < 0) {
>
> This won't work using an unsigned.
Thanks for catching this. I will correct this in v3.
>
> Best regards,
> Alexander
>
>
>
Re: [PATCH v2 1/2] gpio: davinci: Shuffle IRQ resource fetching from DT to beginning of probe
On Tuesday, June 12, 2018, 7:27:52 AM CEST Keerthy wrote:
> This is needed in case of PROBE_DEFER if IRQ resource is not yet ready.
>
> Signed-off-by: Keerthy
> ---
> [...]
> --- a/drivers/gpio/gpio-davinci.c
> +++ b/drivers/gpio/gpio-davinci.c
> [...]
> @@ -168,7 +168,7 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> {
> static int ctrl_num, bank_base;
> int gpio, bank, ret = 0;
> - unsigned ngpio, nbank;
> + unsigned ngpio, nbank, bank_irq;
bank_irq should be an int, not unsigned, no?
> struct davinci_gpio_controller *chips;
> struct davinci_gpio_platform_data *pdata;
> struct device *dev = &pdev->dev;
> @@ -209,6 +209,12 @@ static int davinci_gpio_probe(struct platform_device
> *pdev)
> if (IS_ERR(gpio_base))
> return PTR_ERR(gpio_base);
>
> + bank_irq = platform_get_irq(pdev, 0);
> + if (bank_irq < 0) {
This won't work using an unsigned.
Best regards,
Alexander
Re: [PATCHv4 1/3] scripts: Preprocess module-common.lds
kbuild test robot writes: > Hi Laura, > > I love your patch! Yet something to improve: > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.17 next-20180608] > [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/Laura-Abbott/scripts-Preprocess-module-common-lds/20180612-083632 > config: i386-randconfig-a1-201823 (attached as .config) > compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 > reproduce: > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > >>> ld: cannot open linker script file scripts/module-common.lds: No such file >>> or directory This seems to need the following. cheers diff --git a/Makefile b/Makefile index 73f0bb2c7a98..55a5725b6606 100644 --- a/Makefile +++ b/Makefile @@ -425,7 +425,7 @@ KBUILD_AFLAGS_KERNEL := KBUILD_CFLAGS_KERNEL := KBUILD_AFLAGS_MODULE := -DMODULE KBUILD_CFLAGS_MODULE := -DMODULE -KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds +KBUILD_LDFLAGS_MODULE := -T $(objtree)/scripts/module-common.lds LDFLAGS := GCC_PLUGINS_CFLAGS :=
Re: [PATCH] proc: Fix parsing of mount parameters.
On Mon, Jun 11, 2018 at 6:22 PM Eric W. Biederman wrote:
>
> Alistair Strachan writes:
>
> > In commit e94591d0d90c "proc: Convert proc_mount to use mount_ns"
> > the parsing of mount parameters for the proc filesystem was broken.
> >
> > The SB_KERNMOUNT for procfs happens via:
> >
> > start_kernel()
> > rest_init()
> > kernel_thread()
> > _do_fork()
> >copy_process()
> > alloc_pid()
> >pid_ns_prepare_proc()
> > kern_mount_data()
> >proc_mount()
> > mount_ns()
> >
> > In mount_ns(), the kernel calls proc_fill_super() only if the superblock
> > has not previously been set up (i.e. the first mount reference),
> > regardless of SB_KERNMOUNT. Because the call to proc_parse_options() had
> > been moved inside here, and the SB_KERNMOUNT uses no mount options, the
> > option parser became a no-op.
> >
> > When userspace later mounted procfs with e.g. hidepid=2, the options
> > would be ignored.
> >
> > This change backs out a part of the original cleanup and parses the
> > procfs mount options at every mount call. Because the options currently
> > only update the pid_ns for the mount, they are applied for all mounts of
> > proc by that pid or childen of that pid, instantaneously. This is the
> > same behavior as the original code.
>
> Two years for a regression to be reported is a litte long. I think that
> gets out of the kneejerk immediate fix or revert phase and into thinking
> a little bout about what makes sense in this code.
Android has been using hidepid=2 for a while, but most shipping
products were on 3.18 or 4.4 kernels. To us, it's a new problem.
> As we say with devpts there is a very real danger of someone mounting
> a second instance of proc in a chroot and causing problems by either
> strengthening or weakening the hid pid protections for the entire pid
> namespace. If we go with your proposed change in behavior.
I guess my change does change the behavior, but it's just back to the
behavior which the kernel had for a good while (~v3.3 thru v4.7).
> Ordinary block device filesystems (like ext4) avoid this problem by
> allowing a second mount and by not parsing the mount options except
> on remount. What proc currently does.
IMHO, they're not really comparable. You'll only get kernmounts of an
ext4 filesystem when finding rootfs, and in that case the user knows
about the mount and can see it in /proc/mounts, so they know to use -o
remount,.
Since the first mount (where the options might have been respected) is
*always* the kernmount done before init, with your change these mount
options for procfs will never be respected. As userspace didn't yet
mount /proc, it can't know /proc was already mounted, in order to know
to use a remount to re-parse the options. The behavior was changed in
a non-obvious way.
> So I think it can be reasonably argued that the change in behavior is
> was an unintentional fix.
>
> I can see an argument for failing the mount of proc if mount options
> are specified or if those mount options differ from the existing mount
> options.
>
> proc_remount's call of proc_parse_options is definitely buggy as it can
> partially succeed and change the pid namespace and return an error code.
> That is bad error handling.
>
> There may be an argument for making these options available in something
> other than a mount of proc. As they are pid namespace wide.
>
> There may be an argument for multiple instances of proc so that it makes
> sense to process these options during an ordinary mount.
>
>
> Ultimately what I see is that this is a difficult area of semantics that
> there is at least a little room for improvement on, but it is not
> as simple as this proposed change.
An alternative fix might be to ignore the super setup if done from a
kernmount of procfs. IMO, this initial mount shouldn't be considered
the first reference, because it will not pass the mount options and
cannot be observed by userspace. Such a change looks complicated,
though, and it would only be relevant to procfs. It might be better to
roll back the cleanup and implement these semantics directly in the
procfs code.
> > Fixes: e94591d0d90c ("proc: Convert proc_mount to use mount_ns")
> > Signed-off-by: Alistair Strachan
> > Cc: Seth Forshee
> > Cc: Djalal Harouni
> > Cc: "Eric W. Biederman"
> > Cc: kernel-t...@android.com
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > fs/proc/inode.c| 4
> > fs/proc/internal.h | 1 -
> > fs/proc/root.c | 5 -
> > 3 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/fs/proc/inode.c b/fs/proc/inode.c
> > index 2cf3b74391ca..f348be0a 100644
> > --- a/fs/proc/inode.c
> > +++ b/fs/proc/inode.c
> > @@ -492,13 +492,9 @@ struct inode *proc_get_inode(struct super_block *sb,
> > struct proc_dir_entry *de)
> >
> > int proc_fill_super(struct super_block *s, void *data, int silent)
> > {
> > - struct pid_namespace
Re: [GIT PULL] FSI updates
On Tue, Jun 12, 2018 at 02:14:25PM +1000, Benjamin Herrenschmidt wrote: > Hi Greg ! > > There are a first round of updates of the FSI stack, aiming at > reducing/removing > the gap with the OpenBMC tree and a first step in getting dependent drivers > upstream. > > These changes significantly improve the FSI bitbanging driver performance > and reliability, and add the new "sbefifo" driver for communicating with > the POWER9 Self Boot Engine (which will be needed for some upcoming > additional drivers). > > [ Apologies if I got part of the process wrong, I haven't > sent a pull request in years ;-) ] So, these are all for 4.19-rc1, right? Not bugfixes for 4.18-final? > The following changes since commit 8efcf34a263965e471e304f94d1f6799d42a: > > Merge tag 'armsoc-late' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc (2018-06-11 > 18:19:45 -0700) > > are available in the Git repository at: > > https://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git I need a signed tag to pull from, not just a git tree, otherwise I don't know that you really sent me what you think you sent me :) Can you fix that up, and tell me where you want this to go and then I can take it after 4.18-rc1 is out. thanks, greg k-h
Re: [PATCH] mmc: Move the mmc driver init earlier
On 8 June 2018 at 11:51, Feng Tang wrote: > When doing some boot time optimization for an eMMC rootfs NUCs, > we found the rootfs may spend around 100 microseconds waiting > for eMMC card to be initialized, then the rootfs could be > mounted. > [1.216561] Waiting for root device /dev/mmcblk1p1... > [1.289262] mmc1: new HS400 MMC card at address 0001 > [1.289667] mmcblk1: mmc1:0001 R1J56L 14.7 GiB > [1.289772] mmcblk1boot0: mmc1:0001 R1J56L partition 1 8.00 MiB > [1.289869] mmcblk1boot1: mmc1:0001 R1J56L partition 2 8.00 MiB > [1.289967] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 4.00 MiB > [1.292798] mmcblk1: p1 p2 p3 > [1.300576] EXT4-fs (mmcblk1p1): couldn't mount as ext3 due to > feature incompatibilities > [1.300912] EXT4-fs (mmcblk1p1): couldn't mount as ext2 due to > feature incompatibilities > > And this is a common problem for smartphones, tablets, embedded > devices and automotive products. This patch will make the eMMC/SD > card start initializing earlier, by changing its order in drivers/Makefile. > > On our platform, the waiting for eMMC card is almost eliminated with the > patch, > which is critical to boot time. I am wondering what kernel version you are running here. There have been some changes to the mmc initialization path, which perhaps can help. > > Signed-off-by: Feng Tang > --- > drivers/Makefile | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/Makefile b/drivers/Makefile > index 24cd47014657..c473afd3c688 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -50,6 +50,9 @@ obj-$(CONFIG_REGULATOR) += regulator/ > # reset controllers early, since gpu drivers might rely on them to initialize > obj-$(CONFIG_RESET_CONTROLLER) += reset/ > > +# put mmc early as many morden devices use emm/sd card as rootfs storage > +obj-y += mmc/ > + Your suggested approach isn't really a solution, as it may work for your particular case but not for everybody else. > # tty/ comes before char/ so that the VT console is the boot-time > # default. > obj-y += tty/ > @@ -128,7 +131,6 @@ obj-$(CONFIG_EISA) += eisa/ > obj-$(CONFIG_PM_OPP) += opp/ > obj-$(CONFIG_CPU_FREQ) += cpufreq/ > obj-$(CONFIG_CPU_IDLE) += cpuidle/ > -obj-y += mmc/ > obj-$(CONFIG_MEMSTICK) += memstick/ > obj-$(CONFIG_NEW_LEDS) += leds/ > obj-$(CONFIG_INFINIBAND) += infiniband/ > -- > 2.14.1 > Kind regards Uffe
Re: [PATCH] staging: speakup: refactor synths array to use a list
Gregory Nowak, le lun. 11 juin 2018 16:51:22 -0700, a ecrit: > On Tue, Jun 12, 2018 at 12:57:03AM +0200, Samuel Thibault wrote: > > Anybody up for testing please? > > > > If people want to see speakup get mainlined instead of staging, please > > help. > > If I understand right, this patch changes how synthesizers are loaded > and unloaded through /sys/accessibility/speakup/synth, correct? The load/unload is about the module itself, i.e. modprobe speakup_bns ; modprobe speakup_soft, switch between them, then rmmod speakup_bns ; speakup_soft or the converse (to exercise both orders). Thanks! Samuel
Re: [PATCH] staging: lustre: add error handling for try_module_get
On Tue, Jun 12, 2018 at 12:49:26PM +0800, Zhouyang Jia wrote: > When try_module_get fails, the lack of error-handling code may > cause unexpected results. > > This patch adds error-handling code after calling try_module_get. > > Signed-off-by: Zhouyang Jia > --- > drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 5 - This patch does not apply to Linus's tree. Always be sure to work against linux-next to catch things like this. thanks, greg k-h
Re: [PATCH] ipc: Limit sysctl value to IPCMNI
On Mon, 11 Jun 2018 23:27:08 +0200,
Waiman Long wrote:
>
> On 06/08/2018 05:16 PM, Andrew Morton wrote:
> > On Fri, 8 Jun 2018 15:49:49 +0200 Takashi Iwai wrote:
> >
> >> Currently shmmni proc entry accepts all entered integer values, but
> >> the practical limit is IPCMNI (32768). This confuses user as if a
> >> bigger value were accepted but not applied correctly.
> >>
> >> This patch changes the proc entry to use *_minmax variant to limit the
> >> accepted values accordingly.
> > Waiman Long was working on a (vastly more complicated) patchset to
> > address this.
> >
> >> --- a/ipc/ipc_sysctl.c
> >> +++ b/ipc/ipc_sysctl.c
> >> @@ -99,6 +99,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table *table,
> >> int write,
> >> static int zero;
> >> static int one = 1;
> >> static int int_max = INT_MAX;
> >> +static int ipcmni = IPCMNI;
> >>
> >> static struct ctl_table ipc_kern_table[] = {
> >>{
> >> @@ -120,7 +121,9 @@ static struct ctl_table ipc_kern_table[] = {
> >>.data = &init_ipc_ns.shm_ctlmni,
> >>.maxlen = sizeof(init_ipc_ns.shm_ctlmni),
> >>.mode = 0644,
> >> - .proc_handler = proc_ipc_dointvec,
> >> + .proc_handler = proc_ipc_dointvec_minmax,
> >> + .extra1 = &zero,
> >> + .extra2 = &ipcmni,
> >>},
> >>{
> >>.procname = "shm_rmid_forced",
> > What is the back-compatibility situation here?
> >
> >
> Sorry for the late reply. I am planning to send out an updated patch
> once the merge window is closed. The latest patch can be found in
>
> https://lkml.org/lkml/2018/5/7/666
>
> Luis has some concern about the use of __read_mostly tag which I am
> going to remove in the next version.
Thanks, that's as trivial as my patch, unsurprisingly :)
Takashi
Re: [PATCH] ipc: Limit sysctl value to IPCMNI
On Tue, 12 Jun 2018 01:18:45 +0200,
Andrew Morton wrote:
>
> On Sat, 09 Jun 2018 08:48:48 +0200 Takashi Iwai wrote:
>
> > On Fri, 08 Jun 2018 23:16:59 +0200,
> > Andrew Morton wrote:
> > >
> > > On Fri, 8 Jun 2018 15:49:49 +0200 Takashi Iwai wrote:
> > >
> > > > Currently shmmni proc entry accepts all entered integer values, but
> > > > the practical limit is IPCMNI (32768). This confuses user as if a
> > > > bigger value were accepted but not applied correctly.
> > > >
> > > > This patch changes the proc entry to use *_minmax variant to limit the
> > > > accepted values accordingly.
> > >
> > > Waiman Long was working on a (vastly more complicated) patchset to
> > > address this.
> >
> > That's great. Any patch available for testing?
>
> I think
> http://lkml.kernel.org/r/1520885744-1546-1-git-send-email-long...@redhat.com
> is the most recent version.
>
> >
> > > > --- a/ipc/ipc_sysctl.c
> > > > +++ b/ipc/ipc_sysctl.c
> > > > @@ -99,6 +99,7 @@ static int proc_ipc_auto_msgmni(struct ctl_table
> > > > *table, int write,
> > > > static int zero;
> > > > static int one = 1;
> > > > static int int_max = INT_MAX;
> > > > +static int ipcmni = IPCMNI;
> > > >
> > > > static struct ctl_table ipc_kern_table[] = {
> > > > {
> > > > @@ -120,7 +121,9 @@ static struct ctl_table ipc_kern_table[] = {
> > > > .data = &init_ipc_ns.shm_ctlmni,
> > > > .maxlen = sizeof(init_ipc_ns.shm_ctlmni),
> > > > .mode = 0644,
> > > > - .proc_handler = proc_ipc_dointvec,
> > > > + .proc_handler = proc_ipc_dointvec_minmax,
> > > > + .extra1 = &zero,
> > > > + .extra2 = &ipcmni,
> > > > },
> > > > {
> > > > .procname = "shm_rmid_forced",
> > >
> > > What is the back-compatibility situation here?
> >
> > It's obviously an error to set such a high value and suppose that it
> > were accepted. So relying on that behavior must be broken in
> > anyway...
>
> Well the present behaviour is to convert higher values downwards, yes?
>
> int ipc_addid(struct ipc_ids *ids, struct kern_ipc_perm *new, int limit)
> {
> kuid_t euid;
> kgid_t egid;
> int id, err;
>
> if (limit > IPCMNI)
> limit = IPCMNI;
>
> So if someone out there is presently setting this to 99 then their
> kernel will work just fine. After your proposed change, it will no
> longer do so - the tuning attempt will fail with -EINVAL.
>
> It really does us no good to say "you shouldn't have been doing that".
> The fact that they *are* doing it and that it works OK is the kernel
> developers' fault for not applying suitable checking on day one. I
> think we're stuck with continuing to accept such input.
Hm, that's one concern, yes.
OTOH, we do secretly ignore the input value, and this isn't what's
expected by user, either. Moreover, user-space has no slightest idea
which value can be accepted and which not.
Actually I posted it just because of requests from customers who
needed to raise the bar, but didn't notice the effect.
Maybe another possible solution would be to add another proc entry to
handle this correctly, and make the old one only for compatibility.
thanks,
Takashi
Re: [PATCH v3 5/7] dt-bindings: power: Add qcom rpmh power domain driver bindings
On 06/12/2018 11:09 AM, Bjorn Andersson wrote:
> On Mon 11 Jun 21:40 PDT 2018, Rajendra Nayak wrote:
>
>> Add DT bindings to describe the rpmh powerdomains found on Qualcomm
>> Technologies, Inc. SoCs. These power domains communicate a performance
>> state to RPMh, which then translates it into corresponding voltage on
>> a PMIC rail.
>>
>> Signed-off-by: Rajendra Nayak
>> ---
>> .../devicetree/bindings/power/qcom,rpmhpd.txt | 65 +++
>> 1 file changed, 65 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>> b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>> new file mode 100644
>> index ..41ef7afa6b24
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/qcom,rpmhpd.txt
>> @@ -0,0 +1,65 @@
>> +Qualcomm RPMh Power domains
>> +
>> +For RPMh Power domains, we communicate a performance state to RPMh
>> +which then translates it into a corresponding voltage on a rail
>> +
>> +Required Properties:
>> + - compatible: Should be one of the following
>> +* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
>
> Afaict this binding is identical to the one introduced in patch 1, so I
> would suggest that you just add the compatible there.
Sure, makes sense. thanks.
>
> Regards,
> Bjorn
>
>> + - power-domain-cells: number of cells in power domain specifier
>> +must be 1
>> + - operating-points-v2: Phandle to the OPP table for the power-domain.
>> +Refer to Documentation/devicetree/bindings/power/power_domain.txt
>> +and Documentation/devicetree/bindings/opp/qcom-opp.txt for more details
>> +
>> +Example:
>> +
>> +rpmhpd: power-controller {
>> +compatible = "qcom,sdm845-rpmhpd";
>> +#power-domain-cells = <1>;
>> +operating-points-v2 = <&rpmhpd_opp_table>;
>> +};
>> +
>> +rpmhpd_opp_table: opp-table {
>> +compatible = "operating-points-v2-qcom-level";
>> +
>> +rpmhpd_opp_ret: opp1 {
>> +qcom-level = <16>;
>> +};
>> +
>> +rpmhpd_opp_min_svs: opp2 {
>> +qcom-level = <48>;
>> +};
>> +
>> +rpmhpd_opp_low_svs: opp3 {
>> +qcom-level = <64>;
>> +};
>> +
>> +rpmhpd_opp_svs: opp4 {
>> +qcom-level = <128>;
>> +};
>> +
>> +rpmhpd_opp_svs_l1: opp5 {
>> +qcom-level = <192>;
>> +};
>> +
>> +rpmhpd_opp_nom: opp6 {
>> +qcom-level = <256>;
>> +};
>> +
>> +rpmhpd_opp_nom_l1: opp7 {
>> +qcom-level = <320>;
>> +};
>> +
>> +rpmhpd_opp_nom_l2: opp8 {
>> +qcom-level = <336>;
>> +};
>> +
>> +rpmhpd_opp_turbo: opp9 {
>> +qcom-level = <384>;
>> +};
>> +
>> +rpmhpd_opp_turbo_l1: opp10 {
>> +qcom-level = <416>;
>> +};
>> +};
>> --
>> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
>> of Code Aurora Forum, hosted by The Linux Foundation
>>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
RE: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller
Hi Boris, -Original Message- From: linux-mtd [mailto:linux-mtd-boun...@lists.infradead.org] On Behalf Of Yogesh Narayan Gaur Sent: Monday, June 11, 2018 3:51 PM To: Boris Brezillon Cc: rich...@nod.at; Prabhakar Kushwaha ; Han Xu ; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; marek.va...@gmail.com; Frieder Schrempf ; broo...@kernel.org; linux-...@lists.infradead.org; miquel.ray...@bootlin.com; Fabio Estevam ; David Wolfe ; computersforpe...@gmail.com; dw...@infradead.org Subject: RE: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller Hi Boris, -Original Message- From: Boris Brezillon [mailto:boris.brezil...@bootlin.com] Sent: Monday, June 11, 2018 3:46 PM To: Yogesh Narayan Gaur Cc: marek.va...@gmail.com; Frieder Schrempf ; linux-...@lists.infradead.org; linux-...@vger.kernel.org; dw...@infradead.org; computersforpe...@gmail.com; rich...@nod.at; miquel.ray...@bootlin.com; broo...@kernel.org; David Wolfe ; Fabio Estevam ; Prabhakar Kushwaha ; Han Xu ; linux-kernel@vger.kernel.org Subject: Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller On Mon, 11 Jun 2018 09:38:14 + Yogesh Narayan Gaur wrote: > > > Observation 3: > > > As we can support JFFS2 filesystem on NOR flash, so we can expect JFFS2 > > > commands should work fine on NOR flash. > > > But with this driver change my mount command is not working. > > > > > > In my target there are 2 flash slave devices connected, and I have given > > > argument to create MTD partition like > > > "mtdparts=20c.quadspi-1:5M(rcw),10M(test),46M(rootfs) " for 2nd flash. > > > Below is output for /proc/mtd commands > > > root@ls1012ardb:~# cat /proc/mtd > > > dev:size erasesize name > > > mtd0: 0400 0004 "20c.quadspi-0" --> First 64MB flash > > > mtd1: 0050 0004 "rcw" --> > > > Second 64 MB flash device, 3 MTD partition are created for it. > > > mtd2: 00a0 0004 "test" > > > mtd3: 02e0 0004 "rootfs" When I do mtd1 + mtd2 + mtd3, I end up with 0x3d0 instead of 0x400. Is that normal? Do you reserve a bit of space at the end or is it that rcw is not starting at 0? I have given partition size n bootargs as mtdparts=20c.quadspi-1:5M(rcw),10M(test),46M(rootfs) 5 + 10 + 46 ==> 61M i.e. 0x3d0. I have just reserve the bit at the end, we can modify these settings also. > > > > > > root@ls1012ardb:~# mkdir /media/ram ; flash_eraseall /dev/mtd3 > > > flash_eraseall has been replaced by `flash_erase 0 0`; > > > please use it > > > Erasing 256 Kibyte @ 0 -- 0 % complete [ 18.299929] random: crng > > > init done > > > Erasing 256 Kibyte @ 2dc -- 100 % complete > > > root@ls1012ardb:~# mount -t jffs2 /dev/mtdblock3 /media/ram/ > > > > > > This command didn't finish successfully and there are lot of messages > > > coming on console mentioning failure in jffs2_scan_eraseblock() > > > [ 187.118677] jffs2: jffs2_scan_eraseblock(): Magic bitmask > > > 0x1985 not found at 0x013c: 0x2886 instead >> Did you try to create a smaller partition? Maybe we have a problem when >> accessing addresses higher than X with the new driver (X to be determined). > Would try and update you. I have tried JFFS2 mounting with smaller partition size but still getting failure. For partition size equal or less than 1MB, getting errors as [ 25.044930] jffs2: Too few erase blocks (4) Thus, need to have size more than 1MB. For 2MB partition size getting error message from jffs2_scan_eraseblock(). root@ls1012ardb:~# cat /proc/mtd dev:size erasesize name mtd0: 0400 0004 "20c.quadspi-0" mtd1: 0050 0004 "rcw" mtd2: 00a0 0004 "test" mtd3: 0020 0004 "rootfs" root@ls1012ardb:~# mkdir /media/ram ; flash_eraseall /dev/mtd3 flash_eraseall has been replaced by `flash_erase 0 0`; please use it Erasing 256 Kibyte @ 1c -- 100 % complete root@ls1012ardb:~# mount -t jffs2 /dev/mtdblock3 /media/ram/ [ 26.380989] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x: 0x0dd0 instead [ 26.390509] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x004c: 0x7366 instead [ 26.39] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0050: 0x736c instead -- Regards Yogesh Gaur > > > [ 187.128159] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 > > > not found at 0x013c0004: 0x7a3b instead > > > [ 187.137641] jffs2: jffs2_scan_eraseblock(): Magic bitmask > > > 0x1985 not found at 0x013c0008: 0xb10f instead > > > __ Linux MTD discussion mailing list https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fmailman%2Flistinfo%2Flinux-mtd%2F&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7C0b09ae5
Re: [PATCH v2 1/2] ALSA: hda: add dock and led support for HP EliteBook 830 G5
On Tue, 12 Jun 2018 07:10:59 +0200, Dennis Wassenberg wrote: > > This patch adds missing initialisation for HP 2013 UltraSlim Dock > Line-In/Out PINs and activates keyboard mute/micmute leds > for HP EliteBook 830 G5 > > Signed-off-by: Dennis Wassenberg Applied, thanks. Takashi
Re: [PATCH] ALSA: lx6464es: add error handling for pci_ioremap_bar
On Tue, 12 Jun 2018 05:23:14 +0200,
Zhouyang Jia wrote:
>
> When pci_ioremap_bar fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling pci_ioremap_bar.
>
> Signed-off-by: Zhouyang Jia
This patch makes no sense, sorry. The whole lx6464es error handling
there is buggy. We need to fix it more properly.
And, you must have noticed a bad smell in that change before
submitting this. Basically, using the same goto label for the error
handling of the next step is already fishy. In this case, you'd have
to unmap at the error path after this point. If you can use the same
label, it means that the unmap is missing -- already something wrong.
thanks,
Takashi
> ---
> sound/pci/lx6464es/lx6464es.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/sound/pci/lx6464es/lx6464es.c b/sound/pci/lx6464es/lx6464es.c
> index 9655b08..6157b6d 100644
> --- a/sound/pci/lx6464es/lx6464es.c
> +++ b/sound/pci/lx6464es/lx6464es.c
> @@ -1016,6 +1016,10 @@ static int snd_lx6464es_create(struct snd_card *card,
>
> /* dsp port */
> chip->port_dsp_bar = pci_ioremap_bar(pci, 2);
> + if (!chip->port_dsp_bar) {
> + dev_err(card->dev, "cannot remap PCI memory region\n");
> + goto request_irq_failed;
> + }
>
> err = request_threaded_irq(pci->irq, lx_interrupt, lx_threaded_irq,
> IRQF_SHARED, KBUILD_MODNAME, chip);
> --
> 2.7.4
>
>
Re: [PATCH v2 2/2] ALSA: hda: add dock and led support for HP ProBook 640 G4
On Tue, 12 Jun 2018 07:11:11 +0200, Dennis Wassenberg wrote: > > This patch adds missing initialisation for HP 2013 UltraSlim Dock > Line-In/Out PINs and activates keyboard mute/micmute leds > for HP ProBook 640 G4 > > Signed-off-by: Dennis Wassenberg Applied, thanks. Takashi
Re: [PATCH v13 0/3] Fix issues with huge mapping in ioremap for ARM64
Hi Andrew, On 6/6/2018 9:15 PM, Will Deacon wrote: [...] On Wed, Jun 06, 2018 at 12:31:18PM +0530, Chintan Pandya wrote: This series of patches re-bring huge vmap back for arm64. Patch 1/3 has been taken by Toshi in his series of patches by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86" to avoid merge conflict with this series. [...] arch/arm64/include/asm/tlbflush.h | 7 ++ arch/arm64/mm/mmu.c | 48 +++ arch/x86/mm/pgtable.c | 8 --- include/asm-generic/pgtable.h | 8 +++ lib/ioremap.c | 4 ++-- If you get an ack from the x86 folks, then I could take all of this via arm64. Alternatively, now that I've reviewed the series this could happily go via another tree (e.g. akpm). Would you be able to take a look at this series ? - 1/3 has been reviewed by Will and Toshi (as it touches arm64 and x86). - 2/3 & 3/3 are arm64 specific changes. If you think to take these patches, great ! Otherwise, I will try to reach-out to x86 folks for their ack. Thanks, Will ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Chintan -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCHv4 0/3] Salted build ids via linker sections
Laura Abbott writes:
> Hi,
>
> This is v4 of the series to allow unique build ids in the kernel. As a
> reminder of the context:
>
> ""
> In Fedora, the debug information is packaged separately (foo-debuginfo) and
> can be installed separately. There's been a long standing issue where only one
> version of a debuginfo info package can be installed at a time. Mark Wielaard
> made an effort for Fedora 27 to allow parallel installation of debuginfo (see
> https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo for
> more details)
>
> Part of the requirement to allow this to work is that build ids are
> unique between builds. The existing upstream rpm implementation ensures
> this by re-calculating the build-id using the version and release as a
> seed. This doesn't work 100% for the kernel because of the vDSO which is
> its own binary and doesn't get updated. After poking holes in a few of my
> ideas, there was a discussion with some people from the binutils team about
> adding --build-id-salt to let ld do the calculation debugedit is doing. There
> was a counter proposal made to add in the salt while building. The
> easiest proposal was to add an item in the linker script vs. linking in
> an object since we need the salt to go in every module as well as the
> kernel and vmlinux.
> ""
>
> v4 takes Linus' suggestion of using linker fill to insert the build id.
> This removes the need to use a generated header which makes things much
> easier. One change is that because this section isn't .comment it won't
> get stripped automatically. This is pretty small but I also know people
> can be picky so I'm open to opinions or suggestions here.
>
> Laura Abbott (3):
> scripts: Preprocess module-common.lds
> kbuild: Introduce build-salt linker section and config option
> x86: Add build salt to the vDSO and kernel linker scripts
Hi Laura,
Here's a patch to get it working on powerpc. Seems to work as expected.
cheers
>From fc5e22e4873956f9328e401ee5dd2835f4884db9 Mon Sep 17 00:00:00 2001
From: Michael Ellerman
Date: Tue, 12 Jun 2018 14:52:34 +1000
Subject: [PATCH] powerpc: Add support for BUILD_SALT in kernel, modules & VDSO
This patch adds support for BUILD_SALT in the kernel, modules and
VDSO. See the commit that adds BUILD_SALT for more info.
Kernel:
0:mon> d c1340840
c1340840 0055aaff12345678 1234567812345678 |.U...4Vx.4Vx.4Vx|
c1340850 1234567812345678 1234567812345678 |.4Vx.4Vx.4Vx.4Vx|
Module:
$ cat/sys/module/kvm/sections/.salt
0xd64385e8
...
0:mon> d d64385e8
d64385e8 0055aaff12345678 1234567812345678 |.U...4Vx.4Vx.4Vx|
d64385f8 1234567812345678 1234567812345678 |.4Vx.4Vx.4Vx.4Vx|
vdso:
(gdb) x/4xw (0x77f8 + 0x4a0)
0x77f804a0: 0xffaa5500 0x78563412 0x78563412
0x78563412
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/vdso32/vdso32.lds.S | 2 ++
arch/powerpc/kernel/vdso64/vdso64.lds.S | 2 ++
arch/powerpc/kernel/vmlinux.lds.S | 1 +
3 files changed, 5 insertions(+)
diff --git a/arch/powerpc/kernel/vdso32/vdso32.lds.S
b/arch/powerpc/kernel/vdso32/vdso32.lds.S
index 099a6db14e67..c06a1260 100644
--- a/arch/powerpc/kernel/vdso32/vdso32.lds.S
+++ b/arch/powerpc/kernel/vdso32/vdso32.lds.S
@@ -4,6 +4,7 @@
* library
*/
#include
+#include
#ifdef __LITTLE_ENDIAN__
OUTPUT_FORMAT("elf32-powerpcle", "elf32-powerpcle", "elf32-powerpcle")
@@ -25,6 +26,7 @@ SECTIONS
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
+ BUILD_SALT
.note : { *(.note.*) }:text :note
. = ALIGN(16);
diff --git a/arch/powerpc/kernel/vdso64/vdso64.lds.S
b/arch/powerpc/kernel/vdso64/vdso64.lds.S
index 256fb9720298..ace69258446a 100644
--- a/arch/powerpc/kernel/vdso64/vdso64.lds.S
+++ b/arch/powerpc/kernel/vdso64/vdso64.lds.S
@@ -4,6 +4,7 @@
* library
*/
#include
+#include
#ifdef __LITTLE_ENDIAN__
OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle")
@@ -25,6 +26,7 @@ SECTIONS
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
+ BUILD_SALT
.note : { *(.note.*) }:text :note
. = ALIGN(16);
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 5baac79df97e..59635369ceea 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -348,6 +348,7 @@ SECTIONS
}
BUG_TABLE
+ BUILD_SALT
. = ALIGN(PAGE_SIZE);
_edata = .;
--
2.14.1
[PATCH v3 0/6] add virt-dma support for imx-sdma
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Change from v2:
1. include Sascha's patch to make the main patch easier to review.
Thanks Sacha.
2. remove useless 'desc'/'chan' in struct sdma_channe.
Change from v1:
1. split v1 patch into 5 patches.
2. remove some unnecessary condition check.
3. remove unnecessary 'pending' list.
Robin Gong (5):
dmaengine: imx-sdma: add virt-dma support
Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled
during interrupt"
dmaengine: imx-sdma: remove usless lock
dmaengine: imx-sdma: remove the maximum limation for bd numbers
dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 392 -
2 files changed, 227 insertions(+), 166 deletions(-)
--
2.7.4
Robin Gong (5):
dmaengine: imx-sdma: add virt-dma support
Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled
during interrupt"
dmaengine: imx-sdma: remove usless lock
dmaengine: imx-sdma: remove the maximum limation for bd numbers
dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
Sascha Hauer (1):
dmaengine: imx-sdma: factor out a struct sdma_desc from struct
sdma_channel
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 391 -
2 files changed, 226 insertions(+), 166 deletions(-)
--
2.7.4
[PATCH v3 1/6] dmaengine: imx-sdma: factor out a struct sdma_desc from struct sdma_channel
From: Sascha Hauer
This is a preparation step to make the adding of virt-dma easier.
We create a struct sdma_desc, move some fields from struct sdma_channel
there and add a pointer from the former to the latter. For now we
allocate the data statically in struct sdma_channel, but with
virt-dma support it will be dynamically allocated.
Signed-off-by: Sascha Hauer
---
drivers/dma/imx-sdma.c | 137 ++---
1 file changed, 83 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3..556d087 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -296,6 +296,30 @@ struct sdma_context_data {
struct sdma_engine;
/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ unsigned intnum_bd;
+ dma_addr_t bd_phys;
+ unsigned intbuf_tail;
+ unsigned intbuf_ptail;
+ unsigned intperiod_len;
+ unsigned intchn_real_count;
+ unsigned intchn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
+/**
* struct sdma_channel - housekeeping for a SDMA channel
*
* @sdma pointer to the SDMA engine for this channel
@@ -305,11 +329,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct sdma_desc*desc;
+ struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -317,12 +340,6 @@ struct sdma_channel {
unsigned intevent_id0;
unsigned intevent_id1;
enum dma_slave_buswidth word_size;
- unsigned intbuf_tail;
- unsigned intbuf_ptail;
- unsigned intnum_bd;
- unsigned intperiod_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
unsigned intpc_from_device, pc_to_device;
unsigned intdevice_to_device;
unsigned long flags;
@@ -332,10 +349,8 @@ struct sdma_channel {
u32 shp_addr, per_addr;
struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor desc;
+ struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- unsigned intchn_count;
- unsigned intchn_real_count;
struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
@@ -398,6 +413,8 @@ struct sdma_engine {
u32 spba_start_addr;
u32 spba_end_addr;
unsigned intirq;
+ dma_addr_t bd0_phys;
+ struct sdma_buffer_descriptor *bd0;
};
static struct sdma_driver_data sdma_imx31 = {
@@ -632,7 +649,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
u32 address)
{
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
void *buf_virt;
dma_addr_t buf_phys;
int ret;
@@ -707,7 +724,9 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* call callback function.
*/
while (1) {
- bd = &sdmac->bd[sdmac->buf_tail];
+ struct sdma_desc *desc = sdmac->desc;
+
+ bd = &desc->bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
@@ -723,11 +742,11 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* t
[PATCH v3 2/6] dmaengine: imx-sdma: add virt-dma support
The legacy sdma driver has below limitations or drawbacks:
1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
one page size for one channel regardless of only few BDs needed
most time. But in few cases, the max PAGE_SIZE maybe not enough.
2. One SDMA channel can't stop immediatley once channel disabled which
means SDMA interrupt may come in after this channel terminated.There
are some patches for this corner case such as commit "2746e2c389f9",
but not cover non-cyclic.
The common virt-dma overcomes the above limitations. It can alloc bd
dynamically and free bd once this tx transfer done. No memory wasted or
maximum limititation here, only depends on how many memory can be requested
from kernel. For No.2, such issue can be workaround by checking if there
is available descript("sdmac->desc") now once the unwanted interrupt
coming. At last the common virt-dma is easier for sdma driver maintain.
Signed-off-by: Robin Gong
---
drivers/dma/Kconfig| 1 +
drivers/dma/imx-sdma.c | 258 -
2 files changed, 168 insertions(+), 91 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6d61cd0..78715a2 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -257,6 +257,7 @@ config IMX_SDMA
tristate "i.MX SDMA support"
depends on ARCH_MXC
select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
help
Support the i.MX SDMA engine. This engine is integrated into
Freescale i.MX25/31/35/51/53/6 chips.
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 556d087..474c105 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -48,6 +48,7 @@
#include
#include "dmaengine.h"
+#include "virt-dma.h"
/* SDMA registers */
#define SDMA_H_C0PTR 0x000
@@ -308,6 +309,7 @@ struct sdma_engine;
* @bd pointer of alloced bd
*/
struct sdma_desc {
+ struct virt_dma_descvd;
unsigned intnum_bd;
dma_addr_t bd_phys;
unsigned intbuf_tail;
@@ -331,8 +333,8 @@ struct sdma_desc {
* @word_size peripheral access size
*/
struct sdma_channel {
+ struct virt_dma_chanvc;
struct sdma_desc*desc;
- struct sdma_desc_desc;
struct sdma_engine *sdma;
unsigned intchannel;
enum dma_transfer_direction direction;
@@ -347,11 +349,8 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- struct tasklet_struct tasklet;
struct imx_dma_data data;
boolenabled;
};
@@ -705,6 +704,35 @@ static void sdma_event_disable(struct sdma_channel *sdmac,
unsigned int event)
writel_relaxed(val, sdma->regs + chnenbl);
}
+static struct sdma_desc *to_sdma_desc(struct dma_async_tx_descriptor *t)
+{
+ return container_of(t, struct sdma_desc, vd.tx);
+}
+
+static void sdma_start_desc(struct sdma_channel *sdmac)
+{
+ struct virt_dma_desc *vd = vchan_next_desc(&sdmac->vc);
+ struct sdma_desc *desc;
+ struct sdma_engine *sdma = sdmac->sdma;
+ int channel = sdmac->channel;
+
+ if (!vd) {
+ sdmac->desc = NULL;
+ return;
+ }
+ sdmac->desc = desc = to_sdma_desc(&vd->tx);
+ /*
+* Do not delete the node in desc_issued list in cyclic mode, otherwise
+* the desc alloced will never be freed in vchan_dma_desc_free_list
+*/
+ if (!(sdmac->flags & IMX_DMA_SG_LOOP))
+ list_del(&vd->node);
+
+ sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
+ sdma_enable_channel(sdma, sdmac->channel);
+}
+
static void sdma_update_channel_loop(struct sdma_channel *sdmac)
{
struct sdma_buffer_descriptor *bd;
@@ -723,7 +751,7 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* loop mode. Iterate over descriptors, re-setup them and
* call callback function.
*/
- while (1) {
+ while (sdmac->desc) {
struct sdma_desc *desc = sdmac->desc;
bd = &desc->bd[desc->buf_tail];
@@ -755,14 +783,14 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
* executed.
*/
- dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
+ dmaengine_desc_get_callback_invoke(&desc->vd.tx, NULL);
[PATCH v3 6/6] dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
There are lot of codes overlap between prep_sg and prep_cyclic function.
Add sdma_transfer_init() function to elimated the code overlap.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 83 ++
1 file changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 0b0588d2..486ebfe 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1254,6 +1254,40 @@ static void sdma_free_chan_resources(struct dma_chan
*chan)
clk_disable(sdma->clk_ahb);
}
+static struct sdma_desc *sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction, u32 bds)
+{
+ struct sdma_desc *desc;
+
+ desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ if (!desc)
+ goto err_out;
+
+ sdmac->status = DMA_IN_PROGRESS;
+ sdmac->direction = direction;
+ sdmac->flags = 0;
+
+ desc->chn_count = 0;
+ desc->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->sdmac = sdmac;
+ desc->num_bd = bds;
+
+ if (sdma_alloc_bd(desc))
+ goto err_desc_out;
+
+ if (sdma_load_context(sdmac))
+ goto err_desc_out;
+
+ return desc;
+
+err_desc_out:
+ kfree(desc);
+err_out:
+ return NULL;
+}
+
static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
struct dma_chan *chan, struct scatterlist *sgl,
unsigned int sg_len, enum dma_transfer_direction direction,
@@ -1266,36 +1300,13 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
struct scatterlist *sg;
struct sdma_desc *desc;
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
- sdmac->status = DMA_IN_PROGRESS;
-
- sdmac->flags = 0;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, sg_len);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = sg_len;
- desc->chn_real_count = 0;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_out;
- }
-
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
- sdmac->direction = direction;
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
-
- desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
@@ -1371,38 +1382,18 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
struct sdma_engine *sdma = sdmac->sdma;
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
- int ret, i = 0, buf = 0;
+ int i = 0, buf = 0;
struct sdma_desc *desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
- if (sdmac->status == DMA_IN_PROGRESS)
- return NULL;
-
- sdmac->status = DMA_IN_PROGRESS;
-
- desc = kzalloc((sizeof(*desc)), GFP_KERNEL);
+ desc = sdma_transfer_init(sdmac, direction, num_periods);
if (!desc)
goto err_out;
- desc->buf_tail = 0;
- desc->buf_ptail = 0;
- desc->sdmac = sdmac;
- desc->num_bd = num_periods;
- desc->chn_real_count = 0;
desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
- sdmac->direction = direction;
-
- if (sdma_alloc_bd(desc)) {
- kfree(desc);
- goto err_bd_out;
- }
-
- ret = sdma_load_context(sdmac);
- if (ret)
- goto err_bd_out;
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
--
2.7.4
Re: [PATCH] perf test: Test 6 dumps core on s390
On 06/08/2018 04:53 PM, Kim Phillips wrote: > On Fri, 8 Jun 2018 15:17:28 +0200 > Thomas Richter wrote: > >> Perf test case 6 "Parse event definition strings" >> dumps core when executed on s390. > > I reported it actually fails on any $ARCH system without > Intel Processor Trace (PT) h/w: > > https://www.spinics.net/lists/linux-perf-users/msg06020.html > > There was a follow-up patch sent here: > > https://www.spinics.net/lists/linux-perf-users/msg06029.html > > which worked for me, but I don't know what has/has-not transpired > since, other than it is still broken, as you found. > > Kim Looks like this is still broken. I also can not find this patch on git clone -b perf/core git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux We actually need 2 patches - one to fix the core dump - one to test for x86 platform -- Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany -- Vorsitzende des Aufsichtsrats: Martina Koederitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
[PATCH v3 3/6] Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled during interrupt"
This reverts commit 2746e2c389f9d50043d21e2204270403efb9d62f.
Don't need this patch anymore,since we can easily check 'sdmac->desc' to avoid
handling dma interrupt after channel disabled if virt-dma used.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 474c105..e0af8ee 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -352,7 +352,6 @@ struct sdma_channel {
spinlock_t lock;
enum dma_status status;
struct imx_dma_data data;
- boolenabled;
};
#define IMX_DMA_SG_LOOPBIT(0)
@@ -613,14 +612,7 @@ static int sdma_config_ownership(struct sdma_channel
*sdmac,
static void sdma_enable_channel(struct sdma_engine *sdma, int channel)
{
- unsigned long flags;
- struct sdma_channel *sdmac = &sdma->channel[channel];
-
writel(BIT(channel), sdma->regs + SDMA_H_START);
-
- spin_lock_irqsave(&sdmac->lock, flags);
- sdmac->enabled = true;
- spin_unlock_irqrestore(&sdmac->lock, flags);
}
/*
@@ -738,14 +730,6 @@ static void sdma_update_channel_loop(struct sdma_channel
*sdmac)
struct sdma_buffer_descriptor *bd;
int error = 0;
enum dma_status old_status = sdmac->status;
- unsigned long flags;
-
- spin_lock_irqsave(&sdmac->lock, flags);
- if (!sdmac->enabled) {
- spin_unlock_irqrestore(&sdmac->lock, flags);
- return;
- }
- spin_unlock_irqrestore(&sdmac->lock, flags);
/*
* loop mode. Iterate over descriptors, re-setup them and
@@ -1006,15 +990,10 @@ static int sdma_disable_channel(struct dma_chan *chan)
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
int channel = sdmac->channel;
- unsigned long flags;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
sdmac->status = DMA_ERROR;
- spin_lock_irqsave(&sdmac->lock, flags);
- sdmac->enabled = false;
- spin_unlock_irqrestore(&sdmac->lock, flags);
-
return 0;
}
--
2.7.4
[PATCH v3 5/6] dmaengine: imx-sdma: remove the maximum limation for bd numbers
No this limitation now after virtual dma used since bd is allocated
dynamically instead of static.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index f150b38..0b0588d2 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -292,7 +292,6 @@ struct sdma_context_data {
u32 scratch7;
} __attribute__ ((packed));
-#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
struct sdma_engine;
@@ -1296,13 +1295,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_slave_sg(
if (ret)
goto err_bd_out;
- if (sg_len > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, sg_len, NUM_BD);
- ret = -EINVAL;
- goto err_bd_out;
- }
-
desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
struct sdma_buffer_descriptor *bd = &desc->bd[i];
@@ -1412,12 +1404,6 @@ static struct dma_async_tx_descriptor
*sdma_prep_dma_cyclic(
if (ret)
goto err_bd_out;
- if (num_periods > NUM_BD) {
- dev_err(sdma->dev, "SDMA channel %d: maximum number of sg
exceeded: %d > %d\n",
- channel, num_periods, NUM_BD);
- goto err_bd_out;
- }
-
if (period_len > 0x) {
dev_err(sdma->dev, "SDMA channel %d: maximum period size
exceeded: %zu > %d\n",
channel, period_len, 0x);
--
2.7.4
[PATCH v3 4/6] dmaengine: imx-sdma: remove usless lock
No need anymore for 'lock' now since virtual dma will provide
the common lock instead.
Signed-off-by: Robin Gong
---
drivers/dma/imx-sdma.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index e0af8ee..f150b38 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -349,7 +349,6 @@ struct sdma_channel {
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
- spinlock_t lock;
enum dma_status status;
struct imx_dma_data data;
};
@@ -1907,7 +1906,6 @@ static int sdma_probe(struct platform_device *pdev)
struct sdma_channel *sdmac = &sdma->channel[i];
sdmac->sdma = sdma;
- spin_lock_init(&sdmac->lock);
sdmac->channel = i;
sdmac->vc.desc_free = sdma_desc_free;
--
2.7.4
Re: [PATCH v3 4/6] bus: ti-sysc: Add support for software reset
* Faiz Abbas [180611 06:48]: > Hi, > > On Monday 11 June 2018 11:59 AM, Tony Lindgren wrote: > > * Faiz Abbas [180611 06:28]: > >> Great. I thought I completely misunderstood you. But I don't see what > >> adding another function will accomplish. A QUIRK flag used in the same > >> function would work well enough> > > Fine with me as long as the function stays simple for both > > syss and sysc reset. > > > > > In general a reset status bit being in sysstatus is the norm and it > being in sysconfig should be the "quirk" for which a flag needs to be > added. What do you think? Sure makes sense to me. > As an aside, naming bitshifts by the name of the platform they were > originally added in seems weird. There should be some generic mask > saying "soft reset is the 0th bit". Currently I am using > SYSC_OMAP4_SOFTRESET for a dra76x module. I guess it depends on how many > different sysconfig types we have. Sure we could have a macro for that. Regards, Tony
Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )
I think the prime issue is that dma_direct_alloc respects the dma mask. Which we don't need if actually using the iommu. This would be mostly harmless exept for the the SEV bit high in the address that makes the checks fail. For now I'd say revert this commit for 4.17/4.18-rc and I'll look into addressing these issues properly.
Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header
On Sun 10-06-18 08:12:16, Mike Rapoport wrote: > On Fri, Jun 08, 2018 at 05:53:14PM +0800, 禹舟键 wrote: > > Hi Mike > > > My question was why do you call to alloc_constrained in the dump_header() > > > function rather than pass the constraint that was detected a bit earlier > > > to > > > that function? > > > > dump_header will be called by three functions: oom_kill_process, > > check_panic_on_oom, out_of_memory. > > We can get the constraint from the last two > > functions(check_panic_on_oom, out_of_memory), but I need to > > pass a new parameter(constraint) for oom_kill_process. > > Another option is to add the constraint to the oom_control structure. Which would make more sense because oom_control should contain the full OOM context. -- Michal Hocko SUSE Labs
Re: [RFC PATCH v4 1/8] usb: pd: include kernel.h
On Fri, Jun 08, 2018 at 02:29:34PM +0300, Heikki Krogerus wrote: > Some of the macros use le16_to_cpu(). What macros? Is this causing build errors today? If so, why should it not be included now? thanks, greg k-h
Re: [PATCH 14/39] ovl: stack file ops
On Sun, Jun 10, 2018 at 6:13 AM, Al Viro wrote:
> On Tue, May 29, 2018 at 04:43:14PM +0200, Miklos Szeredi wrote:
>> Implement file operations on a regular overlay file. The underlying file
>> is opened separately and cached in ->private_data.
>>
>> It might be worth making an exception for such files when accounting in
>> nr_file to confirm to userspace expectations. We are only adding a small
>> overhead (248bytes for the struct file) since the real inode and dentry are
>> pinned by overlayfs anyway.
>>
>> This patch doesn't have any effect, since the vfs will use d_real() to find
>> the real underlying file to open. The patch at the end of the series will
>> actually enable this functionality.
>
>> +static struct file *ovl_open_realfile(const struct file *file)
>> +{
>> + struct inode *inode = file_inode(file);
>> + struct inode *upperinode = ovl_inode_upper(inode);
>> + struct inode *realinode = upperinode ?: ovl_inode_lower(inode);
>> + struct file *realfile;
>> + const struct cred *old_cred;
>> +
>> + old_cred = ovl_override_creds(inode->i_sb);
>> + realfile = path_open(&file->f_path, file->f_flags | O_NOATIME,
>> + realinode, current_cred(), false);
>> + revert_creds(old_cred);
>> +
>> + pr_debug("open(%p[%pD2/%c], 0%o) -> (%p, 0%o)\n",
>> + file, file, upperinode ? 'u' : 'l', file->f_flags,
>> + realfile, IS_ERR(realfile) ? 0 : realfile->f_flags);
>> +
>> + return realfile;
>> +}
>
> IDGI. OK, you open a file in the layer you want; good, but why the hell do
> you
> *not* use the dentry/vfsmount from the same layer?
>
> IOW, why does your path_open() get an explicit inode argument at all? With
> the
> rest of the work done in that series it looks like you should be able to use
> vfs_open() instead... Sure, for ovlfs file you want ->f_path on overlayfs and
> not in a layer, but why do the same for those?
I'd really like to get there some time but...
List of basic requirements:
- Private mmap of overlay file shares page cache with lower file (and
hence with all other overlays using the same lower file).
- /proc/PID/maps shows correct path.
Thought about setting f_mapping/i_mapping of overlay file to that of
underlying file. But that breaks when doing a copy-up. We can't just
go and change those mapping pointers, assumption is that those remain
constant (we'd need READ_ONCE() for all cases where we use the mapping
more than once). It's probably doable, but it's a large and fragile
change.
Thanks,
Miklos
Re: [PATCH 6/6] mmc: host: sdhci-sprd: added Spreadtrum's host controller R11
On 8 June 2018 at 10:18, Chunyan Zhang wrote:
> From: Chunyan Zhang
>
> This patch adds the initial support of Secure Digital Host Controller
> Interface compliant controller - R11 found in some latest Spreadtrum
> chipsets.
>
> R11 is a variant based on SD v4.0 specification.
>
> With this driver, mmc can be initialized, can be mounted, read and
> written.
>
> Original-by: Billows Wu
> Signed-off-by: Chunyan Zhang
> ---
> drivers/mmc/host/Kconfig | 13 ++
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/sdhci-sprd-r11.c | 472
> ++
> 3 files changed, 486 insertions(+)
> create mode 100644 drivers/mmc/host/sdhci-sprd-r11.c
This is a DT based driver. Please add a separate patch describing the
corresponding bindings and compatibles.
[...]
> +static int sdhci_sprd_get_dt_resource(struct platform_device *pdev,
> + struct sdhci_sprd_host *sprd_host)
> +{
> + int ret = 0;
> + struct clk *clk;
> +
> + clk = devm_clk_get(&pdev->dev, "sdio");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + dev_warn(&pdev->dev, "Failed to get sdio clock (%d)\n", ret);
> + goto out;
> + }
> + sprd_host->clk_sdio = clk;
> +
> + clk = devm_clk_get(&pdev->dev, "source");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + dev_warn(&pdev->dev, "Failed to get source clock (%d)\n",
> ret);
> + goto out;
> + }
> + sprd_host->clk_source = clk;
> +
> + clk_set_parent(sprd_host->clk_sdio, sprd_host->clk_source);
> + sprd_host->base_rate = clk_get_rate(sprd_host->clk_source);
> + if (!sprd_host->base_rate) {
> + sprd_host->base_rate = 2600;
> + dev_warn(&pdev->dev, "The source clock rate is 0\n");
> + }
> +
The above can be managed by the assigned-clock* DT bindings. Please
have a look at:
Documentation/devicetree/bindings/clock/clock-bindings.txt
drivers/clk/clk-conf.c
> + clk = devm_clk_get(&pdev->dev, "enable");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + dev_warn(&pdev->dev, "Failed to get gate clock (%d)\n", ret);
The printed name of the clock doesn't match the name used in
devm_clk_get() call.
BTW, I think devm_clk_get() already prints some information when it
fails to lookup a clock. Isn't that sufficient?
> + goto out;
> + }
> + sprd_host->clk_enable = clk;
> +
> +out:
> + return ret;
> +}
> +
> +static void sdhci_sprd_set_mmc_struct(struct platform_device *pdev,
> + struct mmc_host *mmc)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct sdhci_host *host = mmc_priv(mmc);
> +
> + mmc->caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED |
> + MMC_CAP_ERASE | MMC_CAP_CMD23;
> +
> + mmc_of_parse(mmc);
> + mmc_of_parse_voltage(np, &host->ocr_mask);
mmc_of_parse_voltage() is intended to be used for controllers that
internally manages the powered to the card. Is that really the case?
I assume you have external regulator(s) to manage that, no?
> +
> + mmc->ocr_avail = 0x4;
> + mmc->ocr_avail_sdio = mmc->ocr_avail;
> + mmc->ocr_avail_sd = mmc->ocr_avail;
> + mmc->ocr_avail_mmc = mmc->ocr_avail;
If there is external regulators used, all the above can go away. In
either case, at least the *_sdio, *_sd, *_mmc can go away.
> +
> + mmc->max_current_330 = SDHCI_SPRD_MAX_CUR;
> + mmc->max_current_300 = SDHCI_SPRD_MAX_CUR;
> + mmc->max_current_180 = SDHCI_SPRD_MAX_CUR;
This should probably also be fetched used an external regulator and
sdhci already manages that.
> +
> + host->dma_mask = DMA_BIT_MASK(64);
> + mmc_dev(host->mmc)->dma_mask = &host->dma_mask;
> +}
[...]
> +
> +static unsigned int sdhci_sprd_get_min_clock(struct sdhci_host *host)
> +{
> + return 40;
> +}
Isn't there a more straightforward way to assign the minimum clock
rate? Do you really need to use a callback?
> +
> +static void sdhci_sprd_reset(struct sdhci_host *host, u8 mask)
> +{
> + sdhci_reset(host, mask);
> +}
Looks like an unnecessary wrapper function.
[...]
> +static int sdhci_sprd_probe(struct platform_device *pdev)
> +{
> + struct sdhci_host *host;
> + struct sdhci_sprd_host *sprd_host;
> + int ret = 0;
> +
> + host = sdhci_pltfm_init(pdev, &sdhci_sprd_pdata, sizeof(*sprd_host));
> + if (IS_ERR(host))
> + return PTR_ERR(host);
> +
> + sprd_host = TO_SPRD_HOST(host);
> +
> + ret = sdhci_sprd_get_dt_resource(pdev, sprd_host);
> + if (ret)
> + goto pltfm_free;
> +
> + clk_prepare_enable(sprd_host->clk_sdio);
> + clk_prepare_enable(sprd_host->clk_enable);
> +
> + sdhci_sprd_init_config(host);
> +
> + sdhci_sprd_set_mmc_struct(pdev, host->mmc);
Re: [linus:master] BUILD REGRESSION 68abbe729567cef128b2c2141f2ed2567f3b8372
On Sat, Jun 09, 2018 at 08:29:17AM +0800, Philip Li wrote: > On Fri, Jun 08, 2018 at 08:48:29AM -0700, Linus Torvalds wrote: > > On Fri, Jun 8, 2018 at 8:12 AM kbuild test robot wrote: > > > > > > arch/sh/include/asm/io.h:246:32: warning: cast to pointer from integer of > > > different size [-Wint-to-pointer-cast] > > > arch/x86/net/bpf_jit_comp32.c:2449 do_jit() warn: potential off by one > > > 'addrs[]' limit 'bpf_prog->len' > > > drivers/acpi/battery.c:720:3-9: preceding lock on line 701 > > > drivers/gpu/drm/amd/amdkfd/Kconfig:8: unknown option "imply" > > > drivers/gpu/drm/amd/amdkfd/Kconfig:9: syntax error > > > .. lots of these .. > > > > Hmm? Is the kbuild robot not feeling well? This looks odd. > Thanks Linus, we will follow up to check what possibly went wrong here, > this does look unreasonable. Hi Linus, this is caused by some cherry picked old commits are compiled on one randconfig, and triggers bisect. The error is discussed before as you may know, at https://patchwork.kernel.org/patch/9459363/ or http://lkml.iu.edu/hypermail/linux/kernel/1611.2/01337.html. The bisect considers the errors belong to mainline tree, meanwhile, there's a corner case, the bot sends out this mail externally which is supposed to send only internally for double check. Kindly ignore this. We will continue the improvement of the bot. > > > > > Linus > >
[PATCH v2 2/2] platform/x86: asus-wmi: Add keyboard backlight toggle support
Some ASUS laptops like UX550GE has hotkey (Fn+F7) for keyboard
backlight toggle which would emit the scan code 0xc7 each keypress.
On the UX550GE, the max keyboard brightness level is 3 so the
toggle would not be simply on/off the led but need to be cyclic.
Per ASUS spec, it should increment the brightness for each keypress,
then toggle(off) the LED when it already reached the max level.
Signed-off-by: Chris Chiu
---
drivers/platform/x86/asus-wmi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index a18484f4bae3..bfcafca54a7a 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -67,6 +67,7 @@ MODULE_LICENSE("GPL");
#define NOTIFY_BRNDOWN_MAX 0x2e
#define NOTIFY_KBD_BRTUP 0xc4
#define NOTIFY_KBD_BRTDWN 0xc5
+#define NOTIFY_KBD_BRTTOGGLE 0xc7
/* WMI Methods */
#define ASUS_WMI_METHODID_SPEC 0x43455053 /* BIOS SPECification */
@@ -1755,6 +1756,13 @@ static void asus_wmi_notify(u32 value, void *context)
kbd_led_set(&asus->kbd_led, asus->kbd_led_wk - 1);
goto exit;
}
+ if (code == NOTIFY_KBD_BRTTOGGLE) {
+ if (asus->kbd_led_wk == asus->kbd_led.max_brightness)
+ kbd_led_set(&asus->kbd_led, 0);
+ else
+ kbd_led_set(&asus->kbd_led, asus->kbd_led_wk + 1);
+ goto exit;
+ }
if (is_display_toggle(code) &&
asus->driver->quirks->no_display_toggle)
--
2.11.0
[PATCH v2 1/2] platform/x86: asus-wmi: Call led hw_changed API on kbd brightness change
Make asus-wmi notify on hotkey kbd brightness changes, listen for
brightness events and update the brightness directly in the driver.
For this purpose, bound check on brightness in kbd_led_set must be
based on the same data type to prevent illegal value been set.
Update the brightness by led_classdev_notify_brightness_hw_changed.
This will allow userspace to monitor (poll) for brightness changes
on the LED without reporting via input keymapping.
Signed-off-by: Chris Chiu
---
drivers/platform/x86/asus-wmi.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 1f6e68f0b646..a18484f4bae3 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -460,6 +460,7 @@ static void kbd_led_update(struct work_struct *work)
ctrl_param = 0x80 | (asus->kbd_led_wk & 0x7F);
asus_wmi_set_devstate(ASUS_WMI_DEVID_KBD_BACKLIGHT, ctrl_param, NULL);
+ led_classdev_notify_brightness_hw_changed(&asus->kbd_led,
asus->kbd_led_wk);
}
static int kbd_led_read(struct asus_wmi *asus, int *level, int *env)
@@ -497,9 +498,9 @@ static void kbd_led_set(struct led_classdev *led_cdev,
asus = container_of(led_cdev, struct asus_wmi, kbd_led);
- if (value > asus->kbd_led.max_brightness)
+ if ((int)value > (int)asus->kbd_led.max_brightness)
value = asus->kbd_led.max_brightness;
- else if (value < 0)
+ else if ((int)value < 0)
value = 0;
asus->kbd_led_wk = value;
@@ -656,6 +657,7 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
asus->kbd_led_wk = led_val;
asus->kbd_led.name = "asus::kbd_backlight";
+ asus->kbd_led.flags = LED_BRIGHT_HW_CHANGED;
asus->kbd_led.brightness_set = kbd_led_set;
asus->kbd_led.brightness_get = kbd_led_get;
asus->kbd_led.max_brightness = 3;
@@ -1745,6 +1747,15 @@ static void asus_wmi_notify(u32 value, void *context)
}
}
+ if (code == NOTIFY_KBD_BRTUP) {
+ kbd_led_set(&asus->kbd_led, asus->kbd_led_wk + 1);
+ goto exit;
+ }
+ if (code == NOTIFY_KBD_BRTDWN) {
+ kbd_led_set(&asus->kbd_led, asus->kbd_led_wk - 1);
+ goto exit;
+ }
+
if (is_display_toggle(code) &&
asus->driver->quirks->no_display_toggle)
goto exit;
--
2.11.0
Re: [PATCH 07/39] vfs: export vfs_ioctl() to modules
On Sun, Jun 10, 2018 at 6:57 AM, Al Viro wrote: > On Mon, Jun 04, 2018 at 01:49:04AM -0700, Christoph Hellwig wrote: >> On Tue, May 29, 2018 at 04:43:07PM +0200, Miklos Szeredi wrote: >> > This is needed by the stacked ioctl implementation in overlayfs. >> >> EXPORT_SYMBOL_GPL for exporting random internals, please. Same >> for any following patches. > > *blink* > > Christoph, get real and RTFS - vfs_ioctl() simply calls ->unlocked_ioctl(); > all there is to it. > > This isn't even a case of "using that function establishes that the > caller is a derived work" - *anyone* who can see definition of > file_operations can bloody well open-code it. There isn't anything > establishing derivation here. > > Hell, it could've been a static inline in include/linux/fs.h and it would > neither differ from many other inlines in there nor need an export at all. > > This is really getting close to lxo-worthy levels of bogosity... > > More interesting question is why do we want to pass those ioctls to layers > in the first place, especially if it's something with different availability > (or, worse yet, argument layouts) before and after copyup. We don't. Obviously need to make sure to only ever do ioctl's in overlayfs that have a common definition across filesystems. Not a lot of those, luckily... Thanks, Miklos
Re: [PATCH] mm/madvise: allow MADV_DONTNEED to free memory that is MLOCK_ONFAULT
[CCing linux-api - please make sure to CC this mailing list anytime you
are touching user visible apis]
On Fri 08-06-18 14:56:52, Jason Baron wrote:
> In order to free memory that is marked MLOCK_ONFAULT, the memory region
> needs to be first unlocked, before calling MADV_DONTNEED. And if the region
> is to be reused as MLOCK_ONFAULT, we require another call to mlock2() with
> the MLOCK_ONFAULT flag.
>
> Let's simplify freeing memory that is set MLOCK_ONFAULT, by allowing
> MADV_DONTNEED to work directly for memory that is set MLOCK_ONFAULT.
I do not understand the point here. How is MLOCK_ONFAULT any different
from the regular mlock here? If you want to free mlocked memory then
fine but the behavior should be consistent. MLOCK_ONFAULT is just a way
to say that we do not want to pre-populate the mlocked area and do that
lazily on the page fault time. madvise should make any difference here.
That being said we do not allow MADV_DONTNEED on VM_LOCKED since ever. I
do not really see why but this would be a user visible change. Can we do
that? What was the original motivation for exclusion?
[keeping the rest of email for linux-api]
> The
> locked memory limits, tracked by mm->locked_vm do not need to be adjusted
> in this case, since they were charged to the entire region when
> MLOCK_ONFAULT was initially set.
>
> Further, I don't think allowing MADV_FREE for MLOCK_ONFAULT regions makes
> sense, since the point of MLOCK_ONFAULT is for userspace to know when pages
> are locked in memory and thus to know when page faults will occur.
>
> Signed-off-by: Jason Baron
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: Vlastimil Babka
> Cc: Joonsoo Kim
> Cc: Mel Gorman
> Cc: Kirill A. Shutemov
> ---
> mm/internal.h | 18 ++
> mm/madvise.c | 4 ++--
> mm/oom_kill.c | 2 +-
> 3 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index 9e3654d..16c0041 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * The set of flags that only affect watermark checking and reclaim
> @@ -45,9 +46,26 @@ void free_pgtables(struct mmu_gather *tlb, struct
> vm_area_struct *start_vma,
>
> static inline bool can_madv_dontneed_vma(struct vm_area_struct *vma)
> {
> + return !(((vma->vm_flags & (VM_LOCKED|VM_LOCKONFAULT)) == VM_LOCKED) ||
> + (vma->vm_flags & (VM_HUGETLB|VM_PFNMAP)));
> +}
> +
> +static inline bool can_madv_free_vma(struct vm_area_struct *vma)
> +{
> return !(vma->vm_flags & (VM_LOCKED|VM_HUGETLB|VM_PFNMAP));
> }
>
> +static inline bool can_madv_dontneed_or_free_vma(struct vm_area_struct *vma,
> + int behavior)
> +{
> + if (behavior == MADV_DONTNEED)
> + return can_madv_dontneed_vma(vma);
> + else if (behavior == MADV_FREE)
> + return can_madv_free_vma(vma);
> + else
> + return 0;
> +}
> +
> void unmap_page_range(struct mmu_gather *tlb,
>struct vm_area_struct *vma,
>unsigned long addr, unsigned long end,
> diff --git a/mm/madvise.c b/mm/madvise.c
> index 4d3c922..61ff306 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -517,7 +517,7 @@ static long madvise_dontneed_free(struct vm_area_struct
> *vma,
> int behavior)
> {
> *prev = vma;
> - if (!can_madv_dontneed_vma(vma))
> + if (!can_madv_dontneed_or_free_vma(vma, behavior))
> return -EINVAL;
>
> if (!userfaultfd_remove(vma, start, end)) {
> @@ -539,7 +539,7 @@ static long madvise_dontneed_free(struct vm_area_struct
> *vma,
>*/
> return -ENOMEM;
> }
> - if (!can_madv_dontneed_vma(vma))
> + if (!can_madv_dontneed_or_free_vma(vma, behavior))
> return -EINVAL;
> if (end > vma->vm_end) {
> /*
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 8ba6cb8..9817d15 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -492,7 +492,7 @@ void __oom_reap_task_mm(struct mm_struct *mm)
> set_bit(MMF_UNSTABLE, &mm->flags);
>
> for (vma = mm->mmap ; vma; vma = vma->vm_next) {
> - if (!can_madv_dontneed_vma(vma))
> + if (!can_madv_free_vma(vma))
> continue;
>
> /*
> --
> 2.7.4
>
--
Michal Hocko
SUSE Labs
Re: [PATCH] pcmcia: add error handling for pcmcia_enable_device
On Mon, Jun 11, 2018 at 01:15:50PM +0800, Zhouyang Jia wrote:
> When pcmcia_enable_device fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling pcmcia_enable_device.
>
> Signed-off-by: Zhouyang Jia
> ---
> drivers/scsi/pcmcia/qlogic_stub.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/pcmcia/qlogic_stub.c
> b/drivers/scsi/pcmcia/qlogic_stub.c
> index 0556054..9287d52 100644
> --- a/drivers/scsi/pcmcia/qlogic_stub.c
> +++ b/drivers/scsi/pcmcia/qlogic_stub.c
> @@ -254,8 +254,14 @@ static void qlogic_release(struct pcmcia_device *link)
> static int qlogic_resume(struct pcmcia_device *link)
> {
> scsi_info_t *info = link->priv;
> + int ret;
> +
> + ret = pcmcia_enable_device(link);
> + if (ret) {
> + pcmcia_disable_device(link);
> + return -ENODEV;
> + }
pcmcia_enable_device() can fail for three reasons:
1) the socket is not present
2) the configuration is locked
3) setting the socket's power control fails
In all three cases I think it's actually an error to call
pcmcia_disable_device().
Imagine the following scenario:
pcmcia_enable_device() failed because the device configuration is
locked by another driver, then you call pcmcia_disable_device() which
calls pcmcia_release_configuration(). pcmcia_release_configuration()
checks if the device is locked, decrements the lock counter, clears
the CONFIG_LOCKED bit in the PCMCIA config and sets the voltage to 0
without the first driver every noticing it.
Byte,
Johannes
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: INFO: task hung in __sb_start_write
On Sun, Jun 10, 2018 at 11:47:56PM +0900, Tetsuo Handa wrote: > This looks quite strange that nobody is holding percpu_rw_semaphore for > write but everybody is stuck trying to hold it for read. (Since there > is no "X locks held by ..." line without followup "#0:" line, there is > no possibility that somebody is in TASK_RUNNING state while holding > percpu_rw_semaphore for write.) > > I feel that either API has a bug or API usage is wrong. > Any idea for debugging this? Look at percpu_rwsem_release() and usage. The whole fs freezer thing is magic.
[PATCH 1/2] perf record: Support s390 random socket_id assignment
On s390 the socket identifier assigned to a CPU identifier is
random and (depending on the configuration of the LPAR) may be higher
than the CPU identifier. This is currently not supported.
Fix this by allowing arbitrary socket identifiers being assigned to
CPU id.
Output before:
[root@p23lp27 perf]# ./perf report --header -I -v
...
socket_id number is too big.You may need to upgrade the perf tool.
Error:
The perf.data file has no samples!
#
# captured on: Tue May 29 09:29:57 2018
# header version : 1
...
# Core ID and Socket ID information is not available
...
[root@p23lp27 perf]#
Output after:
[root@p23lp27 perf]# ./perf report --header -I -v
...
Error:
The perf.data file has no samples!
#
# captured on: Tue May 29 09:29:57 2018
# header version : 1
...
# CPU 0: Core ID 0, Socket ID 6
# CPU 1: Core ID 1, Socket ID 3
# CPU 2: Core ID -1, Socket ID -1
...
[root@p23lp27 perf]#
Signed-off-by: Thomas Richter
Reviewed-by: Hendrik Brueckner
---
tools/perf/util/header.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index a8bff2178fbc..34e9d6b9d945 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -2113,6 +2113,7 @@ static int process_cpu_topology(struct feat_fd *ff, void
*data __maybe_unused)
int cpu_nr = ff->ph->env.nr_cpus_avail;
u64 size = 0;
struct perf_header *ph = ff->ph;
+ bool do_core_id_test = true;
ph->env.cpu = calloc(cpu_nr, sizeof(*ph->env.cpu));
if (!ph->env.cpu)
@@ -2167,6 +2168,13 @@ static int process_cpu_topology(struct feat_fd *ff, void
*data __maybe_unused)
return 0;
}
+ /* On s390 the socket_id number is not related to the numbers of cpus.
+* The socket_id number might be higher than the numbers of cpus.
+* This depends on the configuration.
+*/
+ if (ph->env.arch && !strncmp(ph->env.arch, "s390", 4))
+ do_core_id_test = false;
+
for (i = 0; i < (u32)cpu_nr; i++) {
if (do_read_u32(ff, &nr))
goto free_cpu;
@@ -2176,7 +2184,7 @@ static int process_cpu_topology(struct feat_fd *ff, void
*data __maybe_unused)
if (do_read_u32(ff, &nr))
goto free_cpu;
- if (nr != (u32)-1 && nr > (u32)cpu_nr) {
+ if (do_core_id_test && nr != (u32)-1 && nr > (u32)cpu_nr) {
pr_debug("socket_id number is too big."
"You may need to upgrade the perf tool.\n");
goto free_cpu;
--
2.14.3
[PATCH 2/2] perf test: Fix test 39 Session topology for s390
On s390 this test case fails because the socket identifiction numbers
assigned to the CPU are higher than the CPU identification numbers.
Fix this by adding the platform architecture into the perf data header
flag information. This helps identifiing the test platform and handles
s390 specifics in process_cpu_topology().
Output before:
[root@p23lp27 perf]# ./perf test -v -F 39
39: Session topology :
--- start ---
templ file: /tmp/perf-test-iUv755
socket_id number is too big.You may need to upgrade the perf tool.
end
Session topology: Skip
[root@p23lp27 perf]#
Output after:
[root@p23lp27 perf]# ./perf test -v -F 39
39: Session topology :
--- start ---
templ file: /tmp/perf-test-8X8VTs
CPU 0, core 0, socket 6
CPU 1, core 1, socket 3
end
Session topology: Ok
[root@p23lp27 perf]#
Fixes: c84974ed9fb6 ("perf test: Add entry to test cpu topology")
Signed-off-by: Thomas Richter
Reviewed-by: Hendrik Brueckner
---
tools/perf/tests/topology.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/tests/topology.c b/tools/perf/tests/topology.c
index 40e30a26b23c..9497d02f69e6 100644
--- a/tools/perf/tests/topology.c
+++ b/tools/perf/tests/topology.c
@@ -45,6 +45,7 @@ static int session_write_header(char *path)
perf_header__set_feat(&session->header, HEADER_CPU_TOPOLOGY);
perf_header__set_feat(&session->header, HEADER_NRCPUS);
+ perf_header__set_feat(&session->header, HEADER_ARCH);
session->header.data_size += DATA_SIZE;
--
2.14.3
Re: [PATCH] mm: fix null pointer dereference in mem_cgroup_protected
On Fri 08-06-18 18:06:07, Roman Gushchin wrote:
> Shakeel reported a crash in mem_cgroup_protected(), which
> can be triggered by memcg reclaim if the legacy cgroup v1
> use_hierarchy=0 mode is used:
>
> [ 226.060572] BUG: unable to handle kernel NULL pointer dereference
> at 0120
> [ 226.068310] PGD 801ff55da067 P4D 801ff55da067 PUD 1fdc7df067 PMD 0
> [ 226.075191] Oops: [#4] SMP PTI
> [ 226.078637] CPU: 0 PID: 15581 Comm: bash Tainted: G D
> 4.17.0-smp-clean #5
> [ 226.086635] Hardware name: ...
> [ 226.094546] RIP: 0010:mem_cgroup_protected+0x54/0x130
> [ 226.099533] Code: 4c 8b 8e 00 01 00 00 4c 8b 86 08 01 00 00 48 8d
> 8a 08 ff ff ff 48 85 d2 ba 00 00 00 00 48 0f 44 ca 48 39 c8 0f 84 cf
> 00 00 00 <48> 8b 81 20 01 00 00 4d 89 ca 4c 39 c8 4c 0f 46 d0 4d 85 d2
> 74 05
> [ 226.118194] RSP: :abe64dfafa58 EFLAGS: 00010286
> [ 226.123358] RAX: 9fb6ff03d000 RBX: 9fb6f5b1b000 RCX:
>
> [ 226.130406] RDX: RSI: 9fb6f5b1b000 RDI:
> 9fb6f5b1b000
> [ 226.137454] RBP: abe64dfafb08 R08: R09:
>
> [ 226.144503] R10: R11: c800 R12:
> abe64dfafb88
> [ 226.151551] R13: 9fb6f5b1b000 R14: abe64dfafb88 R15:
> 9fb77fffe000
> [ 226.158602] FS: 7fed1f8ac700() GS:9fb6ff40()
> knlGS:
> [ 226.166594] CS: 0010 DS: ES: CR0: 80050033
> [ 226.172270] CR2: 0120 CR3: 001fdcf86003 CR4:
> 001606f0
> [ 226.179317] Call Trace:
> [ 226.181732] ? shrink_node+0x194/0x510
> [ 226.185435] do_try_to_free_pages+0xfd/0x390
> [ 226.189653] try_to_free_mem_cgroup_pages+0x123/0x210
> [ 226.194643] try_charge+0x19e/0x700
> [ 226.198088] mem_cgroup_try_charge+0x10b/0x1a0
> [ 226.202478] wp_page_copy+0x134/0x5b0
> [ 226.206094] do_wp_page+0x90/0x460
> [ 226.209453] __handle_mm_fault+0x8e3/0xf30
> [ 226.213498] handle_mm_fault+0xfe/0x220
> [ 226.217285] __do_page_fault+0x262/0x500
> [ 226.221158] do_page_fault+0x28/0xd0
> [ 226.224689] ? page_fault+0x8/0x30
> [ 226.228048] page_fault+0x1e/0x30
> [ 226.231323] RIP: 0033:0x485b72
>
> The problem happens because parent_mem_cgroup() returns a NULL
> pointer, which is dereferenced later without a check.
>
> As cgroup v1 has no memory guarantee support, let's make
> mem_cgroup_protected() immediately return MEMCG_PROT_NONE,
> if the given cgroup has no parent (non-hierarchical mode is used).
>
Fixes: bf8d5d52ffe8 ("memcg: introduce memory.min")
I guess.
> Reported-by: Shakeel Butt
> Signed-off-by: Roman Gushchin
> Cc: Johannes Weiner
> Cc: Michal Hocko
> Cc: Andrew Morton
Acked-by: Michal Hocko
I really do not see why the whole min limit thing had to be rushed into
mainline. It has clearly not been tested for all configurations. Sigh...
> ---
> mm/memcontrol.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 6c9fb4e47be3..6205ba512928 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -5750,6 +5750,9 @@ enum mem_cgroup_protection mem_cgroup_protected(struct
> mem_cgroup *root,
> elow = memcg->memory.low;
>
> parent = parent_mem_cgroup(memcg);
> + if (!parent)
> + return MEMCG_PROT_NONE;
> +
This deserves a comment.
/* No parent means a non-hierarchical mode on v1 memcg */
> if (parent == root_mem_cgroup)
> goto exit;
>
> --
> 2.14.3
--
Michal Hocko
SUSE Labs
Re: [PATCH -next] media/platform/cadence: add to fix build error
On Fri, Jun 08, 2018 at 02:19:06PM -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Add #include to fix build errors. > This driver uses kzalloc() and kfree() so it needs to #include > the appropriate header file for those interfaces. > > Fixes these build errors: > > ../drivers/media/platform/cadence/cdns-csi2rx.c: In function 'csi2rx_probe': > ../drivers/media/platform/cadence/cdns-csi2rx.c:421:2: error: implicit > declaration of function 'kzalloc' [-Werror=implicit-function-declaration] > csi2rx = kzalloc(sizeof(*csi2rx), GFP_KERNEL); > ../drivers/media/platform/cadence/cdns-csi2rx.c:421:9: warning: assignment > makes pointer from integer without a cast [enabled by default] > csi2rx = kzalloc(sizeof(*csi2rx), GFP_KERNEL); > ../drivers/media/platform/cadence/cdns-csi2rx.c:466:2: error: implicit > declaration of function 'kfree' [-Werror=implicit-function-declaration] > kfree(csi2rx); > > Signed-off-by: Randy Dunlap > Cc: Maxime Ripard Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature
Re: [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
On 11/06/18 08:44, Keiichi Watanabe wrote: > Hi, Hans. > Thank you for the review. > Your idea sounds good. > > However, I think that changing V4L2_CID_MPEG_VIDEO_VPX_PROFILE to an enum > breaks both of s5p-mfc and venus drivers. This is because they call > 'v4l2_ctrl_new_std' for it. For menu controls, > 'v4l2_ctrl_new_std_menu' must be used. > > https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c#L2678 > https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/qcom/venus/vdec_ctrls.c#L133 > > I can fix them within the commit for adding VP8_PROFILE control, but > cannot confirm that it works on real devices since I don't have them. > What should I do? Fix it in both drivers with a Cc to stanimir.varba...@linaro.org (venus) and s.nawro...@samsung.com (s5p) to let them test/ack the patch. Venus is no problem, the s5p driver can decide to keep the old INT control since it has been in use for such a long time, but that is up to Sylwester to decide. Regards, Hans > > Best regards, > Keiichi > On Fri, Jun 8, 2018 at 10:00 PM Nicolas Dufresne wrote: >> >> >> >> Le ven. 8 juin 2018 08:56, Stanimir Varbanov >> a écrit : >>> >>> Hi Hans, >>> >>> On 06/08/2018 12:29 PM, Hans Verkuil wrote: On 05/30/2018 09:16 AM, Keiichi Watanabe wrote: > Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired > profile for VP9 encoder and querying for supported profiles by VP9 encoder > or decoder. > > An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be > used for querying since it is not a menu control but an integer > control, which cannot return an arbitrary set of supported profiles. > > The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as > with controls for other codec profiles. (e.g. H264) Please ignore my reply to patch 2/2. I looked at this a bit more and what you should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum. All other codec profile controls are all enums, so the fact that VPX_PROFILE isn't is a bug. Changing the type should not cause any problems since the same control value is used when you set the control. Sylwester: I see that s5p-mfc uses this control, but it is explicitly added as an integer type control, so the s5p-mfc driver should not be affected by changing the type of this control. Stanimir: this will slightly change the venus driver, but since it is a very recent driver I think we can get away with changing the core type of the VPX_PROFILE control. I think that's better than ending up with two controls that do the same thing. >>> >>> I agree. Actually the changes shouldn't be so much in venus driver. >> >> >> Also fine on userspace side, since profiles enumeration isn't implemented >> yet in FFMPEG, GStreamer, Chrome >> >> >>> >>> -- >>> regards, >>> Stan
[PATCH 1/2] KVM: Fix lock holder candidate yield
From: Wanpeng Li
After detecting pause loop which is executed by a Lock Waiter in the
guest, the pCPU will be yielded to a Lock Holder candidate, the Lock
Holder candidate may have its own task affinity constrain, however,
current yield logic yield to the Lock Holder condidate unconditionally
w/o checking the affinity constrain and set the task to the next buddy
of cfs, this will break the scheduler. This patch fixes it by skipping
the candidate vCPU if the current pCPU doesn't meat the affinity constrain.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Peter Zijlstra
Cc: Ingo Molnar
Signed-off-by: Wanpeng Li
---
virt/kvm/kvm_main.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index aa7da1d8e..ccf8907 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2239,17 +2239,40 @@ void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
EXPORT_SYMBOL_GPL(kvm_vcpu_kick);
#endif /* !CONFIG_S390 */
-int kvm_vcpu_yield_to(struct kvm_vcpu *target)
+struct task_struct *vcpu_to_task(struct kvm_vcpu *target)
{
struct pid *pid;
struct task_struct *task = NULL;
- int ret = 0;
rcu_read_lock();
pid = rcu_dereference(target->pid);
if (pid)
task = get_pid_task(pid, PIDTYPE_PID);
rcu_read_unlock();
+ return task;
+}
+
+bool kvm_vcpu_allow_yield(struct kvm_vcpu *target)
+{
+ struct task_struct *task = NULL;
+ bool ret = false;
+
+ task = vcpu_to_task(target);
+ if (!task)
+ return ret;
+ if (cpumask_test_cpu(raw_smp_processor_id(), &task->cpus_allowed))
+ ret = true;
+ put_task_struct(task);
+
+ return ret;
+}
+
+int kvm_vcpu_yield_to(struct kvm_vcpu *target)
+{
+ struct task_struct *task = NULL;
+ int ret = 0;
+
+ task = vcpu_to_task(target);
if (!task)
return ret;
ret = yield_to(task, 1);
@@ -2333,6 +2356,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool
yield_to_kernel_mode)
continue;
if (!kvm_vcpu_eligible_for_directed_yield(vcpu))
continue;
+ if (!kvm_vcpu_allow_yield(vcpu))
+ continue;
yielded = kvm_vcpu_yield_to(vcpu);
if (yielded > 0) {
--
2.7.4
[PATCH 2/2] sched/core: Consider afffinity constrain when yield to a task
From: Wanpeng Li
Consider the task afffinity constrain when yield to a task.
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Peter Zijlstra
Cc: Ingo Molnar
Signed-off-by: Wanpeng Li
---
kernel/sched/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 092f7c4..11001ff 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5102,6 +5102,9 @@ int __sched yield_to(struct task_struct *p, bool preempt)
if (task_running(p_rq, p) || p->state)
goto out_unlock;
+ if (!cpumask_test_cpu(smp_processor_id(), &p->cpus_allowed))
+ goto out_unlock;
+
yielded = curr->sched_class->yield_to_task(rq, p, preempt);
if (yielded) {
schedstat_inc(rq->yld_count);
--
2.7.4
Re: INFO: task hung in __sb_start_write
On Mon, Jun 11, 2018 at 9:30 AM, Peter Zijlstra wrote: > On Sun, Jun 10, 2018 at 11:47:56PM +0900, Tetsuo Handa wrote: > >> This looks quite strange that nobody is holding percpu_rw_semaphore for >> write but everybody is stuck trying to hold it for read. (Since there >> is no "X locks held by ..." line without followup "#0:" line, there is >> no possibility that somebody is in TASK_RUNNING state while holding >> percpu_rw_semaphore for write.) >> >> I feel that either API has a bug or API usage is wrong. >> Any idea for debugging this? > > Look at percpu_rwsem_release() and usage. The whole fs freezer thing is > magic. Do you mean that we froze fs? We tried to never-ever issue ioctl(FIFREEZE) during fuzzing. Are there other ways to do this?
[PATCH] MAINTAINERS: update two greybus sections
Fix a file entry typo and drop the obsolete timesync entries, which were all caught by: scripts/get_maintainer.pl --self-test=patterns Reported-by: Joe Perches Signed-off-by: Johan Hovold --- This has been reported and at least partially fixed in the past, but due to various other clean-up work that was going on in MAINTAINERS at the time, was never applied. Johan MAINTAINERS | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9c125f705f78..09d7f9eb5c13 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6065,7 +6065,7 @@ F:drivers/staging/greybus/bootrom.c F: drivers/staging/greybus/firmware.h F: drivers/staging/greybus/fw-core.c F: drivers/staging/greybus/fw-download.c -F: drivers/staging/greybus/fw-managament.c +F: drivers/staging/greybus/fw-management.c F: drivers/staging/greybus/greybus_authentication.h F: drivers/staging/greybus/greybus_firmware.h F: drivers/staging/greybus/hid.c @@ -6074,12 +6074,10 @@ F: drivers/staging/greybus/spi.c F: drivers/staging/greybus/spilib.c F: drivers/staging/greybus/spilib.h -GREYBUS LOOPBACK/TIME PROTOCOLS DRIVERS +GREYBUS LOOPBACK DRIVER M: Bryan O'Donoghue S: Maintained F: drivers/staging/greybus/loopback.c -F: drivers/staging/greybus/timesync.c -F: drivers/staging/greybus/timesync_platform.c GREYBUS PLATFORM DRIVERS M: Vaibhav Hiremath -- 2.17.1
Re: [PATCH v3 6/9] x86: prevent inline distortion by paravirt ops
On Sun, Jun 10, 2018 at 07:19:08AM -0700, Nadav Amit wrote: > +/* > + * This generates an indirect call based on the operation type number. > + * The type number, computed in PARAVIRT_PATCH, is derived from the > + * offset into the paravirt_patch_template structure, and can therefore be > + * freely converted back into a structure offset. > + */ > +.macro PARAVIRT_ALT type:req clobber:req pv_opptr:req Unlike the marcro maze you replaced, this has the CALL hardcoded in. So maybe name this PARAVIRT_CALL instead of PARAVIRT_ALT ? > +771: ANNOTATE_RETPOLINE_SAFE > + call *\pv_opptr > +772: .pushsection .parainstructions,"a" > + _ASM_ALIGN > + _ASM_PTR 771b > + .byte \type > + .byte 772b-771b > + .short \clobber > + .popsection > +.endm
[PATCH] media: cx88: add error handling for snd_ctl_add
When snd_ctl_add fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling snd_ctl_add.
Signed-off-by: Zhouyang Jia
---
drivers/media/pci/cx88/cx88-alsa.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88-alsa.c
b/drivers/media/pci/cx88/cx88-alsa.c
index 8a28fda..d366793 100644
--- a/drivers/media/pci/cx88/cx88-alsa.c
+++ b/drivers/media/pci/cx88/cx88-alsa.c
@@ -962,8 +962,11 @@ static int cx88_audio_initdev(struct pci_dev *pci,
goto error;
/* If there's a wm8775 then add a Line-In ALC switch */
- if (core->sd_wm8775)
- snd_ctl_add(card, snd_ctl_new1(&snd_cx88_alc_switch, chip));
+ if (core->sd_wm8775) {
+ err = snd_ctl_add(card, snd_ctl_new1(&snd_cx88_alc_switch,
chip));
+ if (err < 0)
+ goto error;
+ }
strcpy(card->driver, "CX88x");
sprintf(card->shortname, "Conexant CX%x", pci->device);
--
2.7.4
Re: [PATCH 03/11] spi: Add a driver for the Freescale/NXP QuadSPI controller
Hi Yogesh, On Mon, 11 Jun 2018 06:31:00 + Yogesh Narayan Gaur wrote: > > > > > Observation 2: > > I have observed data sanity issue after performing read/write > > operations using MTD interface. Explained below > > > > root:~# mtd_debug erase /dev/mtd0 0x100 0x4 > > Erased 262144 bytes from address 0x0100 in flash > > --> Erase at address 0x100 of erase size 0x4 > > root:~# mtd_debug read /dev/mtd0 0x0 0x100 rp > > Copied 256 bytes from address 0x in flash to rp > > --> Read 0x100 bytes from flash from address 0x0 in file rp > > root:~# mtd_debug write /dev/mtd0 0x100 0x100 rp > > Copied 256 bytes from rp to address 0x0100 in flash > > --> Write 0x100 bytes to flash address 0x100 from file rp > > root:~# mtd_debug read /dev/mtd0 0x100 0x100 wp > > Copied 256 bytes from address 0x0100 in flash to wp > > --> Read 0x100 bytes from flash from address 0x100 in file wp > > root:~# diff rp wp > > --> compare both rp and wp files, if they > > are different output comes on console stating file are different > > Files rp and wp differ > > root:~# hexdump wp > > 000 aa55 aa55 8010 541c 4000 0040 > > 010 000a > > 020 0030 11a0 00a0 2580 > > 030 0040 005b > > 040 > > * > > 100 > > root:~# hexdump rp > > 000 aa55 aa55 8010 541c 4000 0040 > > 010 000a > > 020 0030 11a0 00a0 2580 > > 030 0040 005b > > 040 2403 > > 050 > > * > > 070 0011 09e7 4411 9555 0050 > > 080 f9bc afa1 0404 31e0 > > 090 0400 31e0 2010 08dc 31eb > > 0a0 2880 0050 1300 31eb 4e20 8010 80ff > > 0b0 beef dead beef dead beef dead > > 0c0 beef dead beef dead beef dead beef dead > > * > > 100 > > root:~# > > > > In hexdump output of the file which being read from address 0x100,wp, > > it can be observed that only first 64 bytes (0x40) are written on the flash. > > > > Observation 3: > > As we can support JFFS2 filesystem on NOR flash, so we can expect JFFS2 > > commands should work fine on NOR flash. > > But with this driver change my mount command is not working. > > > > In my target there are 2 flash slave devices connected, and I have given > > argument to create MTD partition like > > "mtdparts=20c.quadspi-1:5M(rcw),10M(test),46M(rootfs) " for 2nd flash. > > Below is output for /proc/mtd commands > > root@ls1012ardb:~# cat /proc/mtd > > dev:size erasesize name > > mtd0: 0400 0004 "20c.quadspi-0" --> First 64MB flash > > mtd1: 0050 0004 "rcw" --> Second > > 64 MB flash device, 3 MTD partition are created for it. > > mtd2: 00a0 0004 "test" > > mtd3: 02e0 0004 "rootfs" > > > > root@ls1012ardb:~# mkdir /media/ram ; flash_eraseall /dev/mtd3 > > flash_eraseall has been replaced by `flash_erase 0 0`; please > > use it > > Erasing 256 Kibyte @ 0 -- 0 % complete [ 18.299929] random: crng > > init done > > Erasing 256 Kibyte @ 2dc -- 100 % complete > > root@ls1012ardb:~# mount -t jffs2 /dev/mtdblock3 /media/ram/ > > > > This command didn't finish successfully and there are lot of messages > > coming on console mentioning failure in jffs2_scan_eraseblock() > > [ 187.118677] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not > > found at 0x013c: 0x2886 instead > > [ 187.128159] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not > > found at 0x013c0004: 0x7a3b instead > > [ 187.137641] jffs2: jffs2_scan_eraseblock(): Magic bitmask > > 0x1985 not found at 0x013c0008: 0xb10f instead > > > > If I remove this patch series and check with older implementation, JFFS2 > > mounting is working fine. > > Problems 2 and 3 should definitely be fixed. That's weird because I remember > that Frieder tested the new driver with a NOR chip, maybe not with JFFS2 > though. > > For write issue, it would be happening due to the changes pushed in spi-mem > framework. Now I understand why Frieder didn't face this issue: he was testing on an imx6 which has a 512 bytes TX FIFO, while you're probably testing on a vhybrid or layerscape platform which only has a 64 bytes TX FIFO. I think it's time to accept having partial page writes. This has come up several times (last time was [1]) and it looks like the fsl quadspi driver was already doing this sort of things (well hidden in the probe path [2] :-)). Marek, any comment on that? Regards,
Re: [PATCH 04/24] 32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
On Sat, Jun 9, 2018 at 9:42 AM, Yury Norov wrote: > On Fri, Jun 08, 2018 at 06:32:07PM +0100, Catalin Marinas wrote: >> On Wed, May 16, 2018 at 11:18:49AM +0300, Yury Norov wrote: >> > diff --git a/arch/Kconfig b/arch/Kconfig >> > index 76c0b54443b1..ee079244dc3c 100644 >> > --- a/arch/Kconfig >> > +++ b/arch/Kconfig >> > @@ -264,6 +264,21 @@ config ARCH_THREAD_STACK_ALLOCATOR >> > config ARCH_WANTS_DYNAMIC_TASK_STRUCT >> > bool >> > >> > +config ARCH_32BIT_OFF_T >> > + bool >> > + depends on !64BIT >> > + help >> > + All new 32-bit architectures should have 64-bit off_t type on >> > + userspace side which corresponds to the loff_t kernel type. This >> > + is the requirement for modern ABIs. Some existing architectures >> > + already have 32-bit off_t. This option is enabled for all such >> > + architectures explicitly. Namely: arc, arm, blackfin, cris, frv, >> > + h8300, hexagon, m32r, m68k, metag, microblaze, mips32, mn10300, >> > + nios2, openrisc, parisc32, powerpc32, score, sh, sparc, tile32, >> > + unicore32, x86_32 and xtensa. This is the complete list. Any >> > + new 32-bit architecture should declare 64-bit off_t type on user >> > + side and so should not enable this option. >> >> Do you know if this is the case for riscv and nds32, merged in the >> meantime? If not, I suggest you drop this patch altogether and just >> define force_o_largefile() for arm64/ilp32 as we don't seem to stick to >> "all new 32-bit architectures should have 64-bit off_t". > > I wrote this patch at request of Arnd Bergmann. This is actually his > words that all new 32-bit architectures should have 64-bit off_t. So > I was surprized when riscv was merged with 32-bit off_t (and I didn't > follow nds32). > > If this rule is still in force, we'd better add new exceptions to this > patch. Otherwise, we can drop it. > > Arnd, could you please comment it? I completely forgot about it and had assumed that it was merged long ago, sorry about that. Arnd
Re: [PATCH v3 9/9] x86: jump-labels: use macros instead of inline assembly
On Sun, Jun 10, 2018 at 07:19:11AM -0700, Nadav Amit wrote:
> static __always_inline bool arch_static_branch(struct static_key *key, bool
> branch)
> {
> + asm_volatile_goto("STATIC_BRANCH_GOTO l_yes=\"%l[l_yes]\" key=\"%c0\" "
> + "branch=\"%c1\""
> + : : "i" (key), "i" (branch) : : l_yes);
>
> return false;
> l_yes:
> @@ -48,13 +44,8 @@ static __always_inline bool arch_static_branch(struct
> static_key *key, bool bran
>
> static __always_inline bool arch_static_branch_jump(struct static_key *key,
> bool branch)
> {
> + asm_volatile_goto("STATIC_BRANCH_JUMP_GOTO l_yes=\"%l[l_yes]\"
> key=\"%c0\" "
> + "branch=\"%c1\""
> : : "i" (key), "i" (branch) : : l_yes);
>
> return false;
> @@ -108,6 +99,26 @@ struct jump_entry {
> .popsection
> .endm
>
> +.macro STATIC_BRANCH_GOTO l_yes:req key:req branch:req
STATIC_BRANCH_NOP
> +1:
> + .byte STATIC_KEY_INIT_NOP
> + .pushsection __jump_table, "aw"
> + _ASM_ALIGN
> + _ASM_PTR 1b, \l_yes, \key + \branch
> + .popsection
> +.endm
> +
> +.macro STATIC_BRANCH_JUMP_GOTO l_yes:req key:req branch:req
STATIC_BRANCH_JMP
> +1:
> + .byte 0xe9
> + .long \l_yes - 2f
> +2:
> + .pushsection __jump_table, "aw"
> + _ASM_ALIGN
> + _ASM_PTR 1b, \l_yes, \key + \branch
> + .popsection
> +.endm
> +
> #endif /* __ASSEMBLY__ */
Re: [PATCH] RISC-V: Handle R_RISCV_32 in modules
On Jun 08 2018, Palmer Dabbelt wrote:
> On Thu, 07 Jun 2018 03:27:27 PDT (-0700), sch...@suse.de wrote:
>> With CONFIG_MODVERSIONS=y the R_RISCV_32 relocation is used by the
>> __kcrctab section.
>>
>> Signed-off-by: Andreas Schwab
>> ---
>> arch/riscv/kernel/module.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
>> index 5dddba301d..1d5e9b934b 100644
>> --- a/arch/riscv/kernel/module.c
>> +++ b/arch/riscv/kernel/module.c
>> @@ -17,6 +17,17 @@
>> #include
>> #include
>>
>> +static int apply_r_riscv_32_rela(struct module *me, u32 *location, Elf_Addr
>> v)
>> +{
>> +if (v != (u32)v) {
>
> My worry with this kind of check is that it relies on some sort of
> undefined behavior in C and that at some point in the future GCC will just
> go decide the check can never fail. I checked and GCC doesn't elide these
> checks now, so I might be wrong.
>
> Is this defined to do what it looks like it's doing?
This is unsigned arithmetic, thus fully defined.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [RFC PATCH 2/2] media: docs-rst: Add encoder UAPI specification to Codec Interfaces
Hi Hans, On Thu, Jun 7, 2018 at 6:21 PM Hans Verkuil wrote: > > On 06/05/2018 12:33 PM, Tomasz Figa wrote: [snip] > > +Initialization > > +-- > > + > > +1. (optional) Enumerate supported formats and resolutions. See > > + capability enumeration. > > + > > +2. Set a coded format on the CAPTURE queue via :c:func:`VIDIOC_S_FMT` > > + > > + a. Required fields: > > + > > + i. type = CAPTURE > > + > > + ii. fmt.pix_mp.pixelformat set to a coded format to be produced > > + > > + b. Return values: > > + > > + i. EINVAL: unsupported format. > > I'm still not sure about returning an error in this case. > > And what should TRY_FMT do? > > Do you know what current codecs do? Return EINVAL or replace with a supported > format? > s5p-mfc returns -EINVAL, while mtk-vcodec and coda seem to fall back to current format. > It would be nice to standardize on one rule or another. > > The spec says that it should always return a valid format, but not all > drivers adhere > to that. Perhaps we need to add a flag to let the driver signal the behavior > of S_FMT > to userspace. > > This is a long-standing issue with S_FMT, actually. > Agreed. I'd personally prefer agreeing on one pattern to simplify things. I generally don't like the "negotiation hell" that the fallback introduces, but with the general documentation clearly stating such behavior, I'd be worried that returning an error actually breaks some userspace. [snip] > > +Encoding > > + > > + > > +This state is reached after a successful initialization sequence. In > > +this state, client queues and dequeues buffers to both queues via > > +:c:func:`VIDIOC_QBUF` and :c:func:`VIDIOC_DQBUF`, as per spec. > > + > > +Both queues operate independently. The client may queue and dequeue > > +buffers to queues in any order and at any rate, also at a rate different > > +for each queue. The client may queue buffers within the same queue in > > +any order (V4L2 index-wise). > > I'd drop the whole 'in any order' in the text above. This has always been > the case, and I think it is only confusing. I think what you really want > to say is that both queues operate independently and quite possibly at > different rates. So clients should operate them independently as well. I think there are at least 3 different "in any order" in play: 1) the order of buffers being dequeued not matching the order of queuing the buffers in the same queue (e.g. encoder keeping some buffers as reference framebuffers) 2) possible difference in order of queuing raw frames to encoder OUTPUT and dequeuing encoded bitstream from encoder CAPTURE, 3) the order of handling the queue/dequeue operations on both queues, i.e. dequeue OUTPUT, queue OUTPUT, dequeue CAPTURE, queue CAPTURE, 4) the order of queuing buffers (indices) within the queue being up to the client - this has always been the case indeed. The extra bit here is that this keeps being true, even with having 2 queues. I believe the text above refers to 3) and 4). I guess we can drop 4) indeed and we actually may want to clearly state 1) and 2). By the way, do we already have some place in the documentation that mentions the bits that have always been the case? We could refer to it instead. > > It is recommended for the client to operate > > +the queues independently for best performance. > > + > > +Source OUTPUT buffers must contain full raw frames in the selected > > +OUTPUT format, exactly one frame per buffer. > > + > > +Encoding parameter changes > > +-- > > + > > +The client is allowed to use :c:func:`VIDIOC_S_CTRL` to change encoder > > +parameters at any time. The driver must apply the new setting starting > > +at the next frame queued to it. > > + > > +This specifically means that if the driver maintains a queue of buffers > > +to be encoded and at the time of the call to :c:func:`VIDIOC_S_CTRL` not > > all the > > +buffers in the queue are processed yet, the driver must not apply the > > +change immediately, but schedule it for when the next buffer queued > > +after the :c:func:`VIDIOC_S_CTRL` starts being processed. > > Is this what drivers do today? I thought it was applied immediately? > This sounds like something for which you need the Request API. mtk-vcodec seems to implement the above, while s5p-mfc, coda, venus don't seem to be doing so. > > + > > +Flush > > +- > > + > > +Flush is the process of draining the CAPTURE queue of any remaining > > +buffers. After the flush sequence is complete, the client has received > > +all encoded frames for all OUTPUT buffers queued before the sequence was > > +started. > > + > > +1. Begin flush by issuing :c:func:`VIDIOC_ENCODER_CMD`. > > + > > + a. Required fields: > > + > > + i. cmd = ``V4L2_ENC_CMD_STOP`` > > + > > +2. The driver must process and encode as normal all OUTPUT buffers > > + queued by the client before the :c:func:`VIDIOC_ENCODER_CMD` was issued. > > Note: TRY_ENCODER_CMD should also be supporte
[PATCH] xen/netfront: raise max number of slots in xennet_get_responses()
The max number of slots used in xennet_get_responses() is set to MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD). In old kernel-xen MAX_SKB_FRAGS was 18, while nowadays it is 17. This difference is resulting in frequent messages "too many slots" and a reduced network throughput for some workloads (factor 10 below that of a kernel-xen based guest). Replacing MAX_SKB_FRAGS by XEN_NETIF_NR_SLOTS_MIN for calculation of the max number of slots to use solves that problem (tests showed no more messages "too many slots" and throughput was as high as with the kernel-xen based guest system). Signed-off-by: Juergen Gross --- drivers/net/xen-netfront.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 679da1abd73c..ba411005d829 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -790,7 +790,7 @@ static int xennet_get_responses(struct netfront_queue *queue, RING_IDX cons = queue->rx.rsp_cons; struct sk_buff *skb = xennet_get_rx_skb(queue, cons); grant_ref_t ref = xennet_get_rx_ref(queue, cons); - int max = MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD); + int max = XEN_NETIF_NR_SLOTS_MIN + (rx->status <= RX_COPY_THRESHOLD); int slots = 1; int err = 0; unsigned long ret; -- 2.13.7
Re: [PATCH 19/39] ovl: add ovl_mmap()
On Sun, Jun 10, 2018 at 06:24:59AM +0100, Al Viro wrote:
> On Tue, May 29, 2018 at 04:43:19PM +0200, Miklos Szeredi wrote:
> > Implement stacked mmap.
> >
> > Signed-off-by: Miklos Szeredi
> > ---
> > fs/overlayfs/file.c | 28
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
> > index 7b47dce4b072..4057bbf2e141 100644
> > --- a/fs/overlayfs/file.c
> > +++ b/fs/overlayfs/file.c
> > @@ -255,6 +255,33 @@ static int ovl_fsync(struct file *file, loff_t start,
> > loff_t end, int datasync)
> > return ret;
> > }
> >
> > +static int ovl_mmap(struct file *file, struct vm_area_struct *vma)
> > +{
> > + struct fd real;
> > + const struct cred *old_cred;
> > + int ret;
> > +
> > + ret = ovl_real_fdget(file, &real);
> > + if (ret)
> > + return ret;
> > +
> > + /* transfer ref: */
> > + fput(vma->vm_file);
> > + vma->vm_file = get_file(real.file);
> > + fdput(real);
> > +
> > + if (!vma->vm_file->f_op->mmap)
> > + return -ENODEV;
>
> That's broken. ->mmap() failure will fput(file), not fput(vma->vm_file).
> What's more, _here_ your "corner case" is a huge DoS - open file r/o,
> then have somebody else trigger copyup, then do tons of MAP_PRIVATE
> mmaps on the r/o descriptor. *EACH* *OF* *THEM* will open a separate
> struct file and stash into into new vmas.
>
> NAK with extreme prejudice, sensu PTerry...
Okay, okay, got it now. Incremental below. It's a step back (mmap after
copy-up will get old data), but not a regression from current state. Obviously
need to fix properly and I think that's doable together with dealing with shared
map coherency.
diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
index f801e1175a0b..b5a6bcc1bcfa 100644
--- a/fs/overlayfs/file.c
+++ b/fs/overlayfs/file.c
@@ -282,26 +282,30 @@ static int ovl_fsync(struct file *file, loff_t start,
loff_t end, int datasync)
static int ovl_mmap(struct file *file, struct vm_area_struct *vma)
{
- struct fd real;
+ struct file *realfile = file->private_data;
const struct cred *old_cred;
int ret;
- ret = ovl_real_fdget(file, &real);
- if (ret)
- return ret;
+ if (!realfile->f_op->mmap)
+ return -ENODEV;
- /* transfer ref: */
- fput(vma->vm_file);
- vma->vm_file = get_file(real.file);
- fdput(real);
+ if (WARN_ON(file != vma->vm_file))
+ return -EIO;
- if (!vma->vm_file->f_op->mmap)
- return -ENODEV;
+ vma->vm_file = get_file(realfile);
old_cred = ovl_override_creds(file_inode(file)->i_sb);
ret = call_mmap(vma->vm_file, vma);
revert_creds(old_cred);
+ if (ret) {
+ /* Drop reference count from new vm_file value */
+ fput(realfile);
+ } else {
+ /* Drop reference count from previous vm_file value */
+ fput(file);
+ }
+
ovl_file_accessed(file);
return ret;
