Re: [PATCH 09/16 linux-next] net: xilinx: constify of_device_id array
On 03/17/2015 07:37 PM, Fabian Frederick wrote:
> of_device_id is always used as const.
> (See driver.of_match_table and open firmware functions)
>
> Signed-off-by: Fabian Frederick
> ---
> drivers/net/ethernet/xilinx/ll_temac_main.c | 2 +-
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
> drivers/net/ethernet/xilinx/xilinx_emaclite.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/ll_temac_main.c
> b/drivers/net/ethernet/xilinx/ll_temac_main.c
> index dbcbf0c..690a4c3 100644
> --- a/drivers/net/ethernet/xilinx/ll_temac_main.c
> +++ b/drivers/net/ethernet/xilinx/ll_temac_main.c
> @@ -1157,7 +1157,7 @@ static int temac_of_remove(struct platform_device *op)
> return 0;
> }
>
> -static struct of_device_id temac_of_match[] = {
> +static const struct of_device_id temac_of_match[] = {
> { .compatible = "xlnx,xps-ll-temac-1.01.b", },
> { .compatible = "xlnx,xps-ll-temac-2.00.a", },
> { .compatible = "xlnx,xps-ll-temac-2.02.a", },
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index a6d2860..28b7e7d 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -48,7 +48,7 @@
> #define AXIENET_REGS_N 32
>
> /* Match table for of_platform binding */
> -static struct of_device_id axienet_of_match[] = {
> +static const struct of_device_id axienet_of_match[] = {
> { .compatible = "xlnx,axi-ethernet-1.00.a", },
> { .compatible = "xlnx,axi-ethernet-1.01.a", },
> { .compatible = "xlnx,axi-ethernet-2.01.a", },
> diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> index 9d4ce38..2111b91 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> @@ -1231,7 +1231,7 @@ static struct net_device_ops xemaclite_netdev_ops = {
> };
>
> /* Match table for OF platform binding */
> -static struct of_device_id xemaclite_of_match[] = {
> +static const struct of_device_id xemaclite_of_match[] = {
> { .compatible = "xlnx,opb-ethernetlite-1.01.a", },
> { .compatible = "xlnx,opb-ethernetlite-1.01.b", },
> { .compatible = "xlnx,xps-ethernetlite-1.00.a", },
>
Acked-by: Michal Simek
Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[update][PATCH v10 06/21] ACPI / sleep: Introduce CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT
From: Graeme Gregory
ACPI 5.1 does not currently support S states for ARM64 hardware but
ACPI code will call acpi_target_system_state() and acpi_sleep_init()
for device power management, so introduce
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT and select it for x86 and
ia64 only to make sleep functions available, and also introduce stub
function to allow other drivers to function until S states are defined
for ARM64.
It will be no functional change for x86 and IA64.
Suggested-by: Rafael J. Wysocki
Acked-by: Lorenzo Pieralisi
Signed-off-by: Graeme Gregory
Signed-off-by: Tomasz Nowicki
Signed-off-by: Hanjun Guo
---
Hi Lorenzo,
Since this patch only updated the config name with no fucntion
change, I assume your ACK still apply, if not, please let me
know.
Thanks
Hanjun
---
arch/ia64/Kconfig | 1 +
arch/x86/Kconfig| 1 +
drivers/acpi/Kconfig| 4
drivers/acpi/Makefile | 2 +-
drivers/acpi/internal.h | 4
5 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 074e52b..cc3414f 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -10,6 +10,7 @@ config IA64
select ARCH_MIGHT_HAVE_PC_SERIO
select PCI if (!IA64_HP_SIM)
select ACPI if (!IA64_HP_SIM)
+ select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_IDE
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b7d31ca..c3ea9f9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -22,6 +22,7 @@ config X86_64
### Arch settings
config X86
def_bool y
+ select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
select ARCH_HAS_FAST_MULTIPLIER
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index e6c3ddd..a726381 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -48,9 +48,13 @@ config ACPI_LEGACY_TABLES_LOOKUP
config ARCH_MIGHT_HAVE_ACPI_PDC
bool
+config ACPI_SYSTEM_POWER_STATES_SUPPORT
+ bool
+
config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
+ depends on ACPI_SYSTEM_POWER_STATES_SUPPORT
default y
config ACPI_PROCFS_POWER
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 623b117..db153c6 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -23,7 +23,7 @@ acpi-y+= nvs.o
# Power management related files
acpi-y += wakeup.o
-acpi-y += sleep.o
+acpi-$(CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT) += sleep.o
acpi-y += device_pm.o
acpi-$(CONFIG_ACPI_SLEEP) += proc.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 56b321a..ba4a61e 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -161,7 +161,11 @@ void acpi_ec_remove_query_handler(struct acpi_ec *ec, u8
query_bit);
/*--
Suspend/Resume
-- */
+#ifdef CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT
extern int acpi_sleep_init(void);
+#else
+static inline int acpi_sleep_init(void) { return -ENXIO; }
+#endif
#ifdef CONFIG_ACPI_SLEEP
int acpi_sleep_proc_init(void);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] brcmfmac: cfg80211: use msecs_to_jiffies for time conversion
On Tue, 17 Mar 2015, Joe Perches wrote: > On Tue, 2015-03-17 at 08:06 -0400, Nicholas Mc Guire wrote: > > Converting milliseconds to jiffies by "val * HZ / 1000" is technically > > OK but msecs_to_jiffies(val) is the cleaner solution and handles all > > corner cases correctly. This is a minor API consolidation only and > > should make things more readable. > > Hi Nicholas > > These API consolidation changes now always have a function > call when the compiler may have previously been able to > optimize out the "constant * HZ / 1000" calculation. > > Perhaps the [um]secs_to_jiffies calls should be indirected > with yet another static inline with a __builtin_constant_p() > test so that the function calls can again be avoided when > possible. will give it a try > > (and a trivial style note) > > > diff --git a/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c > > b/drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c > [] > > @@ -1110,7 +1110,7 @@ brcmf_cfg80211_escan(struct wiphy *wiphy, struct > > brcmf_cfg80211_vif *vif, > > > > /* Arm scan timeout timer */ > > mod_timer(&cfg->escan_timeout, jiffies + > > - WL_ESCAN_TIMER_INTERVAL_MS * HZ / 1000); > > + msecs_to_jiffies(WL_ESCAN_TIMER_INTERVAL_MS)); > > It may be nicer to keep the arithmetic on one line sorry that was plain carelessness afer it went over 80 char. > > mod_timer(&cfg->escan_timeout, > jiffies + msecs_to_jiffies(WL_ESCAN_TIMER_INTERVAL_MS)); > thx! hofrat -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/8] Add support for Tegra Activity Monitor
On 18 March 2015 at 06:10, MyungJoo Ham wrote:
>> Hello,
>>
>> something happened during the last cycle and an old version of the devfreq
>> driver was merged.
>>
>> This thread contains patches that bring it up to date to the last submitted
>> version and also incorporates the feedback that that version received, plus
>> some other small fixes and improvements that came up during rebase and
>> testing.
>>
>> These patches implement support for setting the rate of the EMC clock based
>> on
>> stats collected from the ACTMON, a piece of hw in the Tegra124 that counts
>> memory accesses (among others).
>>
>> It depends on the following in-flight patches:
>>
>> * EMC driver: http://thread.gmane.org/gmane.linux.kernel/1907035
>> * CPUFreq driver: http://thread.gmane.org/gmane.linux.kernel/1897078
>>
>> I have pushed a branch here for testing:
>>
>> http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=actmon-v6
>>
>> Regards,
>>
>> Tomeu
>>
>> Tomeu Vizoso (8):
>> of: Add binding for NVIDIA Tegra ACTMON node
>> PM / devfreq: tegra: Update to v5 of the submitted patches
>> clk: tegra: Have EMC clock implement determine_rate()
>> PM / devfreq: tegra: Use clock rate constraints
>> PM / devfreq: tegra: remove operating-points
>> PM / devfreq: tegra: Set drvdata before enabling the irq
>> PM / devfreq: tegra: Enable interrupts after resuming the devfreq
>> monitor
>> ARM: tegra: Add Tegra124 ACTMON support
>
> Acked-by: MyungJoo Ham
> for all PM / devfreq patches (2, 4, 5, 6, 7)
> And merged in for-rc tree with a little modification.
Thanks. Though that's fine with me, I was wondering if Mikko or
Alexandre would have any comments on the changes, even if they are
small regarding what they already reviewed.
> In the patch 2/8, I would like to add "const" in Line 748.
> Would it be fine with you?
Yes, thanks, that's fine.
Regards,
Tomeu
> (You may look at:
> https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/log/?h=for-rc )
>
>
> The diff after applying all 2/8 to 7/8 will be:
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 0d1edd5..8e633a6 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -740,7 +740,7 @@ static int tegra_devfreq_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -static struct of_device_id tegra_devfreq_of_match[] = {
> +static const struct of_device_id tegra_devfreq_of_match[] = {
> { .compatible = "nvidia,tegra124-actmon" },
> { },
> };
>
>
>>
>> .../devicetree/bindings/arm/tegra/actmon.txt | 28 ++
>> arch/arm/boot/dts/tegra124.dtsi| 11 +
>> drivers/clk/tegra/clk-emc.c| 19 +-
>> drivers/devfreq/tegra-devfreq.c| 480
>> +++--
>> 4 files changed, 316 insertions(+), 222 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/arm/tegra/actmon.txt
>>
>> --
>> 2.1.0
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] tpm: fix: sanitized code paths in tpm_chip_register()
I started to work with PPI interface so that it would be available
under character device sysfs directory and realized that chip
registeration was still too messy.
In TPM 1.x in some rare scenarios (errors that almost never occur)
wrong order in deinitialization steps was taken in teardown. I
reproduced these scenarios by manually inserting error codes in the
place of the corresponding function calls.
The key problem is that the teardown is messy with two separate code
paths (this was inherited when moving code from tpm-interface.c).
Moved TPM 1.x specific register/unregister functionality to own helper
functions and added single code path for teardown in tpm_chip_register().
Now the code paths have been fixed and it should be easier to review
later on this part of the code.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 66 -
1 file changed, 42 insertions(+), 24 deletions(-)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index e096e9c..283f00a 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -170,6 +170,41 @@ static void tpm_dev_del_device(struct tpm_chip *chip)
device_unregister(&chip->dev);
}
+static int tpm1_chip_register(struct tpm_chip *chip)
+{
+ int rc;
+
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ return 0;
+
+ rc = tpm_sysfs_add_device(chip);
+ if (rc)
+ return rc;
+
+ rc = tpm_add_ppi(chip);
+ if (rc) {
+ tpm_sysfs_del_device(chip);
+ return rc;
+ }
+
+ chip->bios_dir = tpm_bios_log_setup(chip->devname);
+
+ return 0;
+}
+
+static void tpm1_chip_unregister(struct tpm_chip *chip)
+{
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ return;
+
+ if (chip->bios_dir)
+ tpm_bios_log_teardown(chip->bios_dir);
+
+ tpm_remove_ppi(chip);
+
+ tpm_sysfs_del_device(chip);
+}
+
/*
* tpm_chip_register() - create a character device for the TPM chip
* @chip: TPM chip to use.
@@ -185,22 +220,13 @@ int tpm_chip_register(struct tpm_chip *chip)
{
int rc;
- /* Populate sysfs for TPM1 devices. */
- if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
- rc = tpm_sysfs_add_device(chip);
- if (rc)
- goto del_misc;
-
- rc = tpm_add_ppi(chip);
- if (rc)
- goto del_sysfs;
-
- chip->bios_dir = tpm_bios_log_setup(chip->devname);
- }
+ rc = tpm1_chip_register(chip);
+ if (rc)
+ return rc;
rc = tpm_dev_add_device(chip);
if (rc)
- return rc;
+ goto out_err;
/* Make the chip available. */
spin_lock(&driver_lock);
@@ -210,10 +236,8 @@ int tpm_chip_register(struct tpm_chip *chip)
chip->flags |= TPM_CHIP_FLAG_REGISTERED;
return 0;
-del_sysfs:
- tpm_sysfs_del_device(chip);
-del_misc:
- tpm_dev_del_device(chip);
+out_err:
+ tpm1_chip_unregister(chip);
return rc;
}
EXPORT_SYMBOL_GPL(tpm_chip_register);
@@ -238,13 +262,7 @@ void tpm_chip_unregister(struct tpm_chip *chip)
spin_unlock(&driver_lock);
synchronize_rcu();
- if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
- if (chip->bios_dir)
- tpm_bios_log_teardown(chip->bios_dir);
- tpm_remove_ppi(chip);
- tpm_sysfs_del_device(chip);
- }
-
+ tpm1_chip_unregister(chip);
tpm_dev_del_device(chip);
}
EXPORT_SYMBOL_GPL(tpm_chip_unregister);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Mar 18
Hi all, Changes since 20150317: The vfs tree still had its build failure for which I applied a patch and gained a conflict against the ext3 tree. The slave-dma tree gained conflicts against the arm-soc and renesas trees. The crypto tree lost its build failure. The virtio tree gained a conflict against Linus' tree and a build failure for which I applied a merge fix patch. The kvm-arm tree gained a conflict against Linus' tree/ Non-merge commits (relative to Linus' tree): 4883 4598 files changed, 213489 insertions(+), 96777 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 210 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (c58616580ea5 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (6d021b724481 ARM: dump pgd, pmd and pte states on unhandled data abort faults) Merging m68k-current/for-linus (4436820a98cd m68k/defconfig: Enable Ethernet bridging) Merging metag-fixes/fixes (c2996cb29bfb metag: Fix KSTK_EIP() and KSTK_ESP() macros) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging powerpc-merge-mpe/fixes (06e5801b8cb3 Linux 4.0-rc4) Merging sparc/master (53eb2516972b sparc: semtimedop() unreachable due to comparison error) Merging net/master (8d7d9cca4390 Revert "smc91x: retrieve IRQ and trigger flags in a modern way") Merging ipsec/master (ac37e2515c1a xfrm: release dst_orig in case of error in xfrm_lookup()) Merging sound-current/for-linus (3fc6c5a1cfb9 Merge tag 'asoc-fix-v4.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (bc3b5b47c80d PCI: cpcihp: Add missing curly braces in cpci_configure_slot()) Merging wireless-drivers/master (c09396eb8e5a ath9k: disable TPC support again (for now)) Merging driver-core.current/driver-core-linus (d5e7cafd69da LZ4 : fix the data abort issue) Merging tty.current/tty-linus (7fd6f640f2dd serial: 8250_dw: Fix deadlock in LCR workaround) Merging usb.current/usb-linus (963ffa3e97d4 MAINTAINERS: add entry for USB OTG FSM) Merging usb-gadget-fixes/fixes (2c247804796b Revert "usb: gadget: zero: Add support for interrupt EP") Merging usb-serial-fixes/usb-linus (4899c054a904 USB: ftdi_sio: Added custom PID for Synapse Wireless product) Merging staging.current/staging-linus (1f51d5801859 vt6655: Fix late setting of byRFType.) Merging char-misc.current/char-misc-linus (3d7a8278fdfd Revert "pcmcia: add a new resource manager for non ISA systems") Merging input-current/for-linus (09d042a2eb90 Revert "Input: synaptics - use dmax in input_mt_assign_slots") Merging crypto-current/master (ccfe8c3f7e52 crypto: aesni - fix memory usage in GCM decryption) Merging ide/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays with sub-devices tests) Merging rr-fixes/fixes (f47689345931 lguest: update help text.) Merging vfio-fixes/for-linus (ec76f4007079 vfio-p
Re: [RFC 00/16] Introduce ZONE_CMA
2015-03-17 18:46 GMT+09:00 Aneesh Kumar K.V : > Joonsoo Kim writes: > >> I passed boot test on x86, ARM32 and ARM64. I did some stress tests >> on x86 and there is no problem. Feel free to enjoy and please give me >> a feedback. :) > > Tested on ppc64 with kvm. (I used the CONFIG_SPARSEMEM_VMEMMAP). I will > check with other sparsemem config and update if I find any issue. Wow! Really thanks for testing this patchset. I will test more and if any error is found, will notify soon. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] ARM: dts: mt8173: Add psci-0.2 cpuidle support
add device tree for psci-0.2 on mt8173 platform
add device tree for cupidle-arm64 on mt8173 platform
Signed-off-by: Howard Chen
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 8554ec3..96dff1e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -48,6 +48,8 @@
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x000>;
+ enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
cpu1: cpu@1 {
@@ -55,6 +57,7 @@
compatible = "arm,cortex-a53";
reg = <0x001>;
enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
cpu2: cpu@100 {
@@ -62,6 +65,7 @@
compatible = "arm,cortex-a57";
reg = <0x100>;
enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
cpu3: cpu@101 {
@@ -69,15 +73,33 @@
compatible = "arm,cortex-a57";
reg = <0x101>;
enable-method = "psci";
+ cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
};
+
+ idle-states {
+ entry-method = "arm,psci-0.2";
+
+ CPU_SLEEP_0_0: cpu-sleep-0-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x001>;
+ entry-latency-us = <600>;
+ exit-latency-us = <600>;
+ min-residency-us = <1200>;
+ };
+
+ CLUSTER_SLEEP_0: cluster-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x101>;
+ entry-latency-us = <800>;
+ exit-latency-us = <1000>;
+ min-residency-us = <2000>;
+ wakeup-latency-us = <1000>;
+ };
};
psci {
- compatible = "arm,psci";
+ compatible = "arm,psci-0.2";
method = "smc";
- cpu_suspend = <0x8401>;
- cpu_off = <0x8402>;
- cpu_on= <0x8403>;
};
uart_clk: dummy26m {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.
If a platform has a particular device permanently attached to a UART,
there may be out-of-band signaling necessary to power the device
on and off.
This driver controls that signalling for a number of different devices.
It can
- enable/disable a regulator
- toggle a GPIO
- register an 'rfkill' which can force the device to be off.
When the rfkill is absent or unblocked, the device will be on when the
associated tty device is open, and closed otherwise.
Signed-off-by: NeilBrown
---
.../bindings/tty_slave/wi2wi,w2cbw003.txt | 19 +
.../bindings/tty_slave/wi2wi,w2sg0004.txt | 37 +
.../devicetree/bindings/vendor-prefixes.txt|1
drivers/tty/slave/Kconfig | 14 +
drivers/tty/slave/Makefile |2
drivers/tty/slave/serial-power-manager.c | 510
6 files changed, 583 insertions(+)
create mode 100644
Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
create mode 100644
Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
create mode 100644 drivers/tty/slave/serial-power-manager.c
diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
new file mode 100644
index ..cfe6ee5e01e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
@@ -0,0 +1,19 @@
+wi2wi bluetooth module
+
+This is accessed via a serial port and is largely controlled via that
+link. Extra configuration is needed to enable power on/off
+
+Required properties:
+- compatible: "wi2wi,w2cbw003"
+- vdd-supply: regulator used to power the device.
+
+The node for this device must be the child of a UART.
+
+Example:
+
+&uart1 {
+ bluetooth {
+ compatible = "wi2wi,w2cbw003";
+ vdd-supply = <&vaux4>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
new file mode 100644
index ..fdc52cf56533
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
@@ -0,0 +1,37 @@
+wi2wi GPS device
+
+This is accessed via a serial port and is largely controlled via that
+link. Extra configuration is needed to enable power on/off
+
+Required properties:
+- compatible: "wi2wi,w2sg0004"
+- gpios: gpios used to toggle 'on/off' pin
+- interrupts: interrupt generated by RX pin when device
+ should be off
+
+Optional properties:
+- vdd-supply: regulator used to power antenna
+- pinctrl: "default", "off"
+ if "off" setting is provided it is imposed when device should
+ be off. This can route the RX pin to a GPIO interrupt.
+
+The w2sg0004 uses a pin-toggle both to power-on and to
+power-off, so the driver needs to detect what state it is in.
+It does this by detecting characters on the RX line.
+When it should be off, these can optionally be detected by a GPIO.
+
+The node for this device must be the child of a UART.
+
+Example:
+&uart2 {
+ gps {
+ compatible = "wi2iw,w2sg0004";
+ vdd-supply = <&vsim>;
+ gpios = <&gpio5 17 0>; /* GPIO_145 */
+ interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
+ /* When off, switch RX to be an interrupt */
+ pinctrl-names = "default", "off";
+ pinctrl-0 = <&uart2_pins>;
+ pinctrl-1 = <&uart2_pins_rx_gpio>;
+ };
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389ca1347a77..81d259303710 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -189,6 +189,7 @@ variscite Variscite Ltd.
viaVIA Technologies, Inc.
virtio Virtual I/O Device Specification, developed by the OASIS consortium
voipac Voipac Technologies s.r.o.
+wi2wi wi2wi Inc. http://www.wi2wi.com/
winbond Winbond Electronics corp.
wlfWolfson Microelectronics
wm Wondermedia Technologies, Inc.
diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
index 3976760c2e28..05c5d966ae57 100644
--- a/drivers/tty/slave/Kconfig
+++ b/drivers/tty/slave/Kconfig
@@ -5,3 +5,17 @@ menuconfig TTY_SLAVE
Devices which attach via a uart, but need extra
driver support for power management etc.
+if TTY_SLAVE
+
+config SERIAL_POWER_MANAGER
+ tristate "Power Management controller for serial-attached devices"
+ default n
+ help
+ Some devices permanently attached via a UART can benefit from
+ being power-managed when the tty device is opened or closed.
+ This driver can support several such devices with simple
+ power requirements such as enabling a regulator.
+
+ If in doubt, say 'N'
+
+endif
diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
i
[PATCH 0/3] tty slave device support - version 3.
Hi again, here is version 3 of support for tty-slaves. This version introduces a new bus-type for tty-slaves, and causes a tty-slave device to appear in /sys/devices between the uart and the tty. It effectively intercepts and calls from the tty to the uart (i.e. any tty_operations) and applies extra functionality at that point. Currently the only driver intercepts open and close. It powers on the device on open, and powers off at last-close. Power can be controlled by a regulator or by toggling a GPIO. I think I've incorporated most of the feed back I received from previous versions, but if I missed something - I apologize. If this approach is structurally acceptable then I can fix up all the smaller issues. Thanks for your review, NeilBrown --- NeilBrown (3): TTY: use class_find_device to find port in uart_suspend/resume. TTY: add support for tty_slave devices. tty/slaves: add a driver to power on/off UART attached devices. .../bindings/tty_slave/wi2wi,w2cbw003.txt | 19 + .../bindings/tty_slave/wi2wi,w2sg0004.txt | 37 + .../devicetree/bindings/vendor-prefixes.txt|1 drivers/tty/Kconfig|1 drivers/tty/Makefile |1 drivers/tty/serial/serial_core.c | 21 - drivers/tty/slave/Kconfig | 21 + drivers/tty/slave/Makefile |4 drivers/tty/slave/serial-power-manager.c | 510 drivers/tty/slave/tty_slave_core.c | 136 + drivers/tty/tty_io.c | 60 ++ include/linux/tty.h|2 include/linux/tty_slave.h | 26 + 13 files changed, 813 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt create mode 100644 drivers/tty/slave/Kconfig create mode 100644 drivers/tty/slave/Makefile create mode 100644 drivers/tty/slave/serial-power-manager.c create mode 100644 drivers/tty/slave/tty_slave_core.c create mode 100644 include/linux/tty_slave.h -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] TTY: use class_find_device to find port in uart_suspend/resume.
uart_{suspend,resume}_port seach the children of a uart device
to find a particular tty device.
This requires all the ttys to be direct children of the uart.
A future patch will allow a 'tty_slave' to intervene between
the port and the uart, voiding this requirement.
So change to use class_find_device. This is made possibly by
exporting a "tty_find_device" from tty_io.c
Signed-off-by: NeilBrown
---
drivers/tty/serial/serial_core.c | 21 -
drivers/tty/tty_io.c |6 ++
include/linux/tty.h |1 +
3 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 6a1055ae3437..7abb7474870a 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1960,26 +1960,19 @@ struct uart_match {
struct uart_driver *driver;
};
-static int serial_match_port(struct device *dev, void *data)
-{
- struct uart_match *match = data;
- struct tty_driver *tty_drv = match->driver->tty_driver;
- dev_t devt = MKDEV(tty_drv->major, tty_drv->minor_start) +
- match->port->line;
-
- return dev->devt == devt; /* Actually, only one tty per port */
-}
int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
{
struct uart_state *state = drv->state + uport->line;
struct tty_port *port = &state->port;
struct device *tty_dev;
- struct uart_match match = {uport, drv};
+ dev_t devt = MKDEV(drv->tty_driver->major,
+ drv->tty_driver->minor_start) +
+ uport->line;
mutex_lock(&port->mutex);
- tty_dev = device_find_child(uport->dev, &match, serial_match_port);
+ tty_dev = tty_find_device(devt);
if (device_may_wakeup(tty_dev)) {
if (!enable_irq_wake(uport->irq))
uport->irq_wake = 1;
@@ -2039,12 +2032,14 @@ int uart_resume_port(struct uart_driver *drv, struct
uart_port *uport)
struct uart_state *state = drv->state + uport->line;
struct tty_port *port = &state->port;
struct device *tty_dev;
- struct uart_match match = {uport, drv};
struct ktermios termios;
+ dev_t devt = MKDEV(drv->tty_driver->major,
+ drv->tty_driver->minor_start) +
+ uport->line;
mutex_lock(&port->mutex);
- tty_dev = device_find_child(uport->dev, &match, serial_match_port);
+ tty_dev = tty_find_device(devt);
if (!uport->suspended && device_may_wakeup(tty_dev)) {
if (uport->irq_wake) {
disable_irq_wake(uport->irq);
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 51f066aa375e..27632ad17d6f 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3077,6 +3077,12 @@ static struct device *tty_get_device(struct tty_struct
*tty)
return class_find_device(tty_class, NULL, &devt, dev_match_devt);
}
+struct device *tty_find_device(dev_t devt)
+{
+ return class_find_device(tty_class, NULL, &devt, dev_match_devt);
+}
+EXPORT_SYMBOL(tty_find_device);
+
/**
* alloc_tty_struct
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 358a337af598..04d5f1213700 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -461,6 +461,7 @@ extern void tty_vhangup(struct tty_struct *tty);
extern int tty_hung_up_p(struct file *filp);
extern void do_SAK(struct tty_struct *tty);
extern void __do_SAK(struct tty_struct *tty);
+extern struct device *tty_find_device(dev_t devt);
extern void no_tty(void);
extern void tty_flush_to_ldisc(struct tty_struct *tty);
extern void tty_buffer_free_all(struct tty_port *port);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] TTY: add support for tty_slave devices.
A "tty slave" is a device connected via UART.
Such a device may need its own driver, e.g. for powering
it up on tty open and powering it down on tty release.
tty-slave is a new bus-type which drivers can be written and devices
created.
A "tty slave" device is declared as a child of the uart in
device-tree:
&uart1 {
bluetooth {
compatible = "wi2wi,w2cbw003";
vdd-supply = <&vaux4>;
};
};
This device will be inserted in the driver-model tree between the uart
and the tty.
The tty-slave driver can replace any of the tty_operations functions
so a call by the tty can be intercepted before being handled by the uart.
Signed-off-by: NeilBrown
---
drivers/tty/Kconfig|1
drivers/tty/Makefile |1
drivers/tty/slave/Kconfig |7 ++
drivers/tty/slave/Makefile |2 +
drivers/tty/slave/tty_slave_core.c | 136
drivers/tty/tty_io.c | 54 +++---
include/linux/tty.h|1
include/linux/tty_slave.h | 26 +++
8 files changed, 215 insertions(+), 13 deletions(-)
create mode 100644 drivers/tty/slave/Kconfig
create mode 100644 drivers/tty/slave/Makefile
create mode 100644 drivers/tty/slave/tty_slave_core.c
create mode 100644 include/linux/tty_slave.h
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b24aa010f68c..f9155a45ee7c 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -419,4 +419,5 @@ config DA_CONSOLE
help
This enables a console on a Dash channel.
+source drivers/tty/slave/Kconfig
endif # TTY
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index 58ad1c05b7f8..ec57846eac29 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_GOLDFISH_TTY)+= goldfish.o
obj-$(CONFIG_DA_TTY) += metag_da.o
obj-y += ipwireless/
+obj-y += slave/
diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
new file mode 100644
index ..3976760c2e28
--- /dev/null
+++ b/drivers/tty/slave/Kconfig
@@ -0,0 +1,7 @@
+menuconfig TTY_SLAVE
+ tristate "TTY slave devices"
+ depends on OF
+ help
+ Devices which attach via a uart, but need extra
+ driver support for power management etc.
+
diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
new file mode 100644
index ..65669acb392e
--- /dev/null
+++ b/drivers/tty/slave/Makefile
@@ -0,0 +1,2 @@
+
+obj-$(CONFIG_TTY_SLAVE) += tty_slave_core.o
diff --git a/drivers/tty/slave/tty_slave_core.c
b/drivers/tty/slave/tty_slave_core.c
new file mode 100644
index ..6218ea5bb69e
--- /dev/null
+++ b/drivers/tty/slave/tty_slave_core.c
@@ -0,0 +1,136 @@
+/*
+ * tty-slave-core - device bus for tty slaves
+ *
+ * Copyright (C) 2015 NeilBrown
+ *
+ *This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * A "tty-slave" is a device permanently attached to a particularly
+ * tty, typically wired to a UART.
+ * A tty-slave has two particular roles.
+ * Firstly it can intercept any tty_operations to provide extra control
+ * of the device. For example it might intercept "open" and "close"
+ * in order to power the device up and down. It might intercept
+ * "hangup" to toggle a reset line on the device.
+ *
+ * Secondly it appears as a parent of the tty in the device model, so
+ * that any attributes it presents are visible to udev when the tty
+ * is added. This allows udev to start appropriate handlers such as
+ * hciattach or inputattach.
+ *
+ * tty-slave devices must be described in devicetree as a child node
+ * of the node which described the parent of the tty, typically a
+ * UART.
+ * If such a child is present, the tty device will not be registered
+ * until the slave device is fully probed and initialized.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+static int tty_slave_match(struct device *dev, struct device_driver *drv)
+{
+ return of_driver_match_device(dev, drv);
+}
+
+static void tty_slave_release(struct device *dev)
+{
+ kfree(dev);
+}
+
+struct bus_type tty_slave_bus_type = {
+ .name = "tty-slave",
+ .match = tty_slave_match,
+};
+
+int tty_slave_register(struct device *parent, struct device_node *node,
+ struct device *tty, struct tty_driver *drv)
+{
+ struct tty_slave *slave;
+ int retval;
Re: [PATCHv2] mm/slub: fix lockups on PREEMPT && !SMP kernels
2015-03-17 21:15 GMT+09:00 Mark Rutland :
> Commit 9aabf810a67cd97e ("mm/slub: optimize alloc/free fastpath by
> removing preemption on/off") introduced an occasional hang for kernels
> built with CONFIG_PREEMPT && !CONFIG_SMP.
>
> The problem is the following loop the patch introduced to
> slab_alloc_node and slab_free:
>
> do {
> tid = this_cpu_read(s->cpu_slab->tid);
> c = raw_cpu_ptr(s->cpu_slab);
> } while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != c->tid));
>
> GCC 4.9 has been observed to hoist the load of c and c->tid above the
> loop for !SMP kernels (as in this case raw_cpu_ptr(x) is compile-time
> constant and does not force a reload). On arm64 the generated assembly
> looks like:
>
> ffc00016d3c4: f9400404ldr x4, [x0,#8]
> ffc00016d3c8: f9400401ldr x1, [x0,#8]
> ffc00016d3cc: eb04003fcmp x1, x4
> ffc00016d3d0: 54c1b.neffc00016d3c8
>
>
> If the thread is preempted between the load of c->tid (into x1) and tid
> (into x4), and an allocation or free occurs in another thread (bumping
> the cpu_slab's tid), the thread will be stuck in the loop until
> s->cpu_slab->tid wraps, which may be forever in the absence of
> allocations/frees on the same CPU.
>
> This patch changes the loop condition to access c->tid with READ_ONCE.
> This ensures that the value is reloaded even when the compiler would
> otherwise assume it could cache the value, and also ensures that the
> load will not be torn.
>
> Signed-off-by: Mark Rutland
> Cc: Andrew Morton
> Cc: Catalin Marinas
> Cc: Christoph Lameter
> Cc: David Rientjes
> Cc: Jesper Dangaard Brouer
> Cc: Joonsoo Kim
> Cc: Linus Torvalds
> Cc: Pekka Enberg
> Cc: Steve Capper
> ---
> mm/slub.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Since v1 [1]:
> * Do not erroneously remove the loop
>
> [1] lkml.kernel.org/r/1426261632-8911-1-git-send-email-mark.rutl...@arm.com
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 6832c4e..82c4737 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2449,7 +2449,8 @@ redo:
> do {
> tid = this_cpu_read(s->cpu_slab->tid);
> c = raw_cpu_ptr(s->cpu_slab);
> - } while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != c->tid));
> + } while (IS_ENABLED(CONFIG_PREEMPT) &&
> +unlikely(tid != READ_ONCE(c->tid)));
>
> /*
> * Irqless object alloc/free algorithm used here depends on sequence
> @@ -2718,7 +2719,8 @@ redo:
> do {
> tid = this_cpu_read(s->cpu_slab->tid);
> c = raw_cpu_ptr(s->cpu_slab);
> - } while (IS_ENABLED(CONFIG_PREEMPT) && unlikely(tid != c->tid));
> + } while (IS_ENABLED(CONFIG_PREEMPT) &&
> +unlikely(tid != READ_ONCE(c->tid)));
>
> /* Same with comment on barrier() in slab_alloc_node() */
> barrier();
> --
Hello,
Could you show me generated code again?
What we need to check is redoing whole things in the loop.
Previous attached code seems to me that it already did
refetching c->tid in the loop and this patch looks only handle
refetching c->tid.
READ_ONCE(c->tid) will trigger redoing 'tid = this_cpu_read(s->cpu_slab->tid)'?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch: match more world writable permissions
On Tue, 2015-03-17 at 16:17 -0700, Andrew Morton wrote:
> ---
> a/scripts/checkpatch.pl~checkpatch-match-more-world-writable-permissions-fix
[]
> -$our $mode_perms_world_writable = qr{
> +our $mode_perms_world_writable = qr{
You're a perl monk too? Cool!
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] mm/vmalloc: occupy newly allocated vmap block just after allocation
2015-03-13 21:12 GMT+09:00 Roman Pen :
> Previous implementation allocates new vmap block and repeats search of a free
> block from the very beginning, iterating over the CPU free list.
>
> Why it can be better??
>
> 1. Allocation can happen on one CPU, but search can be done on another CPU.
>In worst case we preallocate amount of vmap blocks which is equal to
>CPU number on the system.
>
> 2. In previous patch I added newly allocated block to the tail of free list
>to avoid soon exhaustion of virtual space and give a chance to occupy
>blocks which were allocated long time ago. Thus to find newly allocated
>block all the search sequence should be repeated, seems it is not
> efficient.
>
> In this patch newly allocated block is occupied right away, address of virtual
> space is returned to the caller, so there is no any need to repeat the search
> sequence, allocation job is done.
>
> Signed-off-by: Roman Pen
> Cc: Nick Piggin
> Cc: Andrew Morton
> Cc: Eric Dumazet
> Cc: Joonsoo Kim
> Cc: David Rientjes
> Cc: WANG Chao
> Cc: Fabian Frederick
> Cc: Christoph Lameter
> Cc: Gioh Kim
> Cc: Rob Jones
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> ---
> mm/vmalloc.c | 57 -
> 1 file changed, 36 insertions(+), 21 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index db6bffb..9759c92 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -791,13 +791,30 @@ static unsigned long addr_to_vb_idx(unsigned long addr)
> return addr;
> }
>
> -static struct vmap_block *new_vmap_block(gfp_t gfp_mask)
> +static void *vmap_block_vaddr(unsigned long va_start, unsigned long
> pages_off)
> +{
> + unsigned long addr = va_start + (pages_off << PAGE_SHIFT);
> + BUG_ON(addr_to_vb_idx(addr) != addr_to_vb_idx(va_start));
Need one blank line between above two lines.
Please run script/checkpatch.pl.
> + return (void *)addr;
> +}
> +
> +/**
> + * new_vmap_block - allocates new vmap_block and occupies 2^order pages in
> this
> + * block. Of course pages number can't exceed
> VMAP_BBMAP_BITS
> + * @order:how many 2^order pages should be occupied in newly allocated
> block
> + * @gfp_mask: flags for the page level allocator
> + * @addr: output virtual address of a newly allocator block
> + *
> + * Returns: address of virtual space in a block or ERR_PTR
> + */
> +static void *new_vmap_block(unsigned int order, gfp_t gfp_mask)
> {
> struct vmap_block_queue *vbq;
> struct vmap_block *vb;
> struct vmap_area *va;
> unsigned long vb_idx;
> int node, err;
> + void *vaddr;
>
> node = numa_node_id();
>
> @@ -821,9 +838,12 @@ static struct vmap_block *new_vmap_block(gfp_t gfp_mask)
> return ERR_PTR(err);
> }
>
> + vaddr = vmap_block_vaddr(va->va_start, 0);
> spin_lock_init(&vb->lock);
> vb->va = va;
> - vb->free = VMAP_BBMAP_BITS;
> + /* At least something should be left free */
> + BUG_ON(VMAP_BBMAP_BITS <= (1UL << order));
> + vb->free = VMAP_BBMAP_BITS - (1UL << order);
> vb->dirty = 0;
> bitmap_zero(vb->dirty_map, VMAP_BBMAP_BITS);
> INIT_LIST_HEAD(&vb->free_list);
> @@ -841,7 +861,7 @@ static struct vmap_block *new_vmap_block(gfp_t gfp_mask)
> spin_unlock(&vbq->lock);
> put_cpu_var(vmap_block_queue);
>
> - return vb;
> + return vaddr;
> }
>
> static void free_vmap_block(struct vmap_block *vb)
> @@ -905,7 +925,7 @@ static void *vb_alloc(unsigned long size, gfp_t gfp_mask)
> {
> struct vmap_block_queue *vbq;
> struct vmap_block *vb;
> - unsigned long addr = 0;
> + void *vaddr = NULL;
> unsigned int order;
>
> BUG_ON(size & ~PAGE_MASK);
> @@ -920,43 +940,38 @@ static void *vb_alloc(unsigned long size, gfp_t
> gfp_mask)
> }
> order = get_order(size);
>
> -again:
> rcu_read_lock();
> vbq = &get_cpu_var(vmap_block_queue);
> list_for_each_entry_rcu(vb, &vbq->free, free_list) {
> - int i;
> + unsigned long pages_nr;
I think that pages_off is better. Is there any reason to use this naming?
Anyway, patch looks okay to me.
Acked-by: Joonsoo Kim
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mm/vmalloc: get rid of dirty bitmap inside vmap_block structure
2015-03-13 21:12 GMT+09:00 Roman Pen : > In original implementation of vm_map_ram made by Nick Piggin there were two > bitmaps: alloc_map and dirty_map. None of them were used as supposed to be: > finding a suitable free hole for next allocation in block. vm_map_ram > allocates > space sequentially in block and on free call marks pages as dirty, so freed > space can't be reused anymore. > > Actually would be very interesting to know the real meaning of those bitmaps, > maybe implementation was incomplete, etc. > > But long time ago Zhang Yanfei removed alloc_map by these two commits: > > mm/vmalloc.c: remove dead code in vb_alloc > 3fcd76e8028e0be37b02a2002b4f56755daeda06 > mm/vmalloc.c: remove alloc_map from vmap_block > b8e748b6c32999f221ea4786557b8e7e6c4e4e7a > > In current patch I replaced dirty_map with two range variables: dirty min and > max. These variables store minimum and maximum position of dirty space in a > block, since we need only to know the dirty range, not exact position of dirty > pages. > > Why it was made? Several reasons: at first glance it seems that vm_map_ram > allocator concerns about fragmentation thus it uses bitmaps for finding free > hole, but it is not true. To avoid complexity seems it is better to use > something simple, like min or max range values. Secondly, code also becomes > simpler, without iteration over bitmap, just comparing values in min and max > macros. Thirdly, bitmap occupies up to 1024 bits (4MB is a max size of a > block). Here I replaced the whole bitmap with two longs. > > Finally vm_unmap_aliases should be slightly faster and the whole vmap_block > structure occupies less memory. > > Signed-off-by: Roman Pen > Cc: Nick Piggin > Cc: Zhang Yanfei > Cc: Andrew Morton > Cc: Eric Dumazet > Cc: Joonsoo Kim > Cc: David Rientjes > Cc: WANG Chao > Cc: Fabian Frederick > Cc: Christoph Lameter > Cc: Gioh Kim > Cc: Rob Jones > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org Acked-by: Joonsoo Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] mfd: provide RTC resource in MT6397 MFD
Provide MT6397 RTC interrupt, base address, and register in
MT6397 MFD.
Signed-off-by: Eddie Huang
---
drivers/mfd/mt6397-core.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index b61c4eb..ef431d8 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -21,9 +21,24 @@
#include
#include
+static const struct resource mt6397_rtc_resources[] = {
+ {
+ .start = 0xe000,
+ .end = 0xe03e,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MT6397_IRQ_RTC,
+ .end = MT6397_IRQ_RTC,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
static const struct mfd_cell mt6397_devs[] = {
{
.name = "mt6397-rtc",
+ .num_resources = ARRAY_SIZE(mt6397_rtc_resources),
+ .resources = mt6397_rtc_resources,
.of_compatible = "mediatek,mt6397-rtc",
}, {
.name = "mt6397-regulator",
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] MAINTAINERS: add Mediatek RTC driver
Add Mediatek RTC driver to maintainer entry. Signed-off-by: Eddie Huang --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ddc5a8c..ca27a69 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1202,6 +1202,13 @@ W: http://www.digriz.org.uk/ts78xx/kernel S: Maintained F: arch/arm/mach-orion5x/ts78xx-* +ARM/Mediatek RTC DRIVER +M: Eddie Huang +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-media...@lists.infradead.org (moderated for non-subscribers) +S: Maintained +F: drivers/rtc/rtc-mt* + ARM/Mediatek SoC support M: Matthias Brugger L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] rtc: mediatek: Add MT6397 RTC driver
From: Tianping Fang
Add Mediatek MT6397 RTC driver
Signed-off-by: Tianping Fang
Signed-off-by: Eddie Huang
---
drivers/rtc/Kconfig | 10 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/rtc-mt6397.c | 454 +++
3 files changed, 465 insertions(+)
create mode 100644 drivers/rtc/rtc-mt6397.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b5b5c3d..dcb94af 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1510,6 +1510,16 @@ config RTC_DRV_MOXART
This driver can also be built as a module. If so, the module
will be called rtc-moxart
+config RTC_DRV_MT6397
+ tristate "Mediatek Real Time Clock driver"
+ depends on MFD_MT6397 || COMPILE_TEST
+ help
+ This selects the Mediatek(R) RTC driver. RTC is part of Mediatek
+ MT6397 PMIC. You should enable MT6397 PMIC MFD before select
+ Mediatek(R) RTC driver.
+
+ If you want to use Mediatek(R) RTC interface, select Y or M here.
+
config RTC_DRV_XGENE
tristate "APM X-Gene RTC"
depends on HAS_IOMEM
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 69c8706..85c8bea 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -153,3 +153,4 @@ obj-$(CONFIG_RTC_DRV_X1205) += rtc-x1205.o
obj-$(CONFIG_RTC_DRV_XGENE)+= rtc-xgene.o
obj-$(CONFIG_RTC_DRV_SIRFSOC) += rtc-sirfsoc.o
obj-$(CONFIG_RTC_DRV_MOXART) += rtc-moxart.o
+obj-$(CONFIG_RTC_DRV_MT6397) += rtc-mt6397.o
diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
new file mode 100644
index 000..130480d
--- /dev/null
+++ b/drivers/rtc/rtc-mt6397.c
@@ -0,0 +1,454 @@
+/*
+* Copyright (c) 2014-2015 MediaTek Inc.
+* Author: Tianping.Fang
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RTC_BBPU 0x
+#define RTC_WRTGR 0x003c
+#define RTC_IRQ_EN 0x0004
+#define RTC_IRQ_STA0x0002
+
+#define RTC_BBPU_CBUSY (1 << 6)
+#define RTC_IRQ_STA_AL (1 << 0)
+#define RTC_IRQ_STA_LP (1 << 3)
+
+#define RTC_AL_MASK0x0008
+#define RTC_TC_SEC 0x000a
+#define RTC_TC_MIN 0x000c
+#define RTC_TC_HOU 0x000e
+#define RTC_TC_DOM 0x0010
+#define RTC_TC_MTH 0x0014
+#define RTC_TC_YEA 0x0016
+#define RTC_AL_SEC 0x0018
+#define RTC_AL_MIN 0x001a
+
+#define RTC_IRQ_EN_AL (1 << 0)
+#define RTC_IRQ_EN_ONESHOT (1 << 2)
+#define RTC_IRQ_EN_LP (1 << 3)
+#define RTC_IRQ_EN_ONESHOT_AL (RTC_IRQ_EN_ONESHOT | RTC_IRQ_EN_AL)
+
+#define RTC_TC_MIN_MASK0x003f
+#define RTC_TC_SEC_MASK0x003f
+#define RTC_TC_HOU_MASK0x001f
+#define RTC_TC_DOM_MASK0x001f
+#define RTC_TC_MTH_MASK0x000f
+#define RTC_TC_YEA_MASK0x007f
+
+#define RTC_AL_SEC_MASK0x003f
+#define RTC_AL_MIN_MASK0x003f
+#define RTC_AL_MASK_DOW(1 << 4)
+
+#define RTC_AL_HOU 0x001c
+#define RTC_AL_HOU_MASK0x001f
+
+#define RTC_AL_DOM 0x001e
+#define RTC_AL_DOM_MASK0x001f
+
+#define RTC_AL_MTH 0x0022
+#define RTC_AL_MTH_MASK0x000f
+
+#define RTC_AL_YEA 0x0024
+#define RTC_AL_YEA_MASK0x007f
+
+#define RTC_PDN2 0x002e
+#define RTC_PDN2_PWRON_MTH_MASK0x000f
+#define RTC_PDN2_PWRON_MTH_SHIFT 0
+#define RTC_PDN2_PWRON_ALARM (1 << 4)
+#define RTC_PDN2_UART_MASK 0x0060
+#define RTC_PDN2_UART_SHIFT5
+#define RTC_PDN2_PWRON_YEA_MASK0x7f00
+#define RTC_PDN2_PWRON_YEA_SHIFT 8
+#define RTC_PDN2_PWRON_LOGO(1 << 15)
+
+#define RTC_MIN_YEAR 1968
+#define RTC_BASE_YEAR 1900
+#define RTC_NUM_YEARS 128
+#define RTC_MIN_YEAR_OFFSET(RTC_MIN_YEAR - RTC_BASE_YEAR)
+#define RTC_RELPWR_WHEN_XRST 1
+
+struct mt6397_rtc {
+ struct device *dev;
+ struct rtc_device *rtc_dev;
+ struct mutexlock;
+ struct regmap *regmap;
+ int irq;
+ u32 addr_base;
+ u32 addr_range;
+};
+
+static int mtk_rtc_read(struct mt6397_rtc *rtc, u32 offse
[PATCH v2 0/3] Add Mediatek SoC RTC driver
RTC is one submodule of Mediatek MT6397 PMIC chip[1]. This series support RTC driver that work with Mediatek SoC like MT8135, MT8173. It implements second counter and also provide alarm function. This series base on 4.0-rc1, and Sascha's PMIC mfd patch[2]. Test ok on MT8173 platform. [1] https://lkml.org/lkml/2015/1/23/325 [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/324985.html Change in v2: 1. Move RTC address and interrupt to mt6397-core.c, and register these resource in mfd_cell. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/323239.html 2. Remove dt-binding document due to register resouce in mfd_cell, not from device tree. 3. Update MAINTAINER file to add Mediatek RTC mainainter. 4. Add prefix mtk_ to some internal functions. 5. Fix racy condition 6. Check return value of regmap_read and regmap_write 7. Remove some unnecessary register readback, clear, then write. 8. Add disable alarm in mtk_rtc_set_alarm function v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/320424.html Eddie Huang (2): mfd: provide RTC resource in MT6397 MFD MAINTAINERS: add Mediatek RTC driver Tianping Fang (1): rtc: mediatek: Add MT6397 RTC driver MAINTAINERS | 7 + drivers/mfd/mt6397-core.c | 15 ++ drivers/rtc/Kconfig | 10 + drivers/rtc/Makefile | 1 + drivers/rtc/rtc-mt6397.c | 454 ++ 5 files changed, 487 insertions(+) create mode 100644 drivers/rtc/rtc-mt6397.c -- 1.8.1.1.dirty -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 1/6] clk: iproc: define Broadcom iProc clock binding
Document the device tree binding for Broadcom iProc architecture based
clock controller
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../bindings/clock/brcm,iproc-clocks.txt | 171
1 file changed, 171 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
new file mode 100644
index 000..bf2316b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
@@ -0,0 +1,171 @@
+Broadcom iProc Family Clocks
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The iProc clock controller manages clocks that are common to the iProc family.
+An SoC from the iProc family may have several PPLs, e.g., ARMPLL, GENPLL,
+LCPLL0, MIPIPLL, and etc., all derived from an onboard crystal. Each PLL
+comprises of several leaf clocks
+
+Required properties for PLLs:
+- compatible:
+Should have a value of the form "brcm,-". For example, GENPLL on
+Cygnus has a compatible string of "brcm,cygnus-genpll"
+
+- #clock-cells:
+Must be <0>
+
+- reg:
+Define the base and range of the I/O address space that contain the iProc
+clock control registers required for the PLL
+
+- clocks:
+The input parent clock phandle for the PLL. For all iProc PLLs, this is an
+onboard crystal with a fixed rate
+
+Example:
+
+ osc: oscillator {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2500>;
+ };
+
+ genpll: genpll {
+ #clock-cells = <0>;
+ compatible = "brcm,cygnus-genpll";
+ reg = <0x0301d000 0x2c>,
+ <0x0301c020 0x4>;
+ clocks = <&osc>;
+ };
+
+Required properties for leaf clocks of a PLL:
+
+- compatible:
+Should have a value of the form "brcm,--clk". For example, leaf
+clocks derived from the GENPLL on Cygnus SoC have a compatible string of
+"brcm,cygnus-genpll-clk"
+
+- #clock-cells:
+Have a value of <1> since there are more than 1 leaf clock of a
+given PLL
+
+- reg:
+Define the base and range of the I/O address space that contain the iProc
+clock control registers required for the PLL leaf clocks
+
+- clocks:
+The input parent PLL phandle for the leaf clock
+
+- clock-output-names:
+An ordered list of strings defining the names of the leaf clocks
+
+Example:
+
+ genpll: genpll {
+ #clock-cells = <0>;
+ compatible = "brcm,cygnus-genpll";
+ reg = <0x0301d000 0x2c>,
+ <0x0301c020 0x4>;
+ clocks = <&osc>;
+ };
+
+ genpll_clks: genpll_clks {
+ #clock-cells = <1>;
+ compatible = "brcm,cygnus-genpll-clk";
+ reg = <0x0301d000 0x2c>;
+ clocks = <&genpll>;
+ clock-output-names = "axi21", "250mhz", "ihost_sys",
+ "enet_sw", "audio_125", "can";
+ };
+
+Required properties for ASIU clocks:
+
+ASIU clocks are a special case. These clocks are derived directly from the
+reference clock of the onboard crystal
+
+- compatible:
+Should have a value of the form "brcm,-asiu-clk". For example, ASIU
+clocks for Cygnus have a compatible string of "brcm,cygnus-asiu-clk"
+
+- #clock-cells:
+Have a value of <1> since there are more than 1 ASIU clocks
+
+- reg:
+Define the base and range of the I/O address space that contain the iProc
+clock control registers required for ASIU clocks
+
+- clocks:
+The input parent clock phandle for the ASIU clock, i.e., the onboard
+crystal
+
+- clock-output-names:
+An ordered list of strings defining the names of the ASIU clocks
+
+Example:
+
+ osc: oscillator {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2500>;
+ };
+
+ asiu_clks: asiu_clks {
+ #clock-cells = <1>;
+ compatible = "brcm,cygnus-asiu-clk";
+ reg = <0x0301d048 0xc>,
+ <0x180aa024 0x4>;
+ clocks = <&osc>;
+ clock-output-names = "keypad", "adc/touch", "pwm";
+ };
+
+Cygnus
+--
+PLL and leaf clock compatible strings for Cygnus are:
+"brcm,cygnus-armpll"
+"brcm,cygnus-genpll"
+"brcm,cygnus-lcpll0"
+"brcm,cygnus-mipipll"
+"brcm,cygnus-genpll-clk"
+"brcm,cygnus-lcpll0-clk"
+"brcm,cygnus-mipipll-clk"
+"brcm,cygnus-asiu-clk"
+
+The following table defines the set of PLL/clock index and ID for Cygnus.
+These clock IDs are defined in:
+"include/dt-bindings/clock/bcm-cygnus.h"
+
+Clock Source Index ID
+----- -
+crystalN/A N/A N/A
+
+armpll cr
[PATCH v6 2/6] clk: iproc: add initial common clock support
This adds basic and generic support for various iProc PLLs and clocks
including the ARMPLL, GENPLL, LCPLL, MIPIPLL, and ASIU clocks.
SoCs under the iProc architecture can define their specific register
offsets and clock parameters for their PLL and clock controllers. These
parameters can be passed as arugments into the generic iProc PLL and
clock setup functions
Derived from code originally provided by Jonathan Richardson
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/clk/bcm/Kconfig|9 +
drivers/clk/bcm/Makefile |1 +
drivers/clk/bcm/clk-iproc-armpll.c | 282 +
drivers/clk/bcm/clk-iproc-asiu.c | 275
drivers/clk/bcm/clk-iproc-clk.c| 244 ++
drivers/clk/bcm/clk-iproc-pll.c| 490
drivers/clk/bcm/clk-iproc.h| 164
7 files changed, 1465 insertions(+)
create mode 100644 drivers/clk/bcm/clk-iproc-armpll.c
create mode 100644 drivers/clk/bcm/clk-iproc-asiu.c
create mode 100644 drivers/clk/bcm/clk-iproc-clk.c
create mode 100644 drivers/clk/bcm/clk-iproc-pll.c
create mode 100644 drivers/clk/bcm/clk-iproc.h
diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index 75506e5..131a3af 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -7,3 +7,12 @@ config CLK_BCM_KONA
Enable common clock framework support for Broadcom SoCs
using "Kona" style clock control units, including those
in the BCM281xx and BCM21664 families.
+
+config COMMON_CLK_IPROC
+ bool "Broadcom iProc clock support"
+ depends on ARCH_BCM_IPROC
+ depends on COMMON_CLK
+ default ARCH_BCM_IPROC
+ help
+ Enable common clock framework support for Broadcom SoCs
+ based on the "iProc" architecture
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 6297d05..6926636 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_CLK_BCM_KONA) += clk-kona.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
+obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o
clk-iproc-clk.o clk-iproc-asiu.o
diff --git a/drivers/clk/bcm/clk-iproc-armpll.c
b/drivers/clk/bcm/clk-iproc-armpll.c
new file mode 100644
index 000..965cd4e
--- /dev/null
+++ b/drivers/clk/bcm/clk-iproc-armpll.c
@@ -0,0 +1,282 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IPROC_CLK_MAX_FREQ_POLICY0x3
+#define IPROC_CLK_POLICY_FREQ_OFFSET 0x008
+#define IPROC_CLK_POLICY_FREQ_POLICY_FREQ_SHIFT 8
+#define IPROC_CLK_POLICY_FREQ_POLICY_FREQ_MASK 0x7
+
+#define IPROC_CLK_PLLARMA_OFFSET 0xc00
+#define IPROC_CLK_PLLARMA_LOCK_SHIFT 28
+#define IPROC_CLK_PLLARMA_PDIV_SHIFT 24
+#define IPROC_CLK_PLLARMA_PDIV_MASK 0xf
+#define IPROC_CLK_PLLARMA_NDIV_INT_SHIFT 8
+#define IPROC_CLK_PLLARMA_NDIV_INT_MASK 0x3ff
+
+#define IPROC_CLK_PLLARMB_OFFSET 0xc04
+#define IPROC_CLK_PLLARMB_NDIV_FRAC_MASK 0xf
+
+#define IPROC_CLK_PLLARMC_OFFSET 0xc08
+#define IPROC_CLK_PLLARMC_BYPCLK_EN_SHIFT8
+#define IPROC_CLK_PLLARMC_MDIV_MASK 0xff
+
+#define IPROC_CLK_PLLARMCTL5_OFFSET 0xc20
+#define IPROC_CLK_PLLARMCTL5_H_MDIV_MASK 0xff
+
+#define IPROC_CLK_PLLARM_OFFSET_OFFSET 0xc24
+#define IPROC_CLK_PLLARM_SW_CTL_SHIFT29
+#define IPROC_CLK_PLLARM_NDIV_INT_OFFSET_SHIFT 20
+#define IPROC_CLK_PLLARM_NDIV_INT_OFFSET_MASK0xff
+#define IPROC_CLK_PLLARM_NDIV_FRAC_OFFSET_MASK 0xf
+
+#define IPROC_CLK_ARM_DIV_OFFSET 0xe00
+#define IPROC_CLK_ARM_DIV_PLL_SELECT_OVERRIDE_SHIFT 4
+#define IPROC_CLK_ARM_DIV_ARM_PLL_SELECT_MASK0xf
+
+#define IPROC_CLK_POLICY_DBG_OFFSET 0xec0
+#define IPROC_CLK_POLICY_DBG_ACT_FREQ_SHIFT 12
+#define IPROC_CLK_POLICY_DBG_ACT_FREQ_MASK 0x7
+
+enum iproc_arm_pll_fid {
+ ARM_PLL_FID_CRYSTAL_CLK = 0,
+ ARM_PLL_FID_SYS_CLK = 2,
+ ARM_PLL_FID_CH0_SLOW_CLK = 6,
+ ARM_PLL_FID_CH1_FAST_CLK = 7
+};
+
+struct iproc_ar
[PATCH v6 6/6] clk: cygnus: remove Cygnus dummy clock binding
Remove old Cygnus dummy clock binding document, as it's replaced by
Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
Signed-off-by: Ray Jui
---
.../devicetree/bindings/clock/bcm-cygnus-clock.txt | 34
1 file changed, 34 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
b/Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
deleted file mode 100644
index 00d26ed..000
--- a/Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-Broadcom Cygnus Clocks
-
-This binding uses the common clock binding:
-Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Currently various "fixed" clocks are declared for peripheral drivers that use
-the common clock framework to reference their core clocks. Proper support of
-these clocks will be added later
-
-Device tree example:
-
- clocks {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- osc: oscillator {
- compatible = "fixed-clock";
- #clock-cells = <1>;
- clock-frequency = <2500>;
- };
-
- apb_clk: apb_clk {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <10>;
- };
-
- periph_clk: periph_clk {
- compatible = "fixed-clock";
- #clock-cells = <0>;
- clock-frequency = <5>;
- };
- };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 5/6] ARM: dts: enable clock support for Broadcom Cygnus
Replace current device tree dummy clocks with real clock support for
Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus-clock.dtsi | 112 ---
arch/arm/boot/dts/bcm-cygnus.dtsi |2 +-
2 files changed, 88 insertions(+), 26 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
index 60d8389..92aab3d 100644
--- a/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus-clock.dtsi
@@ -36,56 +36,118 @@ clocks {
ranges;
osc: oscillator {
+ #clock-cells = <0>;
compatible = "fixed-clock";
- #clock-cells = <1>;
clock-frequency = <2500>;
};
- apb_clk: apb_clk {
- compatible = "fixed-clock";
+ /* Cygnus ARM PLL */
+ armpll: armpll {
#clock-cells = <0>;
- clock-frequency = <10>;
+ compatible = "brcm,cygnus-armpll";
+ clocks = <&osc>;
+ reg = <0x1900 0x1000>;
};
- periph_clk: periph_clk {
- compatible = "fixed-clock";
+ /* peripheral clock for system timer */
+ arm_periph_clk: arm_periph_clk {
#clock-cells = <0>;
- clock-frequency = <5>;
+ compatible = "fixed-factor-clock";
+ clocks = <&armpll>;
+ clock-div = <2>;
+ clock-mult = <1>;
};
- sdio_clk: lcpll_ch2 {
- compatible = "fixed-clock";
+ /* APB bus clock */
+ apb_clk: apb_clk {
#clock-cells = <0>;
- clock-frequency = <2>;
+ compatible = "fixed-factor-clock";
+ clocks = <&armpll>;
+ clock-div = <4>;
+ clock-mult = <1>;
};
- axi81_clk: axi81_clk {
- compatible = "fixed-clock";
+ genpll: genpll {
#clock-cells = <0>;
- clock-frequency = <1>;
+ compatible = "brcm,cygnus-genpll";
+ reg = <0x0301d000 0x2c>,
+ <0x0301c020 0x4>;
+ clocks = <&osc>;
};
- keypad_clk: keypad_clk {
- compatible = "fixed-clock";
+ /* various clocks running off the GENPLL */
+ genpll_clks: genpll_clks {
+ #clock-cells = <1>;
+ compatible = "brcm,cygnus-genpll-clk";
+ reg = <0x0301d000 0x2c>;
+ clocks = <&genpll>;
+ clock-output-names = "axi21", "250mhz", "ihost_sys",
+ "enet_sw", "audio_125", "can";
+ };
+
+ /* always 1/2 of the axi21 clock */
+ axi41_clk: axi41_clk {
#clock-cells = <0>;
- clock-frequency = <31806>;
+ compatible = "fixed-factor-clock";
+ clocks = <&genpll_clks 0>;
+ clock-div = <2>;
+ clock-mult = <1>;
};
- adc_clk: adc_clk {
- compatible = "fixed-clock";
+ /* always 1/4 of the axi21 clock */
+ axi81_clk: axi81_clk {
#clock-cells = <0>;
- clock-frequency = <1562500>;
+ compatible = "fixed-factor-clock";
+ clocks = <&genpll_clks 0>;
+ clock-div = <4>;
+ clock-mult = <1>;
};
- pwm_clk: pwm_clk {
- compatible = "fixed-clock";
+ lcpll0: lcpll0 {
#clock-cells = <0>;
- clock-frequency = <100>;
+ compatible = "brcm,cygnus-lcpll0";
+ reg = <0x0301d02c 0x1c>,
+ <0x0301c020 0x4>;
+ clocks = <&osc>;
};
- lcd_clk: mipipll_ch1 {
- compatible = "fixed-clock";
+ /* various clocks running off the LCPLL0 */
+ lcpll0_clks: lcpll0_clks {
+ #clock-cells = <1>;
+ compatible = "brcm,cygnus-lcpll0-clk";
+ reg = <0x0301d02c 0x1c>;
+ clocks = <&lcpll0>;
+ clock-output-names = "pcie_phy", "ddr_phy", "sdio",
+ "usb_phy", "smart_card", "ch5";
+ };
+
+ mipipll: mipipll {
#clock-cells = <0>;
- clock-frequency = <1>;
+ compatible = "brcm,cygnus-mipipll";
+ reg = <0x180a9800 0x2c>,
+ <0x0301c020 0x4>,
+ <0x180aa024 0x4>;
+ clocks = <&osc>;
+
+ assigned-clocks = <&mipipll>;
+ assigned-clock-rates = <21>;
+ };
+
+ mipipll_clks: mipipll_clks {
+ #clock-cells = <1>;
+ compatible = "brcm,cygnus-mipipll-clk";
+ reg = <0x180a9800 0x2c>;
+ clocks = <&mipipll>;
+ clock-output-nam
[PATCH v6 4/6] clk: cygnus: add clock support for Broadcom Cygnus
The Broadcom Cygnus SoC is architected under the iProc architecture. It
has the following PLLs: ARMPLL, GENPLL, LCPLL0, MIPIPLL, all dervied
from an onboard crystal. Cygnus also has various ASIU clocks that are
derived directly from the onboard crystal.
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/clk/bcm/Makefile |1 +
drivers/clk/bcm/clk-cygnus.c | 284
include/dt-bindings/clock/bcm-cygnus.h | 65
3 files changed, 350 insertions(+)
create mode 100644 drivers/clk/bcm/clk-cygnus.c
create mode 100644 include/dt-bindings/clock/bcm-cygnus.h
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 6926636..afcbe55 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o
clk-iproc-clk.o clk-iproc-asiu.o
+obj-$(CONFIG_ARCH_BCM_CYGNUS) += clk-cygnus.o
diff --git a/drivers/clk/bcm/clk-cygnus.c b/drivers/clk/bcm/clk-cygnus.c
new file mode 100644
index 000..fe3013b
--- /dev/null
+++ b/drivers/clk/bcm/clk-cygnus.c
@@ -0,0 +1,284 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "clk-iproc.h"
+
+#define reg_val(o, s, w) { .offset = o, .shift = s, .width = w, }
+
+#define aon_val(o, pw, ps, is) { .offset = o, .pwr_width = pw, \
+ .pwr_shift = ps, .iso_shift = is }
+
+#define asiu_div_val(o, es, hs, hw, ls, lw) \
+ { .offset = o, .en_shift = es, .high_shift = hs, \
+ .high_width = hw, .low_shift = ls, .low_width = lw }
+
+#define reset_val(o, rs, prs, kis, kiw, kps, kpw, kas, kaw) { .offset = o, \
+ .reset_shift = rs, .p_reset_shift = prs, .ki_shift = kis, \
+ .ki_width = kiw, .kp_shift = kps, .kp_width = kpw, .ka_shift = kas, \
+ .ka_width = kaw }
+
+#define vco_ctrl_val(uo, lo) { .u_offset = uo, .l_offset = lo }
+
+#define enable_val(o, es, hs, bs) { .offset = o, .enable_shift = es, \
+ .hold_shift = hs, .bypass_shift = bs }
+
+#define asiu_gate_val(o, es) { .offset = o, .en_shift = es }
+
+static void __init cygnus_armpll_init(struct device_node *node)
+{
+ iproc_armpll_setup(node);
+}
+CLK_OF_DECLARE(cygnus_armpll, "brcm,cygnus-armpll", cygnus_armpll_init);
+
+static const struct iproc_pll_ctrl genpll = {
+ .flags = IPROC_CLK_AON | IPROC_CLK_PLL_HAS_NDIV_FRAC,
+ .aon = aon_val(0x0, 2, 1, 0),
+ .reset = reset_val(0x0, 11, 10, 4, 3, 0, 4, 7, 3),
+ .ndiv_int = reg_val(0x10, 20, 10),
+ .ndiv_frac = reg_val(0x10, 0, 20),
+ .pdiv = reg_val(0x14, 0, 4),
+ .vco_ctrl = vco_ctrl_val(0x18, 0x1c),
+ .status = reg_val(0x28, 12, 1),
+};
+
+static void __init cygnus_genpll_init(struct device_node *node)
+{
+ iproc_pll_setup(node, &genpll, NULL, 0);
+}
+CLK_OF_DECLARE(cygnus_genpll, "brcm,cygnus-genpll", cygnus_genpll_init);
+
+static const struct iproc_pll_ctrl lcpll0 = {
+ .flags = IPROC_CLK_AON,
+ .aon = aon_val(0x0, 2, 5, 4),
+ .reset = reset_val(0x0, 31, 30, 27, 3, 23, 4, 19, 4),
+ .ndiv_int = reg_val(0x4, 16, 10),
+ .pdiv = reg_val(0x4, 26, 4),
+ .vco_ctrl = vco_ctrl_val(0x10, 0x14),
+ .status = reg_val(0x18, 12, 1),
+};
+
+static void __init cygnus_lcpll0_init(struct device_node *node)
+{
+ iproc_pll_setup(node, &lcpll0, NULL, 0);
+}
+CLK_OF_DECLARE(cygnus_lcpll0, "brcm,cygnus-lcpll0", cygnus_lcpll0_init);
+
+/*
+ * MIPI PLL VCO frequency parameter table
+ */
+static const struct iproc_pll_vco_freq_param mipipll_vco_params[] = {
+ /* rate (Hz) ndiv_int ndiv_frac pdiv */
+ { 75000UL, 30, 0,1 },
+ { 10UL, 40, 0,1 },
+ { 135000ul, 54, 0,1 },
+ { 20UL, 80, 0,1 },
+ { 21UL, 84, 0,1 },
+ { 225000UL, 90, 0,1 },
+ { 25UL, 100,0,1 },
+ { 27UL, 54, 0,0 },
+ { 297500UL, 119,0,1 },
+ { 31UL, 124,0,1 },
+ { 315000UL, 126,0,1 },
+};
+
+static const struct iproc_pll_ctrl mipipll = {
+ .flags = IPROC_CLK_PLL_ASIU | IPROC_CLK_PLL_HAS_NDIV_FRAC |
+IPROC_CL
[PATCH v6 0/6] Add common clock support for Broadcom iProc architecture
This patchset contains the initial common clock support for Broadcom's iProc family of SoCs. The iProc clock architecture comprises of various PLLs, e.g., ARMPLL, GENPLL, LCPLL0, MIPIPLL, and etc. An onboard crystal serves as the basic reference clock for these PLLs. Each PLL may have several leaf clocks. One special group of clocks is the ASIU clocks, which are dervied directly from the crystal reference clock. This patchset also contains the basic clock support for the Broadcom Cygnus SoC, which implements the iProc clock architecture Changes from v5: - Rebase to v4.0-rc4 - Drop of_clk_get_parent_rate helper function from the clock framework - Get rid of custom "clock-frequency" support in iProc PLL code. Instead, add standard clock set_rate and round_rate support and make use of DT properties "assigned-clocks" and "assigned-clock-rates" to initialize PLL to the desired rate when registering to the clock framework - Add SW workaround for ASIC bug on MIPI PLL to always read back the same register following a write transaction, to ensure value is written to the correct register Changes from v4: - Add of_clk_get_parent_rate helper function into the clock framework - Switch to use of_clk_get_parent_rate in the iProc PLL clock driver Changes from v3: - Fix incorrect use of passing in of_clk_src_onecell_get when adding ARM PLL and other iProc PLLs as clock provider. These PLLs have zero cells in DT and thefore of_clk_src_simple_get should be used instead - Rename Cygnus MIPI PLL Channel 2 clock from BCM_CYGNUS_MIPIPLL_CH2_UNUSED to BCM_CYGNUS_MIPIPLL_CH2_V3D, since a 3D graphic rendering engine has been integrated into Cygnus revision B0 and has its core clock running off MIPI PLL Channel 2 - Changed default MIPI PLL VCO frequency from 1.75 GHz to 2.1 GHz. This allows us to derive 300 MHz V3D clock from channel 2 through the post divisor Changes from v2: - Re-arrange Cygnus clock/pll init functions so each init function is right next to its clock table - Removed #defines for number of clocks in Cygnus. Have the number of clocks automatically determined based on array size of the clock table Changes from v1: - Separate drivers/clk/Makefile change for drivers/clk/bcm out to a standalone patch Ray Jui (6): clk: iproc: define Broadcom iProc clock binding clk: iproc: add initial common clock support clk: Change bcm clocks build dependency clk: cygnus: add clock support for Broadcom Cygnus ARM: dts: enable clock support for Broadcom Cygnus clk: cygnus: remove Cygnus dummy clock binding .../devicetree/bindings/clock/bcm-cygnus-clock.txt | 34 -- .../bindings/clock/brcm,iproc-clocks.txt | 171 +++ arch/arm/boot/dts/bcm-cygnus-clock.dtsi| 112 - arch/arm/boot/dts/bcm-cygnus.dtsi |2 +- drivers/clk/Makefile |2 +- drivers/clk/bcm/Kconfig|9 + drivers/clk/bcm/Makefile |2 + drivers/clk/bcm/clk-cygnus.c | 284 drivers/clk/bcm/clk-iproc-armpll.c | 282 +++ drivers/clk/bcm/clk-iproc-asiu.c | 275 +++ drivers/clk/bcm/clk-iproc-clk.c| 244 ++ drivers/clk/bcm/clk-iproc-pll.c| 490 drivers/clk/bcm/clk-iproc.h| 164 +++ include/dt-bindings/clock/bcm-cygnus.h | 65 +++ 14 files changed, 2075 insertions(+), 61 deletions(-) delete mode 100644 Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt create mode 100644 Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt create mode 100644 drivers/clk/bcm/clk-cygnus.c create mode 100644 drivers/clk/bcm/clk-iproc-armpll.c create mode 100644 drivers/clk/bcm/clk-iproc-asiu.c create mode 100644 drivers/clk/bcm/clk-iproc-clk.c create mode 100644 drivers/clk/bcm/clk-iproc-pll.c create mode 100644 drivers/clk/bcm/clk-iproc.h create mode 100644 include/dt-bindings/clock/bcm-cygnus.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/6] clk: Change bcm clocks build dependency
The clock code under drivers/clk/bcm now contains code for both the Broadcom mobile SoCs and the iProc SoCs. Change the the makefile dependency to be under config flag CONFIG_ARCH_BCM that's enabled for both families of SoCs Signed-off-by: Ray Jui --- drivers/clk/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index d478ceb..1dde3c8 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -43,7 +43,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o obj-$(CONFIG_COMMON_CLK_WM831X)+= clk-wm831x.o obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o obj-$(CONFIG_COMMON_CLK_AT91) += at91/ -obj-$(CONFIG_ARCH_BCM_MOBILE) += bcm/ +obj-$(CONFIG_ARCH_BCM) += bcm/ obj-$(CONFIG_ARCH_BERLIN) += berlin/ obj-$(CONFIG_ARCH_HI3xxx) += hisilicon/ obj-$(CONFIG_ARCH_HIP04) += hisilicon/ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re:Re: [PATCH V2] gpio: mmp: add GPIO driver for Marvell MMP series
At 2015-03-17 18:25:24, "Linus Walleij" wrote:
>On Fri, Mar 6, 2015 at 3:04 AM, Chao Xie wrote:
>
>> Signed-off-by: Chao Xie
>
>First can some of the MMP people comment on this driver please?
>(Eric/Haojian)
>
>So this driver duplicates drivers/gpio/gpio-pxa.c in some sense but
>is nicer and cleaner and thus an incentive for me to merge it.
>At the same time I don't want two drivers for essentially the same
>hardware and in that way I would prefer to clean up the PXA driver.
>
>But I don't know how close the PXA and MMP drivers really are.
>
>Will it also cover MMP2 that is currently using by the PXA driver?
>
>Is it really complicated to migrate gpio-pxa to GPIOLIB_IRQCHIP?
>
>I guess you should also delete the compatible string and
>compatibility code in drivers/gpio/gpio-pxa.c (as a separate patch
>in this series) and merge this along with some defconfig
>changes that activates this by default for the MMP machines?
>
I will ask Haojian to comment at it when send out V3 patch.
pxa and mmp are two different series.
First pxa is Intel's product, and after Intel sell its xscale to marvell, the
SOC series become mmp.
The SOC design has many differences.
now mmp gpio has some registers kept in order to use the old pxa driver, but
silicon designer
warned us that it is better to use the new register interfaces.
The major differences are:
For all the edge detecting setting/clearing, level setting/clearing, direction
setting/clearing, mmp has
separated registers
>> +config GPIO_MMP
>> + bool "MMP GPIO support"
>> + depends on ARCH_MMP
>> + select GPIOLIB_IRQCHIP
>
>NICE!
>
>> +struct mmp_gpio_bank {
>> + void __iomem *reg_bank;
>> + u32 irq_mask;
>> + u32 irq_rising_edge;
>> + u32 irq_falling_edge;
>
>I can't see why you're keeping all these settings of the edges and mask
>in these variables. Why can't you just keep the state in the hardware
>registers?
>
When other driver request gpio, it will set whether it is rising edge detect or
falling edge detect or both.
We need record it.
So when user mask/unmask the interrupt, we know whether we need clear/set
rising edge detect/falling edge detect or both.
>> +};
>> +
>> +struct mmp_gpio_chip {
>> + struct gpio_chip chip;
>> + void __iomem *reg_base;
>> + int irq;
>
>Do you need to keep irq around if you use devm_* to request the
>IRQ?
>
Yes, it is right. I will remove it.
>> + unsigned int ngpio;
>
>This is already stored in struct gpio_chip, why
>store it a second time in this struct?
>
>> + unsigned int nbank;
>> + struct mmp_gpio_bank *banks;
>
>To repeat an eternal story: why do you have to register several
>banks under the same gpio_chip? I guess it's because they share
>a single IRQ line, but wanna make sure
>
Yes. they share same interrupt line.
There are the following reasons
1. There is only one IRQ for the whole GPIO, even there are 3 or more banks.
2. The registers are not formatted into group. They are interleaved.
For example, there are three banks, So for the registers order are
LEVEL_STATUS_BANK0, LEVEL_STASTUS_BANK1, LEVEL_STATUS_BANK2
DIRECTION_STATUS_BANK0, DIRECTION_STATUS_BANK1, DIRECTION_STATUS_BANK2
>> +};>> +
>> +static int mmp_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
>> +{
>> + struct mmp_gpio_chip *mmp_chip =
>> + container_of(chip, struct mmp_gpio_chip, chip);
>> + struct mmp_gpio_bank *bank =
>> + &mmp_chip->banks[mmp_gpio_to_bank_idx(offset)];
>
>Rewrite this:
>
>> + u32 bit = (1 << mmp_gpio_to_bank_offset(offset));
>> +
>> + writel(bit, bank->reg_bank + GCDR);
>
>Like this:
>
>#include
>
>writel(BIT(mmp_gpio_to_bank_offset(offset)), bank->reg_bank + GCDR);
>
I will do it.>
>> +static int mmp_gpio_direction_output(struct gpio_chip *chip,
>> +unsigned offset, int value)
>> +{
>
>Use the same pattern with BIT() as described above.
>
I will do it.>> +static int mmp_gpio_get(struct gpio_chip *chip, unsigned
offset)
>> +{
>> +
>> + return !!(gplr & bit);
>
>Use the same pattern with BIT() as described above.
>
I will do it.
I will use BIT() for all below comments you suggested. Thanks.>> +static struct
irq_chip mmp_muxed_gpio_chip = {
>> + .name = "mmp-gpio-irqchip",
>> + .irq_mask = mmp_mask_muxed_gpio,
>> + .irq_unmask = mmp_unmask_muxed_gpio,
>> + .irq_set_type = mmp_gpio_irq_type,
>> + .flags = IRQCHIP_SKIP_SET_WAKE,
>> +};
>> +
>> +static struct of_device_id mmp_gpio_dt_ids[] = {
>> + { .compatible = "marvell,mmp-gpio"},
>> + {}
>> +};
>
>So the same functionality in the other compatible driver should
>be deleted as a separate patch.
>
Yes. a separated patch is needed.
>> +static int mmp_gpio_probe_dt(struct platform_device *pdev,
>> + struct mmp_gpio_chip *mmp_chip)
>> +{
>> +
Re: [PATCH] vfs: avoid recopying filename in getname_flags
On Fri, Mar 13, 2015 at 09:45:59AM -0400, Paul Moore wrote:
> On Monday, March 09, 2015 04:24:32 PM Boqun Feng wrote:
> > Ping.
> > Any opinion?
>
> You might want to look at some of the recent changes to Al's vfs.git#for-next
> branch; at the very least it looks like your patch should be rebased against
> those changes.
Thank you for your reminder ;-)
After learning several changes on that branch, I get a question for
commit ca160d0 "kill struct filename.separate".
I think the two following situations explains how that commit works.
(`iname` and `name` are fields in struct filename)
Not separate:
|---PATH_MAX bytes by names_cachep --|
|--struct filename--|---space for name---|
^
iname/name
name->iname == name->name is true
Separate:
|--by kzalloc --| |---PATH_MAX bytes by names_cachep---|
|--struct filename--|..|---space for name---|
^ ^
iname name
name->iname == name->name is false
However, I think of a third situation, which we were unlucky, that
the bytes allocated by kzalloc and the bytes allocated by names_cachep
somehow become continous, like the following situation:
Separate:
|--by kzalloc --|---PATH_MAX bytes by names_cachep --|
|--struct filename--|---space for name---|
^
iname/name
In this situation, the struct and the name are separate but
name->iname == name->name is true
Since struct filename is small, so kzalloc will call kmem_cache_alloc
actually. As I don't know much about kmem_cache allocators, my question
is "Can the 'unlucky' situation happen now?" If the answer is no, can it
happen in the future considering there may be new kmem_cache allocating
algorithms?
Thanks and Best Regards,
Boqun Feng
>
> > On Wed, Feb 25, 2015 at 8:31 PM, Boqun Feng wrote:
> > > In the current implementation of getname_flags, filename in the
> > > user-space will be recopied if it takes more space that
> > > EMBEDDED_NAME_MAX, however, at this moment, EMBEDDED_NAME_MAX bytes of
> > > the filename are already copied into kernel space, the only reason why
> > > the recopy is needed is that "kname" needs to be relocated.
> > >
> > > And the recopy can be avoided if we change the memory layout of the
> > > "names_cache" allocation. By putting the struct "filename" at the tail
> > > of the allocation instead of the head, relocation of kname is avoided.
> > >
> > > Once putting the struct at the tail, each byte in the user space will be
> > > copied only one time, so the recopy is avoided and code is more clear.
> > >
> > > Of course, other functions aware of the layout of the names_cache
> > > allocation, i.e., getname_kernel and putname also need to be modified to
> > > adapt to the new layout.
> > >
> > > This patch is based on v4.0-rc1.
> > >
> > > Cc: Al Viro
> > > Cc: Paul Moore
> > > Signed-off-by: Boqun Feng
> > > ---
> > >
> > > fs/namei.c | 50 +++---
> > > 1 file changed, 31 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/fs/namei.c b/fs/namei.c
> > > index c83145a..3be372b 100644
> > > --- a/fs/namei.c
> > > +++ b/fs/namei.c
> > > @@ -133,21 +133,20 @@ getname_flags(const char __user *filename, int
> > > flags, int *empty)>
> > > if (result)
> > >
> > > return result;
> > >
> > > - result = __getname();
> > > - if (unlikely(!result))
> > > + kname = __getname();
> > > + if (unlikely(!kname))
> > >
> > > return ERR_PTR(-ENOMEM);
> > >
> > > - result->refcnt = 1;
> > >
> > > /*
> > >
> > > * First, try to embed the struct filename inside the names_cache
> > > * allocation
> > > */
> > >
> > > - kname = (char *)result + sizeof(*result);
> > > + result = (struct filename *)(kname + EMBEDDED_NAME_MAX);
> > >
> > > result->name = kname;
> > > result->separate = false;
> > >
> > > + result->refcnt = 1;
> > >
> > > max = EMBEDDED_NAME_MAX;
> > >
> > > -recopy:
> > > len = strncpy_from_user(kname, filename, max);
> > > if (unlikely(len < 0)) {
> > >
> > > err = ERR_PTR(len);
> > >
> > > @@ -157,23 +156,34 @@ recopy:
> > > /*
> > >
> > > * Uh-oh. We have a name that's approaching PATH_MAX. Allocate a
> > > * separate struct filename so we can dedicate the entire
> > >
> > > -* names_cache allocation for the pathname, and re-do the copy
> > > from
> > > +* names_cache allocation for the pathname, and continue the copy
> > > from>
> > > * userland.
> > > */
> > >
> > > - if (len == EMBEDDED_NAME_MAX && max == EMBEDDED_NAME_MAX) {
> > > - kname = (char *)result;
> > > -
> > > + if (len == EMBEDD
Crypto Fixes for 4.0
Hi Linus: On Mon, Mar 09, 2015 at 04:19:50PM +1100, Herbert Xu wrote: > > This push fixes a bug in the ARM XTS implementation that can > cause failures to in decrypting encrypted disks. For some reason this didn't get pulled so I'm resending it with another fix. The new fix is a memory overwrite bug that can cause a crash which can be triggered from userspace. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git or master.kernel.org:/pub/scm/linux/kernel/git/herbert/crypto-2.6.git Ard Biesheuvel (1): crypto: arm/aes update NEON AES module to latest OpenSSL version Stephan Mueller (1): crypto: aesni - fix memory usage in GCM decryption arch/arm/crypto/aesbs-core.S_shipped | 12 arch/arm/crypto/bsaes-armv7.pl | 12 arch/x86/crypto/aesni-intel_glue.c |4 ++-- 3 files changed, 18 insertions(+), 10 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 5/8] PM / devfreq: tegra: remove operating-points
> As the DT bindings don't have an operating-points property any more,
> build the OPP table from the frequencies supported by the EMC clock.
>
> Signed-off-by: Tomeu Vizoso
> ---
> drivers/devfreq/tegra-devfreq.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
> index 5a6164c..1de3f8b 100644
> --- a/drivers/devfreq/tegra-devfreq.c
> +++ b/drivers/devfreq/tegra-devfreq.c
> @@ -618,6 +618,7 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> struct tegra_devfreq_device *dev;
> struct resource *res;
> unsigned int i;
> + unsigned long rate;
> int irq;
> int err;
>
> @@ -649,12 +650,6 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> return PTR_ERR(tegra->emc_clock);
> }
>
> - err = of_init_opp_table(&pdev->dev);
> - if (err) {
> - dev_err(&pdev->dev, "Failed to init operating point table\n");
> - return err;
> - }
> -
> clk_set_rate(tegra->emc_clock, ULONG_MAX);
>
> tegra->rate_change_nb.notifier_call = tegra_actmon_rate_notify_cb;
> @@ -691,6 +686,11 @@ static int tegra_devfreq_probe(struct platform_device
> *pdev)
> tegra_actmon_configure_device(tegra, dev);
> }
>
> + for (rate = 0; rate <= tegra->max_freq * KHZ; rate++) {
> + rate = clk_round_rate(tegra->emc_clock, rate);
> + dev_pm_opp_add(&pdev->dev, rate, 0);
> + }
> +
Although I am not going to NACK for the single-time performance of a
single device driver for a device that I do not have or fully understand,
please note that you may be wasting several billion cycles unless
your product is running at MHZ/kHZ level.
What is going on with this loop? Do you really have such a virtually-continuous
frequency scaling in your product? (Wow but in such a case, I don't think
OPP is appropriate.)
Cheers,
MyungJoo
> irq = platform_get_irq(pdev, 0);
> if (irq <= 0) {
> dev_err(&pdev->dev, "Failed to get IRQ\n");
> --
> 2.1.0
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH] hwrng: core - allow perfect entropy from hardware devices
Hardware random number quality is measured from 0 (no entropy) to 1024 (perfect entropy). Allow hardware devices to assert the full range by truncating the device-provided value at 1024 instead of 1023. Signed-off-by: Keith Packard --- drivers/char/hw_random/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index 1500cfd..b726683 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/char/hw_random/core.c @@ -98,7 +98,8 @@ static inline int hwrng_init(struct hwrng *rng) add_early_randomness(rng); current_quality = rng->quality ? : default_quality; - current_quality &= 1023; + if (current_quality > 1024) + current_quality = 1024; if (current_quality == 0 && hwrng_fill) kthread_stop(hwrng_fill); -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hwrng: core - allow perfect entropy from hardware devices
On Tue, Mar 17, 2015 at 10:13:28PM -0700, Keith Packard wrote: > Hardware random number quality is measured from 0 (no entropy) to 1024 > (perfect entropy). Allow hardware devices to assert the full range by > truncating the device-provided value at 1024 instead of 1023. > > Signed-off-by: Keith Packard Please cc all hwrng patches to linux-cry...@vger.kernel.org so that it gets picked up by patchworks. Thanks! -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/8] Add support for Tegra Activity Monitor
> Hello,
>
> something happened during the last cycle and an old version of the devfreq
> driver was merged.
>
> This thread contains patches that bring it up to date to the last submitted
> version and also incorporates the feedback that that version received, plus
> some other small fixes and improvements that came up during rebase and
> testing.
>
> These patches implement support for setting the rate of the EMC clock based on
> stats collected from the ACTMON, a piece of hw in the Tegra124 that counts
> memory accesses (among others).
>
> It depends on the following in-flight patches:
>
> * EMC driver: http://thread.gmane.org/gmane.linux.kernel/1907035
> * CPUFreq driver: http://thread.gmane.org/gmane.linux.kernel/1897078
>
> I have pushed a branch here for testing:
>
> http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=actmon-v6
>
> Regards,
>
> Tomeu
>
> Tomeu Vizoso (8):
> of: Add binding for NVIDIA Tegra ACTMON node
> PM / devfreq: tegra: Update to v5 of the submitted patches
> clk: tegra: Have EMC clock implement determine_rate()
> PM / devfreq: tegra: Use clock rate constraints
> PM / devfreq: tegra: remove operating-points
> PM / devfreq: tegra: Set drvdata before enabling the irq
> PM / devfreq: tegra: Enable interrupts after resuming the devfreq
> monitor
> ARM: tegra: Add Tegra124 ACTMON support
Acked-by: MyungJoo Ham
for all PM / devfreq patches (2, 4, 5, 6, 7)
And merged in for-rc tree with a little modification.
In the patch 2/8, I would like to add "const" in Line 748.
Would it be fine with you?
(You may look at:
https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/log/?h=for-rc )
The diff after applying all 2/8 to 7/8 will be:
diff --git a/drivers/devfreq/tegra-devfreq.c b/drivers/devfreq/tegra-devfreq.c
index 0d1edd5..8e633a6 100644
--- a/drivers/devfreq/tegra-devfreq.c
+++ b/drivers/devfreq/tegra-devfreq.c
@@ -740,7 +740,7 @@ static int tegra_devfreq_remove(struct platform_device
*pdev)
return 0;
}
-static struct of_device_id tegra_devfreq_of_match[] = {
+static const struct of_device_id tegra_devfreq_of_match[] = {
{ .compatible = "nvidia,tegra124-actmon" },
{ },
};
>
> .../devicetree/bindings/arm/tegra/actmon.txt | 28 ++
> arch/arm/boot/dts/tegra124.dtsi| 11 +
> drivers/clk/tegra/clk-emc.c| 19 +-
> drivers/devfreq/tegra-devfreq.c| 480
> +++--
> 4 files changed, 316 insertions(+), 222 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/tegra/actmon.txt
>
> --
> 2.1.0
>
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 1/3] mm/vmalloc: fix possible exhaustion of vmalloc space caused by vm_map_ram allocator
2015-03-18 6:58 GMT+09:00 Andrew Morton : > On Tue, 17 Mar 2015 17:22:46 +0900 Roman Peniaev wrote: > >> >> My second patch fixes this problem. >> >> I occupy the block on allocation and avoid jumping to the search loop. >> > >> > I'm not sure that this fixes above case. >> > 'vm_map_ram (3) * 85' means 85 times vm_map_ram() calls. >> > >> > First vm_map_ram(3) caller could get benefit from your second patch. >> > But, second caller and the other callers in each iteration could not >> > get benefit and should iterate whole list to find suitable free block, >> > because this free block is put to the tail of the list. Am I missing >> > something? >> >> You are missing the fact that we occupy blocks in 2^n. >> So in your example 4 page slots will be occupied (order is 2), not 3. > > Could you please > > - update the changelogs so they answer the questions which Joonsoo > Kim and Gioh Kim asked > > - write a little in-kernel benchmark to test the scenario which > Joonsoo described and include the before and after timing results in > the changelogs I misunderstand before and my scenario isn't possible. So, I'm fine with current patch. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mm/vmalloc: fix possible exhaustion of vmalloc space caused by vm_map_ram allocator
2015-03-17 17:22 GMT+09:00 Roman Peniaev :
> On Tue, Mar 17, 2015 at 4:29 PM, Joonsoo Kim wrote:
>> On Tue, Mar 17, 2015 at 02:12:14PM +0900, Roman Peniaev wrote:
>>> On Tue, Mar 17, 2015 at 1:56 PM, Joonsoo Kim wrote:
>>> > On Fri, Mar 13, 2015 at 09:12:55PM +0900, Roman Pen wrote:
>>> >> If suitable block can't be found, new block is allocated and put into a
>>> >> head
>>> >> of a free list, so on next iteration this new block will be found first.
>>> >>
>>> >> That's bad, because old blocks in a free list will not get a chance to
>>> >> be fully
>>> >> used, thus fragmentation will grow.
>>> >>
>>> >> Let's consider this simple example:
>>> >>
>>> >> #1 We have one block in a free list which is partially used, and where
>>> >> only
>>> >> one page is free:
>>> >>
>>> >> HEAD |x-| TAIL
>>> >>^
>>> >>free space for 1 page, order 0
>>> >>
>>> >> #2 New allocation request of order 1 (2 pages) comes, new block is
>>> >> allocated
>>> >> since we do not have free space to complete this request. New block
>>> >> is put
>>> >> into a head of a free list:
>>> >>
>>> >> HEAD |--|x-| TAIL
>>> >>
>>> >> #3 Two pages were occupied in a new found block:
>>> >>
>>> >> HEAD |xx|x-| TAIL
>>> >> ^
>>> >> two pages mapped here
>>> >>
>>> >> #4 New allocation request of order 0 (1 page) comes. Block, which was
>>> >> created
>>> >> on #2 step, is located at the beginning of a free list, so it will
>>> >> be found
>>> >> first:
>>> >>
>>> >> HEAD |xxX---|x-| TAIL
>>> >> ^ ^
>>> >> page mapped here, but better to use this hole
>>> >>
>>> >> It is obvious, that it is better to complete request of #4 step using
>>> >> the old
>>> >> block, where free space is left, because in other case fragmentation
>>> >> will be
>>> >> highly increased.
>>> >>
>>> >> But fragmentation is not only the case. The most worst thing is that I
>>> >> can
>>> >> easily create scenario, when the whole vmalloc space is exhausted by
>>> >> blocks,
>>> >> which are not used, but already dirty and have several free pages.
>>> >>
>>> >> Let's consider this function which execution should be pinned to one CPU:
>>> >>
>>> >>
>>> >> --
>>> >> /* Here we consider that our block is equal to 1MB, thus 256 pages */
>>> >> static void exhaust_virtual_space(struct page *pages[256], int iters)
>>> >> {
>>> >> /* Firstly we have to map a big chunk, e.g. 16 pages.
>>> >>* Then we have to occupy the remaining space with smaller
>>> >>* chunks, i.e. 8 pages. At the end small hole should remain.
>>> >>* So at the end of our allocation sequence block looks like
>>> >>* this:
>>> >>*XX big chunk
>>> >>* |XXxxx-|x small chunk
>>> >>* - hole, which is enough for a small chunk,
>>> >>*but not for a big chunk
>>> >>*/
>>> >> unsigned big_allocs = 1;
>>> >> /* -1 for hole, which should be left at the end of each block
>>> >>* to keep it partially used, with some free space available */
>>> >> unsigned small_allocs = (256 - 16) / 8 - 1;
>>> >> void*vaddrs[big_allocs + small_allocs];
>>> >>
>>> >> while (iters--) {
>>> >> int i = 0, j;
>>> >>
>>> >> /* Map big chunk */
>>> >> vaddrs[i++] = vm_map_ram(pages, 16, -1, PAGE_KERNEL);
>>> >>
>>> >> /* Map small chunks */
>>> >> for (j = 0; j < small_allocs; j++)
>>> >> vaddrs[i++] = vm_map_ram(pages + 16 + j * 8, 8, -1,
>>> >>PAGE_KERNEL);
>>> >>
>>> >> /* Unmap everything */
>>> >> while (i--)
>>> >> vm_unmap_ram(vaddrs[i], (i ? 8 : 16));
>>> >> }
>>> >> }
>>> >>
>>> >> --
>>> >>
>>> >> On every iteration new block (1MB of vm area in my case) will be
>>> >> allocated and
>>> >> then will be occupied, without attempt to resolve small allocation
>>> >> request
>>> >> using previously allocated blocks in a free list.
>>> >>
>>> >> In current patch I simply put newly allocated block to the tail of a
>>> >> free list,
>>> >> thus reduce fragmentation, giving a chance to resolve allocation request
>>> >> using
>>> >> older blocks with possible holes left.
>>> >
>>> > Hello,
>>> >
>>> > I think that if you put newly allocated block to the tail of a free
>>> > list, below example would results in enormous performance degradation.
>>> >
>>> > new block: 1MB (256 pages)
>>> >
>>> > while (iters--) {
>>> > vm_map_ram(3 or something else not dividable for 256) * 85
>>> > vm_unmap_ram(3) * 85
>>> > }
>>> >
>>> >
Re: [PATCH] tpm: fix: sanitized code paths in tpm_chip_register()
Resending v2 soon. This version was from wrong branch :( Sorry.
On Wed, Mar 18, 2015 at 06:50:01AM +0200, Jarkko Sakkinen wrote:
> I started to work with PPI interface so that it would be available
> under character device sysfs directory and realized that chip
> registeration was still too messy.
>
> In TPM 1.x in some rare scenarios (errors that almost never occur)
> wrong order in deinitialization steps was taken in teardown. I
> reproduced these scenarios by manually inserting error codes in the
> place of the corresponding function calls.
>
> The key problem is that the teardown is messy with two separate code
> paths (this was inherited when moving code from tpm-interface.c).
>
> Moved TPM 1.x specific register/unregister functionality to own helper
> functions and added single code path for teardown in tpm_chip_register().
> Now the code paths have been fixed and it should be easier to review
> later on this part of the code.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> drivers/char/tpm/tpm-chip.c | 56
> +
> 1 file changed, 36 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index cf43f4b..e5b0481 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -170,6 +170,33 @@ static void tpm_dev_del_device(struct tpm_chip *chip)
> device_unregister(&chip->dev);
> }
>
> +static int tpm1_chip_register(struct tpm_chip *chip)
> +{
> + int rc;
> +
> + if (chip->flags & TPM_CHIP_FLAG_TPM2)
> + return 0;
> +
> + rc = tpm_sysfs_add_device(chip);
> + if (rc)
> + return rc;
> +
> + chip->bios_dir = tpm_bios_log_setup(chip->devname);
> +
> + return 0;
> +}
> +
> +static void tpm1_chip_unregister(struct tpm_chip *chip)
> +{
> + if (chip->flags & TPM_CHIP_FLAG_TPM2)
> + return;
> +
> + if (chip->bios_dir)
> + tpm_bios_log_teardown(chip->bios_dir);
> +
> + tpm_sysfs_del_device(chip);
> +}
> +
> /*
> * tpm_chip_register() - create a character device for the TPM chip
> * @chip: TPM chip to use.
> @@ -185,22 +212,17 @@ int tpm_chip_register(struct tpm_chip *chip)
> {
> int rc;
>
> - /* Populate sysfs for TPM1 devices. */
> - if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
> - rc = tpm_sysfs_add_device(chip);
> - if (rc)
> - goto del_misc;
> -
> - chip->bios_dir = tpm_bios_log_setup(chip->devname);
> - }
> + rc = tpm1_chip_register(chip);
> + if (rc)
> + return rc;
>
> rc = tpm_add_ppi(chip);
> if (rc)
> - goto del_sysfs;
> + goto out_err;
>
> rc = tpm_dev_add_device(chip);
> if (rc)
> - return rc;
> + goto out_err;
>
> /* Make the chip available. */
> spin_lock(&driver_lock);
> @@ -210,10 +232,9 @@ int tpm_chip_register(struct tpm_chip *chip)
> chip->flags |= TPM_CHIP_FLAG_REGISTERED;
>
> return 0;
> -del_sysfs:
> - tpm_sysfs_del_device(chip);
> -del_misc:
> - tpm_dev_del_device(chip);
> +out_err:
> + tpm_remove_ppi(chip);
> + tpm1_chip_unregister(chip);
> return rc;
> }
> EXPORT_SYMBOL_GPL(tpm_chip_register);
> @@ -238,13 +259,8 @@ void tpm_chip_unregister(struct tpm_chip *chip)
> spin_unlock(&driver_lock);
> synchronize_rcu();
>
> - if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
> - if (chip->bios_dir)
> - tpm_bios_log_teardown(chip->bios_dir);
> - tpm_sysfs_del_device(chip);
> - }
> -
> tpm_remove_ppi(chip);
> + tpm1_chip_unregister(chip);
> tpm_dev_del_device(chip);
> }
> EXPORT_SYMBOL_GPL(tpm_chip_unregister);
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rtmutex: Cleanup the variable's name in rt_mutex_adjust_prio_chain
From: "Tom(JeHyeon) Yeon" change "deadlock_detect" to "chwalk" following by commit 8930ed80 Signed-off-by: Tom(JeHyeon) Yeon --- kernel/locking/rtmutex.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index 6357265..b732793 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -349,7 +349,7 @@ static inline struct rt_mutex *task_blocked_on_lock(struct task_struct *p) * * @task: the task owning the mutex (owner) for which a chain walk is * probably needed - * @deadlock_detect: do we have to carry out deadlock detection? + * @chwalk:do we have to carry out deadlock detection? * @orig_lock: the mutex (can be NULL if we are walking the chain to recheck * things for a task that has just got its priority adjusted, and * is waiting on a mutex) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
performance changes on d4b4c2cd: 37.6% fsmark.files_per_sec, -15.9% fsmark.files_per_sec, and few more
Hi, FYI, we noticed performance changes on `fsmark.files_per_sec' by d4b4c2cdffab86f5c7594c44635286a6d277d5c6: > commit d4b4c2cdffab86f5c7594c44635286a6d277d5c6 > Author: s...@kernel.org > AuthorDate: Mon Dec 15 12:57:03 2014 +1100 > Commit: NeilBrown > CommitDate: Wed Mar 4 13:40:17 2015 +1100 > > RAID5: batch adjacent full stripe write c1dfe87e41d9c2926fe92f803f02c733ddbccf0b d4b4c2cdffab86f5c7594c44635286a6d277d5c6 run time(m) metric_value ±stddev run time(m) metric_value ±stddev change testbox/benchmark/sub-testcase --- -- --- -- -- 4 15.3 33.525 ±3.0% 6 11.1 46.133 ±5.0% 37.6% ivb44/fsmark/1x-1t-3HDD-RAID5-xfs-4M-120G-NoSync 3 0.5 262.800 ±1.5% 3 0.4 307.367 ±1.2% 17.0% ivb44/fsmark/1x-1t-4BRD_12G-RAID5-f2fs-4M-30G-NoSync 3 0.5 289.900 ±0.3% 3 0.4 323.367 ±2.4% 11.5% ivb44/fsmark/1x-64t-4BRD_12G-RAID5-f2fs-4M-30G-NoSync 3 0.5 325.667 ±2.2% 3 0.5 358.800 ±1.8% 10.2% ivb44/fsmark/1x-64t-4BRD_12G-RAID5-ext4-4M-30G-NoSync 3 0.6 216.100 ±0.4% 3 0.6 230.100 ±0.4% 6.5% ivb44/fsmark/1x-64t-4BRD_12G-RAID5-f2fs-4M-30G-fsyncBeforeClose 3 0.5 309.900 ±0.3% 3 0.5 328.500 ±1.1% 6.0% ivb44/fsmark/1x-64t-4BRD_12G-RAID5-xfs-4M-30G-NoSync 3 13.8 37.000 ±0.2% 3 16.5 31.100 ±0.3% -15.9% ivb44/fsmark/1x-1t-3HDD-RAID5-f2fs-4M-120G-NoSync NOTE: here are some more info about those test parameters for you to understand the testcase better: 1x : where 'x' means iterations or loop, corresponding to the 'L' option of fsmark 64t: where 't' means thread 4M : means the single file size, corresponding to the '-s' option of fsmark 120G, 30G: means the total test size 4BRD_12G: BRD is the ramdisk, where '4' means 4 ramdisk, and where '12G' means the size of one ramdisk. So, it would be 48G in total. And we made a raid on those ramdisk. And FYI, here I listed more detailed changes for the maximal postive and negtive changes. more detailed changes about ivb44/fsmark/1x-1t-3HDD-RAID5-xfs-4M-120G-NoSync - c1dfe87e41d9c292 d4b4c2cdffab86f5c7594c4463 -- %stddev %change %stddev \ |\ 33.53 ± 3% +37.6% 46.13 ± 4% fsmark.files_per_sec 916 ± 3% -27.2%667 ± 5% fsmark.time.elapsed_time.max 916 ± 3% -27.2%667 ± 5% fsmark.time.elapsed_time 7 ± 5% +37.6% 10 ± 6% fsmark.time.percent_of_cpu_this_job_got 92097 ± 2% -23.1% 70865 ± 4% fsmark.time.voluntary_context_switches 0.04 ± 42%+681.0% 0.27 ± 22% turbostat.Pkg%pc3 716062 ± 3% -82.7% 124210 ± 21% cpuidle.C1-IVT.usage 6.883e+08 ± 2% -86.8% 91146705 ± 34% cpuidle.C1-IVT.time 0.04 ± 30%+145.8% 0.10 ± 25% turbostat.CPU%c3 404 ± 16% -58.4%168 ± 14% cpuidle.POLL.usage 159 ± 47%+179.5%444 ± 23% proc-vmstat.kswapd_low_wmark_hit_quickly 11133 ± 23%+100.3% 22298 ± 30% cpuidle.C3-IVT.usage 10286681 ± 27% +95.6% 20116924 ± 27% cpuidle.C3-IVT.time 7.92 ± 16% +77.4% 14.05 ± 6% turbostat.Pkg%pc6 4.93 ± 3% -38.6% 3.03 ± 2% turbostat.CPU%c1 916 ± 3% -27.2%667 ± 5% time.elapsed_time.max 916 ± 3% -27.2%667 ± 5% time.elapsed_time 2137390 ± 3% -26.7%1566752 ± 5% proc-vmstat.pgfault 7 ± 5% +37.6% 10 ± 6% time.percent_of_cpu_this_job_got 4.309e+10 ± 3% -26.3% 3.176e+10 ± 5% cpuidle.C6-IVT.time 49038 ± 2% -23.9% 37334 ± 4% uptime.idle 1047 ± 2% -23.8%797 ± 4% uptime.boot 92097 ± 2% -23.1% 70865 ± 4% time.voluntary_context_switches 4005888 ± 0% +13.3%4537685 ± 11% meminfo.DirectMap2M 3917 ± 2% -16.3% 3278 ± 5% proc-vmstat.pageoutrun 213737 ± 1% -13.9% 183969 ± 3% softirqs.SCHED 46.86 ± 1% +16.5% 54.59 ± 1% turbostat.Pkg%pc2 32603 ± 3% -11.7% 28781 ± 5% numa-vmstat.node1.nr_unevictable 130415 ± 3% -11.7% 115127 ± 5% numa-meminfo.node1.Unevictable 256781 ± 2% -8.8% 234146 ± 3% softirqs.TASKLET 253606 ± 2% -8.9% 231108 ± 3% softirqs.BLOCK 119.10 ± 2% -7
performance changes on 4400755e: 200.0% fsmark.files_per_sec, -18.1% fsmark.files_per_sec, and few more
Hi, FYI, we noticed performance changes on `fsmark.files_per_sec' by 4400755e356f9a2b0b7ceaa02f57b1c7546c3765: > commit 4400755e356f9a2b0b7ceaa02f57b1c7546c3765 > Author: NeilBrown > AuthorDate: Thu Feb 26 12:47:56 2015 +1100 > Commit: NeilBrown > CommitDate: Wed Mar 4 13:40:19 2015 +1100 > > md/raid5: allow the stripe_cache to grow and shrink. 26089f4902595a2f64c512066af07af6e82eb096 4400755e356f9a2b0b7ceaa02f57b1c7546c3765 run time(m) metric_value ±stddev run time(m) metric_value ±stddev change testbox/benchmark/sub-testcase --- -- --- -- -- 3 18.6 6.400 ±0.0% 5 9.2 19.200 ±0.0% 200.0% ivb44/fsmark/1x-64t-3HDD-RAID5-ext4-4M-40G-fsyncBeforeClose 3 24.7 6.400 ±0.0% 3 13.7 12.800 ±0.0% 100.0% ivb44/fsmark/1x-64t-3HDD-RAID5-f2fs-4M-40G-fsyncBeforeClose 3 17.5 28.267 ±9.6% 3 12.3 42.833 ±6.5% 51.5% ivb44/fsmark/1x-64t-3HDD-RAID5-f2fs-4M-120G-NoSync 3 16.7 30.700 ±1.5% 3 12.6 40.733 ±2.4% 32.7% ivb44/fsmark/1x-1t-3HDD-RAID5-f2fs-4M-120G-NoSync 3 29.0 5.867 ±0.8% 5 23.6 7.240 ±0.7% 23.4% ivb44/fsmark/1x-1t-3HDD-RAID5-btrfs-4M-40G-fsyncBeforeClose 3 28.5 6.000 ±0.0% 3 23.2 7.367 ±0.6% 22.8% ivb44/fsmark/1x-1t-3HDD-RAID5-f2fs-4M-40G-fsyncBeforeClose 5 11.7 14.600 ±0.0% 5 9.7 17.500 ±0.4% 19.9% ivb44/fsmark/1x-1t-3HDD-RAID5-xfs-4M-40G-fsyncBeforeClose 3 22.4 25.600 ±0.0% 5 17.9 30.120 ±4.1% 17.7% ivb44/fsmark/1x-64t-3HDD-RAID5-xfs-4M-120G-NoSync 5 10.8 47.320 ±0.6% 5 9.3 54.820 ±0.2% 15.8% ivb44/fsmark/1x-1t-3HDD-RAID5-xfs-4M-120G-NoSync 1 0.5 252.400 ±0.0% 1 0.5 263.300 ±0.0% 4.3% ivb44/fsmark/1x-1t-4BRD_12G-RAID5-ext4-4M-30G-NoSync 3 0.5 273.100 ±4.3% 3 0.6 223.567 ±6.5% -18.1% ivb44/fsmark/1x-64t-4BRD_12G-RAID5-btrfs-4M-30G-NoSync 3 8.1 63.133 ±0.5% 3 9.2 55.633 ±0.2% -11.9% ivb44/fsmark/1x-1t-3HDD-RAID5-btrfs-4M-120G-NoSync 3 8.2 64.000 ±0.0% 3 9.2 57.600 ±0.0% -10.0% ivb44/fsmark/1x-64t-3HDD-RAID5-btrfs-4M-120G-NoSync NOTE: here are some more info about those test parameters for you to understand the testcase better: 1x: where 'x' means iterations or loop, corresponding to the 'L' option of fsmark 1t, 64t: where 't' means thread 4M: means the single file size, corresponding to the '-s' option of fsmark 40G, 30G, 120G: means the total test size 4BRD_12G: BRD is the ramdisk, where '4' means 4 ramdisk, and where '12G' means the size of one ramdisk. So, it would be 48G in total. And we made a raid on those ramdisk. As you can see from above data, interestingly, all performance regressions come from btrfs testing. That's why Chris is also in the cc list, with which just FYI. FYI, here I listed more detailed changes for the maximal postive and negtive changes. more detailed changes about ivb44/fsmark/1x-64t-3HDD-RAID5-ext4-4M-40G-fsyncBeforeClose - 26089f4902595a2f 4400755e356f9a2b0b7ceaa02f -- %stddev %change %stddev \ |\ 6.40 ± 0%+200.0% 19.20 ± 0% fsmark.files_per_sec 1.015e+08 ± 1% -73.6% 26767355 ± 3% fsmark.time.voluntary_context_switches 13793 ± 1% -73.9% 3603 ± 5% fsmark.time.system_time 78473 ± 6% -64.3% 28016 ± 7% fsmark.time.involuntary_context_switches 15789555 ± 9% -54.7%7159485 ± 13% fsmark.app_overhead 1115 ± 0% -50.3%554 ± 1% fsmark.time.elapsed_time.max 1115 ± 0% -50.3%554 ± 1% fsmark.time.elapsed_time 1235 ± 2% -47.5%649 ± 3% fsmark.time.percent_of_cpu_this_job_got 456465 ± 1% -26.7% 334594 ± 4% fsmark.time.minor_page_faults 275 ± 0% +1257.7% 3733 ± 2% slabinfo.raid5-md0.num_objs 275 ± 0% +1257.7% 3733 ± 2% slabinfo.raid5-md0.active_objs 11 ± 0% +1250.9%148 ± 2% slabinfo.raid5-md0.active_slabs 11 ± 0% +1250.9%148 ± 2% slabinfo.raid5-md0.num_slabs 2407 ± 4%+293.4% 9471 ± 26% numa-mem
Re: [RFC, v2] powerpc/powernv: Introduce kernel param to control fastsleep workaround behavior
On Tue, 2015-03-17 at 21:19 +0530, Shreyas B Prabhu wrote: > > On Tuesday 17 March 2015 03:09 PM, Benjamin Herrenschmidt wrote: > > On Tue, 2015-03-17 at 19:57 +1100, Michael Ellerman wrote: > >> > >> >From what I can see below, the decision as to whether you apply the > >> >workaround > >> or not doesn't affect the list of idle states. So this could just as well > >> be a > >> runtime parameter, ie. a sysfs file, which can then be set by the user > >> whenever > >> they like? They might do it in a boot script, but that's up to them. > > > > Right, that would work too. > > Okay. I'll send a patch with this design. Thanks. > >> For simplicity I think it would also be fine to make it a write-once > >> parameter, > >> ie. you don't need to handle undoing it. > > > > It would be easy enough to make it rw using stop machine I think... > > > >> I think the only complication that would add is that you'd need to be a > >> little > >> careful about the order in which you nop out the calls vs applying the > >> workaround, in case some threads are idle when you're called. > > Right, we should be safe with this sequence- > - NOP call to undo workaround > - Apply workaround on all cores. > - NOP call to apply workaround Yeah that sounds right. > > I wouldn't bother with NOP'ing in that case, a runtime test will probably > > be noise > > in the measurement. > > Didn't get your point here. Do you mean, ignore the request if some > cores are in sleep or deeper state? I *think* what he means is we probably don't actually need to patch a nop in/out. Instead we could just test a flag, because the cost of testing a flag is miniscule compared to the rest of the logic. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] tpm: fix: sanitized code paths in tpm_chip_register()
I started to work with PPI interface so that it would be available
under character device sysfs directory and realized that chip
registeration was still too messy.
In TPM 1.x in some rare scenarios (errors that almost never occur)
wrong order in deinitialization steps was taken in teardown. I
reproduced these scenarios by manually inserting error codes in the
place of the corresponding function calls.
The key problem is that the teardown is messy with two separate code
paths (this was inherited when moving code from tpm-interface.c).
Moved TPM 1.x specific register/unregister functionality to own helper
functions and added single code path for teardown in tpm_chip_register().
Now the code paths have been fixed and it should be easier to review
later on this part of the code.
Signed-off-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-chip.c | 56 +
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index cf43f4b..e5b0481 100644
--- a/drivers/char/tpm/tpm-chip.c
+++ b/drivers/char/tpm/tpm-chip.c
@@ -170,6 +170,33 @@ static void tpm_dev_del_device(struct tpm_chip *chip)
device_unregister(&chip->dev);
}
+static int tpm1_chip_register(struct tpm_chip *chip)
+{
+ int rc;
+
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ return 0;
+
+ rc = tpm_sysfs_add_device(chip);
+ if (rc)
+ return rc;
+
+ chip->bios_dir = tpm_bios_log_setup(chip->devname);
+
+ return 0;
+}
+
+static void tpm1_chip_unregister(struct tpm_chip *chip)
+{
+ if (chip->flags & TPM_CHIP_FLAG_TPM2)
+ return;
+
+ if (chip->bios_dir)
+ tpm_bios_log_teardown(chip->bios_dir);
+
+ tpm_sysfs_del_device(chip);
+}
+
/*
* tpm_chip_register() - create a character device for the TPM chip
* @chip: TPM chip to use.
@@ -185,22 +212,17 @@ int tpm_chip_register(struct tpm_chip *chip)
{
int rc;
- /* Populate sysfs for TPM1 devices. */
- if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
- rc = tpm_sysfs_add_device(chip);
- if (rc)
- goto del_misc;
-
- chip->bios_dir = tpm_bios_log_setup(chip->devname);
- }
+ rc = tpm1_chip_register(chip);
+ if (rc)
+ return rc;
rc = tpm_add_ppi(chip);
if (rc)
- goto del_sysfs;
+ goto out_err;
rc = tpm_dev_add_device(chip);
if (rc)
- return rc;
+ goto out_err;
/* Make the chip available. */
spin_lock(&driver_lock);
@@ -210,10 +232,9 @@ int tpm_chip_register(struct tpm_chip *chip)
chip->flags |= TPM_CHIP_FLAG_REGISTERED;
return 0;
-del_sysfs:
- tpm_sysfs_del_device(chip);
-del_misc:
- tpm_dev_del_device(chip);
+out_err:
+ tpm_remove_ppi(chip);
+ tpm1_chip_unregister(chip);
return rc;
}
EXPORT_SYMBOL_GPL(tpm_chip_register);
@@ -238,13 +259,8 @@ void tpm_chip_unregister(struct tpm_chip *chip)
spin_unlock(&driver_lock);
synchronize_rcu();
- if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
- if (chip->bios_dir)
- tpm_bios_log_teardown(chip->bios_dir);
- tpm_sysfs_del_device(chip);
- }
-
tpm_remove_ppi(chip);
+ tpm1_chip_unregister(chip);
tpm_dev_del_device(chip);
}
EXPORT_SYMBOL_GPL(tpm_chip_unregister);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Revert "of: Fix premature bootconsole disable with 'stdout-path'"
On Tue, 2015-03-17 at 16:46 -0400, Peter Hurley wrote: > This reverts commit 2fa645cb2703d9b3786d850db815414dfeefa51d. > > The assumption that at least 1 preferred console will be registered > when the stdout-path property is set is invalid, which can result > in _no_ consoles. > > Signed-off-by: Peter Hurley Grant/Rob, in case you didn't see it, this has caused a panic on at least one powerpc box. So would be nice if it could go in for 4.0. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4 V5] workqueue: Create low-level unbound workqueues cpumask
From: Frederic Weisbecker
Create a cpumask that limit the affinity of all unbound workqueues.
This cpumask is controlled though a file at the root of the workqueue
sysfs directory.
It works on a lower-level than the per WQ_SYSFS workqueues cpumask files
such that the effective cpumask applied for a given unbound workqueue is
the intersection of /sys/devices/virtual/workqueue/$WORKQUEUE/cpumask and
the new /sys/devices/virtual/workqueue/cpumask_unbounds file.
This patch implements the basic infrastructure and the read interface.
cpumask_unbounds is initially set to cpu_possible_mask.
Cc: Christoph Lameter
Cc: Kevin Hilman
Cc: Lai Jiangshan
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Tejun Heo
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
Signed-off-by: Lai Jiangshan
---
kernel/workqueue.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index b150828..d1197f0 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -299,6 +299,8 @@ static DEFINE_SPINLOCK(wq_mayday_lock); /* protects
wq->maydays list */
static LIST_HEAD(workqueues); /* PR: list of all workqueues */
static bool workqueue_freezing;/* PL: have wqs started
freezing? */
+static cpumask_var_t wq_unbound_cpumask;
+
/* the per-cpu worker pools */
static DEFINE_PER_CPU_SHARED_ALIGNED(struct worker_pool [NR_STD_WORKER_POOLS],
cpu_worker_pools);
@@ -3532,7 +3534,7 @@ wq_unbound_install_ctx_prepare(struct workqueue_struct
*wq,
/* make a copy of @attrs and sanitize it */
copy_workqueue_attrs(new_attrs, attrs);
- cpumask_and(new_attrs->cpumask, new_attrs->cpumask, cpu_possible_mask);
+ cpumask_and(new_attrs->cpumask, new_attrs->cpumask, wq_unbound_cpumask);
/*
* We may create multiple pwqs with differing cpumasks. Make a
@@ -3963,9 +3965,29 @@ static struct bus_type wq_subsys = {
.dev_groups = wq_sysfs_groups,
};
+static ssize_t unbounds_cpumask_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ int written;
+
+ written = scnprintf(buf, PAGE_SIZE, "%*pb\n",
+ cpumask_pr_args(wq_unbound_cpumask));
+
+ return written;
+}
+
+static struct device_attribute wq_sysfs_cpumask_attr =
+ __ATTR(cpumask, 0444, unbounds_cpumask_show, NULL);
+
static int __init wq_sysfs_init(void)
{
- return subsys_virtual_register(&wq_subsys, NULL);
+ int err;
+
+ err = subsys_virtual_register(&wq_subsys, NULL);
+ if (err)
+ return err;
+
+ return device_create_file(wq_subsys.dev_root, &wq_sysfs_cpumask_attr);
}
core_initcall(wq_sysfs_init);
@@ -5098,6 +5120,9 @@ static int __init init_workqueues(void)
WARN_ON(__alignof__(struct pool_workqueue) < __alignof__(long long));
+ BUG_ON(!alloc_cpumask_var(&wq_unbound_cpumask, GFP_KERNEL));
+ cpumask_copy(wq_unbound_cpumask, cpu_possible_mask);
+
pwq_cache = KMEM_CACHE(pool_workqueue, SLAB_PANIC);
cpu_notifier(workqueue_cpu_up_callback, CPU_PRI_WORKQUEUE_UP);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4 V5] workqueue: split apply_workqueue_attrs() into 3 stages
Current apply_workqueue_attrs() includes pwqs-allocation and pwqs-installation,
so when we batch multiple apply_workqueue_attrs()s as a transaction, we can't
ensure the transaction must succeed or fail as a complete unit.
To solve this, we split apply_workqueue_attrs() into three stages.
The first stage does the preparation: allocation memory, pwqs.
The second stage does the attrs-installaion and pwqs-installation.
The third stage frees the allocated memory and (old or unused) pwqs.
As the result, batching multiple apply_workqueue_attrs()s can
succeed or fail as a complete unit:
1) batch do all the first stage for all the workqueues
2) only commit all when all the above succeed.
This patch is a preparation for the next patch ("Allow modifying low level
unbound workqueue cpumask") which will do a multiple apply_workqueue_attrs().
The patch doesn't have functionality changed except two minor adjustment:
1) free_unbound_pwq() for the error path is removed, we use the
heavier version put_pwq_unlocked() instead since the error path
is rare. this adjustment simplifies the code.
2) the memory-allocation is also moved into wq_pool_mutex.
this is needed to avoid to do the further splitting.
Suggested-by: Tejun Heo
Cc: Christoph Lameter
Cc: Kevin Hilman
Cc: Lai Jiangshan
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Tejun Heo
Cc: Viresh Kumar
Cc: Frederic Weisbecker
Signed-off-by: Lai Jiangshan
---
kernel/workqueue.c | 203 +++--
1 file changed, 119 insertions(+), 84 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c6845fa..b150828 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3424,17 +3424,6 @@ static struct pool_workqueue *alloc_unbound_pwq(struct
workqueue_struct *wq,
return pwq;
}
-/* undo alloc_unbound_pwq(), used only in the error path */
-static void free_unbound_pwq(struct pool_workqueue *pwq)
-{
- lockdep_assert_held(&wq_pool_mutex);
-
- if (pwq) {
- put_unbound_pool(pwq->pool);
- kmem_cache_free(pwq_cache, pwq);
- }
-}
-
/**
* wq_calc_node_mask - calculate a wq_attrs' cpumask for the specified node
* @attrs: the wq_attrs of interest
@@ -3497,42 +3486,49 @@ static struct pool_workqueue
*numa_pwq_tbl_install(struct workqueue_struct *wq,
return old_pwq;
}
-/**
- * apply_workqueue_attrs - apply new workqueue_attrs to an unbound workqueue
- * @wq: the target workqueue
- * @attrs: the workqueue_attrs to apply, allocated with alloc_workqueue_attrs()
- *
- * Apply @attrs to an unbound workqueue @wq. Unless disabled, on NUMA
- * machines, this function maps a separate pwq to each NUMA node with
- * possibles CPUs in @attrs->cpumask so that work items are affine to the
- * NUMA node it was issued on. Older pwqs are released as in-flight work
- * items finish. Note that a work item which repeatedly requeues itself
- * back-to-back will stay on its current pwq.
- *
- * Performs GFP_KERNEL allocations.
- *
- * Return: 0 on success and -errno on failure.
- */
-int apply_workqueue_attrs(struct workqueue_struct *wq,
- const struct workqueue_attrs *attrs)
+/* Context to store the prepared attrs & pwqs before installed */
+struct wq_unbound_install_ctx {
+ struct workqueue_struct *wq;/* target to be installed */
+ struct workqueue_attrs *attrs; /* attrs for installing */
+ struct pool_workqueue *dfl_pwq;
+ struct pool_workqueue *pwq_tbl[];
+};
+
+/* Free the resources after success or abort */
+static void wq_unbound_install_ctx_free(struct wq_unbound_install_ctx *ctx)
{
+ int node;
+
+ if (ctx) {
+ /* put the pwqs */
+ for_each_node(node)
+ put_pwq_unlocked(ctx->pwq_tbl[node]);
+ put_pwq_unlocked(ctx->dfl_pwq);
+
+ free_workqueue_attrs(ctx->attrs);
+ }
+
+ kfree(ctx);
+}
+
+/* Allocates the attrs and pwqs for later installment */
+static struct wq_unbound_install_ctx *
+wq_unbound_install_ctx_prepare(struct workqueue_struct *wq,
+ const struct workqueue_attrs *attrs)
+{
+ struct wq_unbound_install_ctx *ctx;
struct workqueue_attrs *new_attrs, *tmp_attrs;
- struct pool_workqueue **pwq_tbl, *dfl_pwq;
- int node, ret;
+ int node;
- /* only unbound workqueues can change attributes */
- if (WARN_ON(!(wq->flags & WQ_UNBOUND)))
- return -EINVAL;
+ lockdep_assert_held(&wq_pool_mutex);
- /* creating multiple pwqs breaks ordering guarantee */
- if (WARN_ON((wq->flags & __WQ_ORDERED) && !list_empty(&wq->pwqs)))
- return -EINVAL;
+ ctx = kzalloc(sizeof(*ctx) + nr_node_ids * sizeof(ctx->pwq_tbl[0]),
+ GFP_KERNEL);
- pwq_tbl = kzalloc(nr_node_ids * sizeof(pwq_tbl[0]), GFP_KERNEL);
[PATCH 0/4 V5] workqueue: Introduce low-level unbound wq sysfs cpumask v5
This patchset mostly copies from Frederic and split the apply_workqueue_attrs() as TJ's suggest. This patchset still doesn't include the patch "workqueue: Allow changing attributions of ordered workqueues", I hope to reduce the review processing. The handling for the ordered workqueue will be repose after this patchset accepted. Changed from V4 Add workqueue_unbounds_cpumask_set() kernel API and minimally restruct the patch4. Thanks, Lai Frederic Weisbecker (2): workqueue: Reorder sysfs code workqueue: Create low-level unbound workqueues cpumask Lai Jiangshan (2): workqueue: split apply_workqueue_attrs() into 3 stages workqueue: Allow modifying low level unbound workqueue cpumask include/linux/workqueue.h | 1 + kernel/workqueue.c| 971 +++--- 2 files changed, 569 insertions(+), 403 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4 V5] workqueue: Allow modifying low level unbound workqueue cpumask
Allow to modify the low-level unbound workqueues cpumask through
sysfs. This is performed by traversing the entire workqueue list
and calling wq_unbound_install_ctx_prepare() on the unbound workqueues
with the low level mask passed in. Only after all the preparation are done,
we commit them all together.
The oreder-workquue is ignore from the low level unbound workqueue cpumask,
it will be handled in near future.
The per-nodes' pwqs are mandatorily controlled by the low level cpumask, while
the default pwq ignores the low level cpumask when (and ONLY when) the cpumask
set
by the user doesn't overlap with the low level cpumask. In this case, we can't
apply the empty cpumask to the default pwq, so we use the user-set cpumask
directly.
The default wq_unbound_cpumask is still cpu_possible_mask due to the workqueue
subsystem doesn't know what is the best default value for the runtime, the
system manager or other subsystem which knows the sufficient information should
set
it when needed.
Cc: Christoph Lameter
Cc: Kevin Hilman
Cc: Lai Jiangshan
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Tejun Heo
Cc: Viresh Kumar
Cc: Frederic Weisbecker
Original-patch-by: Frederic Weisbecker
Signed-off-by: Lai Jiangshan
---
include/linux/workqueue.h | 1 +
kernel/workqueue.c| 121 +++---
2 files changed, 114 insertions(+), 8 deletions(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index deee212..052d1bf 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -424,6 +424,7 @@ struct workqueue_attrs *alloc_workqueue_attrs(gfp_t
gfp_mask);
void free_workqueue_attrs(struct workqueue_attrs *attrs);
int apply_workqueue_attrs(struct workqueue_struct *wq,
const struct workqueue_attrs *attrs);
+int workqueue_unbounds_cpumask_set(cpumask_var_t cpumask);
extern bool queue_work_on(int cpu, struct workqueue_struct *wq,
struct work_struct *work);
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index d1197f0..47f1a9d 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -299,7 +299,7 @@ static DEFINE_SPINLOCK(wq_mayday_lock); /* protects
wq->maydays list */
static LIST_HEAD(workqueues); /* PR: list of all workqueues */
static bool workqueue_freezing;/* PL: have wqs started
freezing? */
-static cpumask_var_t wq_unbound_cpumask;
+static cpumask_var_t wq_unbound_cpumask; /* PL: low level cpumask for all
unbound wqs */
/* the per-cpu worker pools */
static DEFINE_PER_CPU_SHARED_ALIGNED(struct worker_pool [NR_STD_WORKER_POOLS],
@@ -3492,6 +3492,7 @@ static struct pool_workqueue *numa_pwq_tbl_install(struct
workqueue_struct *wq,
struct wq_unbound_install_ctx {
struct workqueue_struct *wq;/* target to be installed */
struct workqueue_attrs *attrs; /* attrs for installing */
+ struct list_headlist; /* queued for batching commit */
struct pool_workqueue *dfl_pwq;
struct pool_workqueue *pwq_tbl[];
};
@@ -3516,10 +3517,11 @@ static void wq_unbound_install_ctx_free(struct
wq_unbound_install_ctx *ctx)
/* Allocates the attrs and pwqs for later installment */
static struct wq_unbound_install_ctx *
wq_unbound_install_ctx_prepare(struct workqueue_struct *wq,
- const struct workqueue_attrs *attrs)
+ const struct workqueue_attrs *attrs,
+ cpumask_var_t unbound_cpumask)
{
struct wq_unbound_install_ctx *ctx;
- struct workqueue_attrs *new_attrs, *tmp_attrs;
+ struct workqueue_attrs *new_attrs, *pwq_attrs, *tmp_attrs;
int node;
lockdep_assert_held(&wq_pool_mutex);
@@ -3528,13 +3530,16 @@ wq_unbound_install_ctx_prepare(struct workqueue_struct
*wq,
GFP_KERNEL);
new_attrs = alloc_workqueue_attrs(GFP_KERNEL);
+ pwq_attrs = alloc_workqueue_attrs(GFP_KERNEL);
tmp_attrs = alloc_workqueue_attrs(GFP_KERNEL);
if (!ctx || !new_attrs || !tmp_attrs)
goto out_free;
/* make a copy of @attrs and sanitize it */
copy_workqueue_attrs(new_attrs, attrs);
- cpumask_and(new_attrs->cpumask, new_attrs->cpumask, wq_unbound_cpumask);
+ copy_workqueue_attrs(pwq_attrs, attrs);
+ cpumask_and(new_attrs->cpumask, new_attrs->cpumask, cpu_possible_mask);
+ cpumask_and(pwq_attrs->cpumask, pwq_attrs->cpumask, unbound_cpumask);
/*
* We may create multiple pwqs with differing cpumasks. Make a
@@ -3547,13 +3552,21 @@ wq_unbound_install_ctx_prepare(struct workqueue_struct
*wq,
* If something goes wrong during CPU up/down, we'll fall back to
* the default pwq covering whole @attrs->cpumask. Always create
* it even if we don't use it immediately.
+*
+* If the cpumask set by the user doesn't overlap with the global
+* wq_unboun
[PATCH 1/4 V5] workqueue: Reorder sysfs code
From: Frederic Weisbecker
The sysfs code usually belongs to the botom of the file since it deals
with high level objects. In the workqueue code it's misplaced and such
that we'll need to work around functions references to allow the sysfs
code to call APIs like apply_workqueue_attrs().
Lets move that block further in the file, right above alloc_workqueue_key()
which reference it.
Suggested-by: Tejun Heo
Cc: Christoph Lameter
Cc: Kevin Hilman
Cc: Lai Jiangshan
Cc: Mike Galbraith
Cc: Paul E. McKenney
Cc: Tejun Heo
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
Signed-off-by: Lai Jiangshan
---
kernel/workqueue.c | 634 ++---
1 file changed, 317 insertions(+), 317 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 1ca0b1d..c6845fa 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3001,323 +3001,6 @@ int execute_in_process_context(work_func_t fn, struct
execute_work *ew)
}
EXPORT_SYMBOL_GPL(execute_in_process_context);
-#ifdef CONFIG_SYSFS
-/*
- * Workqueues with WQ_SYSFS flag set is visible to userland via
- * /sys/bus/workqueue/devices/WQ_NAME. All visible workqueues have the
- * following attributes.
- *
- * per_cpuRO bool : whether the workqueue is per-cpu or unbound
- * max_active RW int : maximum number of in-flight work items
- *
- * Unbound workqueues have the following extra attributes.
- *
- * id RO int : the associated pool ID
- * nice RW int : nice value of the workers
- * cpumaskRW mask : bitmask of allowed CPUs for the workers
- */
-struct wq_device {
- struct workqueue_struct *wq;
- struct device dev;
-};
-
-static struct workqueue_struct *dev_to_wq(struct device *dev)
-{
- struct wq_device *wq_dev = container_of(dev, struct wq_device, dev);
-
- return wq_dev->wq;
-}
-
-static ssize_t per_cpu_show(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct workqueue_struct *wq = dev_to_wq(dev);
-
- return scnprintf(buf, PAGE_SIZE, "%d\n", (bool)!(wq->flags &
WQ_UNBOUND));
-}
-static DEVICE_ATTR_RO(per_cpu);
-
-static ssize_t max_active_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct workqueue_struct *wq = dev_to_wq(dev);
-
- return scnprintf(buf, PAGE_SIZE, "%d\n", wq->saved_max_active);
-}
-
-static ssize_t max_active_store(struct device *dev,
- struct device_attribute *attr, const char *buf,
- size_t count)
-{
- struct workqueue_struct *wq = dev_to_wq(dev);
- int val;
-
- if (sscanf(buf, "%d", &val) != 1 || val <= 0)
- return -EINVAL;
-
- workqueue_set_max_active(wq, val);
- return count;
-}
-static DEVICE_ATTR_RW(max_active);
-
-static struct attribute *wq_sysfs_attrs[] = {
- &dev_attr_per_cpu.attr,
- &dev_attr_max_active.attr,
- NULL,
-};
-ATTRIBUTE_GROUPS(wq_sysfs);
-
-static ssize_t wq_pool_ids_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct workqueue_struct *wq = dev_to_wq(dev);
- const char *delim = "";
- int node, written = 0;
-
- rcu_read_lock_sched();
- for_each_node(node) {
- written += scnprintf(buf + written, PAGE_SIZE - written,
-"%s%d:%d", delim, node,
-unbound_pwq_by_node(wq, node)->pool->id);
- delim = " ";
- }
- written += scnprintf(buf + written, PAGE_SIZE - written, "\n");
- rcu_read_unlock_sched();
-
- return written;
-}
-
-static ssize_t wq_nice_show(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct workqueue_struct *wq = dev_to_wq(dev);
- int written;
-
- mutex_lock(&wq->mutex);
- written = scnprintf(buf, PAGE_SIZE, "%d\n", wq->unbound_attrs->nice);
- mutex_unlock(&wq->mutex);
-
- return written;
-}
-
-/* prepare workqueue_attrs for sysfs store operations */
-static struct workqueue_attrs *wq_sysfs_prep_attrs(struct workqueue_struct *wq)
-{
- struct workqueue_attrs *attrs;
-
- attrs = alloc_workqueue_attrs(GFP_KERNEL);
- if (!attrs)
- return NULL;
-
- mutex_lock(&wq->mutex);
- copy_workqueue_attrs(attrs, wq->unbound_attrs);
- mutex_unlock(&wq->mutex);
- return attrs;
-}
-
-static ssize_t wq_nice_store(struct device *dev, struct device_attribute *attr,
-const char *buf, size_t count)
-{
- struct workqueue_struct *wq = dev_to_wq(dev);
- struct workqueue_attrs *attrs;
- int ret;
-
- attrs = wq_sysfs_prep_attrs(wq);
- if (!attrs)
- return -ENOMEM;
-
- if (sscanf(buf, "%d", &attrs->nice) == 1 &&
- attrs->nic
Re: [PATCH] Avoid null-pointer access in w1/slaves/w1_therm
On Sat, Mar 14, 2015 at 11:55:16PM +0300, Evgeniy Polyakov wrote:
> Hi David
>
> 12.03.2015, 03:54, "David Fries" :
> > Would that be removing all four refcnt, w1_slave, w1_master,
> > w1_family, w1_cb_block, or just some of them? It sounds good to me,
> > if that had bugs there would be much more than just the w1 system
> > relying on it. I don't know enough about that system or have the time
> > to code up that change.
> >
> > I can take another look at and post the reference counting w1_therm
> > fix instead of the mutex version as a near term work around until that
> > is available if you want.
>
> Please cook up a quick fix for this problem - this bug really hurts people.
> And then we will discuss how 'ideal' life cycle should look
Done, I don't like it, I'm not sure anyone else will either, but I'm
no longer crashing in testing, so that's an improvement. My
"production" system doesn't use w1_therm, so I only see these bugs in
development testing it. I've come to the conclusion that in the face
of a slave vanishing, w1_therm can't avoid all the race conditions, so
the real fix must be elsewhere.
>From 51d4024ca667c8b712de462489d125a78e85aa57 Mon Sep 17 00:00:00 2001
From: David Fries
Date: Sat, 7 Mar 2015 22:25:37 -0600
Subject: [PATCH] w1_therm, reduce race conditions in w1_slave_show
After applying this patch commands such as the following in one
process,
slave=28-02c95fb1
while true; do echo $slave > /sys/devices/w1_bus_master1/w1_master_add; sleep
.1; echo $slave > /sys/devices/w1_bus_master1/w1_master_remove; sleep .1; done
and then two at the same time in two other processes,
slave=28-02c95fb1
while true; do time cat /sys/devices/w1_bus_master1/$slave/w1_slave ; sleep .1;
done
then randomly stop all three and repeat.
With this patch I no longer see crashes, but at best this patch
effectively hiding the result of a race condition. sl->family_data is
being freed and set to NULL in the slave removal while the
w1_slave_show is then dereferencing it, this holds on to the pointer
meaning it's probably clobbering memory now instead of crashing. I
wonder if that would make RCU be a fit for this? The original bug
report was pointing the problem as unlocking bus_mutex while waiting
for the temperature conversion, but I was getting sl->family_data set
to NULL more reliable without external power which means bux_mutex was
held for the duration of w1_slave_show, which is not to say that the
original bug report wasn't correct, it is to say that even with the
spinlock, holding bus_mutex on the slave, isn't sufficient to keep the
slave from being removed.
Reported-By: Thorsten Bschorr
---
drivers/w1/slaves/w1_therm.c | 70 +-
1 file changed, 55 insertions(+), 15 deletions(-)
diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
index 1f11a20..403285d 100644
--- a/drivers/w1/slaves/w1_therm.c
+++ b/drivers/w1/slaves/w1_therm.c
@@ -59,16 +59,32 @@ MODULE_ALIAS("w1-family-" __stringify(W1_THERM_DS28EA00));
static int w1_strong_pullup = 1;
module_param_named(strong_pullup, w1_strong_pullup, int, 0);
+struct w1_therm_family_data {
+ uint8_t rom[9];
+ atomic_t refcnt;
+};
+
+/* return the address of the refcnt in the family data */
+#define THERM_REFCNT(family_data) \
+ (&((struct w1_therm_family_data*)family_data)->refcnt)
+
static int w1_therm_add_slave(struct w1_slave *sl)
{
- sl->family_data = kzalloc(9, GFP_KERNEL);
+ sl->family_data = kzalloc(sizeof(struct w1_therm_family_data),
+ GFP_KERNEL);
if (!sl->family_data)
return -ENOMEM;
+ atomic_set(THERM_REFCNT(sl->family_data), 1);
return 0;
}
static void w1_therm_remove_slave(struct w1_slave *sl)
{
+ int refcnt = atomic_sub_return(1, THERM_REFCNT(sl->family_data));
+ while(refcnt) {
+ msleep(1000);
+ refcnt = atomic_read(THERM_REFCNT(sl->family_data));
+ }
kfree(sl->family_data);
sl->family_data = NULL;
}
@@ -194,13 +210,30 @@ static ssize_t w1_slave_show(struct device *device,
struct w1_slave *sl = dev_to_w1_slave(device);
struct w1_master *dev = sl->master;
u8 rom[9], crc, verdict, external_power;
- int i, max_trying = 10;
+ int i, ret, max_trying = 10;
ssize_t c = PAGE_SIZE;
+ u8 *family_data = sl->family_data;
+
+ ret = mutex_lock_interruptible(&dev->bus_mutex);
+ if (ret != 0)
+ goto post_unlock;
- i = mutex_lock_interruptible(&dev->bus_mutex);
- if (i != 0)
- return i;
+ if(!sl->family_data)
+ {
+ ret = -ENODEV;
+ /* Note for anyoe who actually saw this message, it is a known
+* problem with either slave drivers or this driver in
+* particular and the request is only a canary indication as
+* to how many people and how often
Re: [PATCH] PM / devfreq: Fix faulty error message
> The misleading log "releasing devfreq which doesn't exist" prints out
> for well behaved clients. This is due to the fact that _remove_devfreq
> calls itself recursively by proxy (via put_device()). The second time
> _devfreq_remove is called the respective device has already been
> deleted, causing the misleading warning.
>
> So just skip printing the message if _devfreq_remove was called via
> put_device().
>
> Signed-off-by: Deva Ramasubramanian
> ---
> drivers/devfreq/devfreq.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 30b538d8..bee59db 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -399,7 +399,8 @@ static void _remove_devfreq(struct devfreq *devfreq)
> mutex_lock(&devfreq_list_lock);
> if (IS_ERR(find_device_devfreq(devfreq->dev.parent))) {
> mutex_unlock(&devfreq_list_lock);
> - dev_warn(&devfreq->dev, "releasing devfreq which doesn't
> exist\n");
> + if (!skip)
> + dev_warn(&devfreq->dev, "releasing devfreq which
> doesn't exist\n");
There is no variable 'skip' in the function. (you get build error.)
And with patch 585fc83ece43be63, we do not call the function recursively,
either.
---
drivers/devfreq/devfreq.c: In function ‘_remove_devfreq’:
drivers/devfreq/devfreq.c:402:8: error: ‘skip’ undeclared (first use in this
function)
drivers/devfreq/devfreq.c:402:8: note: each undeclared identifier is reported
only once for each function it appears in
make[2]: *** [drivers/devfreq/devfreq.o] Error 1
make[1]: *** [drivers/devfreq] Error 2
make[1]: *** Waiting for unfinished jobs
---
I'll update the function description.
Cheers,
MyungJoo.
> return;
> }
> list_del(&devfreq->node);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
linux-next: manual merge of the kvm-arm tree with Linus' tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in
virt/kvm/arm/vgic.c between commit ae705930fca6 ("arm/arm64: KVM: Keep
elrsr/aisr in sync with software model") from Linus' tree and commit
71760950bf3d ("arm/arm64: KVM: add a common vgic_queue_irq_to_lr fn")
from the kvm-arm tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc virt/kvm/arm/vgic.c
index c9f60f524588,ffd937ca5141..
--- a/virt/kvm/arm/vgic.c
+++ b/virt/kvm/arm/vgic.c
@@@ -982,9 -1092,7 +1098,8 @@@ bool vgic_queue_irq(struct kvm_vcpu *vc
if (vlr.source == sgi_source_id) {
kvm_debug("LR%d piggyback for IRQ%d\n", lr, vlr.irq);
BUG_ON(!test_bit(lr, vgic_cpu->lr_used));
- vlr.state |= LR_STATE_PENDING;
- vgic_set_lr(vcpu, lr, vlr);
+ vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
+ vgic_sync_lr_elrsr(vcpu, lr, vlr);
return true;
}
}
@@@ -1001,12 -1109,8 +1116,9 @@@
vlr.irq = irq;
vlr.source = sgi_source_id;
- vlr.state = LR_STATE_PENDING;
- if (!vgic_irq_is_edge(vcpu, irq))
- vlr.state |= LR_EOI_INT;
-
- vgic_set_lr(vcpu, lr, vlr);
+ vlr.state = 0;
+ vgic_queue_irq_to_lr(vcpu, irq, lr, vlr);
+ vgic_sync_lr_elrsr(vcpu, lr, vlr);
return true;
}
pgpvji7Rbvb9u.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/1] UBIFS: fix incorrect unlocking handling
Yes. The last commit that modifies 'ubifs/dir.c' (sorry for missing the context). All error handling routines introduced by 'd7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53' 1) incorrectly 'unlock' and 2) incorrectly restore 'i_size'. Thanks, Taesoo On 03/17/15 at 08:18pm, Brian Norris wrote: > On Tue, Mar 17, 2015 at 10:09:26PM -0400, Taesoo Kim wrote: > > When ubifs_init_security() fails, 'ui_mutex' is incorrectly > > unlocked and incorrectly restores 'i_size'. There are four > > such places that were introduce by the last commit. > > "The last commit" is not very descriptive. Are you speaking of this > commit? > > commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53 > Author: Subodh Nijsure > Date: Fri Oct 31 13:50:30 2014 -0500 > > UBIFS: Add security.* XATTR support for the UBIFS > > CC'ing authors/reviewers. > > Brian > > > Signed-off-by: Taesoo Kim > > --- > > fs/ubifs/dir.c | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c > > index 0fa6c80..5b24bc4 100644 > > --- a/fs/ubifs/dir.c > > +++ b/fs/ubifs/dir.c > > @@ -272,7 +272,7 @@ static int ubifs_create(struct inode *dir, struct > > dentry *dentry, umode_t mode, > > > > err = ubifs_init_security(dir, inode, &dentry->d_name); > > if (err) > > - goto out_cancel; > > + goto out_inode; > > > > mutex_lock(&dir_ui->ui_mutex); > > dir->i_size += sz_change; > > @@ -292,6 +292,7 @@ out_cancel: > > dir->i_size -= sz_change; > > dir_ui->ui_size = dir->i_size; > > mutex_unlock(&dir_ui->ui_mutex); > > +out_inode: > > make_bad_inode(inode); > > iput(inode); > > out_budg: > > @@ -732,7 +733,7 @@ static int ubifs_mkdir(struct inode *dir, struct dentry > > *dentry, umode_t mode) > > > > err = ubifs_init_security(dir, inode, &dentry->d_name); > > if (err) > > - goto out_cancel; > > + goto out_inode; > > > > mutex_lock(&dir_ui->ui_mutex); > > insert_inode_hash(inode); > > @@ -757,6 +758,7 @@ out_cancel: > > dir_ui->ui_size = dir->i_size; > > drop_nlink(dir); > > mutex_unlock(&dir_ui->ui_mutex); > > +out_inode: > > make_bad_inode(inode); > > iput(inode); > > out_budg: > > @@ -816,7 +818,7 @@ static int ubifs_mknod(struct inode *dir, struct dentry > > *dentry, > > > > err = ubifs_init_security(dir, inode, &dentry->d_name); > > if (err) > > - goto out_cancel; > > + goto out_inode; > > > > mutex_lock(&dir_ui->ui_mutex); > > dir->i_size += sz_change; > > @@ -836,6 +838,7 @@ out_cancel: > > dir->i_size -= sz_change; > > dir_ui->ui_size = dir->i_size; > > mutex_unlock(&dir_ui->ui_mutex); > > +out_inode: > > make_bad_inode(inode); > > iput(inode); > > out_budg: > > @@ -896,7 +899,7 @@ static int ubifs_symlink(struct inode *dir, struct > > dentry *dentry, > > > > err = ubifs_init_security(dir, inode, &dentry->d_name); > > if (err) > > - goto out_cancel; > > + goto out_inode; > > > > mutex_lock(&dir_ui->ui_mutex); > > dir->i_size += sz_change; > > -- > > 2.3.3 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] rtc: mediatek: Add MT63xx RTC driver
Hi Uwe,
On Tue, 2015-03-17 at 14:43 +0100, Uwe Kleine-König wrote:
> Hello Eddie,
>
> On Tue, Mar 17, 2015 at 08:31:14PM +0800, Eddie Huang wrote:
> > On Mon, 2015-03-16 at 16:30 +0100, Uwe Kleine-König wrote:
> > > On Wed, Jan 28, 2015 at 05:27:56PM +0800, Eddie Huang wrote:
> > > > [...]
> > > > +static u16 rtc_read(struct mt6397_rtc *rtc, u32 offset)
> > > rtc_read is a bad name for a driver. There are already 6 functions with
> > > this name in the kernel. Better use a unique prefix.
> >
> > I will use prefix mtk_
> I would prefer a prefix that is unique to the driver. "mtk_" doesn't
> work to distinguish between the rtc and a (say) spi driver. What you
> want here is that if someone reports a bug on any mailinglist with a
> backtrace you are able to immediately see which driver is affected.
>
My meaning is mtk_rtc_read, mtk_rtc_write.
> > > > [...]
> > > > +static irqreturn_t rtc_irq_handler_thread(int irq, void *data)
> > > > +{
> > > > + struct mt6397_rtc *rtc = data;
> > > > + u16 irqsta, irqen;
> > > > +
> > > > + mutex_lock(&rtc->lock);
> > > > + irqsta = rtc_read(rtc, RTC_IRQ_STA);
> > > Do you really need to lock for a single read access?
> >
> > I think this lock is necessary, because other thread may access rtc
> > register at the same time, for example, call mtk_rtc_set_alarm to modify
> > alarm time.
> That would be a valid reason if mtk_rtc_set_alarm touched that register
> twice in a single critical section and the handler must not read the
> value of the first write. Otherwise it should be fine, shouldn't it?
>
My original though is if disable alarm in mtk_rtc_set_alarm function,
RTC_IRQ_STA may be affected, this is why I add mutex. After checking
with designer, RTC_IRQ_STA will not be affected. I will remove the
mutex.
> > > > +static int mtk_rtc_set_time(struct device *dev, struct rtc_time *tm)
> > > > +{
> > > > + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> > > > +
> > > > + tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> > > > + tm->tm_mon++;
> > > > + mutex_lock(&rtc->lock);
> > > > + rtc_write(rtc, RTC_TC_YEA, tm->tm_year);
> > > > + rtc_write(rtc, RTC_TC_MTH, tm->tm_mon);
> > > > + rtc_write(rtc, RTC_TC_DOM, tm->tm_mday);
> > > > + rtc_write(rtc, RTC_TC_HOU, tm->tm_hour);
> > > > + rtc_write(rtc, RTC_TC_MIN, tm->tm_min);
> > > > + rtc_write(rtc, RTC_TC_SEC, tm->tm_sec);
> > > Is this racy? I.e. what happens if RTC_TC_SEC overflows just before you
> > > write to it but after you wrote RTC_TC_MIN?
> >
> > register value will write to hardware after rtc_write_trigger, so the
> > racy condition not exist.
> Ah, it seems the hardware guys did their job. Nice.
>
> Best regards
> Uwe
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: sun8i: dt: Enable A23 SMP support
Add enable-method property to enable SMP support.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a23.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index 78440dffd678..b5684a0048b2 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -81,6 +81,7 @@
};
cpus {
+ enable-method = "allwinner,sun8i-a23";
#address-cells = <1>;
#size-cells = <0>;
@@ -650,6 +651,11 @@
};
};
+ cpucfg@01f01c00 {
+ compatible = "allwinner,sun8i-a23-cpuconfig";
+ reg = <0x01f01c00 0x300>;
+ };
+
r_uart: serial@01f02800 {
compatible = "snps,dw-apb-uart";
reg = <0x01f02800 0x400>;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: dts: sun8i: Enable ARM architected timer on A23
The A23 SoC has the architected timer, but the existing firmware from
Allwinner does not set CNTFRQ at all.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a23.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index 674d4c5e7ee1..78440dffd678 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -70,6 +70,16 @@
};
};
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = ,
+,
+,
+;
+ clock-frequency = <2400>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: sun8i: Add SMP support for the Allwinner A23
The A23 is a dual Cortex-A7. Add the logic to use the IPs used to
control the CPU configuration and the CPU power so that we can
bring up secondary CPUs at boot.
Signed-off-by: Chen-Yu Tsai
---
We can't use of_io_request_and_map() here, as it will conflict
with PRCM, and leave us without a serial console.
I think a proper way to solve this would be a syscon device or
something like the mfd-simple device posted by Arnd.
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/mach-sunxi/platsmp.c | 69 ++
2 files changed, 70 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 8b9e0a95de31..40202d85b132 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -188,6 +188,7 @@ nodes to be present and contain the properties described
below.
# On ARM 32-bit systems this property is optional and
can be one of:
"allwinner,sun6i-a31"
+ "allwinner,sun8i-a23"
"arm,psci"
"brcm,brahma-b15"
"marvell,armada-375-smp"
diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
index 587b0468efcc..e8483ec79d67 100644
--- a/arch/arm/mach-sunxi/platsmp.c
+++ b/arch/arm/mach-sunxi/platsmp.c
@@ -121,3 +121,72 @@ static struct smp_operations sun6i_smp_ops __initdata = {
.smp_boot_secondary = sun6i_smp_boot_secondary,
};
CPU_METHOD_OF_DECLARE(sun6i_a31_smp, "allwinner,sun6i-a31", &sun6i_smp_ops);
+
+static void __init sun8i_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, "allwinner,sun8i-a23-prcm");
+ if (!node) {
+ pr_err("Missing A23 PRCM node in the device tree\n");
+ return;
+ }
+
+ prcm_membase = of_iomap(node, 0);
+ if (!prcm_membase) {
+ pr_err("Couldn't map A23 PRCM registers\n");
+ return;
+ }
+
+ node = of_find_compatible_node(NULL, NULL,
+ "allwinner,sun8i-a23-cpuconfig");
+ if (!node) {
+ pr_err("Missing A23 CPU config node in the device tree\n");
+ return;
+ }
+
+ cpucfg_membase = of_iomap(node, 0);
+ if (!cpucfg_membase)
+ pr_err("Couldn't map A23 CPU config registers\n");
+
+}
+
+static int sun8i_smp_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ u32 reg;
+
+ if (!(prcm_membase && cpucfg_membase))
+ return -EFAULT;
+
+ spin_lock(&cpu_lock);
+
+ /* Set CPU boot address */
+ writel(virt_to_phys(secondary_startup),
+ cpucfg_membase + CPUCFG_PRIVATE0_REG);
+
+ /* Assert the CPU core in reset */
+ writel(0, cpucfg_membase + CPUCFG_CPU_RST_CTRL_REG(cpu));
+
+ /* Assert the L1 cache in reset */
+ reg = readl(cpucfg_membase + CPUCFG_GEN_CTRL_REG);
+ writel(reg & ~BIT(cpu), cpucfg_membase + CPUCFG_GEN_CTRL_REG);
+
+ /* Clear CPU power-off gating */
+ reg = readl(prcm_membase + PRCM_CPU_PWROFF_REG);
+ writel(reg & ~BIT(cpu), prcm_membase + PRCM_CPU_PWROFF_REG);
+ mdelay(1);
+
+ /* Deassert the CPU core reset */
+ writel(3, cpucfg_membase + CPUCFG_CPU_RST_CTRL_REG(cpu));
+
+ spin_unlock(&cpu_lock);
+
+ return 0;
+}
+
+struct smp_operations sun8i_smp_ops __initdata = {
+ .smp_prepare_cpus = sun8i_smp_prepare_cpus,
+ .smp_boot_secondary = sun8i_smp_boot_secondary,
+};
+CPU_METHOD_OF_DECLARE(sun8i_a23_smp, "allwinner,sun8i-a23", &sun8i_smp_ops);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] ARM: sun8i: Add SMP and arch-timer support for A23
Hi Maxime, This series adds support for SMP and arch-timer for the A23. This follows our discussion from yesterday about getting arch-timer support for sun8i and sun9i. I will post a separate patch for sun9i-a80. I know some people would like to see arch-timer and SMP supported with PSCI, but work on this has been slow. So in the mean time, I thought I'd just post what SMP code I have. Feel free to just merge the first patch if you think SMP can wait. Regards ChenYu Chen-Yu Tsai (3): ARM: dts: sun8i: Enable ARM architected timer on A23 ARM: sun8i: Add SMP support for the Allwinner A23 ARM: sun8i: dt: Enable A23 SMP support Documentation/devicetree/bindings/arm/cpus.txt | 1 + arch/arm/boot/dts/sun8i-a23.dtsi | 16 ++ arch/arm/mach-sunxi/platsmp.c | 69 ++ 3 files changed, 86 insertions(+) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] UBIFS: fix incorrect unlocking handling
On Tue, Mar 17, 2015 at 10:09:26PM -0400, Taesoo Kim wrote: > When ubifs_init_security() fails, 'ui_mutex' is incorrectly > unlocked and incorrectly restores 'i_size'. There are four > such places that were introduce by the last commit. "The last commit" is not very descriptive. Are you speaking of this commit? commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53 Author: Subodh Nijsure Date: Fri Oct 31 13:50:30 2014 -0500 UBIFS: Add security.* XATTR support for the UBIFS CC'ing authors/reviewers. Brian > Signed-off-by: Taesoo Kim > --- > fs/ubifs/dir.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c > index 0fa6c80..5b24bc4 100644 > --- a/fs/ubifs/dir.c > +++ b/fs/ubifs/dir.c > @@ -272,7 +272,7 @@ static int ubifs_create(struct inode *dir, struct dentry > *dentry, umode_t mode, > > err = ubifs_init_security(dir, inode, &dentry->d_name); > if (err) > - goto out_cancel; > + goto out_inode; > > mutex_lock(&dir_ui->ui_mutex); > dir->i_size += sz_change; > @@ -292,6 +292,7 @@ out_cancel: > dir->i_size -= sz_change; > dir_ui->ui_size = dir->i_size; > mutex_unlock(&dir_ui->ui_mutex); > +out_inode: > make_bad_inode(inode); > iput(inode); > out_budg: > @@ -732,7 +733,7 @@ static int ubifs_mkdir(struct inode *dir, struct dentry > *dentry, umode_t mode) > > err = ubifs_init_security(dir, inode, &dentry->d_name); > if (err) > - goto out_cancel; > + goto out_inode; > > mutex_lock(&dir_ui->ui_mutex); > insert_inode_hash(inode); > @@ -757,6 +758,7 @@ out_cancel: > dir_ui->ui_size = dir->i_size; > drop_nlink(dir); > mutex_unlock(&dir_ui->ui_mutex); > +out_inode: > make_bad_inode(inode); > iput(inode); > out_budg: > @@ -816,7 +818,7 @@ static int ubifs_mknod(struct inode *dir, struct dentry > *dentry, > > err = ubifs_init_security(dir, inode, &dentry->d_name); > if (err) > - goto out_cancel; > + goto out_inode; > > mutex_lock(&dir_ui->ui_mutex); > dir->i_size += sz_change; > @@ -836,6 +838,7 @@ out_cancel: > dir->i_size -= sz_change; > dir_ui->ui_size = dir->i_size; > mutex_unlock(&dir_ui->ui_mutex); > +out_inode: > make_bad_inode(inode); > iput(inode); > out_budg: > @@ -896,7 +899,7 @@ static int ubifs_symlink(struct inode *dir, struct dentry > *dentry, > > err = ubifs_init_security(dir, inode, &dentry->d_name); > if (err) > - goto out_cancel; > + goto out_inode; > > mutex_lock(&dir_ui->ui_mutex); > dir->i_size += sz_change; > -- > 2.3.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/2 net-next] hyperv: Support batched notification
On Wed, Mar 18, 2015 at 12:02 AM, K. Y. Srinivasan
wrote:
Optimize notifying the host by deferring notification until there
are no more packets to be sent. This will help in batching the
requests
on the host.
Signed-off-by: K. Y. Srinivasan
---
drivers/net/hyperv/hyperv_net.h |2 +-
drivers/net/hyperv/netvsc.c | 14 +-
drivers/net/hyperv/netvsc_drv.c |2 +-
drivers/net/hyperv/rndis_filter.c |2 +-
4 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/net/hyperv/hyperv_net.h
b/drivers/net/hyperv/hyperv_net.h
index 4815843..3fd9896 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -184,7 +184,7 @@ struct rndis_device {
int netvsc_device_add(struct hv_device *device, void
*additional_info);
int netvsc_device_remove(struct hv_device *device);
int netvsc_send(struct hv_device *device,
- struct hv_netvsc_packet *packet);
+ struct hv_netvsc_packet *packet, bool kick_q);
void netvsc_linkstatus_callback(struct hv_device *device_obj,
struct rndis_message *resp);
int netvsc_recv_callback(struct hv_device *device_obj,
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 208eb05..9003b94 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -707,7 +707,7 @@ static u32 netvsc_copy_to_send_buf(struct
netvsc_device *net_device,
}
int netvsc_send(struct hv_device *device,
- struct hv_netvsc_packet *packet)
+ struct hv_netvsc_packet *packet, bool kick_q)
{
struct netvsc_device *net_device;
int ret = 0;
@@ -719,6 +719,7 @@ int netvsc_send(struct hv_device *device,
u32 msg_size = 0;
struct sk_buff *skb = NULL;
u16 q_idx = packet->q_idx;
+ u32 vmbus_flags = VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED;
net_device = get_outbound_net_device(device);
@@ -768,18 +769,21 @@ int netvsc_send(struct hv_device *device,
return -ENODEV;
if (packet->page_buf_cnt) {
- ret = vmbus_sendpacket_pagebuffer(out_channel,
+ ret = vmbus_sendpacket_pagebuffer_ctl(out_channel,
packet->page_buf,
packet->page_buf_cnt,
&sendMessage,
sizeof(struct nvsp_message),
- req_id);
+ req_id,
+ vmbus_flags,
+ kick_q);
} else {
- ret = vmbus_sendpacket(out_channel, &sendMessage,
+ ret = vmbus_sendpacket_ctl(out_channel, &sendMessage,
sizeof(struct nvsp_message),
req_id,
VM_PKT_DATA_INBAND,
- VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
+ vmbus_flags,
+ kick_q);
}
if (ret == 0) {
diff --git a/drivers/net/hyperv/netvsc_drv.c
b/drivers/net/hyperv/netvsc_drv.c
index a06bd66..eae58db 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -556,7 +556,7 @@ do_send:
packet->page_buf_cnt = init_page_array(rndis_msg, rndis_msg_size,
skb, &packet->page_buf[0]);
- ret = netvsc_send(net_device_ctx->device_ctx, packet);
+ ret = netvsc_send(net_device_ctx->device_ctx, packet,
!skb->xmit_more);
Looks like the issue of V2 still there (E.g we need to kick when
hv_ringbuffer_write() returns -EAGAIN?
drop:
if (ret == 0) {
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index ca81de0..05f3792 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -238,7 +238,7 @@ static int rndis_filter_send_request(struct
rndis_device *dev,
packet->send_completion = NULL;
- ret = netvsc_send(dev->net_dev->dev, packet);
+ ret = netvsc_send(dev->net_dev->dev, packet, true);
return ret;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 xfstests 2/3] generic: test openat and new O_BENEATH flag
On Tue, Mar 17, 2015 at 08:33:27AM -0700, Kees Cook wrote: > On Mon, Mar 16, 2015 at 4:24 PM, Dave Chinner > wrote: > > On Mon, Mar 09, 2015 at 02:00:11PM +, David Drysdale wrote: > >> Test basic openat(2) behaviour. > >> > >> Test that if O_BENEATH flag is set, openat() will only open > >> paths that have no .. component and do not start with /. > >> Symlinks are also checked for the same restrictions. > >> > >> Signed-off-by: David Drysdale --- > >> .gitignore| 1 + common/openat | 61 > >> ++ src/Makefile | 3 +- > >> src/openat.c | 100 > >> + > > > > This strikes me as something that shoul dbe added to xfs_io for > > testing, as it already supports a heap of other open flags and > > xfstests is already dependent on it. > > While I don't see a problem adding this to xfs_io, I'd still like > to see this test live in the kernel tree too. You can do whatever you want with the kernel tree - it doesn't concern me at all. > Having it in the > same source means more testing, IMO. That's complete bunk, though. This helper binary is a limited use, one shot test that can't be combined with anything else. "sharing" the source code across multiple different test suites doesn't change that. However, putting support into xfs_io means it will get more testing because we can *easily* use the functionality in many, many different ways. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC V2] proc: change /proc/stat show
This patch change /proc/stat to show each cpu,
we show each present cpus instead of eacn online cpu,
because some cpus are online / offline dynamically,
we should also show its cputime even it is offline,
some lib will read this file to detect cpu numbers,
we should also return the real present cpu numbers,
not just online cpus.
Signed-off-by: Yalin Wang
---
fs/proc/stat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/proc/stat.c b/fs/proc/stat.c
index 510413eb..f009cdd 100644
--- a/fs/proc/stat.c
+++ b/fs/proc/stat.c
@@ -130,7 +130,7 @@ static int show_stat(struct seq_file *p, void *v)
seq_put_decimal_ull(p, ' ', cputime64_to_clock_t(guest_nice));
seq_putc(p, '\n');
- for_each_online_cpu(i) {
+ for_each_present_cpu(i) {
/* Copy values here to work around gcc-2.95.3, gcc-2.96 */
user = kcpustat_cpu(i).cpustat[CPUTIME_USER];
nice = kcpustat_cpu(i).cpustat[CPUTIME_NICE];
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Hit a deadlock: between AER and pcieport/pciehp
[+cc Rafael] Hi Rajat, On Tue, Mar 17, 2015 at 2:11 PM, Rajat Jain wrote: > Hello, > > I was wondering if any one has a any suggestions to make here. I > believe this is a pretty serious deadlock - and I'm looking for ideas > on what should be the right way to fix this. I agree, this definitely sounds like a real problem. I'm not ignoring it; I just haven't had time to look into it :) After ten seconds of thought, my suggestion is to try to make this work in a way that doesn't require taking the mutexes in two different orders. It might be *possible* to write code that is smart enough to take them in different orders, but I'm pretty sure our automated lock checking tools wouldn't be that smart. I added Rafael because he recently did some work on PCI bus locking and might have better ideas than I do. > On Wed, Mar 11, 2015 at 6:48 PM, Rajat Jain wrote: >> Hello, >> >> >> I have hit a kernel deadlock situation on my system that has >> hierarchical hot plug situations (i.e. we can hot-plug a card, that >> itself may have a hot-plug slot for another level of hot-pluggable >> add-on cards). In summary, I see 2 threads that are both waiting on >> mutexes that is acquired by the other one. The mutexes are the >> (global) "pci_bus_sem" and "device->mutex" respectively. >> >> >> Thread1 >> === >> This is the pciehp worker thread, that scans a new card, and on >> finding that there is a hotplug slot downstream, tries to >> pci_create_slot(). >> pciehp_power_thread() >>-> pciehp_enable_slot() >> -> pciehp_configure_device() >>-> pci_bus_add_devices() discovers all devices including a new >> hotplug slot. >> -> (etc)... >> -> device_attach(dev) (for the newly discovered HP slot / >> downstream port) >>-> device_lock(dev) SUCCESSFULLY ACQUIRES dev->mutex for >> the new slot. >> -> (etc)... >> -> ... (goes on) >> -> pciehp_probe(dev) >> -> __pci_hp_register() >> -> pci_create_slot() >> -> down_write(pci_bus_sem); /* Deadlocked */ >> >> This how the stack looks like: >> [] call_rwsem_down_write_failed+0x13/0x20 >> [] pci_create_slot+0x3f/0x280 >> [] __pci_hp_register+0x70/0x400 >> [] pciehp_probe+0x1a9/0x450 >> [] pcie_port_probe_service+0x3d/0x90 >> [] driver_probe_device+0xf9/0x350 >> [] __device_attach+0x4b/0x60 >> [] bus_for_each_drv+0x56/0xa0 >> [] device_attach+0xa8/0xc0 >> [] bus_probe_device+0xb0/0xe0 >> [] device_add+0x3de/0x560 >> [] device_register+0x1e/0x30 >> [] pcie_port_device_register+0x32f/0x510 >> [] pcie_portdrv_probe+0x48/0x80 >> [] pci_device_probe+0x9c/0xf0 >> [] driver_probe_device+0xf9/0x350 >> [] __device_attach+0x4b/0x60 >> [] bus_for_each_drv+0x56/0xa0 >> [] device_attach+0xa8/0xc0 >> [] pci_bus_add_device+0x41/0x70 >> [] pci_bus_add_devices+0x41/0x90 >> [] pci_bus_add_devices+0x6f/0x90 >> [] pciehp_configure_device+0xa2/0x140 >> [] pciehp_enable_slot+0x188/0x2d0 >> [] pciehp_power_thread+0x2b1/0x3c0 >> [] process_one_work+0x1d0/0x510 >> [] worker_thread+0x121/0x440 >> [] kthread+0xef/0x110 >> [] ret_from_fork+0x7c/0xb0 >> [] 0x >> >> >> Thread2 >> === >> While the above thread is doing its work, the root port gets a >> completion timeout. And thus the AER Error recovery worker thread >> kicks in to handle that error. And as part of that error recovery - >> since the completion timeout was detected at root port, attempts to >> see for ALL the devices downstream if they have an error handler that >> need to be called. Here is what happens: >> >> >> aer_isr() >>-> aer_isr_one_error() >> -> aer_process_err_device() >> -> ... (etc)... >> -> do_recovery() >> -> broadcast_error_message() >> -> pci_walk_bus( ..., report_error_detected,...) /* >> effectively for all buses below root port */ >> -> down_read(&pci_bus_sem); /* SUCCESSFULLY >> ACQUIRES the semaophore */ >> -> report_error_detected(dev) /* for the newly >> detected slot */ >> -> device_lock(dev) /* Deadlocked */ >> >> This is how the stack looks like: >> [] report_error_detected+0x4e/0x170 <--- Waiting on >> device_lock() >> [] pci_walk_bus+0x4e/0xa0 >> [] broadcast_error_message+0xc4/0xf0 >> [] do_recovery+0x3d/0x280 >> [] aer_isr+0x300/0x3e0 >> [] process_one_work+0x1d0/0x510 >> [] worker_thread+0x121/0x440 >> [] kthread+0xef/0x110 >> [] ret_from_fork+0x7c/0xb0 >> [] 0x >> >> >> As a temporary work around to let me proceed, I was thinking may be I >> could change in report_error_detected() such that completion timeouts >> errors may not be broadcast (do we really have any drivers that have >> aer handlers that handle such an error? What would the handler do >> anyway to fix such an error?) >> >> >> But not sure what the right solution might look like. I thought about >> whether these locks shoul
RE: [f2fs-dev] [PATCH 2/4] f2fs: set buffer_new when new blocks are allocated
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Wednesday, March 18, 2015 12:58 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 2/4] f2fs: set buffer_new when new blocks are
> allocated
>
> This patch modifies to call set_buffer_new, if new blocks are allocated.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/data.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index ba70a78..cefaa67 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -257,7 +257,6 @@ static void f2fs_map_bh(struct super_block *sb, pgoff_t
> pgofs,
> unsigned int blkbits = sb->s_blocksize_bits;
> size_t count;
>
> - set_buffer_new(bh_result);
> map_bh(bh_result, sb, ei->blk + pgofs - ei->fofs);
> count = ei->fofs + ei->len - pgofs;
> if (count < (UINT_MAX >> blkbits))
> @@ -1139,7 +1138,7 @@ static int __get_data_block(struct inode *inode,
> sector_t iblock,
> goto put_out;
>
> if (dn.data_blkaddr != NULL_ADDR) {
> - set_buffer_new(bh_result);
> + clear_buffer_new(bh_result);
Add clear_buffer_new in f2fs_map_bh?
Thanks,
> map_bh(bh_result, inode->i_sb, dn.data_blkaddr);
> } else if (create) {
> err = __allocate_data_block(&dn);
> @@ -1184,6 +1183,7 @@ get_next:
> if (err)
> goto sync_out;
> allocated = true;
> + set_buffer_new(bh_result);
> blkaddr = dn.data_blkaddr;
> }
> /* Give more consecutive addresses for the readahead */
> --
> 2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] UBIFS: fix incorrect unlocking handling
When ubifs_init_security() fails, 'ui_mutex' is incorrectly unlocked and incorrectly restores 'i_size'. There are four such places that were introduce by the last commit. Signed-off-by: Taesoo Kim --- fs/ubifs/dir.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c index 0fa6c80..5b24bc4 100644 --- a/fs/ubifs/dir.c +++ b/fs/ubifs/dir.c @@ -272,7 +272,7 @@ static int ubifs_create(struct inode *dir, struct dentry *dentry, umode_t mode, err = ubifs_init_security(dir, inode, &dentry->d_name); if (err) - goto out_cancel; + goto out_inode; mutex_lock(&dir_ui->ui_mutex); dir->i_size += sz_change; @@ -292,6 +292,7 @@ out_cancel: dir->i_size -= sz_change; dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); +out_inode: make_bad_inode(inode); iput(inode); out_budg: @@ -732,7 +733,7 @@ static int ubifs_mkdir(struct inode *dir, struct dentry *dentry, umode_t mode) err = ubifs_init_security(dir, inode, &dentry->d_name); if (err) - goto out_cancel; + goto out_inode; mutex_lock(&dir_ui->ui_mutex); insert_inode_hash(inode); @@ -757,6 +758,7 @@ out_cancel: dir_ui->ui_size = dir->i_size; drop_nlink(dir); mutex_unlock(&dir_ui->ui_mutex); +out_inode: make_bad_inode(inode); iput(inode); out_budg: @@ -816,7 +818,7 @@ static int ubifs_mknod(struct inode *dir, struct dentry *dentry, err = ubifs_init_security(dir, inode, &dentry->d_name); if (err) - goto out_cancel; + goto out_inode; mutex_lock(&dir_ui->ui_mutex); dir->i_size += sz_change; @@ -836,6 +838,7 @@ out_cancel: dir->i_size -= sz_change; dir_ui->ui_size = dir->i_size; mutex_unlock(&dir_ui->ui_mutex); +out_inode: make_bad_inode(inode); iput(inode); out_budg: @@ -896,7 +899,7 @@ static int ubifs_symlink(struct inode *dir, struct dentry *dentry, err = ubifs_init_security(dir, inode, &dentry->d_name); if (err) - goto out_cancel; + goto out_inode; mutex_lock(&dir_ui->ui_mutex); dir->i_size += sz_change; -- 2.3.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] jbd2: fix incorrect unlock on j_list_lock
When 'jh->b_transaction == transaction' (asserted by below)
J_ASSERT_JH(jh, (jh->b_transaction == transaction || ...
'journal->j_list_lock' will be incorrectly unlocked, since
the the lock is aquired only at the end of if / else-if
statements (missing the else case).
Signed-off-by: Taesoo Kim
---
fs/jbd2/transaction.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index 5f09370..edb7f59 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -1091,6 +1091,7 @@ int jbd2_journal_get_create_access(handle_t *handle,
struct buffer_head *bh)
JBUFFER_TRACE(jh, "file as BJ_Reserved");
spin_lock(&journal->j_list_lock);
__jbd2_journal_file_buffer(jh, transaction, BJ_Reserved);
+ spin_unlock(&journal->j_list_lock);
} else if (jh->b_transaction == journal->j_committing_transaction) {
/* first access by this transaction */
jh->b_modified = 0;
@@ -1098,8 +1099,8 @@ int jbd2_journal_get_create_access(handle_t *handle,
struct buffer_head *bh)
JBUFFER_TRACE(jh, "set next transaction");
spin_lock(&journal->j_list_lock);
jh->b_next_transaction = transaction;
+ spin_unlock(&journal->j_list_lock);
}
- spin_unlock(&journal->j_list_lock);
jbd_unlock_bh_state(bh);
/*
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86,boot: standardize strcmp()
On Die, 2015-03-17 at 19:43 +0530, Arjun Sreedharan wrote:
[...]
> On a related note, IMO strcmp() should return {-1,0,1} since many
> programmers just expect this behavior. just my opinion.
-ENOPATCH.
MfG,
Bernd
--
"I dislike type abstraction if it has no real reason. And saving
on typing is not a good reason - if your typing speed is the main
issue when you're coding, you're doing something seriously wrong."
- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [update][PATCH v10 06/21] ACPI / sleep: Introduce CONFIG_ACPI_GENERIC_SLEEP
On 2015/3/17 22:33, Rafael J. Wysocki wrote:
> On Tuesday, March 17, 2015 12:10:02 PM Hanjun Guo wrote:
>> On 2015/3/17 11:23, Rafael J. Wysocki wrote:
>>> On Tuesday, March 17, 2015 10:36:47 AM Hanjun Guo wrote:
On 2015/3/17 10:28, Rafael J. Wysocki wrote:
> On Tuesday, March 17, 2015 09:08:45 AM Hanjun Guo wrote:
>> On 2015/3/17 7:15, Rafael J. Wysocki wrote:
>>> On Monday, March 16, 2015 08:14:52 PM Hanjun Guo wrote:
On 2015年03月14日 05:49, Rafael J. Wysocki wrote:
> On Friday, March 13, 2015 04:14:29 PM Hanjun Guo wrote:
>> [...]
>> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
>> index 074e52b..e8728d7 100644
>> --- a/arch/ia64/Kconfig
>> +++ b/arch/ia64/Kconfig
>> @@ -10,6 +10,7 @@ config IA64
>> select ARCH_MIGHT_HAVE_PC_SERIO
>> select PCI if (!IA64_HP_SIM)
>> select ACPI if (!IA64_HP_SIM)
>> +select ACPI_GENERIC_SLEEP if ACPI
>> select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
>> select HAVE_UNSTABLE_SCHED_CLOCK
>> select HAVE_IDE
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index b7d31ca..9804431 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -22,6 +22,7 @@ config X86_64
>> ### Arch settings
>> config X86
>> def_bool y
>> +select ACPI_GENERIC_SLEEP if ACPI
> One more nit. If you did
>
> + select ACPI_GENERIC_SLEEP if ACPI_SLEEP
>
> here (and above for ia64), you'd avoid having to make ACPI_SLEEP
> depend on ACPI_GENERIC_SLEEP which goes somewhat backwards.
In sleep.c,
#ifdef CONFIG_ACPI_SLEEP
acpi_target_system_state()
{
}
#endif
and CONFIG_ACPI_SLEEP depends on SUSPEND || HIBERNATION,
which one of them will be enabled on ARM64 so ACPI_SLEEP
will also enabled too.
So if we
+select ACPI_GENERIC_SLEEP if ACPI_SLEEP
and
+acpi-$(CONFIG_ACPI_GENERIC_SLEEP) += sleep.o
it will lead to errors for acpi_target_system_state() that
is declared but not defined, so I will keep the code as
it is, what do you think?
>>> No, we need to hash this out. Having two different Kconfig options
>>> meaning
>>> almost the same thing (ACPI_SLEEP and ACPI_GENERIC_SLEEP) is beyond
>>> ugly.
>>>
>>> Do you need ACPI_SLEEP on ARM64 at all?
>> No, at least for now we don't need it, the spec for sleep is not ready
>> for
>> ARM64 arch, so ACPI_SLEEP will not work at all on ARM64.
> Well, so what about selecting ACPI_SLEEP from the architectures that use
> it?
Do you mean remove CONFIG_ACPI_GENERIC_SLEEP and
+acpi-$(CONFIG_ACPI_SLEEP) += sleep.o
as well (also need to remove duplicate #ifdef CONFIG_ACPI_SLEEP in sleep.c
if
we doing so)?
>>> Well, almost. There is one problem with that, becuase sleep.c contains code
>>> outside of the ACPI_SLEEP-dependent blocks. That code is used for powering
>>> off ACPI platforms.
>>>
>>> I guess you don't want that code on ARM too, right?
>> Yes, you are right.
>>
>>> Perhaps we can use ACPI_REDUCED_HARDWARE_ONLY for that? ARM64 will be the
>> Sorry, I can't fully understand your intention here, could you please
>> explain it more?
>>
>> Let me guess a little bit. Do you mean use ACPI_REDUCED_HARDWARE_ONLY for
>> powering off ACPI platforms? if so, I guess it's not a good idea, ACPI spec
>> only says that S4BIOS is not supported on HW-reduced ACPI platforms, S5
>> has no such limitation, if I miss something here, please let me know.
> OK, so in your current patch, please replace ACPI_GENERIC_SLEEP with
> ACPI_SYSTEM_POWER_STATES_SUPPORT and all should be clear.
OK, I will send a updated patch.
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC] proc: change /proc/stat show
> -Original Message-
> From: David Rientjes [mailto:rient...@google.com]
> Sent: Wednesday, March 18, 2015 7:02 AM
> To: Wang, Yalin
> Cc: a...@linux-foundation.org; heiko.carst...@de.ibm.com;
> t...@linutronix.de; linux-kernel@vger.kernel.org
> Subject: Re: [RFC] proc: change /proc/stat show
>
> On Tue, 17 Mar 2015, Wang, Yalin wrote:
>
> > diff --git a/fs/proc/stat.c b/fs/proc/stat.c
> > index 510413eb..60b39e2 100644
> > --- a/fs/proc/stat.c
> > +++ b/fs/proc/stat.c
> > @@ -130,7 +130,7 @@ static int show_stat(struct seq_file *p, void *v)
> > seq_put_decimal_ull(p, ' ', cputime64_to_clock_t(guest_nice));
> > seq_putc(p, '\n');
> >
> > - for_each_online_cpu(i) {
> > + for_each_present_cpu(i) {
> > /* Copy values here to work around gcc-2.95.3, gcc-2.96 */
> > user = kcpustat_cpu(i).cpustat[CPUTIME_USER];
> > nice = kcpustat_cpu(i).cpustat[CPUTIME_NICE];
> > @@ -153,6 +153,7 @@ static int show_stat(struct seq_file *p, void *v)
> > seq_put_decimal_ull(p, ' ', cputime64_to_clock_t(steal));
> > seq_put_decimal_ull(p, ' ', cputime64_to_clock_t(guest));
> > seq_put_decimal_ull(p, ' ', cputime64_to_clock_t(guest_nice));
> > + seq_printf(p, " %d", cpu_online(i)? 1 : 0);
> > seq_putc(p, '\n');
> > }
> > seq_printf(p, "intr %llu", (unsigned long long)sum);
>
> Makes sense, but why do we need to output the cpu state as part of
> /proc/stat? This information should already be available elsewhere.
Yeah, online / offline info can be read from /sys/devices/cpu .
I can remove this line , if you think it is not needed .
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH REGRESSION FIX] x86 idle: restore mwait_idle()
On 17 March 2015 at 08:22, Ingo Molnar wrote: > > * Ian Malone wrote: > >> Looks like Ingo Molnar has committed to tip which is probably a good >> sign, thanks all. >> (Have to hand this system on to someone who wont be patching kernels...) > > Guys, since I don't have the affected hardware, mind testing the > latest sched/core tree: > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > cd tip > git checkout sched/core > # build a test kernel and boot it > > Or if you already have a kernel git tree, do something like this to > pick up the scheduler development tree: > > cd linux.git > git remote add git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tip > git remote update > git checkout tip/sched/core > # build a test kernel and boot it > > and check whether the mwait related bugs are now fixed for good? > Fixes https://bugzilla.kernel.org/show_bug.cgi?id=60770, thank you. -- imalone http://ibmalone.blogspot.co.uk -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [mm] cc87317726f: WARNING: CPU: 0 PID: 1 at drivers/iommu/io-pgtable-arm.c:413 __arm_lpae_unmap+0x341/0x380()
On Tue, 2015-03-17 at 15:24 -0400, Johannes Weiner wrote: > On Tue, Mar 17, 2015 at 10:15:29AM -0700, Linus Torvalds wrote: > > Explicitly adding the emails of other people involved with that commit > > and the original oom thread to make sure people are aware, since this > > didn't get any response. > > > > Commit cc87317726f8 fixed some behavior, but also seems to have turned > > an oom situation into a complete hang. So presumably we shouldn't loop > > *forever*. Hmm? > > It seems we are between a rock and a hard place here, as we reverted > specifically to that endless looping on request of filesystem people. > They said[1] they rely on these allocations never returning NULL, or > they might fail inside a transactions and corrupt on-disk data. > > Huang, against which kernels did you first run this test on this exact > setup? Is there a chance you could try to run a kernel without/before > 9879de7373fc? I want to make sure I'm not missing something, but all > versions preceding this commit should also have the same hang. There > should only be a tiny window between 9879de7373fc and cc87317726f8 -- > v3.19 -- where these allocations are allowed to fail. I checked the test result of v3.19-rc6. It shows that boot will hang at the same position. BTW: the test is run on 32 bit system. Best Regards, Huang, Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] gpio / ACPI: Two minor cleanups related to ACPI_HANDLE()
On Wed, Mar 18, 2015 at 10:37 AM, Rafael J. Wysocki wrote: > On Tuesday, March 10, 2015 11:07:36 PM Rafael J. Wysocki wrote: >> Hi, >> >> As per the subject, avoid evaluating ACPI_HANDLE() if we can as that one is >> rather costly. > > Linus, Alexandre, any objections to this series? > > If not, would there be any problem if I took these to my tree? I'll probably > have material on top of them. Sorry for the delay. Looks like Linus just took the patches in his tree, I hope that's ok? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the virtio tree
Hi Rusty,
After merging the virtio tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/virtio/virtio_mmio.c:250:12: error: redefinition of 'vm_generation'
static u32 vm_generation(struct virtio_device *vdev)
^
drivers/virtio/virtio_mmio.c:240:12: note: previous definition of
'vm_generation' was here
static u32 vm_generation(struct virtio_device *vdev)
^
Caused by the bad merge of commits 87e7bf1450c9 ("virtio_mmio:
generation support") from Linus' tree and cf02b2c2d1a1 ("virtio_mmio:
generation support") from the virtio tree.
I fixed it up by removing the second version of that function.
Could the virtio tree should be cleaned up to match what was sent to
Linus, please?
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp5g725tjQZ1.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
* Linus Walleij [150317 18:31]:
> On Tue, Mar 10, 2015 at 7:33 PM, Nishanth Menon wrote:
> > On 03/10/2015 12:31 PM, Tony Lindgren wrote:
>
> >> Yes except I'd make use of some kind of #pinctrl-cells here just like
> >> interrupt controller has #interrupt-cells. Then you can have the values
> >> seprate and the controller knows what to do with them based on the
> >> compatible flag and #pinctrl-cells.
> >
> > Something like the following I suppose, where pinctrl-cells is optional?
> >
> > dra7_pmx_core: pinmux@4a003400 {
> > compatible = "ti,dra7-padconf", "pinctrl-single";
> > reg = <0x4a003400 0x0464>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > #interrupt-cells = <1>;
> > interrupt-controller;
> > pinctrl-single,register-width = <32>;
> > pinctrl-single,function-mask = <0x3fff>;
> > };
> >
> > dra7_iodelay_core: padconf@4844a000 {
> > compatible = "ti,dra7-iodelay";
> > reg = <0x4844a000 0x0d1c>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > #pinctrl-cells = <2>;
> > };
> >
> > Linus,
> >
> > I hope you are ok with the above?
>
> Hm depends on where the documentation hits I guess?
>
> Such a generic cell count property has to be to the generic
> pinctrl-bindings.txt document if I read it right.
Yeah agreed. I suggest discussing the binding and the generic
parsing code for it first :)
> Overall I guess this will be acceptable but you really need to
> reuse some more code between this driver and pinctrl-single.c
> if I read it right.
It seems with the generic binding the actual driver should be
just the hardware specific code hopefully.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: install_special_mapping && vm_pgoff (Was: vvar, gup && coredump)
On Tue, Mar 17, 2015 at 6:43 AM, Oleg Nesterov wrote:
> On 03/16, Oleg Nesterov wrote:
>>
>> On 03/16, Andy Lutomirski wrote:
>> >
>> > Ick, you're probably right. For what it's worth, the vdso *seems* to
>> > be okay (on 64-bit only, and only if you don't poke at it too hard) if
>> > you mremap it in one piece. CRIU does that.
>>
>> I need to run away till tomorrow, but looking at this code even if "one
>> piece"
>> case doesn't look right if it was cow'ed. I'll verify tomorrow.
>
> And I am still not sure this all is 100% correct, but I got lost in this code.
> Probably this is fine...
>
> But at least the bug exposed by the test-case looks clear:
>
> do_linear_fault:
>
> vmf->pgoff = (((address & PAGE_MASK) - vma->vm_start) >>
> PAGE_SHIFT)
> + vma->vm_pgoff;
> ...
>
> special_mapping_fault:
>
> pgoff = vmf->pgoff - vma->vm_pgoff;
>
>
> So special_mapping_fault() can only work if this mapping starts from the
> first page in ->pages[].
>
> So perhaps we need _something like_ the (wrong/incomplete) patch below...
>
> Or, really, perhaps we can create vdso_mapping ? So that map_vdso() could
> simply mmap the anon_inode file...
That's slightly tricky, I think, because it could start showing up in
/proc/PID/map_files or whatever it's called, and I don't think we want
that. I also don't want to commit to all special mappings everywhere
being semantically identical (there are already two kinds on both x86
and arm64, and I'd eventually like to have them vary per-process as
well). None of that precludes using non-null vm_file, but it's a
complication.
Your patch does look like a considerable improvement, though. Let me
see if I can find some time to fold it in with the rest of my special
mapping rework over the next few days.
--Andy
>
> Oleg.
>
> --- x/mm/mmap.c
> +++ x/mm/mmap.c
> @@ -2832,6 +2832,8 @@ int insert_vm_struct(struct mm_struct *mm, struct
> vm_area_struct *vma)
> return 0;
> }
>
> +bool is_special_vma(struct vm_area_struct *vma);
> +
> /*
> * Copy the vma structure to a new location in the same mm,
> * prior to moving page table entries, to effect an mremap move.
> @@ -2851,7 +2853,7 @@ struct vm_area_struct *copy_vma(struct vm_area_struct
> **vmap,
> * If anonymous vma has not yet been faulted, update new pgoff
> * to match new location, to increase its chance of merging.
> */
> - if (unlikely(!vma->vm_file && !vma->anon_vma)) {
> + if (unlikely(!vma->vm_file && !is_special_vma(vma) &&
> !vma->anon_vma)) {
> pgoff = addr >> PAGE_SHIFT;
> faulted_in_anon_vma = false;
> }
> @@ -2953,6 +2955,11 @@ static const struct vm_operations_struct
> legacy_special_mapping_vmops = {
> .fault = special_mapping_fault,
> };
>
> +bool is_special_vma(struct vm_area_struct *vma)
> +{
> + return vma->vm_ops == &special_mapping_vmops;
> +}
> +
> static int special_mapping_fault(struct vm_area_struct *vma,
> struct vm_fault *vmf)
> {
> @@ -2965,7 +2972,7 @@ static int special_mapping_fault(struct vm_area_struct
> *vma,
> * We are allowed to do this because we are the mm; do not copy
> * this code into drivers!
> */
> - pgoff = vmf->pgoff - vma->vm_pgoff;
> + pgoff = vmf->pgoff;
>
> if (vma->vm_ops == &legacy_special_mapping_vmops)
> pages = vma->vm_private_data;
> @@ -3014,6 +3021,7 @@ static struct vm_area_struct *__install_special_mapping(
> if (ret)
> goto out;
>
> + vma->vm_pgoff = 0;
> mm->total_vm += len >> PAGE_SHIFT;
>
> perf_event_mmap(vma);
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] fs/pstore: Optimization function ramoops_init_przs
The value of cxt->record_size does not change in the loop,
so this patch optimize the assign statement by dropping
sz entirely and using cxt->record_size in its place.
Signed-off-by: Wang Long
---
fs/pstore/ram.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 44a549b..f29373d 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -394,18 +394,16 @@ static int ramoops_init_przs(struct device *dev, struct
ramoops_context *cxt,
}
for (i = 0; i < cxt->max_dump_cnt; i++) {
- size_t sz = cxt->record_size;
-
- cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
+ cxt->przs[i] = persistent_ram_new(*paddr, cxt->record_size, 0,
&cxt->ecc_info,
cxt->memtype);
if (IS_ERR(cxt->przs[i])) {
err = PTR_ERR(cxt->przs[i]);
dev_err(dev, "failed to request mem region
(0x%zx@0x%llx): %d\n",
- sz, (unsigned long long)*paddr, err);
+ cxt->record_size, (unsigned long long)*paddr,
err);
goto fail_prz;
}
- *paddr += sz;
+ *paddr += cxt->record_size;
}
return 0;
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the virtio tree with Linus' tree
Hi Rusty,
Today's linux-next merge of the virtio tree got a conflict in
net/9p/trans_virtio.c between commit 8051a2a518fc ("9p/trans_virtio:
fix hot-unplug") from Linus' tree and commit 1991755689ad
("9p/trans_virtio: fix hot-unplug") from the virtio tree.
I fixed it up (the latter is an older version the former, which is now
in Linus' tree) and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpQRCmMKD3zl.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 6/8] pinctrl: cygnus: add gpio/pinconf driver
On Wed, Mar 11, 2015 at 10:15 AM, Linus Walleij wrote: > On Tue, Mar 10, 2015 at 6:57 PM, Ray Jui wrote: >> On 3/10/2015 3:20 AM, Linus Walleij wrote: >>> On Mon, Mar 9, 2015 at 9:45 PM, Ray Jui wrote: >>> This adds the initial support of the Broadcom Cygnus GPIO/PINCONF driver that supports all 3 GPIO controllers on Cygnus including the ASIU GPIO controller, the chipCommonG GPIO controller, and the always-on GPIO controller. Basic PINCONF configurations such as bias pull up/down, and drive strength are also supported in this driver. Pins from the ASIU GPIO controller can be individually muxed to GPIO function, through interaction with the Cygnus IOMUX controller Signed-off-by: Ray Jui Reviewed-by: Scott Branden Tested-by: Dmitry Torokhov >>> >>> Patch applied! But please look at this: >>> +#include >>> >>> Doesn't just #include work? >>> >> >> I think I need linux/gpio.h for gpiochip_add_pin_range and some related >> APIs. > > OK you're right ... I need to fix this. I sent a patch fixing this now... hope it will work. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix platform_no_drv_owner.cocci warnings
On Wed, Mar 11, 2015 at 12:05 PM, Thierry Reding wrote: > On Fri, Jan 16, 2015 at 09:06:14AM +0800, kbuild test robot wrote: >> drivers/pwm/pwm-stmpe.c:99:3-8: No need to set .owner here. The core will do >> it. >> >> Remove .owner field if calls are used which set it automatically >> >> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci >> >> Signed-off-by: Fengguang Wu >> --- >> >> pwm-stmpe.c |1 - >> 1 file changed, 1 deletion(-) > > Erm... this driver doesn't exist in my tree. What's going on? What's going on is that the 0day build robot builds everything it finds, including experimental branches. I dunno why it's mailing you though, probably I already added your CC on the patch... stupid me. A bit much to think of. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] leds: ktd2692: add device tree bindings for ktd2692
Hi
On 2015년 03월 18일 07:40, Jaehoon Chung wrote:
> On 03/17/2015 05:45 PM, Ingi Kim wrote:
>> This patch adds the device tree bindings for ktd2692 flash LEDs.
>> Add optional properties 'flash-timeout-us' to control flash timeout
>> and 'vin-supply' for flash-led regulator
>>
>> Signed-off-by: Ingi Kim
>> ---
>> .../devicetree/bindings/leds/leds-ktd2692.txt | 37
>> ++
>> 1 file changed, 37 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
>> b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
>> new file mode 100644
>> index 000..1b44225
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt
>> @@ -0,0 +1,37 @@
>> +* Kinetic Technologies - KTD2692 Flash LED Driver
>> +
>> +KTD2692 is the ideal power solution for high-power flash LEDs.
>> +It uses ExpressWire single-wire programming for maximum flexibility.
>> +
>> +The ExpressWire interface through CTRL pin can control LED on/off and
>> +enable/disable the IC, Movie/Flash mode current, Flash timeout,
>> +LVP(low voltage protection).
>> +
>> +Required properties:
>> +- compatible: "kinetic,ktd2692"
>> +- ctrl-gpio : gpio pin in order control ktd2692 flash led.
>> +There is an internal 300kOhm pull-down resistor at this pin
>> +- supply : "vin" LED supply
>> +
>> +Optional property:
>> +- flash-timeout-us : Maximum flash timeout in microseconds.
>> +flash timeout ranges from 0 to 1835000us and
>> +default is 1049000us.
>> +
>> +Example:
>> +
>> +vbat: fixedregulator@0 {
>> +compatible = "regulator-fixed";
>> +regulator-name = "vbat-supply";
>> +regulator-min-microvolt = <500>;
>> +regulator-max-microvolt = <500>;
>> +gpio = <>;
>
> gpio = <> ? What do you mean?
> And this is described at
> Documentation/devicetree/bindings/regulator/fixed-regulator.txt
> I'm not sure whether this example really needs.
>
> Best Regards,
> Jaehoon Chung
>
I just want to show that dummy regulator can be used with flash-led.
As you mentioned earlier, remove unnecessary example and add refer comment
Thanks,
Ingi Kim
>> +regulator-always-on;
>> +};
>> +
>> +flash-led {
>> +compatible = "kinetic,ktd2692";
>> +ctrl-gpio = <&gpc0 1 0>;
>> +flash-timeout-us = <1835000>;
>> +vin-supply = <&vbat>;
>> +};
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] gpio / ACPI: Use local variable instead of ACPI_HANDLE()
On Tue, Mar 10, 2015 at 11:10 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > In acpi_gpiochip_request_interrupts() the handle local > variable already contains the value that we want to pass > to acpi_walk_resources(), so it is better to use that > variable instead of evaluating ACPI_HANDLE() once more > for the same device. > > Signed-off-by: Rafael J. Wysocki Patch applied with Mika's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/pstore: Optimization function ramoops_init_przs
On 2015/3/18 1:39, Kees Cook wrote:
> On Tue, Mar 17, 2015 at 2:31 AM, Wang Long wrote:
>> The value of cxt->record_size does not change in the loop,
>> so this patch optimize the assign statement by moving
>> it to outer.
>>
>> Signed-off-by: Wang Long
>> ---
>> fs/pstore/ram.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
>> index 44a549b..2105a16 100644
>> --- a/fs/pstore/ram.c
>> +++ b/fs/pstore/ram.c
>> @@ -373,6 +373,7 @@ static int ramoops_init_przs(struct device *dev, struct
>> ramoops_context *cxt,
>> {
>> int err = -ENOMEM;
>> int i;
>> + size_t sz;
>>
>> if (!cxt->record_size)
>> return 0;
>> @@ -393,9 +394,8 @@ static int ramoops_init_przs(struct device *dev, struct
>> ramoops_context *cxt,
>> goto fail_prz;
>> }
>>
>> + sz = cxt->record_size;
>> for (i = 0; i < cxt->max_dump_cnt; i++) {
>> - size_t sz = cxt->record_size;
>> -
>> cxt->przs[i] = persistent_ram_new(*paddr, sz, 0,
>> &cxt->ecc_info,
>> cxt->memtype);
>> --
>> 1.8.3.4
>>
>
> Actually, can't we drop sz entirely and just use cxt->record_size in its
> place?
>
> -Kees
>
I agree with you.
drop sz entirely and use cxt->record_size in its place can improve readability.
I will send another patch.
Best Regards
Wang Long
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC v13 02/13] dt-binding: leds: Add common LED DT bindings macros
On Thu, Mar 12, 2015 at 8:45 AM, Jacek Anaszewski wrote: > Add macros for defining boost mode and trigger type properties > of flash LED devices. > Applied, thanks, -Bryan > Signed-off-by: Jacek Anaszewski > Acked-by: Kyungmin Park > Cc: Bryan Wu > Cc: Richard Purdie > --- > include/dt-bindings/leds/common.h | 21 + > 1 file changed, 21 insertions(+) > create mode 100644 include/dt-bindings/leds/common.h > > diff --git a/include/dt-bindings/leds/common.h > b/include/dt-bindings/leds/common.h > new file mode 100644 > index 000..79fcef7 > --- /dev/null > +++ b/include/dt-bindings/leds/common.h > @@ -0,0 +1,21 @@ > +/* > + * This header provides macros for the common LEDs device tree bindings. > + * > + * Copyright (C) 2015, Samsung Electronics Co., Ltd. > + * > + * Author: Jacek Anaszewski > + */ > + > +#ifndef __DT_BINDINGS_LEDS_H__ > +#define __DT_BINDINGS_LEDS_H > + > +/* External trigger type */ > +#define LEDS_TRIG_TYPE_EDGE0 > +#define LEDS_TRIG_TYPE_LEVEL 1 > + > +/* Boost modes */ > +#define LEDS_BOOST_OFF 0 > +#define LEDS_BOOST_ADAPTIVE1 > +#define LEDS_BOOST_FIXED 2 > + > +#endif /* __DT_BINDINGS_LEDS_H */ > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpio / ACPI: Avoid unnecessary checks in __gpiod_get_index()
On Tue, Mar 10, 2015 at 11:08 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > If dev is NULL in __gpiod_get_index() and both ACPI and OF are > enabled, it will be checked twice before the code decides to give > up with DT/ACPI lookup, so avoid that. > > Also use the observation that ACPI_COMPANION() is much more efficient > than ACPI_HANDLE(), because the latter uses the former and carries out > a check and a pointer dereference on top of it, so replace the > ACPI_HANDLE() check with an ACPI_COMPANION() one which does not > require the additional IS_ENABLED(CONFIG_ACPI) check too. > > Signed-off-by: Rafael J. Wysocki Patch applied with review and ACK tags. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
On Tue, Mar 10, 2015 at 7:33 PM, Nishanth Menon wrote:
> On 03/10/2015 12:31 PM, Tony Lindgren wrote:
>> Yes except I'd make use of some kind of #pinctrl-cells here just like
>> interrupt controller has #interrupt-cells. Then you can have the values
>> seprate and the controller knows what to do with them based on the
>> compatible flag and #pinctrl-cells.
>
> Something like the following I suppose, where pinctrl-cells is optional?
>
> dra7_pmx_core: pinmux@4a003400 {
> compatible = "ti,dra7-padconf", "pinctrl-single";
> reg = <0x4a003400 0x0464>;
> #address-cells = <1>;
> #size-cells = <0>;
> #interrupt-cells = <1>;
> interrupt-controller;
> pinctrl-single,register-width = <32>;
> pinctrl-single,function-mask = <0x3fff>;
> };
>
> dra7_iodelay_core: padconf@4844a000 {
> compatible = "ti,dra7-iodelay";
> reg = <0x4844a000 0x0d1c>;
> #address-cells = <1>;
> #size-cells = <0>;
> #pinctrl-cells = <2>;
> };
>
> Linus,
>
> I hope you are ok with the above?
Hm depends on where the documentation hits I guess?
Such a generic cell count property has to be to the generic
pinctrl-bindings.txt document if I read it right.
Overall I guess this will be acceptable but you really need to
reuse some more code between this driver and pinctrl-single.c
if I read it right.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / sleep: Drop acpi_suspend() which is not used
On 2015/3/17 22:29, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The acpi_suspend() function has no callers, so drop it.
>
> Signed-off-by: Rafael J. Wysocki
Reviewed-by: Hanjun Guo
> ---
> drivers/acpi/sleep.c | 15 ---
> drivers/acpi/sleep.h |2 --
> 2 files changed, 17 deletions(-)
>
> Index: linux-pm/drivers/acpi/sleep.c
> ===
> --- linux-pm.orig/drivers/acpi/sleep.c
> +++ linux-pm/drivers/acpi/sleep.c
> @@ -806,21 +806,6 @@ static void acpi_sleep_hibernate_setup(v
> static inline void acpi_sleep_hibernate_setup(void) {}
> #endif /* !CONFIG_HIBERNATION */
>
> -int acpi_suspend(u32 acpi_state)
> -{
> - suspend_state_t states[] = {
> - [1] = PM_SUSPEND_STANDBY,
> - [3] = PM_SUSPEND_MEM,
> - [5] = PM_SUSPEND_MAX
> - };
> -
> - if (acpi_state < 6 && states[acpi_state])
> - return pm_suspend(states[acpi_state]);
> - if (acpi_state == 4)
> - return hibernate();
> - return -EINVAL;
> -}
> -
> static void acpi_power_off_prepare(void)
> {
> /* Prepare to power off the system */
> Index: linux-pm/drivers/acpi/sleep.h
> ===
> --- linux-pm.orig/drivers/acpi/sleep.h
> +++ linux-pm/drivers/acpi/sleep.h
> @@ -1,6 +1,4 @@
>
> -extern int acpi_suspend(u32 state);
> -
> extern void acpi_enable_wakeup_devices(u8 sleep_state);
> extern void acpi_disable_wakeup_devices(u8 sleep_state);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MIPS: MSA: misaligned support
MIPS R5, MIPS R6 and MSA HW specs allow a broad range of address exception
on unalaigned MSA load/store operations - from none unaligned up to
full support in HW. In practice, it is expected that HW can occasionally
triggers AdE for non-aligned data access (misalignment). It is usually
expected on page boundaries because HW handling of two TLBs in single
data access operation may be complicated and expensive.
So, this patch handles MSA LD.df and ST.df Address Error exceptions.
It handles separately two cases - MSA owned by thread and MSA registers
saved in current->thread.fpu. If thread still ownes MSA unit then it
loads and stores directly with MSA unit and only one MSA register. Saving
and restoring the full MSA context (512bytes) on each misalign exception
is expensive! Preemption is disabled, of course.
Signed-off-by: Leonid Yegoshin
---
arch/mips/include/asm/processor.h |2 +
arch/mips/include/uapi/asm/inst.h | 21 +
arch/mips/kernel/r4k_fpu.S| 107
arch/mips/kernel/unaligned.c | 143 +
4 files changed, 273 insertions(+)
diff --git a/arch/mips/include/asm/processor.h
b/arch/mips/include/asm/processor.h
index f1df4cb4a286..af2675060244 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -104,6 +104,8 @@ extern unsigned int vced_count, vcei_count;
#endif
union fpureg {
+ __u8val8[FPU_REG_WIDTH / 8];
+ __u16 val16[FPU_REG_WIDTH / 16];
__u32 val32[FPU_REG_WIDTH / 32];
__u64 val64[FPU_REG_WIDTH / 64];
};
diff --git a/arch/mips/include/uapi/asm/inst.h
b/arch/mips/include/uapi/asm/inst.h
index 89c22433b1c6..7ab6987cb7d5 100644
--- a/arch/mips/include/uapi/asm/inst.h
+++ b/arch/mips/include/uapi/asm/inst.h
@@ -58,6 +58,7 @@ enum spec_op {
dsll_op, spec7_unused_op, dsrl_op, dsra_op,
dsll32_op, spec8_unused_op, dsrl32_op, dsra32_op
};
+#define msa_op mdmx_op
/*
* func field of spec2 opcode.
@@ -217,6 +218,14 @@ enum bshfl_func {
};
/*
+ * func field for MSA MI10 format
+ */
+enum msa_mi10_func {
+ msa_ld_op = 8,
+ msa_st_op = 9,
+};
+
+/*
* (microMIPS) Major opcodes.
*/
enum mm_major_op {
@@ -616,6 +625,17 @@ struct spec3_format { /* SPEC3 */
;)
};
+struct msa_mi10_format {/* MSA */
+ __BITFIELD_FIELD(unsigned int opcode : 6,
+ __BITFIELD_FIELD(signed int s10 : 10,
+ __BITFIELD_FIELD(unsigned int rs : 5,
+ __BITFIELD_FIELD(unsigned int wd : 5,
+ __BITFIELD_FIELD(unsigned int func : 4,
+ __BITFIELD_FIELD(unsigned int df : 2,
+ ;))
+};
+
+
/*
* microMIPS instruction formats (32-bit length)
*
@@ -884,6 +904,7 @@ union mips_instruction {
struct p_format p_format;
struct f_format f_format;
struct ma_format ma_format;
+ struct msa_mi10_format msa_mi10_format;
struct b_format b_format;
struct ps_format ps_format;
struct v_format v_format;
diff --git a/arch/mips/kernel/r4k_fpu.S b/arch/mips/kernel/r4k_fpu.S
index 6c160c67984c..5f48f45f81e7 100644
--- a/arch/mips/kernel/r4k_fpu.S
+++ b/arch/mips/kernel/r4k_fpu.S
@@ -13,6 +13,7 @@
* Copyright (C) 1999, 2001 Silicon Graphics, Inc.
*/
#include
+#include
#include
#include
#include
@@ -268,6 +269,112 @@ LEAF(_restore_fp_context32)
END(_restore_fp_context32)
#endif
+#ifdef CONFIG_CPU_HAS_MSA
+
+ .macro msa_ld_dwd, base
+ ld_d\wd, 0, \base
+ jalr$0, $31
+ nop
+ .align 4
+ .endm
+
+ .macro msa_st_dwd, base
+ st_d\wd, 0, \base
+ jalr$0, $31
+ nop
+ .align 4
+ .endm
+
+LEAF(msa_to_wd)
+ .setpush
+ .setnoreorder
+ sll t0, a0, 4
+ PTR_LA t1, Lmsa_to
+ PTR_ADDUt0, t0, t1
+ jalr$0, t0
+ nop
+Lmsa_to:
+ msa_ld_d0, a1
+ msa_ld_d1, a1
+ msa_ld_d2, a1
+ msa_ld_d3, a1
+ msa_ld_d4, a1
+ msa_ld_d5, a1
+ msa_ld_d6, a1
+ msa_ld_d7, a1
+ msa_ld_d8, a1
+ msa_ld_d9, a1
+ msa_ld_d10, a1
+ msa_ld_d11, a1
+ msa_ld_d12, a1
+ msa_ld_d13, a1
+ msa_ld_d14, a1
+ msa_ld_d15, a1
+ msa_ld_d16, a1
+ msa_ld_d17, a1
+ msa_ld_d18, a1
+ msa_ld_d19, a1
+ msa_ld_d20, a1
+ msa_ld_d21, a1
+ msa_ld_d22, a1
+ msa_ld_d23, a1
+ msa_ld_d24, a1
+ msa_ld_d25, a1
+ msa_ld_d26, a1
+ msa_ld_d27, a1
+ msa_ld_d28, a1
+ msa_ld_d29, a1
+ msa_ld_d30, a1
+ msa_ld_d31, a1
+ .setpop
+ END(msa_to_wd)
+
+LEAF(msa_from_wd)
+ .setpush
+ .setnoreorder
+ sll t0, a0, 4
+ PTR_LA t1, Lmsa_from
+ PTR_ADDUt0, t0,
Re: [PATCH 2/6] ARM: cpuidle: Add a cpuidle ops structure to be used for DT
On 03/17/15 04:29, Lorenzo Pieralisi wrote:
> On Mon, Mar 16, 2015 at 10:08:19PM +, Stephen Boyd wrote:
>> On 03/03/15 04:29, Daniel Lezcano wrote:
>>> The code is optimized to use the __init section intensively in order to
>>> reduce
>>> the memory footprint after the driver is initialized and unify the function
>>> names with ARM64.
>>>
>>> In order to prevent multiple declarations and the specific cpuidle ops to be
>>> spread across the different headers, a mechanism, similar to the cgroup
>>> subsys,
>>> has been introduced.
>>>
>>> A new platform willing to add its cpuidle ops must add an entry in the file
>>> cpuidle_ops.h in the current form:
>>>
>>> #if IS_ENABLED(CONFIG_ARM_FOO_CPUIDLE)
>>> CPUIDLE_OPS(foo)
>>> #endif
>>>
>>> ... and use the variable name in the specific low level code:
>>>
>>> struct cpuidle_ops foo_cpuidle_ops;
>>>
>>> The CPUIDLE_OPS macro will be processed in different way in the cpuidle.c
>>> file,
>>> thus allowing to keep untouched the arm cpuidle core code in the future when
>>> a new platform is added.
>> [...]
>>> diff --git a/arch/arm/include/asm/cpuidle_ops.h
>>> b/arch/arm/include/asm/cpuidle_ops.h
>>> new file mode 100644
>>> index 000..be0a612
>>> --- /dev/null
>>> +++ b/arch/arm/include/asm/cpuidle_ops.h
>>> @@ -0,0 +1,3 @@
>>> +/*
>>> + * List of cpuidle operations
>>> + */
>>> diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c
>>> index 45969f8..25e9789c 100644
>>> --- a/arch/arm/kernel/cpuidle.c
>>> +++ b/arch/arm/kernel/cpuidle.c
>>> @@ -10,8 +10,29 @@
>>> */
>>>
>>> #include
>>> +#include
>>> +#include
>>> #include
>>>
>>> +#define CPUIDLE_OPS(__x) extern struct cpuidle_ops __x ## _cpuidle_ops;
>>> +#include
>>> +#undef CPUIDLE_OPS
>>> +
>>> +#define CPUIDLE_OPS(__x) __x ## _cpuidle_ops_id,
>>> +enum cpuidle_ops_id {
>>> +#include
>>> +CPUIDLE_OPS_COUNT,
>>> +};
>>> +#undef CPUIDLE_OPS
>>> +
>>> +#define CPUIDLE_OPS(__x) [__x ## _cpuidle_ops_id ] = &__x ## _cpuidle_ops,
>>> +static struct cpuidle_ops *supported_cpuidle_ops[] __initconst = {
>>> +#include
>>> +};
>>> +#undef CPUIDLE_OPS
>>> +
>>> +static struct cpuidle_ops cpuidle_ops[NR_CPUS];
>> Is there any reason why we aren't putting these structures into a linker
>> section like we do for the smp operations structures?
> I think it can be done with an OF_TABLE, it is a bit of shame cpuidle_ops
> should work on UP too otherwise they could have been merged in
> smp_ops to create cpu_ops, like arm64 does.
We should merge the two and remove the SMP dependency on arm32.
>> The nice thing about using the linker is it makes it clearer at the
>> location where we define the structure that it's actually used by
>> something. Right now the structures are defined non-static in a file and
>> then we have to know that a CPUIDLE_OPS() define has been made in
>> another architecture specific asm header file so that this macro magic
>> works. The commit text says something about multiple declarations and
>> ops spread across header files, which shouldn't apply if we're using the
>> linker to find these ops and merge them into an array we can iterate over.
> It makes sense, see above for UP vs SMP. I wonder if we can't find
> something to overcome the UP limitation nicely, the init code in
> arch/arm/kernel/devtree.c is identical for smp_ops and cpuidle_ops,
> apart from the CONFIG_SMP ifdeffery.
It should be possible to replace the arm32 smp_operations structure with
something like the arm64 cpu_operations structure. Yes we would have to
drop the SMP dependency, but that will be ok. It would require some work
to make arm32 and arm64 the same, but for these purposes that isn't
really required as long as we can put the cpu idle hook there.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] gpio / ACPI: Two minor cleanups related to ACPI_HANDLE()
On Tuesday, March 10, 2015 11:07:36 PM Rafael J. Wysocki wrote: > Hi, > > As per the subject, avoid evaluating ACPI_HANDLE() if we can as that one is > rather costly. Linus, Alexandre, any objections to this series? If not, would there be any problem if I took these to my tree? I'll probably have material on top of them. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH 4/4] f2fs: avoid wrong f2fs_bug_on when truncating inline_data
Hi Jaegeuk,
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Wednesday, March 18, 2015 12:58 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 4/4] f2fs: avoid wrong f2fs_bug_on when truncating
> inline_data
>
> This patch removes wrong f2fs_bug_on in truncate_inline_inode.
>
> When there is no space, it can happen a corner case where i_isze is over
> MAX_INLINE_SIZE while its inode is still inline_data.
>
> The scenario is
> 1. write small data into file #A.
> 2. fill the whole partition to 100%.
> 3. truncate 4096 on file #A.
If we truncate size over MAX_INLINE_DATA, we will convert inline data in
f2fs_truncate rather than write_begin below. isn't it?
Thanks,
> 4. write data at 8192 offset.
> --> f2fs_write_begin
> -> -ENOSPC = f2fs_convert_inline_page
> -> f2fs_write_failed
> -> truncate_blocks
> -> truncate_inline_inode
> BUG_ON, since i_size is 4096.
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/inline.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
> index 153c5e7..d3e0599 100644
> --- a/fs/f2fs/inline.c
> +++ b/fs/f2fs/inline.c
> @@ -54,13 +54,6 @@ bool truncate_inline_inode(struct page *ipage, u64 from)
> {
> void *addr;
>
> - /*
> - * we should never truncate inline data past max inline data size,
> - * because we always convert inline inode to normal one before
> - * truncating real data if new size is past max inline data size.
> - */
> - f2fs_bug_on(F2FS_P_SB(ipage), from > MAX_INLINE_DATA);
> -
> if (from >= MAX_INLINE_DATA)
> return false;
>
> --
> 2.1.1
>
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/8] Add helper macro for pnp_register_driver boilerplate
On Monday, March 16, 2015 09:46:29 PM Peter Huewe wrote: > This patchset introduces the module_pnp_driver macro which is a > convenience macro for PNP driver modules similar to module_pci_driver > and convert the affected drivers to the new helper macro. > It is intended to be used by drivers which init/exit section does nothing > but register/unregister the PNP driver. By using this macro it is > possible to eliminate a few lines of boilerplate code per PNP driver. > > If easier you can pull directly from my tree: > > The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda: > > Linux 4.0-rc4 (2015-03-15 17:38:20 -0700) > > are available in the git repository at: > > https://github.com/PeterHuewe/linux-tpmdd.git module_pnp_driver > > for you to fetch changes up to 5bf9cf2fdc9f22c7caa1c17a7eb2e17aab099b51: > > pnp: tty/serial/8250/8250_fintek: Use module_pnp_driver to register driver > (2015-03-16 21:40:05 +0100) > > > > Peter Huewe (8): > pnp: Add helper macro for pnp_register_driver boilerplate > pnp: tpm/tpm_infineon: Use module_pnp_driver to register driver > pnp: ata/pata_isapnp: Use module_pnp_driver to register driver > pnp: ide/ide-pnp: Use module_pnp_driver to register driver > pnp: media/rc: Use module_pnp_driver to register driver > pnp: net/sb1000: Use module_pnp_driver to register driver > pnp: platform/x86/apple-gmux: Use module_pnp_driver to register driver > pnp: tty/serial/8250/8250_fintek: Use module_pnp_driver to register > driver Makes sense to me. I'll queue this up for 4.1 if there are no objections. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] KVM: nVMX: mask unrestricted_guest if disabled on L0
On Tue, Mar 17, 2015 at 02:02:32PM +0100, Radim Krčmář wrote:
> If EPT was enabled, unrestricted_guest was allowed in L1 regardless of
> L0. L1 triple faulted when running L2 guest that required emulation.
>
> Another side effect was 'WARN_ON_ONCE(vmx->nested.nested_run_pending)'
> in L0's dmesg:
> WARNING: CPU: 0 PID: 0 at arch/x86/kvm/vmx.c:9190
> nested_vmx_vmexit+0x96e/0xb00 [kvm_intel] ()
>
> Prevent this scenario by masking SECONDARY_EXEC_UNRESTRICTED_GUEST when
> the host doesn't have it enabled.
>
> Fixes: 78051e3b7e35 ("KVM: nVMX: Disable unrestricted mode if ept=0")
> Cc: sta...@vger.kernel.org
> Tested-By: Kashyap Chamarthy
> Signed-off-by: Radim Krčmář
> ---
> The resend Cc'd stable, as recommended by Bandan, and added Tested-by.
Applied to master, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/18] pinctrl: Add pinctrl driver for STM32 MCUs
On Tue, Mar 10, 2015 at 4:08 PM, Arnd Bergmann wrote: > On Friday 20 February 2015 19:01:10 Maxime Coquelin wrote: >> +/* Pull-Up/Down */ >> +#define NO_PULL0 >> +#define PULL_UP1 >> +#define PULL_DOWN 2 >> + >> +/* Type */ >> +#define PUSH_PULL (0 << 2) >> +#define OPEN_DRAIN (1 << 2) >> + > > These should probably not be stm32 specific at all, they sound > rather generic, so maybe put the definitions into a common file. It's part of what GENERIC_PINCONF does and it has bindings in Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods
On Tue, Mar 10, 2015 at 9:34 AM, Nicolas Ferre wrote: > Le 09/03/2015 17:14, Linus Walleij a écrit : >> On Sun, Feb 8, 2015 at 7:23 PM, Boris Brezillon >> wrote: >> >>> The gpiochip_lock_as_irq call can fail and return an error, while the >>> irq_startup is not expected to fail (returns an unsigned int which is not >>> checked by irq core code). >>> >>> irq_request/release_resources functions have been created to address this >>> problem. >>> >>> Move gpiochip_lock/unlock_as_irq calls into >>> irq_request/release_resources functions to prevent using a gpio as an irq >>> if the gpiochip_lock_as_irq call failed. >>> >>> Signed-off-by: Boris Brezillon >> >> Patch applied with all the ACKs. > > Hi Linus, > > As suggested earlier, do you think it can be scheduled for the 4.0-rc > phase as a "fix"? OK argh had to rebase my tree to get the patch out of the devel branch but what can I do. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] sys_membarrier(): system/process-wide memory barrier (x86) (v12)
On Tue, 17 Mar 2015 12:46:41 + (UTC) Mathieu Desnoyers wrote: > > Would that help? > > > > this_cpu_write(saved_next, next); > > rq = context_switch(rq, prev, next); > > rq->curr = this_cpu_read(saved_next); > > Assuming there is a full memory barrier (e.g. load_cr3) within > context_switch, it would help for ordering memory accesses that > are performed prior to the preemption, but not for memory accesses > to be performed immediately after return to userspace from preemption. Hmm, I was thinking that there was a spin_unlock(rq->lock) after that, but it appears that context_switch() does the unlock. If there was an spin_unlock() after this code, then it could work. There's always setting the rq->curr in the context_switch() call itself. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] device_property: Add comments about returning array counts
On Tuesday, March 17, 2015 09:58:58 AM Adrian Hunter wrote: > The "read array" variants of the device property functions > can be used to return the number of values in an array. > Update the comments to reflect that. > > Signed-off-by: Adrian Hunter Looks OK to me. Greg, any objections? > --- > drivers/base/property.c | 53 > + > 1 file changed, 32 insertions(+), 21 deletions(-) > > diff --git a/drivers/base/property.c b/drivers/base/property.c > index c458458..b524a4e 100644 > --- a/drivers/base/property.c > +++ b/drivers/base/property.c > @@ -62,13 +62,14 @@ EXPORT_SYMBOL_GPL(fwnode_property_present); > * device_property_read_u8_array - return a u8 array property of a device > * @dev: Device to get the property of > * @propname: Name of the property > - * @val: The values are stored here > + * @val: The values are stored here or %NULL to return the number of values > * @nval: Size of the @val array > * > * Function reads an array of u8 properties with @propname from the device > * firmware description and stores them to @val if found. > * > - * Return: %0 if the property was found (success), > + * Return: number of values if @val was %NULL, > + * %0 if the property was found (success), > * %-EINVAL if given arguments are not valid, > * %-ENODATA if the property does not have a value, > * %-EPROTO if the property is not an array of numbers, > @@ -85,13 +86,14 @@ EXPORT_SYMBOL_GPL(device_property_read_u8_array); > * device_property_read_u16_array - return a u16 array property of a device > * @dev: Device to get the property of > * @propname: Name of the property > - * @val: The values are stored here > + * @val: The values are stored here or %NULL to return the number of values > * @nval: Size of the @val array > * > * Function reads an array of u16 properties with @propname from the device > * firmware description and stores them to @val if found. > * > - * Return: %0 if the property was found (success), > + * Return: number of values if @val was %NULL, > + * %0 if the property was found (success), > * %-EINVAL if given arguments are not valid, > * %-ENODATA if the property does not have a value, > * %-EPROTO if the property is not an array of numbers, > @@ -108,13 +110,14 @@ EXPORT_SYMBOL_GPL(device_property_read_u16_array); > * device_property_read_u32_array - return a u32 array property of a device > * @dev: Device to get the property of > * @propname: Name of the property > - * @val: The values are stored here > + * @val: The values are stored here or %NULL to return the number of values > * @nval: Size of the @val array > * > * Function reads an array of u32 properties with @propname from the device > * firmware description and stores them to @val if found. > * > - * Return: %0 if the property was found (success), > + * Return: number of values if @val was %NULL, > + * %0 if the property was found (success), > * %-EINVAL if given arguments are not valid, > * %-ENODATA if the property does not have a value, > * %-EPROTO if the property is not an array of numbers, > @@ -131,13 +134,14 @@ EXPORT_SYMBOL_GPL(device_property_read_u32_array); > * device_property_read_u64_array - return a u64 array property of a device > * @dev: Device to get the property of > * @propname: Name of the property > - * @val: The values are stored here > + * @val: The values are stored here or %NULL to return the number of values > * @nval: Size of the @val array > * > * Function reads an array of u64 properties with @propname from the device > * firmware description and stores them to @val if found. > * > - * Return: %0 if the property was found (success), > + * Return: number of values if @val was %NULL, > + * %0 if the property was found (success), > * %-EINVAL if given arguments are not valid, > * %-ENODATA if the property does not have a value, > * %-EPROTO if the property is not an array of numbers, > @@ -154,13 +158,14 @@ EXPORT_SYMBOL_GPL(device_property_read_u64_array); > * device_property_read_string_array - return a string array property of > device > * @dev: Device to get the property of > * @propname: Name of the property > - * @val: The values are stored here > + * @val: The values are stored here or %NULL to return the number of values > * @nval: Size of the @val array > * > * Function reads an array of string properties with @propname from the > device > * firmware description and stores them to @val if found. > * > - * Return: %0 if the property was found (success), > + * Return: number of values if @val was %NULL, > + * %0 if the property was found (success), > * %-EINVAL if given arguments are not valid, > * %-ENODATA if the property does not have a value, > * %-EPROTO or %-EILSEQ if the property is not an array of strings, > @@ -1
linux-next: manual merge of the slave-dma tree with the arm-soc tree
Hi Vinod,
Today's linux-next merge of the slave-dma tree got a conflict in
arch/arm/mach-shmobile/board-mackerel.c between commit a521422ea4ae
("ARM: shmobile: mackerel: Remove Legacy C board code") from the
arm-soc tree and commit c078c62a7528 ("mmc: sh_mobile_sdhi: remove
sh_mobile_sdhi_info v2") from the slave-dma tree.
I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpeXrR0emn0p.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the slave-dma tree with the renesas tree
Hi Vinod,
Today's linux-next merge of the slave-dma tree got a conflict in
arch/arm/mach-shmobile/board-ape6evm.c between commit 9d07d414d4c3
("ARM: shmobile: r8a73a4: ape6evm: Remove legacy platform") from the
renesas tree and commit c078c62a7528 ("mmc: sh_mobile_sdhi: remove
sh_mobile_sdhi_info v2") from the slave-dma tree.
I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpc6bgzTd_QL.pgp
Description: OpenPGP digital signature
[PATCH] regulator: Fix documentation for regmap in the config
dev_get_regulator() does not exist, fix the typo.
Signed-off-by: Axel Lin
---
include/linux/regulator/driver.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index d4ad5b5..045f709 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -316,7 +316,7 @@ struct regulator_desc {
* @driver_data: private regulator data
* @of_node: OpenFirmware node to parse for device tree bindings (may be
* NULL).
- * @regmap: regmap to use for core regmap helpers if dev_get_regulator() is
+ * @regmap: regmap to use for core regmap helpers if dev_get_regmap() is
* insufficient.
* @ena_gpio_initialized: GPIO controlling regulator enable was properly
*initialized, meaning that >= 0 is a valid gpio
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rtc: at91rm9200: double locking bug in at91_rtc_interrupt()
On Tuesday, March 17, 2015 04:38:10 PM Nicolas Ferre wrote:
> From: Dan Carpenter
>
> There is a typo here so we deadlock.
>
> Fixes: dd1f1f391dd7 ('rtc: at91rm9200: rework wakeup and interrupt handling')
> Signed-off-by: Dan Carpenter
> Acked-by: Boris Brezillon
> Reported-also-by: David Dueck
> Signed-off-by: Nicolas Ferre
> ---
> Hi Andrew,
>
> Can you please take care of this fix for 4.0?
> If you fee that I'd better take it myself please tell me.
The commit being fixed went in through my tree, so I'll take this one if that's
not a problem.
> drivers/rtc/rtc-at91rm9200.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
> index b4f7744f6751..b283a1a573b3 100644
> --- a/drivers/rtc/rtc-at91rm9200.c
> +++ b/drivers/rtc/rtc-at91rm9200.c
> @@ -324,7 +324,7 @@ static irqreturn_t at91_rtc_interrupt(int irq, void
> *dev_id)
>
> ret = IRQ_HANDLED;
> }
> - spin_lock(&suspended_lock);
> + spin_unlock(&suspended_lock);
>
> return ret;
> }
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] mfd: stw481x: Remove unused fields from struct stw481x
The mutex lock is not used at all, remove it.
The *vmmc_regulator is not necessary, use a local variable in
stw481x_vmmc_regulator_probe() instead.
Signed-off-by: Axel Lin
Reviewed-by: Linus Walleij
Acked-by: Lee Jones
---
Hi Mark,
Lee prefers this patch to be applied via regulator tree,
so I resend this to you.
drivers/regulator/stw481x-vmmc.c | 8
include/linux/mfd/stw481x.h | 4
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/stw481x-vmmc.c b/drivers/regulator/stw481x-vmmc.c
index 89025f5..7d2ae3e 100644
--- a/drivers/regulator/stw481x-vmmc.c
+++ b/drivers/regulator/stw481x-vmmc.c
@@ -56,6 +56,7 @@ static int stw481x_vmmc_regulator_probe(struct
platform_device *pdev)
{
struct stw481x *stw481x = dev_get_platdata(&pdev->dev);
struct regulator_config config = { };
+ struct regulator_dev *rdev;
int ret;
/* First disable the external VMMC if it's active */
@@ -75,12 +76,11 @@ static int stw481x_vmmc_regulator_probe(struct
platform_device *pdev)
pdev->dev.of_node,
&vmmc_regulator);
- stw481x->vmmc_regulator = devm_regulator_register(&pdev->dev,
- &vmmc_regulator, &config);
- if (IS_ERR(stw481x->vmmc_regulator)) {
+ rdev = devm_regulator_register(&pdev->dev, &vmmc_regulator, &config);
+ if (IS_ERR(rdev)) {
dev_err(&pdev->dev,
"error initializing STw481x VMMC regulator\n");
- return PTR_ERR(stw481x->vmmc_regulator);
+ return PTR_ERR(rdev);
}
dev_info(&pdev->dev, "initialized STw481x VMMC regulator\n");
diff --git a/include/linux/mfd/stw481x.h b/include/linux/mfd/stw481x.h
index eda1215..833074b 100644
--- a/include/linux/mfd/stw481x.h
+++ b/include/linux/mfd/stw481x.h
@@ -41,15 +41,11 @@
/**
* struct stw481x - state holder for the Stw481x drivers
- * @mutex: mutex to serialize I2C accesses
* @i2c_client: corresponding I2C client
- * @regulator: regulator device for regulator children
* @map: regmap handle to access device registers
*/
struct stw481x {
- struct mutexlock;
struct i2c_client *client;
- struct regulator_dev*vmmc_regulator;
struct regmap *map;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
