Re: [Intel-gfx] [PATCH 09/20] i915: switch from acpi_os_ioremap to memremap
On Fri, Oct 09, 2015 at 06:16:25PM -0400, Dan Williams wrote:
> i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly
> map it with memremap rather than the implied cache setting of
> acpi_os_ioremap().
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-...@lists.freedesktop.org
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Dan Williams
Assuming you've run sparse over this to make sure you've caught them all,
and with the nit below addressed this is
Reviewed-by: Daniel Vetter
Feel free to pull v2 into whatever tree you think it's suitable for (but
you can also resend and I'll pick it up).
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index e2ab3f6ed022..c8444d5f549f 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -387,7 +387,7 @@ intel_panel_detect(struct drm_device *dev)
>
> /* Assume that the BIOS does not lie through the OpRegion... */
> if (!i915.panel_ignore_lid && dev_priv->opregion.lid_state) {
> - return ioread32(dev_priv->opregion.lid_state) & 0x1 ?
> + return *(dev_priv->opregion.lid_state) & 0x1 ?
() are redundant now here.
-Daniel
> connector_status_connected :
> connector_status_disconnected;
> }
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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 V7] mm: memory hot-add: memory can not be added to movable zone defaultly
From: Changsheng Liu
After the user config CONFIG_MOVABLE_NODE,
When the memory is hot added, should_add_memory_movable() return 0
because all zones including ZONE_MOVABLE are empty,
so the memory that was hot added will be assigned to ZONE_NORMAL
and ZONE_NORMAL will be created firstly.
But we want the whole node to be added to ZONE_MOVABLE by default.
So we change should_add_memory_movable(): if the user config
CONFIG_MOVABLE_NODE and sysctl parameter hotadd_memory_as_movable is 1
and the ZONE_NORMAL is empty or the pfn of the hot-added memory
is after the end of the ZONE_NORMAL it will always return 1
and then the whole node will be added to ZONE_MOVABLE by default.
If we want the node to be assigned to ZONE_NORMAL,
we can do it as follows:
"echo online_kernel > /sys/devices/system/memory/memoryXXX/state"
By the patch, the behavious of kernel is changed by sysctl,
user can automatically create movable memory
by only the following udev rule:
SUBSYSTEM=="memory", ACTION=="add",
ATTR{state}=="offline", ATTR{state}="online"
Signed-off-by: Changsheng Liu
Signed-off-by: Xiaofeng Yan
Tested-by: Dongdong Fan
Cc: Wang Nan
Cc: Dave Hansen
Cc: Yinghai Lu
Cc: Tang Chen
Cc: Yasuaki Ishimatsu
Cc: Toshi Kani
Cc: Xishi Qiu
---
Documentation/memory-hotplug.txt |5 -
kernel/sysctl.c | 15 +++
mm/memory_hotplug.c | 24
3 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index ce2cfcf..7ac7485 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -277,7 +277,7 @@ And if the memory block is in ZONE_MOVABLE, you can change
it to ZONE_NORMAL:
After this, memory block XXX's state will be 'online' and the amount of
available memory will be increased.
-Currently, newly added memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA).
+Currently, newly added memory is added as ZONE_NORMAL or ZONE_MOVABLE (for
powerpc, ZONE_DMA).
This may be changed in future.
@@ -319,6 +319,9 @@ creates ZONE_MOVABLE as following.
Size of memory not for movable pages (not for offline) is TOTAL - .
Size of memory for movable pages (for offline) is .
+And a sysctl parameter for assigning the hot added memory to ZONE_MOVABLE is
+supported. If the value of "kernel/hotadd_memory_as_movable" is 1,the hot added
+memory will be assigned to ZONE_MOVABLE by default.
Note: Unfortunately, there is no information to show which memory block belongs
to ZONE_MOVABLE. This is TBD.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 19b62b5..16b1501 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -166,6 +166,10 @@ extern int unaligned_dump_stack;
extern int no_unaligned_warning;
#endif
+#ifdef CONFIG_MOVABLE_NODE
+extern int hotadd_memory_as_movable;
+#endif
+
#ifdef CONFIG_PROC_SYSCTL
#define SYSCTL_WRITES_LEGACY -1
@@ -1139,6 +1143,17 @@ static struct ctl_table kern_table[] = {
.proc_handler = timer_migration_handler,
},
#endif
+/*If the value of "kernel/hotadd_memory_as_movable" is 1,the hot added
+ * memory will be assigned to ZONE_MOVABLE by default.*/
+#ifdef CONFIG_MOVABLE_NODE
+ {
+ .procname = "hotadd_memory_as_movable",
+ .data = &hotadd_memory_as_movable,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
+#endif
{ }
};
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 26fbba7..eca5512 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -37,6 +37,11 @@
#include "internal.h"
+/*If the global variable value is 1,
+ * the hot added memory will be assigned to ZONE_MOVABLE by default
+ */
+int hotadd_memory_as_movable;
+
/*
* online_page_callback contains pointer to current page onlining function.
* Initially it is generic_online_page(). If it is required it could be
@@ -1190,6 +1195,9 @@ static int check_hotplug_memory_range(u64 start, u64 size)
/*
* If movable zone has already been setup, newly added memory should be check.
* If its address is higher than movable zone, it should be added as movable.
+ * And if system config CONFIG_MOVABLE_NODE and set the sysctl parameter
+ * "hotadd_memory_as_movable" and added memory does not overlap the zone
+ * before MOVABLE_ZONE,the memory will be added as movable.
* Without this check, movable zone may overlap with other zone.
*/
static int should_add_memory_movable(int nid, u64 start, u64 size)
@@ -1197,6 +1205,22 @@ static int should_add_memory_movable(int nid, u64 start,
u64 size)
unsigned long start_pfn = start >> PAGE_SHIFT;
pg_data_t *pgdat = NODE_DATA(nid);
struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE;
+ struct zone *pre_zone = pgdat->node_zones + (ZONE_MOVABLE - 1);
+ /*
+* The sy
[lkp] [string] 5f6f0801f5: BUG: KASan: out of bounds access in strlcpy+0xc8/0x250 at addr ffff88011a666ee0
FYI, we noticed the below changes on
git://internal_mailing_list_patch_tree
Ingo-Molnar/string-Improve-the-generic-strlcpy-implementation
commit 5f6f0801f5fdfce4984c6a14f99dbfbb417acb66 ("string: Improve the generic
strlcpy() implementation")
[ 22.205482] systemd[1]: RTC configured in localtime, applying delta of 480
minutes to system time.
[ 22.214569] random: systemd urandom read with 11 bits of entropy available
[ 22.241378]
==
[ 22.242067] BUG: KASan: out of bounds access in strlcpy+0xc8/0x250 at addr
88011a666ee0
[ 22.242067] Read of size 8 by task systemd/1
[ 22.242067]
=
[ 22.242067] BUG kmalloc-64 (Not tainted): kasan: bad access detected
[ 22.242067]
-
[ 22.242067]
[ 22.242067] Disabling lock debugging due to kernel taint
[ 22.242067] INFO: Slab 0xea0004699980 objects=64 used=64 fp=0x
(null) flags=0x280
[ 22.242067] INFO: Object 0x88011a666ec0 @offset=3776
fp=0x7379732f62696c2f
[ 22.242067]
[ 22.242067] Bytes b4 88011a666eb0: 00 00 00 00 00 00 00 00 a7 4b c2 ef
07 00 00 00 .K..
[ 22.242067] Object 88011a666ec0: 2f 6c 69 62 2f 73 79 73 74 65 6d 64 2f
73 79 73 /lib/systemd/sys
To reproduce:
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.3.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_KASAN_SHADOW_OFFSET=0xdc00
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
CONFIG_FHANDLE=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
# CONFIG_AUDITSYSCALL is not set
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ_FULL is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
# CONFIG_TICK_CPU_ACCOUNTING is not set
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
# CONFIG_TASK_DELAY_ACCT is not set
# CONFIG_TASK_XACCT is not set
#
# RCU Subsystem
#
CONFIG_PREEMPT_RCU
Re: [PATCH v7 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
On 12.10.2015 13:29, Yakir Yang wrote: > Both hsync/vsync polarity and interlace mode can be parsed from > drm display mode, and dynamic_range and ycbcr_coeff can be judge > by the video code. > > But presumably Exynos still relies on the DT properties, so take > good use of mode_fixup() in to achieve the compatibility hacks. > > Signed-off-by: Yakir Yang > --- > *just add a note that this is v7 of only fifth patch.* > > Changes in v7: > - Back to use the of_property_read_bool() interfacs to provoid backward > compatibility of "hsync-active-high" "vsync-active-high" "interlaced" > to avoid -EOVERFLOW error (Krzysztof) > > Changes in v6: None > Changes in v5: > - Switch video timing type to "u32", so driver could use > "of_property_read_u32" > to get the backword timing values. Krzysztof suggest me that driver could > use > the "of_property_read_bool" to get backword timing values, but that > interfacs > would modify the original drm_display_mode timing directly (whether those > properties exists or not). > > Changes in v4: > - Provide backword compatibility with samsung. (Krzysztof) > > Changes in v3: > - Dynamic parse video timing info from struct drm_display_mode and > struct drm_display_info. (Thierry) > > Changes in v2: None > > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 > + > drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +- > drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +- > 3 files changed, 103 insertions(+), 61 deletions(-) > Looks good and backward compatible to me: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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] irqchip/renesas-intc-irqpin: Remove obsolete platform data support
On Mon, 12 Oct 2015, Simon Horman wrote: > On Fri, Oct 09, 2015 at 02:19:51PM +0200, Thomas Gleixner wrote: > > On Wed, 7 Oct 2015, Geert Uytterhoeven wrote: > > > On Wed, Oct 7, 2015 at 8:51 PM, kbuild test robot wrote: > > > > [auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, > > > > please ignore] > > > > > > > > config: arm-bockw_defconfig (attached as .config) > > > > reproduce: > > > > wget > > > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > > > > -O ~/bin/make.cross > > > > chmod +x ~/bin/make.cross > > > > # save the attached .config to linux build tree > > > > make.cross ARCH=arm > > > > > > > > All errors (new ones prefixed by >>): > > > > > > > >>> arch/arm/mach-shmobile/setup-r8a7778.c:26:57: fatal error: > > > >>> linux/platform_data/irq-renesas-intc-irqpin.h: No such file or > > > >>> directory > > > > #include > > > > ^ > > > > > > Please ignore. Legacy (non-DT) r8a7778/bockw support has been removed > > > in arm-soc/for-next. > > > > That creates a cross tree merge dependency. Bah! > > > > I have > > > > 26c21dd9885a: irqchip/renesas-intc-irqpin: r8a7778 IRLM setup support > > > > in tip irq/core pending. That should not conflict with that one. So I > > suggest, that the arm-soc tree carries that cleanup with my > > > > Reviewed-by: Thomas Gleixner > > > > If you have more changes coming up for irqchip/renesas-intc-irqpin we > > probably need to take them through arm-soc as well. > > I'm happy to take "[PATCH 1/2] irqchip/renesas-intc-irqpin: Remove obsolete > platform data support" into the renesas tree with Thomas's ack and forward > it to arm-soc for v4.4. Though I will need to finalise doing so in > the next few days. I would also be happy to see these patches > re-posted once the removal of Legacy (non-DT) r8a7778/bockw support has > hit next. > > Geert, is that your preferred course of action for this patch? > And what about "[PATCH 2/2] irqchip/renesas-intc-irqpin: Remove > intc_irqpin_priv.number_of_irq"? If you want to take it now: Acked-by-me There is also a new one against irqchip/renesas-intc-irqpin from Paul Gortmaker, you probably want to pick that up as well. Thanks, tglx -- 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] arm64: add kc_offset_to_vaddr and kc_vaddr_to_offset macro
This patch add kc_offset_to_vaddr() and kc_vaddr_to_offset(),
the default version doesn't work on arm64, because arm64 kernel address
is below the PAGE_OFFSET, like module address and vmemmap address are
all below PAGE_OFFSET address.
Signed-off-by: yalin wang
---
arch/arm64/include/asm/pgtable.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 4331d84..23070a8 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -658,6 +658,8 @@ static inline void update_mmu_cache(struct vm_area_struct
*vma,
#define update_mmu_cache_pmd(vma, address, pmd) do { } while (0)
+#definekc_vaddr_to_offset(v) ((v) & ~VA_START)
+#definekc_offset_to_vaddr(o) ((o) | VA_START)
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PGTABLE_H */
--
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: clear RTC alarm status flag prior to suspending
Hi Wenyou,
On 12/10/2015 at 09:17:57 +0800, Wenyou Yang wrote :
> This patch is to clear the RTC alarm status flag prior to suspending
> to avoid the erroneous wake-up activity.
>
Is this a new issue appearing with the sama5d2 or was it present from
the beginning?
> Signed-off-by: Wenyou Yang
> ---
>
> drivers/rtc/rtc-at91rm9200.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
> index cb62e21..b60fd47 100644
> --- a/drivers/rtc/rtc-at91rm9200.c
> +++ b/drivers/rtc/rtc-at91rm9200.c
> @@ -495,6 +495,8 @@ static int at91_rtc_suspend(struct device *dev)
> /* this IRQ is shared with DBGU and other hardware which isn't
>* necessarily doing PM like we are...
>*/
> + at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
> +
> at91_rtc_imr = at91_rtc_read_imr()
> & (AT91_RTC_ALARM|AT91_RTC_SECEV);
> if (at91_rtc_imr) {
> --
> 1.7.9.5
>
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.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/
Re: [PATCH] arm: dts: Fix audio card detection on peach boards
On 12.10.2015 15:26, Alim Akhtar wrote:
> Since the merge of 2fad972 ("ARM: dts: Add mclk entry for Peach boards"),
Please switch to longer SHA abbreviation:
$ git config core.abbrev 12
> sound card detection is broken on peach boards and gives below errors:
>
> [3.630457] max98090 7-0010: MAX98091 REVID=0x51
> [3.634233] max98090 7-0010: use default 2.8v micbias
> [3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
> [3.645307] max98090 7-0010: Invalid master clock frequency
> [3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
> failed: -22
> [3.658914] snow-audio sound: snd_soc_register_card failed (-22)
> [3.664366] snow-audio: probe of sound failed with error -22
>
> This patch adds missing assigned-clocks and assigned-clock-parents for
> pmu_system_controller node which is used as "mclk" for audio codec.
>
> Signed-off-by: Alim Akhtar
> Fixes: 2fad972 ("ARM: dts: Add mclk entry for Peach boards")
> Cc:
> ---
> arch/arm/boot/dts/exynos5420-peach-pit.dts |5 +
> arch/arm/boot/dts/exynos5800-peach-pi.dts |5 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 8f4d76c..525a93a 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -1056,5 +1056,10 @@
> timeout-sec = <32>;
> };
>
> +&pmu_system_controller {
Please put the node in alphabetical order.
> + assigned-clocks = <&pmu_system_controller 0>;
> + assigned-clock-parents = <&clock CLK_FIN_PLL>;
I might be missing something here but isn't the first clock of
pmu_system_controller already a CLK_FIN_PLL? So you are reparenting the
FIN_PLL to FIN_PLL?
In the same time there is doubled space character after '='.
> +};
> +
> #include "cros-ec-keyboard.dtsi"
> #include "cros-adc-thermistors.dtsi"
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index 7d5b386..411de8f 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -1019,5 +1019,10 @@
> timeout-sec = <32>;
> };
>
> +&pmu_system_controller {
> + assigned-clocks = <&pmu_system_controller 0>;
> + assigned-clock-parents = <&clock CLK_FIN_PLL>;
Ditto.
Best regards,
Krzysztof
> +};
> +
> #include "cros-ec-keyboard.dtsi"
> #include "cros-adc-thermistors.dtsi"
>
--
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 v2 5/7] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants
On Sun, Oct 11, 2015 at 06:25:20PM +0800, Boqun Feng wrote:
> On Sat, Oct 10, 2015 at 09:58:05AM +0800, Boqun Feng wrote:
> > Hi Peter,
> >
> > Sorry for replying late.
> >
> > On Thu, Oct 01, 2015 at 02:27:16PM +0200, Peter Zijlstra wrote:
> > > On Wed, Sep 16, 2015 at 11:49:33PM +0800, Boqun Feng wrote:
> > > > Unlike other atomic operation variants, cmpxchg{,64}_acquire and
> > > > atomic{,64}_cmpxchg_acquire don't have acquire semantics if the cmp part
> > > > fails, so we need to implement these using assembly.
> > >
> > > I think that is actually expected and documented. That is, a cmpxchg
> > > only implies barriers on success. See:
> > >
> > > ed2de9f74ecb ("locking/Documentation: Clarify failed cmpxchg() memory
> > > ordering semantics")
> >
> > I probably didn't make myself clear here, my point is that if we use
> > __atomic_op_acquire() to built *_cmpchg_acquire(For ARM and PowerPC),
> > the barrier will be implied _unconditionally_, meaning no matter cmp
> > fails or not, there will be a barrier after the cmpxchg operation.
> > Therefore we have to use assembly to implement the operations right now.
See later, but no, you don't _have_ to.
> Or let me try another way to explain this. What I wanted to say here is
> that unlike the implementation of xchg family, which needs only to
> implement _relaxed version and *remove* the fully ordered version, the
> implementation of cmpxchg family needs to *remain* the fully ordered
> version and implement the _acquire version in assembly. Because if we
> use __atomic_op_*(), the barriers in the cmpxchg family will be implied
> *unconditionally*, for example:
So the point that confused me, and which is still valid for the above,
is your use of 'need'.
You don't need to omit the barrier at all. Its perfectly valid to issue
too many barriers (pointless and a waste of time, yes; incorrect, no).
So what you want to say is: "Optimize cmpxchg_acquire() to avoid
superfluous barrier".
--
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/
[lkp] [tmpfs] afa2db2fb6: -14.5% aim9.creat-clo.ops_per_sec
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit afa2db2fb6f15f860069de94a1257db57589fe95 ("tmpfs: truncate prealloc
blocks past i_size")
=
tbox_group/testcase/rootfs/kconfig/compiler/cpufreq_governor/testtime/test:
lkp-wsx02/aim9/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/performance/300s/creat-clo
commit:
c435a390574d012f8d30074135d8fcc6f480b484
afa2db2fb6f15f860069de94a1257db57589fe95
c435a390574d012f afa2db2fb6f15f860069de94a1
--
%stddev %change %stddev
\ |\
563108 ± 0% -14.5% 481585 ± 6% aim9.creat-clo.ops_per_sec
13485 ± 9% -17.2% 11162 ± 8% numa-meminfo.node0.SReclaimable
9.21 ± 4% -11.7% 8.13 ± 1% time.user_time
2.04 ± 10% -19.6% 1.64 ± 14% turbostat.CPU%c1
11667682 ± 96% -96.0% 463268 ±104% cpuidle.C1E-NHM.time
2401 ± 3% -38.8% 1470 ± 27% cpuidle.C3-NHM.usage
2.25 ± 48%+166.7% 6.00 ± 20% numa-numastat.node2.other_node
4.75 ± 68%+126.3% 10.75 ± 34% numa-numastat.node3.other_node
3370 ± 9% -17.2% 2790 ± 8%
numa-vmstat.node0.nr_slab_reclaimable
15.00 ±101%+338.3% 65.75 ± 69% numa-vmstat.node1.nr_dirtied
14.33 ±108%+357.0% 65.50 ± 68% numa-vmstat.node1.nr_written
43359 ± 0% -50.6% 21399 ± 58% numa-vmstat.node2.numa_other
5522042 ± 0% -11.8%4871759 ± 5% proc-vmstat.numa_hit
5522030 ± 0% -11.8%4871736 ± 5% proc-vmstat.numa_local
10381338 ± 0% -16.1%8713670 ± 5% proc-vmstat.pgalloc_normal
10403821 ± 0% -12.5%9099427 ± 5% proc-vmstat.pgfree
1101 ± 5% -15.9% 926.25 ± 12% slabinfo.blkdev_ioc.active_objs
1101 ± 5% -15.9% 926.25 ± 12% slabinfo.blkdev_ioc.num_objs
1058 ± 3% -12.1% 930.75 ± 8% slabinfo.file_lock_ctx.active_objs
1058 ± 3% -12.1% 930.75 ± 8% slabinfo.file_lock_ctx.num_objs
872.38 ± 56% -46.5% 467.10 ± 70%
sched_debug.cfs_rq[11]:/.exec_clock
530.50 ± 22%+225.1% 1724 ± 52%
sched_debug.cfs_rq[13]:/.avg->runnable_avg_sum
11.00 ± 23%+234.1% 36.75 ± 54%
sched_debug.cfs_rq[13]:/.tg_runnable_contrib
675.18 ± 30%+492.9% 4003 ± 61% sched_debug.cfs_rq[1]:/.exec_clock
3045 ± 37%+420.7% 15858 ± 73%
sched_debug.cfs_rq[1]:/.min_vruntime
5240 ± 48% -56.8% 2264 ± 35%
sched_debug.cfs_rq[22]:/.min_vruntime
5424 ± 93% -93.7% 339.50 ± 70%
sched_debug.cfs_rq[23]:/.avg->runnable_avg_sum
117.00 ± 94% -94.4% 6.50 ± 79%
sched_debug.cfs_rq[23]:/.tg_runnable_contrib
337.21 ± 15% -40.1% 201.92 ± 41%
sched_debug.cfs_rq[24]:/.exec_clock
199.07 ± 78%+241.7% 680.17 ± 50%
sched_debug.cfs_rq[25]:/.exec_clock
367.50 ± 12% -37.2% 230.75 ± 24%
sched_debug.cfs_rq[27]:/.avg->runnable_avg_sum
7.00 ± 17% -39.3% 4.25 ± 30%
sched_debug.cfs_rq[27]:/.tg_runnable_contrib
326.96 ± 15% -42.6% 187.64 ± 47%
sched_debug.cfs_rq[28]:/.exec_clock
200.71 ± 88% +1505.4% 3222 ± 75%
sched_debug.cfs_rq[29]:/.exec_clock
3240 ± 20% +72.0% 5574 ± 23%
sched_debug.cfs_rq[31]:/.min_vruntime
97.47 ± 42%+891.3% 966.27 ± 53%
sched_debug.cfs_rq[37]:/.exec_clock
1403 ± 55%+246.3% 4858 ± 53%
sched_debug.cfs_rq[37]:/.min_vruntime
1461 ± 50%+143.7% 3562 ± 52%
sched_debug.cfs_rq[41]:/.min_vruntime
184.00 ± 46%+671.9% 1420 ± 57%
sched_debug.cfs_rq[42]:/.avg->runnable_avg_sum
3.25 ± 66%+823.1% 30.00 ± 59%
sched_debug.cfs_rq[42]:/.tg_runnable_contrib
69.67 ± 57%+310.2% 285.75 ± 60%
sched_debug.cfs_rq[46]:/.blocked_load_avg
69.67 ± 57%+310.2% 285.75 ± 60%
sched_debug.cfs_rq[46]:/.tg_load_contrib
107.61 ± 51%+155.0% 274.41 ± 13%
sched_debug.cfs_rq[49]:/.exec_clock
3332 ± 40% -85.4% 487.59 ± 87% sched_debug.cfs_rq[4]:/.exec_clock
16.00 ±104% +1359.4% 233.50 ± 81%
sched_debug.cfs_rq[53]:/.blocked_load_avg
16.00 ±104% +1360.9% 233.75 ± 81%
sched_debug.cfs_rq[53]:/.tg_load_contrib
2502 ± 21% +74.1% 4357 ± 22%
sched_debug.cfs_rq[5]:/.min_vruntime
308.22 ± 17% -53.7% 142.65 ± 64%
sched_debug.cfs_rq[60]:/.exec_clock
91.55 ± 65%+530.7% 577.43 ± 93%
sched_debug.cfs_rq[61]:/.exec_clock
1023 ± 55%+205.9% 3130 ± 47%
sched_debug.cfs_rq[61]:/.min_vruntime
10369 ± 2% -14.2% 8892 ± 6%
sched_debug.cfs_rq[63]:/.tg_load_avg
2143 ± 6% -11.1% 1905 ± 7%
sched_debug.cfs_rq[64]:/.tg->runnable_avg
10383 ± 2%
Re: [PATCH 05/16] irqchip: Convert all alloc/xlate users from of_node to fwnode
On 10/07/2015 01:36 AM, Marc Zyngier wrote:
Since we now have a generic data structure to express an
interrupt specifier, convert all hierarchical irqchips that
are OF based to use a fwnode_handle as part of their alloc
and xlate (which becomes translate) callbacks.
As most of these drivers have dependencies (they exchange IRQ
specifiers), change them all in a single, massive patch...
Signed-off-by: Marc Zyngier
---
arch/arm/mach-exynos/suspend.c | 55 ---
arch/arm/mach-imx/gpc.c | 55 ---
arch/arm/mach-omap2/omap-wakeupgen.c | 55 ---
drivers/irqchip/irq-crossbar.c | 62 ++
drivers/irqchip/irq-gic-v2m.c| 18 ++
drivers/irqchip/irq-gic-v3-its.c | 20 ++-
drivers/irqchip/irq-gic-v3.c | 49 +--
drivers/irqchip/irq-gic.c| 33 ---
drivers/irqchip/irq-imx-gpcv2.c | 64
drivers/irqchip/irq-mtk-sysirq.c | 49 ++-
drivers/irqchip/irq-nvic.c | 18 +++---
drivers/irqchip/irq-tegra.c | 55 ---
drivers/irqchip/irq-vf610-mscm-ir.c | 42 +++
13 files changed, 323 insertions(+), 252 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index e00eb39..5a7e47c 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -177,54 +177,57 @@ static struct irq_chip exynos_pmu_chip = {
#endif
};
-static int exynos_pmu_domain_xlate(struct irq_domain *domain,
- struct device_node *controller,
- const u32 *intspec,
- unsigned int intsize,
- unsigned long *out_hwirq,
- unsigned int *out_type)
+static int exynos_pmu_domain_translate(struct irq_domain *d,
+ struct irq_fwspec *fwspec,
+ unsigned long *hwirq,
+ unsigned int *type)
{
- if (domain->of_node != controller)
- return -EINVAL; /* Shouldn't happen, really... */
- if (intsize != 3)
- return -EINVAL; /* Not GIC compliant */
- if (intspec[0] != 0)
- return -EINVAL; /* No PPI should point to this domain */
+ if (is_of_node(fwspec->fwnode)) {
+ if (fwspec->param_count != 3)
+ return -EINVAL;
- *out_hwirq = intspec[1];
- *out_type = intspec[2];
- return 0;
+ /* No PPI should point to this domain */
+ if (fwspec->param[0] != 0)
+ return -EINVAL;
+
+ *hwirq = fwspec->param[1];
+ *type = fwspec->param[2];
+ return 0;
+ }
+
+ return -EINVAL;
}
static int exynos_pmu_domain_alloc(struct irq_domain *domain,
unsigned int virq,
unsigned int nr_irqs, void *data)
{
- struct of_phandle_args *args = data;
- struct of_phandle_args parent_args;
+ struct irq_fwspec *fwspec = data;
+ struct irq_fwspec parent_fwspec;
irq_hw_number_t hwirq;
int i;
- if (args->args_count != 3)
+ if (fwspec->param_count != 3)
return -EINVAL; /* Not GIC compliant */
- if (args->args[0] != 0)
+ if (fwspec->param[0] != 0)
return -EINVAL; /* No PPI should point to this domain */
- hwirq = args->args[1];
+ hwirq = fwspec->param[1];
for (i = 0; i < nr_irqs; i++)
irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
&exynos_pmu_chip, NULL);
- parent_args = *args;
- parent_args.np = domain->parent->of_node;
Hmm, here removes the of_node, but I think we still
need to convert it in the first patch, or will break
the git bisect.
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: Can't we use timeout based OOM warning/killing?
Tetsuo Handa wrote:
> So, zapping the first OOM victim's mm might fail by chance.
I retested with a slightly different version.
-- Reproducer start --
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
static int writer(void *unused)
{
const int fd = open("/proc/self/exe", O_RDONLY);
while (1) {
void *ptr = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, fd, 0);
munmap(ptr, 4096);
}
return 0;
}
int main(int argc, char *argv[])
{
char buffer[128] = { };
const pid_t pid = fork();
if (pid == 0) { /* down_write(&mm->mmap_sem) requester which is chosen
as an OOM victim. */
int i;
for (i = 0; i < 9; i++)
clone(writer, malloc(1024) + 1024, CLONE_THREAD |
CLONE_SIGHAND | CLONE_VM, NULL);
writer(NULL);
}
snprintf(buffer, sizeof(buffer) - 1, "/proc/%u/stat", pid);
if (fork() == 0) { /* down_read(&mm->mmap_sem) requester. */
const int fd = open(buffer, O_RDONLY);
while (pread(fd, buffer, sizeof(buffer), 0) > 0);
_exit(0);
} else { /* A dummy process for invoking the OOM killer. */
char *buf = NULL;
unsigned long size = 0;
const int fd = open("/dev/zero", O_RDONLY);
for (size = 1048576; size < 512UL * (1 << 30); size <<= 1) {
char *cp = realloc(buf, size);
if (!cp) {
size >>= 1;
break;
}
buf = cp;
}
read(fd, buf, size); /* Will cause OOM due to overcommit */
return 0;
}
}
-- Reproducer end --
Complete log is at http://I-love.SAKURA.ne.jp/tmp/serial-20151012.txt.xz .
Uptime between 101 and 300 is a silent hang up (i.e. no OOM killer messages,
no SIGKILL pending tasks, no TIF_MEMDIE tasks) which I solved using SysRq-f
at uptime = 289. I don't know the reason of this silent hang up, but the
memory unzapping kernel thread will not help because there is no OOM victim.
--
[ 101.438951] MemAlloc-Info: 10 stalling task, 0 dying task, 0 victim task.
(...snipped...)
[ 111.817922] MemAlloc-Info: 12 stalling task, 0 dying task, 0 victim task.
(...snipped...)
[ 122.281828] MemAlloc-Info: 13 stalling task, 0 dying task, 0 victim task.
(...snipped...)
[ 132.793724] MemAlloc-Info: 14 stalling task, 0 dying task, 0 victim task.
(...snipped...)
[ 143.336154] MemAlloc-Info: 16 stalling task, 0 dying task, 0 victim task.
(...snipped...)
[ 289.343187] sysrq: SysRq : Manual OOM execution
(...snipped...)
[ 292.065650] MemAlloc-Info: 16 stalling task, 0 dying task, 0 victim task.
(...snipped...)
[ 302.590736] kworker/3:2 invoked oom-killer: gfp_mask=0x24000c0, order=-1,
oom_score_adj=0
(...snipped...)
[ 302.690047] MemAlloc-Info: 4 stalling task, 0 dying task, 0 victim task.
--
Uptime between 379 and 605 is a mmap_sem livelock after the OOM killer was
invoked.
--
[ 380.039897] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents
oom_score_adj name
[ 380.042500] [ 467] 0 46714047 1815 28 30
0 systemd-journal
[ 380.045055] [ 482] 0 48210413 259 23 30
-1000 systemd-udevd
[ 380.047637] [ 504] 0 50412795 119 25 30
-1000 auditd
[ 380.050127] [ 1244] 0 124482428 4257 81 30
0 firewalld
[ 380.052536] [ 1247]70 1247 6988 61 21 30
0 avahi-daemon
[ 380.055028] [ 1250] 0 125054104 1372 42 40
0 rsyslogd
[ 380.057505] [ 1251] 0 1251 137547 2620 91 30
0 tuned
[ 380.059996] [ 1255] 0 1255 4823 77 15 30
0 irqbalance
[ 380.062552] [ 1256] 0 1256 1095 37 8 30
0 rngd
[ 380.065020] [ 1259] 0 125953626 441 60 30
0 abrtd
[ 380.067383] [ 1260] 0 126053001 341 58 50
0 abrt-watch-log
[ 380.069965] [ 1265] 0 1265 8673 83 21 30
0 systemd-logind
[ 380.072554] [ 1266]81 1266 6663 117 18 30
-900 dbus-daemon
[ 380.075122] [ 1272] 0 127231577 154 21 30
0 crond
[ 380.077544] [ 1314]70 1314 6988 57 19 30
0 avahi-daemon
[ 380.080013] [ 1427] 0 142746741 225 44 30
0 vmtoolsd
[ 380.082478] [ 1969] 0 196
[PATCH] arm: dts: Fix audio card detection on peach boards
Since the merge of 2fad972 ("ARM: dts: Add mclk entry for Peach boards"),
sound card detection is broken on peach boards and gives below errors:
[3.630457] max98090 7-0010: MAX98091 REVID=0x51
[3.634233] max98090 7-0010: use default 2.8v micbias
[3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
[3.645307] max98090 7-0010: Invalid master clock frequency
[3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
failed: -22
[3.658914] snow-audio sound: snd_soc_register_card failed (-22)
[3.664366] snow-audio: probe of sound failed with error -22
This patch adds missing assigned-clocks and assigned-clock-parents for
pmu_system_controller node which is used as "mclk" for audio codec.
Signed-off-by: Alim Akhtar
Fixes: 2fad972 ("ARM: dts: Add mclk entry for Peach boards")
Cc:
---
arch/arm/boot/dts/exynos5420-peach-pit.dts |5 +
arch/arm/boot/dts/exynos5800-peach-pi.dts |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 8f4d76c..525a93a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -1056,5 +1056,10 @@
timeout-sec = <32>;
};
+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
+};
+
#include "cros-ec-keyboard.dtsi"
#include "cros-adc-thermistors.dtsi"
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7d5b386..411de8f 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -1019,5 +1019,10 @@
timeout-sec = <32>;
};
+&pmu_system_controller {
+ assigned-clocks = <&pmu_system_controller 0>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>;
+};
+
#include "cros-ec-keyboard.dtsi"
#include "cros-adc-thermistors.dtsi"
--
1.7.10.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: linux-next: manual merge of the tip tree with the crypto tree
On Mon, Oct 12, 2015 at 02:24:21PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/Makefile
>
> between commit:
>
> e38b6b7fcfd1 ("crypto: x86/sha - Add build support for Intel SHA Extensions
> optimized SHA1 and SHA256")
>
> from the crypto tree and commit:
>
> 7b956f035a9e ("x86/asm: Re-add parts of the manual CFI infrastructure")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Thanks Stephen.
--
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/
[PATCH] input: cyapa: fix the copy paste error on electrodes_rx value
Fix the copy paste error on the electrodes_rx value set code which will
cause the electrodes_rx value be always set to the value of electrodes_y.
Reviewed-by: Dmitry Torokhov
Reviewed-by: Sudip Mukherjee
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen6.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/input/mouse/cyapa_gen6.c b/drivers/input/mouse/cyapa_gen6.c
index 5f19107..a5eb5ae 100644
--- a/drivers/input/mouse/cyapa_gen6.c
+++ b/drivers/input/mouse/cyapa_gen6.c
@@ -241,14 +241,12 @@ static int cyapa_gen6_read_sys_info(struct cyapa *cyapa)
memcpy(&cyapa->product_id[13], &resp_data[62], 2);
cyapa->product_id[15] = '\0';
+ /* Get the number of Rx electrodes. */
rotat_align = resp_data[68];
- if (rotat_align) {
+ if (rotat_align)
cyapa->electrodes_rx = cyapa->electrodes_y;
- cyapa->electrodes_rx = cyapa->electrodes_y;
- } else {
+ else
cyapa->electrodes_rx = cyapa->electrodes_x;
- cyapa->electrodes_rx = cyapa->electrodes_y;
- }
cyapa->aligned_electrodes_rx = (cyapa->electrodes_rx + 3) & ~3u;
if (!cyapa->electrodes_x || !cyapa->electrodes_y ||
--
1.9.1
---
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---
--
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] powerpc/pseries/hvcserver: don't memset pi_buff if it is null
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/10/15 01:35, Daniel Axtens wrote: > > Hi Colin, > > This looks good. Out of curiousity, how did you find it? Code > inspection? Bug? Static analysis? static analysis with cppcheck. I forgot to mention that in the commit message. > > Not that it's particularly meaningful for such a trivial fix, but FWIW : > > Reviewed-by: Daniel Axtens > > Regards, > Daniel > > Colin King writes: > >> From: Colin Ian King >> >> pi_buff is being memset before it is sanity checked. Move the >> memset after the null pi_buff sanity check to avoid an oops. >> >> Signed-off-by: Colin Ian King >> --- >> arch/powerpc/platforms/pseries/hvcserver.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/powerpc/platforms/pseries/hvcserver.c b/arch/powerp c/platforms/pseries/hvcserver.c >> index eedb645..94a6e56 100644 >> --- a/arch/powerpc/platforms/pseries/hvcserver.c >> +++ b/arch/powerpc/platforms/pseries/hvcserver.c >> @@ -142,11 +142,11 @@ int hvcs_get_partner_info(uint32_t unit_address , struct list_head *head, >> int more = 1; >> int retval; >> >> -memset(pi_buff, 0x00, PAGE_SIZE); >> /* invalid parameters */ >> if (!head || !pi_buff) >> return -EINVAL; >> >> +memset(pi_buff, 0x00, PAGE_SIZE); >> last_p_partition_ID = last_p_unit_address = ~0UL; >> INIT_LIST_HEAD(head); >> >> -- >> 2.5.0 >> >> ___ >> Linuxppc-dev mailing list >> linuxppc-...@lists.ozlabs.org >> https://lists.ozlabs.org/listinfo/linuxppc-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWG0/KAAoJEGjCh9/GqAImcV8QAIToDexS4X/vya3F8aHZ2qtT idFEvgKl1mJxzgk79RJs874AiGs3CtOEC3/5w5fMh4eA/P6d6vJ1NPDu5bsugzzA I6F329WP/QxeOWgU13GSXxa0p13sUxTXqFRT8sHqwDgEaecX6kR+nf8x+P5pZUYX c7y25IHCZ/nNrj/QwQZcrlNd+U5bwxHyd5zUPJYYInbSEQmPUrhFhW1EkiUDVEYG 6rGmCzRGqfPS2sBqLXG/6ObP4FO8NC+bxQxNWAG/p9iWZg9KdIVL7IFTjWbxT7GC dsVbBsWu7ewUqo6euK56cd5CFf0oFDoHwhbDQ7T9b9CHYvGVWHxW1k7rUCgcep9x yJIIWOAVw78DemV3JkZm53Q2+1jUCYuaY6Vw8M3UmdQbWrg2rvbh8TtgoCiXbbrF HlNO0wlFOBpmr7LoHEPoIV8TsIeoeEikGrXszkqXI/MXKvN8jW1k5vtzcD3j+EU9 gy9wZvovvVZ6RL0erXwVLdzDp+R2clQfIcSi/St2/OGW+5X9NXtuaa+mvBy+dcpW Se0kO8DpLmHfNtcXvXJhCm77O1Oapw7s5UumevXSTibZ/Mhxzrdg+YhSWexm/SRu evcm6pagTpX3Vruq4BTt0Rdji9J/stT8GFlOWT0hGH1ZBLrzIKTlkJskSTkT801N +MkiI6UyL8lqdVoqZrNk =xqJ4 -END PGP 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/
RE: [PATCH 02/10] Drivers: hv: utils: run polling callback always in interrupt context
> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: Friday, October 9, 2015 4:29 AM > To: Vitaly Kuznetsov > Cc: KY Srinivasan ; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; a...@canonical.com; > jasow...@redhat.com > Subject: Re: [PATCH 02/10] Drivers: hv: utils: run polling callback always in > interrupt context > > On Fri, Oct 09, Vitaly Kuznetsov wrote: > > > Olaf Hering writes: > > > > > On Thu, Oct 08, KY Srinivasan wrote: > > > > > >> > yes, but after doing fcopy_respond_to_host(). I'd suggest we leave > the > > >> > check in place, better safe than sorry. > > >> > > >> Agreed; Olaf, if it is ok with you, I can fix it up and send. > > > > > > I will retest with this part reverted. I think without two code paths > > > entering hv_fcopy_callback it should be ok to leave this check in. > > > > I think hv_fcopy_callback() is not involved here: we call fcopy_on_msg() > > every time userspace daemon writes to the device and it is not anyhow > > synchronized with host-guest communication. > > An earlier variant of this patch used locks around the vmbus_recvpacket > and the result was used to decide which thread of execution notifies the > daemon. I think if the interrupt ran earlier than the daemon did the > write then the state expected in fcopy_on_msg would obviously be wrong. > As a result the daemon will just terminate with EFAULT. With the check > removed it would proceed, and either not chancel the timeout or > vmbus_recvpacket reads nothing. > > But now that it is single threaded the state in fcopy_on_msg should be > as expected. As said, will retest. Either later today or on Monday. The only case I can see is if the daemon does not respond in a timely fashion. In this case, we would timeout and terminate the transaction prematurely. In this case when the daemon ultimately responds, we would view that response as an error and return EINVAL and I think in this case it is fine to terminate the daemon; especially now that we are going to increase the timeout value to 30 seconds. Let me know the results of your testing. I will repost the patches after I hear from you. Regards, K. Y
Re: [PATCH V6] mm: memory hot-add: memory can not be added to movable zone defaultly
在 2015/10/12 9:45, Tang Chen 写道:
Hi Ishimatsu,
On 10/10/2015 02:13 AM, Yasuaki Ishimatsu wrote:
Hi Tang,
On Fri, 9 Oct 2015 15:59:38 +0800
Tang Chen wrote:
Hi,
I don't mean to offend, but I really think it is not necessary to do
this.
hot-added memory will be added to ZONE_NORMAL by default. You can
modify it when you online memory. I think it is enough for users.
But we cannot automatically create movable memory even if we use udev
rules.
Thus user must create original scrip to online memory as movable.
Do you think every user understand the rule that ZONE_NORMAL must be
on the
left side of ZONE_MOVABLE?
I think memory hotplug users should understand this.
If we can change the behavir of kernel by sysctl, user can create
movable memory by only the following udev rule.
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline",
ATTR{state}="online"
OK, that is fine. And I think it is better to add this to the commit
message.
Thanks, I will update the patch.
Thanks.
Thanks,
Yasuaki Ishimatsu
And a sysctl interface is also unnecessary. I think one default
behaviour
is enough for kernel. We'd better keep it in the current way, or
change it
and document it. It just makes no sense to enable users to modify it.
Can you please share any use case of this sysctl interface ?
I suggest just keep the current implement. But I'm OK with that if
other
reviewers or users could clarify it is useful. :)
And BTW, please don't cc the following reviewers. Their email addresses
have changed.
Cc: Zhang Yanfei
Cc: Hu Tao
Cc: Lai Jiangshan
Cc: Gu Zheng
Thanks. :)
On 10/09/2015 03:12 PM, Changsheng Liu wrote:
From: Changsheng Liu
After the user config CONFIG_MOVABLE_NODE,
When the memory is hot added, should_add_memory_movable() return 0
because all zones including movable zone are empty,
so the memory that was hot added will be added to the normal zone
and the normal zone will be created firstly.
But we want the whole node to be added to movable zone defaultly.
So we change should_add_memory_movable(): if the user config
CONFIG_MOVABLE_NODE and sysctl parameter hotadd_memory_as_movable and
the ZONE_NORMAL is empty or the pfn of the hot-added memory
is after the end of the ZONE_NORMAL it will always return 1
and all zones is empty at the same time,
so that the movable zone will be created firstly
and then the whole node will be added to movable zone defaultly.
If we want the node to be added to normal zone,
we can do it as follows:
"echo online_kernel > /sys/devices/system/memory/memoryXXX/state"
Signed-off-by: Changsheng Liu
Signed-off-by: Xiaofeng Yan
Tested-by: Dongdong Fan
Cc: Wang Nan
Cc: Zhang Yanfei
Cc: Dave Hansen
Cc: Yinghai Lu
Cc: Tang Chen
Cc: Hu Tao
Cc: Lai Jiangshan
Cc: Yasuaki Ishimatsu
Cc: Gu Zheng
Cc: Toshi Kani
Cc: Xishi Qiu
Signed-off-by: Andrew Morton
---
Documentation/memory-hotplug.txt |5 -
kernel/sysctl.c | 15 +++
mm/memory_hotplug.c | 23 +++
3 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/Documentation/memory-hotplug.txt
b/Documentation/memory-hotplug.txt
index ce2cfcf..7e6b4f4 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -277,7 +277,7 @@ And if the memory block is in ZONE_MOVABLE, you
can change it to ZONE_NORMAL:
After this, memory block XXX's state will be 'online' and the
amount of
available memory will be increased.
-Currently, newly added memory is added as ZONE_NORMAL (for
powerpc, ZONE_DMA).
+Currently, newly added memory is added as ZONE_NORMAL or
ZONE_MOVABLE (for powerpc, ZONE_DMA).
This may be changed in future.
@@ -319,6 +319,9 @@ creates ZONE_MOVABLE as following.
Size of memory not for movable pages (not for offline) is
TOTAL - .
Size of memory for movable pages (for offline) is .
+And a sysctl parameter for assigning the hot added memory to
ZONE_MOVABLE is
+supported. If the value of "kernel/hotadd_memory_as_movable" is
1,the hot added
+memory will be assigned to ZONE_MOVABLE defautly.
Note: Unfortunately, there is no information to show which
memory block belongs
to ZONE_MOVABLE. This is TBD.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 19b62b5..855c48e 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -166,6 +166,10 @@ extern int unaligned_dump_stack;
extern int no_unaligned_warning;
#endif
+#ifdef CONFIG_MOVABLE_NODE
+extern int hotadd_memory_as_movable;
+#endif
+
#ifdef CONFIG_PROC_SYSCTL
#define SYSCTL_WRITES_LEGACY-1
@@ -1139,6 +1143,17 @@ static struct ctl_table kern_table[] = {
.proc_handler= timer_migration_handler,
},
#endif
+/*If the value of "kernel/hotadd_memory_as_movable" is 1,the hot
added
+ * memory will be assigned to ZONE_MOVABLE defautly.*/
+#ifdef CONFIG_MOVABLE_NODE
+{
+.procname= "hotadd_memory_as_movable",
+.dat
Re: [PATCH 01/16] irqdomain: Use an accessor for the of_node field
On 10/07/2015 01:36 AM, Marc Zyngier wrote: The struct irq_domain contains a "struct device_node *" field (of_node) that is almost the only link between the irqdomain and the device tree infrastructure. In order to prepare for the removal of that field, convert all users to use an accessor. Signed-off-by: Marc Zyngier --- arch/arm/mach-omap2/omap-wakeupgen.c | 2 +- arch/c6x/platforms/megamod-pic.c | 2 +- arch/mips/cavium-octeon/octeon-irq.c | 4 ++-- arch/powerpc/platforms/cell/axon_msi.c| 2 +- arch/powerpc/platforms/cell/spider-pic.c | 9 +--- arch/powerpc/platforms/pasemi/msi.c | 6 -- arch/powerpc/platforms/powernv/opal-irqchip.c | 2 +- arch/powerpc/sysdev/ehv_pic.c | 3 ++- arch/powerpc/sysdev/fsl_msi.c | 2 +- arch/powerpc/sysdev/i8259.c | 3 ++- arch/powerpc/sysdev/ipic.c| 3 ++- arch/powerpc/sysdev/mpic.c| 3 ++- arch/powerpc/sysdev/mpic_msi.c| 2 +- arch/powerpc/sysdev/qe_lib/qe_ic.c| 3 ++- drivers/gpio/gpio-sodaville.c | 2 +- drivers/irqchip/exynos-combiner.c | 2 +- drivers/irqchip/irq-atmel-aic-common.c| 2 +- drivers/irqchip/irq-crossbar.c| 4 ++-- drivers/irqchip/irq-gic-v2m.c | 2 +- drivers/irqchip/irq-gic-v3-its.c | 2 +- drivers/irqchip/irq-gic-v3.c | 2 +- drivers/irqchip/irq-gic.c | 2 +- drivers/irqchip/irq-hip04.c | 2 +- drivers/irqchip/irq-imx-gpcv2.c | 2 +- drivers/irqchip/irq-mtk-sysirq.c | 2 +- drivers/irqchip/irq-s3c24xx.c | 4 ++-- drivers/irqchip/irq-tegra.c | 4 ++-- drivers/irqchip/irq-vf610-mscm-ir.c | 5 +++-- drivers/spmi/spmi-pmic-arb.c | 2 +- include/linux/irqdomain.h | 5 + kernel/irq/irqdomain.c| 30 +++ 31 files changed, 74 insertions(+), 46 deletions(-) Some missing files I noticed: ./arch/arm/mach-imx/gpc.c: if (domain->of_node != controller) ./arch/arm/mach-imx/gpc.c: parent_args.np = domain->parent->of_node; ./arch/arm/mach-exynos/suspend.c: if (domain->of_node != controller) ./arch/arm/mach-exynos/suspend.c: parent_args.np = domain->parent->of_node; 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: [PATCH] ARM:mm: fix kmap_atomic_to_page
> On Oct 6, 2015, at 19:09, Chanho Min wrote:
>
> Since kmap_atomic returns the pkmap address without a new mapping to
> fixmap for the page that is already mapped by kmap, It should be
> considered for the pkmap address in kmap_atomic_to_page.
>
> Signed-off-by: Chanho Min
> ---
> arch/arm/mm/highmem.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
> index 45aeaac..3e973b7 100644-
> --- a/arch/arm/mm/highmem.c
> +++ b/arch/arm/mm/highmem.c
> @@ -145,8 +145,13 @@ struct page *kmap_atomic_to_page(const void *ptr)
> {
> unsigned long vaddr = (unsigned long)ptr;
>
> - if (vaddr < FIXADDR_START)
> - return virt_to_page(ptr);
> + if (vaddr >= PKMAP_ADDR(0) && vaddr < PKMAP_ADDR(LAST_PKMAP)) {
> + int i = PKMAP_NR(vaddr);
> + return pte_page(pkmap_page_table[i]);
> + }
> +
> + if (vaddr >= FIXADDR_START)
> + return pte_page(get_fixmap_pte(vaddr));
>
> - return pte_page(get_fixmap_pte(vaddr));
> + return virt_to_page(ptr);
> }
> --
> 1.7.9.5
>
why not change like this,
more simple :
diff --git a/arch/arm/mm/highmem.c b/arch/arm/mm/highmem.c
index 9df5f09..4eeed3d 100644
--- a/arch/arm/mm/highmem.c
+++ b/arch/arm/mm/highmem.c
@@ -152,8 +152,7 @@ struct page *kmap_atomic_to_page(const void *ptr)
{
unsigned long vaddr = (unsigned long)ptr;
- if (vaddr < FIXADDR_START)
- return virt_to_page(ptr);
-
- return pte_page(get_fixmap_pte(vaddr));
+ if (vaddr >= FIXADDR_START && vaddr <= FIXADDR_TOP)
+ return pte_page(get_fixmap_pte(vaddr));
+ return kmap_to_page(ptr);
}
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: mouse event for unknown monitor - uinput?
Hi, On Mon, Oct 12, 2015 at 06:39:35AM +0200, poma wrote: > Hi Fi > > https://bugzilla.redhat.com/show_bug.cgi?id=1269667 > > Guys, can you help clarify, can this be a problem of the uinput after all? > There was a regression in uinput code, you need to make sure you have commit 72d4736253af74147b1fa68145b2f4c61d1f37e1 Thanks. -- Dmitry -- 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 1/2] arm: berlin: use non-self-cleared reset register to reset cpu
Dear Sebastian, On Mon, 21 Sep 2015 10:18:25 +0800 Jisheng Zhang wrote: > Dear Sebastian, > > On Sun, 20 Sep 2015 20:04:01 +0200 > Sebastian Hesselbarth wrote: > > > On 14.09.2015 08:47, Jisheng Zhang wrote: > > > In Berlin SoCs, there are two kinds of cpu reset control registers: the > > > first one's corresponding bits will be self-cleared after some cycles, > > > while the second one's bits won't. Previously the first kind of reset > > > control register is used, this patch uses the second kind one to prepare > > > for the next hotplug commit. > > > > > > Signed-off-by: Jisheng Zhang > > > --- > > > arch/arm/mach-berlin/platsmp.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/arch/arm/mach-berlin/platsmp.c > > > b/arch/arm/mach-berlin/platsmp.c > > > index 34a3753..bde327b 100644 > > > --- a/arch/arm/mach-berlin/platsmp.c > > > +++ b/arch/arm/mach-berlin/platsmp.c > > > @@ -17,7 +17,7 @@ > > > #include > > > #include > > > > > > -#define CPU_RESET0x00 > > > +#define CPU_RESET0x20 > > > > Jisheng, > > > > I am fine with the patch itself, except that I'd like to rather > > rename the 0x00-register to CPU_RESET_SC with a comment about > > the self-clearing nature. The 0x20-register would then be named > > CPU_RESET_NON_SC and used the way you propose. > > Good idea. And such comment would let people understand why do we change > as that. > > > > > Are you fine with me naming the registers accordingly while > > applying the patches? > > Sure, I'm fine. Thank you very much. I found these two patches are missing in your round 1 berlin pull request. Do you want me send v2 patches applying the above changes you suggested? Thanks, Jisheng > > > > > Sebastian > > > > > #define RESET_VECT 0x00 > > > #define SW_RESET_ADDR 0x94 > > > @@ -31,6 +31,8 @@ static inline void berlin_perform_reset_cpu(unsigned > > > int cpu) > > > u32 val; > > > > > > val = readl(cpu_ctrl + CPU_RESET); > > > + val &= ~BIT(cpu_logical_map(cpu)); > > > + writel(val, cpu_ctrl + CPU_RESET); > > > val |= BIT(cpu_logical_map(cpu)); > > > writel(val, cpu_ctrl + CPU_RESET); > > > } > > > > > > -- 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 v10 24/46] xfs: Add richacl support
On Mon, Oct 12, 2015 at 6:05 AM, Dave Chinner wrote:
> On Mon, Oct 12, 2015 at 03:51:15AM +0200, Andreas Grünbacher wrote:
>> 2015-10-12 2:10 GMT+02:00 Dave Chinner :
>> > On Mon, Oct 12, 2015 at 12:58:35AM +0200, Andreas Gruenbacher wrote:
>> >> diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig
>> >> index 5d47b4d..05dd312 100644
>> >> --- a/fs/xfs/Kconfig
>> >> +++ b/fs/xfs/Kconfig
>> >> @@ -52,6 +52,17 @@ config XFS_POSIX_ACL
>> >>
>> >> If you don't know what Access Control Lists are, say N.
>> >>
>> >> +config XFS_RICHACL
>> >> +bool "XFS Rich Access Control Lists (EXPERIMENTAL)"
>> >> +depends on XFS_FS
>> >> +select FS_RICHACL
>> >> +help
>> >> + Richacls are an implementation of NFSv4 ACLs, extended by file
>> >> masks
>> >> + to cleanly integrate into the POSIX file permission model. To
>> >> learn
>> >> + more about them, see http://www.bestbits.at/richacl/.
>> >> +
>> >> + If you don't know what Richacls are, say N.
>> >> +
>> >
>> > So now we have multiple compile time ACL configs that we have to
>> > test. Personally, I see no reason for making either posix or rich
>> > acls compile time dependent. How about we just change CONFIG_FS_XFS
>> > to have "select FS_POSIX_ACL" and "select FS_RICHACL"
>> > unconditionally, and then we can get rid of all the conditional
>> > code?
>>
>> I'm sure neither kind of ACLs makes sense on many tiny systems, it
>> should be possible to disable them. XFS may not make sense on those
>> kinds of systems either, that is not my call to make though.
>
> Well, the smallest systems that use XFS are typically 1-2 disk NAS
> boxes, and I can see them wanting richacls. As it is, the xfs kernel
> module is almost 1MB of object code, so it you have a small embedded
> box you don't want XFS. Almost all distros turn on ACL support I'm
> not sure that it makes sense to have these config options in XFS
> anymore
You have me convinced about removing CONFIG_XFS_RICHACL.
>> >> diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.h
>> >> index 9590a06..8c6da45 100644
>> >> --- a/fs/xfs/libxfs/xfs_format.h
>> >> +++ b/fs/xfs/libxfs/xfs_format.h
>> >> @@ -461,10 +461,18 @@ xfs_sb_has_ro_compat_feature(
>> >> #define XFS_SB_FEAT_INCOMPAT_FTYPE (1 << 0)/* filetype in
>> >> dirent */
>> >> #define XFS_SB_FEAT_INCOMPAT_SPINODES(1 << 1)/* sparse
>> >> inode chunks */
>> >> #define XFS_SB_FEAT_INCOMPAT_META_UUID (1 << 2)/* metadata
>> >> UUID */
>> >> +
>> >> +#ifdef CONFIG_XFS_RICHACL
>> >> +#define XFS_SB_FEAT_INCOMPAT_RICHACL (1 << 3)/* richacls */
>> >> +#else
>> >> +#define XFS_SB_FEAT_INCOMPAT_RICHACL 0
>> >> +#endif
>> >> +
>> >
>> > Regardless of whether we build in richacl support, this is wrong.
>> > Feature bits are on-disk format definitions, so it will always have
>> > this value whether or not the kernel supports the feature.
>>
>> This is so that xfs_mount_validate_sb() will complain when mounting a
>> richacl filesystem on a kernel which doesn't have richacl suport
>> compiled in. The same effect can be had with extra code there of
>> course.
>
> If the kernel doesn't know about a feature, then it will report
> "unknown feature". However, as of this patch set, the kernel will
> know about the richacl feature, and so the correct error message
> is to say "Rich ACLs not supported by this kernel".
>
> Also, from a disk format perspective, this is a this is a read-only
> compat feature, as kernels that don't have richacl support are still
> able to mount and walk the filesystem without errors occurring. It's
> only when allowing modifications are made that problems will arise,
> so why did you make it an incompat feature?
As a read-only compat flag, kernels that cannot enforce richacls would
still be able to mount richacl file systems read-only. That's a
problem when acls are used to forbid read/execute access.
>> >> +int
>> >> +xfs_set_richacl(struct inode *inode, struct richacl *acl)
>> >> +{
>> >> + struct xfs_inode *ip = XFS_I(inode);
>> >> + umode_t mode = inode->i_mode;
>> >> + int error;
>> >> +
>> >> + if (acl) {
>> >> + /* Don't allow acls with unmapped identifiers. */
>> >> + if (richacl_has_unmapped_identifiers(acl))
>> >> + return -EINVAL;
>> >> +
>> >> + if (richacl_equiv_mode(acl, &mode) == 0) {
>> >> + xfs_set_mode(inode, mode);
>> >> + acl = NULL;
>> >> + }
>> >
>> > Comment needed here - why does this now seem to accidentally fall
>> > through to removing the ACL?
>>
>> Setting an ACL that is equivalent to a file mode is the same as
>> removing any existing ACLs and doing a chmod to that equivalent file
>> mode. It's the sams as with POSIX ACLs, and the code is the same as
>> well. I'll add a comment though.
>>
>> > Also, why is this in the XFS specific
>> > code when it's generic richacl func
[PATCH 0/5] fix sdhci-pxav3 clock name and berlin clk clean up
The sdhci-pxav3's clock name isn't correct. The current "io" clock is really the PXAv3 SDHCI IP's "core" clock which is manadatory. The current "core" clock is really the IP's "axi" clock which is optional. We fix this in patch1. The following patches add the axi clock properties to bg2q dtsi, then remove the CLK_IGNORE_UNUSED flag for sdio clk(s). Jisheng Zhang (5): mmc: sdhci-pxav3: fix optional clock name ARM: dts: berlin: correct BG2Q's sdhci2 axi clock ARM: dts: berlin: add axi clock for BG2Q sdhci0 and sdhci1 clk: berlin: bg2q: remove CLK_IGNORE_UNUSED flag for sdio clk clk: berlin: bg2: remove CLK_IGNORE_UNUSED flag for sdio clk .../devicetree/bindings/mmc/sdhci-pxa.txt | 8 ++--- arch/arm/boot/dts/berlin2.dtsi | 6 ++-- arch/arm/boot/dts/berlin2cd.dtsi | 2 +- arch/arm/boot/dts/berlin2q.dtsi| 10 +++--- drivers/clk/berlin/bg2.c | 4 +-- drivers/clk/berlin/bg2q.c | 2 +- drivers/mmc/host/sdhci-pxav3.c | 40 +++--- 7 files changed, 37 insertions(+), 35 deletions(-) -- 2.6.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 2/5] ARM: dts: berlin: correct BG2Q's sdhci2 axi clock
The optional axi clock is CLKID_SDIO. Signed-off-by: Jisheng Zhang --- arch/arm/boot/dts/berlin2q.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi index 4ad585c..2f12048 100644 --- a/arch/arm/boot/dts/berlin2q.dtsi +++ b/arch/arm/boot/dts/berlin2q.dtsi @@ -119,7 +119,7 @@ compatible = "mrvl,pxav3-mmc"; reg = <0xab1000 0x200>; interrupts = ; - clocks = <&chip_clk CLKID_NFC_ECC>, <&chip_clk CLKID_NFC>; + clocks = <&chip_clk CLKID_NFC_ECC>, <&chip_clk CLKID_SDIO>; clock-names = "core", "axi"; status = "disabled"; }; -- 2.6.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 4/5] clk: berlin: bg2q: remove CLK_IGNORE_UNUSED flag for sdio clk
Since we have added the necessary axi clk properties in dts, we can
remove the "sdio" clk's CLK_IGNORE_UNUSED flag now.
Signed-off-by: Jisheng Zhang
---
drivers/clk/berlin/bg2q.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/berlin/bg2q.c b/drivers/clk/berlin/bg2q.c
index 221f40c..243f421 100644
--- a/drivers/clk/berlin/bg2q.c
+++ b/drivers/clk/berlin/bg2q.c
@@ -283,7 +283,7 @@ static const struct berlin2_gate_data bg2q_gates[]
__initconst = {
{ "usb2", "perif",13 },
{ "usb3", "perif",14 },
{ "pbridge","perif",15, CLK_IGNORE_UNUSED },
- { "sdio", "perif",16, CLK_IGNORE_UNUSED },
+ { "sdio", "perif",16 },
{ "nfc","perif",18 },
{ "pcie", "perif",22 },
};
--
2.6.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/5] ARM: dts: berlin: add axi clock for BG2Q sdhci0 and sdhci1
Add the axi clock for BG2Q's sdhci0 and sdhci1. This would let the axi
clock be disabled during runtime pm, so saves power a bit.
Signed-off-by: Jisheng Zhang
---
arch/arm/boot/dts/berlin2q.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 2f12048..a14c9e8 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -102,7 +102,8 @@
sdhci0: sdhci@ab {
compatible = "mrvl,pxav3-mmc";
reg = <0xab 0x200>;
- clocks = <&chip_clk CLKID_SDIO1XIN>;
+ clocks = <&chip_clk CLKID_SDIO1XIN>, <&chip_clk
CLKID_SDIO>;
+ clock-names = "core", "axi";
interrupts = ;
status = "disabled";
};
@@ -110,7 +111,8 @@
sdhci1: sdhci@ab0800 {
compatible = "mrvl,pxav3-mmc";
reg = <0xab0800 0x200>;
- clocks = <&chip_clk CLKID_SDIO1XIN>;
+ clocks = <&chip_clk CLKID_SDIO1XIN>, <&chip_clk
CLKID_SDIO>;
+ clock-names = "core", "axi";
interrupts = ;
status = "disabled";
};
--
2.6.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/5] mmc: sdhci-pxav3: fix optional clock name
Commit 8afdc9cca27f ("mmc: sdhci-pxav3: Get optional core clock") adds
additional optional clock support, but the clock names isn't correct.
The current "io" clock is really the PXAv3 SDHCI IP's "core" clock
which is manadatory. The current "core" clock is really the IP's "axi"
clock which is optional.
Signed-off-by: Jisheng Zhang
---
.../devicetree/bindings/mmc/sdhci-pxa.txt | 8 ++---
arch/arm/boot/dts/berlin2.dtsi | 6 ++--
arch/arm/boot/dts/berlin2cd.dtsi | 2 +-
arch/arm/boot/dts/berlin2q.dtsi| 2 +-
drivers/mmc/host/sdhci-pxav3.c | 40 +++---
5 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index 3d1b449..25d5ba8 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -17,9 +17,9 @@ Required properties:
- reg names: should be "sdhci", "mbus", "conf-sdio3". only mandatory
for "marvell,armada-380-sdhci"
- clocks: Array of clocks required for SDHCI; requires at least one for
-I/O clock.
+core clock.
- clock-names: Array of names corresponding to clocks property; shall be
-"io" for I/O clock and "core" for optional core clock.
+"core" for core clock and "axi" for optional axi clock.
Optional properties:
- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
@@ -32,7 +32,7 @@ sdhci@d4280800 {
bus-width = <8>;
interrupts = <27>;
clocks = <&chip CLKID_SDIO1XIN>, <&chip CLKID_SDIO1>;
- clock-names = "io", "core";
+ clock-names = "core", "axi";
non-removable;
mrvl,clk-delay-cycles = <31>;
};
@@ -45,6 +45,6 @@ sdhci@d8000 {
<0x18454 0x4>;
interrupts = <0 25 0x4>;
clocks = <&gateclk 17>;
- clock-names = "io";
+ clock-names = "core";
mrvl,clk-delay-cycles = <0x1F>;
};
diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index ef811de..9d0a945 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi
@@ -85,7 +85,7 @@
compatible = "mrvl,pxav3-mmc";
reg = <0xab 0x200>;
clocks = <&chip_clk CLKID_SDIO0XIN>, <&chip_clk
CLKID_SDIO0>;
- clock-names = "io", "core";
+ clock-names = "core", "axi";
interrupts = ;
status = "disabled";
};
@@ -94,7 +94,7 @@
compatible = "mrvl,pxav3-mmc";
reg = <0xab0800 0x200>;
clocks = <&chip_clk CLKID_SDIO1XIN>, <&chip_clk
CLKID_SDIO1>;
- clock-names = "io", "core";
+ clock-names = "core", "axi";
interrupts = ;
status = "disabled";
};
@@ -104,7 +104,7 @@
reg = <0xab1000 0x200>;
interrupts = ;
clocks = <&chip_clk CLKID_NFC_ECC>, <&chip_clk
CLKID_NFC>;
- clock-names = "io", "core";
+ clock-names = "core", "axi";
pinctrl-0 = <&emmc_pmux>;
pinctrl-names = "default";
status = "disabled";
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 900213d..11498ad 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -82,7 +82,7 @@
compatible = "mrvl,pxav3-mmc";
reg = <0xab 0x200>;
clocks = <&chip_clk CLKID_SDIO0XIN>, <&chip_clk
CLKID_SDIO0>;
- clock-names = "io", "core";
+ clock-names = "core", "axi";
interrupts = ;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 63a4849..4ad585c 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -120,7 +120,7 @@
reg = <0xab1000 0x200>;
interrupts = ;
clocks = <&chip_clk CLKID_NFC_ECC>, <&chip_clk
CLKID_NFC>;
- clock-names = "io", "core";
+ clock-names = "core", "axi";
status = "disabled";
};
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index f5edf9d..cec95f1 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -59,8 +59,8 @@
#define SDCE_MISC_INT_EN (1<<1)
struct sdhci_pxa {
+ struct clk *clk_axi;
struct clk *clk_core;
- struct clk *clk_io;
[PATCH 5/5] clk: berlin: bg2: remove CLK_IGNORE_UNUSED flag for sdio clk
The axi clock properties already exists, so there's no need to set this
flag for sdio0 and sdio1 clk any more.
Signed-off-by: Jisheng Zhang
---
drivers/clk/berlin/bg2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/berlin/bg2.c b/drivers/clk/berlin/bg2.c
index 73153fc..23e0e3b 100644
--- a/drivers/clk/berlin/bg2.c
+++ b/drivers/clk/berlin/bg2.c
@@ -490,8 +490,8 @@ static const struct berlin2_gate_data bg2_gates[]
__initconst = {
{ "usb0", "perif",11 },
{ "usb1", "perif",12 },
{ "pbridge","perif",13, CLK_IGNORE_UNUSED },
- { "sdio0", "perif",14, CLK_IGNORE_UNUSED },
- { "sdio1", "perif",15, CLK_IGNORE_UNUSED },
+ { "sdio0", "perif",14 },
+ { "sdio1", "perif",15 },
{ "nfc","perif",17 },
{ "smemc", "perif",19 },
{ "audiohd","audiohd_pll", 26 },
--
2.6.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 2/3] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
On 12.10.2015 13:42, Krzysztof Kozlowski wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> Added support for vmmc/vqmmc-supply for emmc/sd cards.
>> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
>
> I can't see the description of a problem which is fixed. If you fix
> something, then please describe what is wrong.
>
>> Added ramp-delay for LDO9(VDD33_USB3_0).
>> Added ramp-delay for LDO13(VDDQ_MMC2).
>> Added ramp-delay for LDO15(ETH_P3V3).
>>
>> Signed-off-by: Anand Moon
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>>
>> Note:
>> Changes need for support of UHS-I highspeed cards.
>> changes for vqmmc-supply for emmc is not supported.
>>
>> [1.831136] vdd_ldo9: ramp_delay not set
>> [1.843049] vdd_ldo13: ramp_delay not set
>> [1.850975] vdd_ldo15: ramp_delay not set
>> [1.862816] vdd_sd: ramp_delay not set
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 26decbd..58c06d3 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -157,6 +157,7 @@
>> regulator-min-microvolt = <300>;
>> regulator-max-microvolt = <300>;
>> regulator-always-on;
>> +regulator-ramp-delay = <12000>;
>> };
>>
>> ldo10_reg: LDO10 {
>> @@ -182,9 +183,10 @@
>>
>> ldo13_reg: LDO13 {
>> regulator-name = "vdd_ldo13";
>> -regulator-min-microvolt = <280>;
>> +regulator-min-microvolt = <180>;
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> +regulator-ramp-delay = <12000>;
>> };
>>
>> ldo15_reg: LDO15 {
>> @@ -213,6 +215,7 @@
>> regulator-min-microvolt = <280>;
>> regulator-max-microvolt = <280>;
>> regulator-always-on;
>> +regulator-ramp-delay = <12000>;
>
> Where did you get this value from? It looks wrong... My datasheet does
> not have 12000 uV/uS.
Anand,
We have actually been here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/351601.html
That time you used 8000. I asked the same question - how did you figure
out the exact value.
Now we have the same question - why 12000?
It is completely fine to make a mistake (I do a lot of them) but please
try not to make the same mistake again.
BR,
Krzysztof
>
>> };
>>
>> ldo24_reg: LDO24 {
>> @@ -338,6 +341,7 @@
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> samsung,dw-mshc-hs400-timing = <0 2>;
>> samsung,read-strobe-delay = <90>;
>> +vmmc-supply = <&ldo3_reg>;
>> pinctrl-names = "default";
>> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8 &sd0_cd
>> &sd0_rclk>;
>> bus-width = <8>;
>> @@ -352,6 +356,8 @@
>> samsung,dw-mshc-ciu-div = <3>;
>> samsung,dw-mshc-sdr-timing = <0 4>;
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> +vmmc-supply = <&ldo19_reg>;
>> +vqmmc-supply = <&ldo13_reg>;
>
> It looks wrong. LDO13 is used in one place as VQMMC and in other as
> VMMC. How did you figure out which regulator supplies which power domain?
>
> Best regards,
> Krzysztof
>
>> cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
>> cd-inverted;
>> pinctrl-names = "default";
>>
>
>
--
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] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support
On 12.10.2015 00:46, Anand Moon wrote:
> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s (SDR104)
This description is not entirely correct. The MMC driver already
supports these UHS speeds (you did not any code) so you rather enabled
it (description of bindings says "is supported").
You mentioned DDR50 but I don't see respective property below.
How do you know that these modes are really supported? I don't know. Can
you convince me?
>
> Signed-off-by: Anand Moon
>
> ---
> Changes based on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v4.4-next/dt-samsung branch
>
> Changes Fixed the UHS-I bus speed detedtion on cold boot.
I don't get what is exactly fixed here. What was the error? What is the
outcome of this fix? The log below is before or after?
Best regards,
Krzysztof
>
> [2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
> 1Hz, actual 1HZ div = 0)
> [2.449729] mmc1: new ultra high speed SDR50 SDHC card at address
> [2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
> [2.461743] mmcblk0: p1 p2
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 58c06d3..ba4a87b 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -364,6 +364,10 @@
> pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
> bus-width = <4>;
> cap-sd-highspeed;
> + sd-uhs-sdr12;
> + sd-uhs-sdr25;
> + sd-uhs-sdr50;
> + sd-uhs-sdr104;
> };
>
> &pinctrl_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/
Re: [PATCH 4/5] regulator: of: add missing of_node_put
On Mon, 12 Oct 2015, Krzysztof Kozlowski wrote:
> 2015-10-10 21:30 GMT+09:00 Julia Lawall :
> >
> > for_each_child_of_node performs an of_node_get on each iteration, so
> > a break out of the loop requires an of_node_put.
> >
> > The semantic patch that fixes this problem is as follows
> > (http://coccinelle.lip6.fr):
> >
> > //
> > @@
> > expression root,e;
> > local idexpression child;
> > @@
> >
> > for_each_child_of_node(root, child) {
> >... when != of_node_put(child)
> >when != e = child
> > (
> >return child;
> > |
> > + of_node_put(child);
> > ? return ...;
> > )
> >...
> > }
> > //
> >
> > Signed-off-by: Julia Lawall
> >
> > ---
> > drivers/regulator/of_regulator.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/regulator/of_regulator.c
> > b/drivers/regulator/of_regulator.c
> > index 499e437..f9d77b4 100644
> > --- a/drivers/regulator/of_regulator.c
> > +++ b/drivers/regulator/of_regulator.c
> > @@ -274,6 +274,7 @@ int of_regulator_match(struct device *dev, struct
> > device_node *node,
> > dev_err(dev,
> > "failed to parse DT for regulator
> > %s\n",
> > child->name);
> > + of_node_put(child);
>
> This looks good.
>
> > return -EINVAL;
> > }
> > match->of_node = of_node_get(child);
>
> But what about 'break' few lines below? The reference from last
> of_get_next_child() should be also dropped because... or we should
> remove this of_node_get() call.
>
> How about fixing also usage of for_each_available_child_of_node() in
> regulator_of_get_init_data()?
I'll check on all of this and resend. Thanks for the feedback.
julia
--
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] ARM:mm: fix kmap_atomic_to_page
We tried to utilize a HW compressor as a zram backend. Current zram uses kmap_atomic to map a page, and the HW DMAes. So we needed to use kmap_atomic_to_page to get the page to be dma-mapped. On 10/07/2015 06:01 PM, Russell King - ARM Linux wrote: > On Wed, Oct 07, 2015 at 12:55:08PM +0900, Jongsung Kim wrote: >> Recently, we made a driver utilizing kmap_atomic_to_page. Of course, >> it's not mainlined. People may be using it outside mainline just like us. > Since kmap_atomic() mappings are supposed to be short-lived, why do you > need it in your driver? Don't you already have the struct page pointer > when setting up the kmap_atomic() mapping? > > It is invalid to setup a mapping, and leave it setup across any context > switching or similar. > > Also, kmap_atomic_to_page() is not exported to modules, so you can only > use it when built-in. > >> vmalloc has vmalloc_to_page, pkmap has kmap_to page, and fixmap has >> kmap_atomic_to_page. Then.. how about letting virt_to_page do them all? > No. virt_to_page() is defined to only work on the lowmem mapping, and > that's not going to change. > > Please show the outline of your code making use of this function so we > can better understand your use case. > -- 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] powerpc/mpc5xxx: Use of_get_next_parent to simplify code
Le 11/10/2015 22:44, Julia Lawall a écrit : of_get_next_parent can be used to simplify the while() loop and avoid the need of a temp variable. Can you do something with the loop in __of_translate_address, in drivers/of/address.c? Is there not an iterator for this? julia Hi Julia, There does not seem to be any 'for_each_parent_of_node' or equivalent. Best regards, CJ -- 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: bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )
On Sun, Oct 11, 2015 at 7:58 PM, Pranith Kumar wrote: > > > ../linux-firmware-image-4.3.0-rc4_4.3.0-rc4-7_powerpc.deb: No such > file or directory > scripts/package/Makefile:97: recipe for target 'bindeb-pkg' failed > make[1]: *** [bindeb-pkg] Error 2 > Makefile:1226: recipe for target 'bindeb-pkg' failed > make: *** [bindeb-pkg] Error 2 So this is a build on a ppc system? What's the distro? I've checked that bindeb-pkg works fine with 4.3-rc4 on Ubuntu 15.04 with the amd64 architecture, but that's probably not much consolation. -- Jim -- 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] md: fix 32-bit build warning
Arnd Bergmann writes:
> On 32-bit architectures, the md code produces this warning when CONFIG_LDAF
> is set:
>
> drivers/md/md.c: In function 'check_sb_changes':
> drivers/md/md.c:8990:10: warning: format '%lu' expects argument of type 'long
> unsigned int', but argument 4 has type 'sector_t {aka long long unsigned
> int}' [-Wformat=]
>pr_info("%s:%d recovery_cp changed from %lu to %lu\n", __func__,
>
> The code was only recently introduced, and uses the wrong format string
> for sector_t. As a workaround, this patch adds an explicit cast to 'u64'
> so we can use the %llu format string on all architectures.
>
> Signed-off-by: Arnd Bergmann
> Fixes: e0212320066e ("md-cluster: Improve md_reload_sb to be less error
> prone")
> Cc: Goldwyn Rodrigues
> ---
>
> I also noticed that some commmits in md/for-next including the one causing
> the problem lack a Signed-off-by line. It might make sense to just fold this
> patch and add the lines at the same time.
>
> diff --git a/drivers/md/md.c b/drivers/md/md.c
> index 7fff1e6884d6..e13f72a3b561 100644
> --- a/drivers/md/md.c
> +++ b/drivers/md/md.c
> @@ -8987,9 +8987,9 @@ static void check_sb_changes(struct mddev *mddev,
> struct md_rdev *rdev)
>
> /* recovery_cp changed */
> if (le64_to_cpu(sb->resync_offset) != mddev->recovery_cp) {
> - pr_info("%s:%d recovery_cp changed from %lu to %lu\n", __func__,
> - __LINE__, mddev->recovery_cp,
> - (unsigned long) le64_to_cpu(sb->resync_offset));
> + pr_info("%s:%d recovery_cp changed from %llu to %llu\n",
> __func__,
> + __LINE__, (u64)mddev->recovery_cp,
> + (u64) le64_to_cpu(sb->resync_offset));
> mddev->recovery_cp = le64_to_cpu(sb->resync_offset);
> }
>
Thanks, but is this really right?
I think u64 is "unsigned long" on 64bit.
I have always used (unsigned long long) when I want to use %llu on
sector_t.
How confident are you of using "u64" ?
Thanks,
NeilBrown
signature.asc
Description: PGP signature
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
Hi,
On 10/12/2015 01:29 PM, Krzysztof Kozlowski wrote:
> On 12.10.2015 00:46, Anand Moon wrote:
>> From: Jaehoon Chung
>>
>> To detect sd-card use the cd-gpio method.
>> It can decrease the interrupt for detecting sd-card.
>>
>> Signed-off-by: Jaehoon Chung
>> Signed-off-by: Anand Moon
>>
>> ---
>> Changes based on
>> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
>> v4.4-next/dt-samsung branch
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 1af5bdc..26decbd 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -352,8 +352,10 @@
>> samsung,dw-mshc-ciu-div = <3>;
>> samsung,dw-mshc-sdr-timing = <0 4>;
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> +cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
>> +cd-inverted;
>> pinctrl-names = "default";
>> -pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
>> +pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
Don't do change this.
>
> Anand,
>
> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
> pad correctly for Exynos5420 boards"). Why? There is no explanation in
> the commit message about this.
I don't remember to send the patch relevant to this. Hmm...
Well, Is this patch really signed-off by me?
Best Regards,
Jaehoon Chung
>
> Best regards,
> Krzysztof
>
>
--
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] ARM: dts: use vmmc-supply of emmc/sd for exynos5422-odroidxu3
On 12.10.2015 00:46, Anand Moon wrote:
> Added support for vmmc/vqmmc-supply for emmc/sd cards.
> Fixed the min values for regulator ldo13_reg (VDDQ_MMC2).
I can't see the description of a problem which is fixed. If you fix
something, then please describe what is wrong.
> Added ramp-delay for LDO9(VDD33_USB3_0).
> Added ramp-delay for LDO13(VDDQ_MMC2).
> Added ramp-delay for LDO15(ETH_P3V3).
>
> Signed-off-by: Anand Moon
>
> ---
> Changes based on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v4.4-next/dt-samsung branch
>
> Note:
> Changes need for support of UHS-I highspeed cards.
> changes for vqmmc-supply for emmc is not supported.
>
> [1.831136] vdd_ldo9: ramp_delay not set
> [1.843049] vdd_ldo13: ramp_delay not set
> [1.850975] vdd_ldo15: ramp_delay not set
> [1.862816] vdd_sd: ramp_delay not set
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 26decbd..58c06d3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -157,6 +157,7 @@
> regulator-min-microvolt = <300>;
> regulator-max-microvolt = <300>;
> regulator-always-on;
> + regulator-ramp-delay = <12000>;
> };
>
> ldo10_reg: LDO10 {
> @@ -182,9 +183,10 @@
>
> ldo13_reg: LDO13 {
> regulator-name = "vdd_ldo13";
> - regulator-min-microvolt = <280>;
> + regulator-min-microvolt = <180>;
> regulator-max-microvolt = <280>;
> regulator-always-on;
> + regulator-ramp-delay = <12000>;
> };
>
> ldo15_reg: LDO15 {
> @@ -213,6 +215,7 @@
> regulator-min-microvolt = <280>;
> regulator-max-microvolt = <280>;
> regulator-always-on;
> + regulator-ramp-delay = <12000>;
Where did you get this value from? It looks wrong... My datasheet does
not have 12000 uV/uS.
> };
>
> ldo24_reg: LDO24 {
> @@ -338,6 +341,7 @@
> samsung,dw-mshc-ddr-timing = <0 2>;
> samsung,dw-mshc-hs400-timing = <0 2>;
> samsung,read-strobe-delay = <90>;
> + vmmc-supply = <&ldo3_reg>;
> pinctrl-names = "default";
> pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus1 &sd0_bus4 &sd0_bus8 &sd0_cd
> &sd0_rclk>;
> bus-width = <8>;
> @@ -352,6 +356,8 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + vmmc-supply = <&ldo19_reg>;
> + vqmmc-supply = <&ldo13_reg>;
It looks wrong. LDO13 is used in one place as VQMMC and in other as
VMMC. How did you figure out which regulator supplies which power domain?
Best regards,
Krzysztof
> cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
> cd-inverted;
> pinctrl-names = "default";
>
--
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/
mouse event for unknown monitor - uinput?
Hi Fi https://bugzilla.redhat.com/show_bug.cgi?id=1269667 Guys, can you help clarify, can this be a problem of the uinput after all? -- 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 v4 18/26] ARM: pxa: magician: Add support for ADS7846
Dne 3.10.2015 v 14:49 Philipp Zabel napsal(a):
> Am Montag, den 28.09.2015, 23:38 +0200 schrieb Petr Cvek:
>> Add support for an ADS7846 touchscreen.
>
> It's actually a TSC2045.
2046..., but I will mention it in next commit message (it was name of the
driver).
>
>> Signed-off-by: Petr Cvek
>> ---
>> arch/arm/mach-pxa/magician.c | 86
>>
>> 1 file changed, 86 insertions(+)
>>
>> diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach
>> -pxa/magician.c
>> index af8133a..450f35f 100644
>> --- a/arch/arm/mach-pxa/magician.c
>> +++ b/arch/arm/mach-pxa/magician.c
>> @@ -28,6 +28,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -44,6 +45,10 @@
>> #include
>> #include
>>
>> +#include
>> +#include
>> +#include
>> +
>> #include "devices.h"
>> #include "generic.h"
>>
>> @@ -748,6 +753,37 @@ static struct platform_device bq24022 = {
>> };
>>
>> /*
>> + * fixed regulator for ads7846
>> + */
>> +
>> +static struct regulator_consumer_supply ads7846_supply =
>> +REGULATOR_SUPPLY("vcc", "spi2.0");
>> +
>> +static struct regulator_init_data vads7846_regulator = {
>> +.constraints = {
>> +.valid_ops_mask = REGULATOR_CHANGE_STATUS,
>> +},
>> +.num_consumer_supplies = 1,
>> +.consumer_supplies = &ads7846_supply,
>> +};
>> +
>> +static struct fixed_voltage_config vads7846 = {
>> +.supply_name= "vads7846",
>> +.microvolts = 330, /* probably */
>
> I agree.
>
>> +.gpio = -EINVAL,
>> +.startup_delay = 0,
>> +.init_data = &vads7846_regulator,
>> +};
>> +
>> +static struct platform_device vads7846_device = {
>> +.name = "reg-fixed-voltage",
>> +.id = 1,
>> +.dev= {
>> +.platform_data = &vads7846,
>> +},
>> +};
>> +
>> +/*
>> * MMC/SD
>> */
>>
>> @@ -879,6 +915,51 @@ static struct i2c_pxa_platform_data
>> magician_i2c_power_info = {
>> };
>>
>> /*
>> + * Touchscreen
>> + */
>> +
>> +static struct ads7846_platform_data ads7846_pdata = {
>> +.model = 7846,
>> +.x_min = 0,
>> +.y_min = 0,
>> +.x_max = 4096,
>> +.y_max = 4096,
>> +.x_plate_ohms = 180, /* for pressure
>> in 0-255 */
>> +.y_plate_ohms = 180,
>> +.pressure_max = 255, /* up to 12bit
>> sampling */
>> +.debounce_max = 10,
>> +.debounce_tol = 3,
>> +.debounce_rep = 1,
>> +.gpio_pendown = GPIO115_MAGICIAN_nPEN_IRQ,
>> +.keep_vref_on = 1,/* FIXME, external
>> Vref? */
>> +.vref_delay_usecs = 100,
>> +/* .wait_for_sync, GPIO77_LCD_BIAS low noise measure,
>> latency! */
>> +};
>> +
>> +struct pxa2xx_spi_chip tsc2046_chip_info = {
>> +.tx_threshold = 1,
>> +.rx_threshold = 2,
>> +.timeout= 64,
>> +.gpio_cs= -1,
>> +};
>> +
>> +static struct pxa2xx_spi_master magician_spi_info = {
>> +.num_chipselect = 1,
>> +.enable_dma = 1,
>> +};
>> +
>> +static struct spi_board_info ads7846_spi_board_info[] __initdata = {
>> +{
>> +.modalias = "ads7846",
>> +.bus_num= 2,
>> +.max_speed_hz = 1857143,
>
> I had used 2.6 MHz here.
Will change to something more visible, probably remnants of some debugging.
BTW It sets frequency of a SPI?
>
>> +.platform_data = &ads7846_pdata,
>> +.controller_data= &tsc2046_chip_info,
>> +.irq = PXA_GPIO_TO_IRQ(GPIO115_MAGICIAN_nPEN_IRQ),
>> +},
>> +};
>> +
>> +/*
>> * Platform devices
>> */
>>
>> @@ -887,6 +968,7 @@ static struct platform_device *devices[]
>> __initdata = {
>> &egpio,
>> &backlight,
>> &pasic3,
>> +&vads7846_device,
>> &bq24022,
>> &gpio_vbus,
>> &power_supply,
>> @@ -944,6 +1026,10 @@ static void __init magician_init(void)
>> lcd_select ? &samsung_info : &toppoly_info);
>> } else
>> pr_err("LCD detection: CPLD mapping failed\n");
>> +
>> +pxa2xx_set_spi_info(2, &magician_spi_info);
>> +spi_register_board_info(ARRAY_AND_SIZE(ads7846_spi_board_inf
>> o));
>> +
>> }
>>
>> MACHINE_START(MAGICIAN, "HTC Magician")
>
> regards
> Philipp
>
Petr
--
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 v7 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Signed-off-by: Yakir Yang
---
*just add a note that this is v7 of only fifth patch.*
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
to get the backword timing values. Krzysztof suggest me that driver could use
the "of_property_read_bool" to get backword timing values, but that interfacs
would modify the original drm_display_mode timing directly (whether those
properties exists or not).
Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)
Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
struct drm_display_info. (Thierry)
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 2 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 14 +-
3 files changed, 103 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 96afb67..6307060 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
return;
}
- ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+ ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+ struct drm_display_mode *orig_mode,
+ struct drm_display_mode *mode)
+{
+ struct analogix_dp_device *dp = bridge->driver_private;
+ struct drm_display_info *display_info = &dp->connector->display_info;
+ struct video_info *video = &dp->video_info;
+ struct device_node *dp_node = dp->dev->of_node;
+ int vic;
+
+ /* Input video interlaces & hsync pol & vsync pol */
+ video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+ video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+ video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+ /* Input video dynamic_range & colorimetry */
+ vic = drm_match_cea_mode(mode);
+ if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+ (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR601;
+ } else if (vic) {
+ video->dynamic_range = CEA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ } else {
+ video->dynamic_range = VESA;
+ video->ycbcr_coeff = COLOR_YCBCR709;
+ }
+
+ /* Input vide bpc and color_formats */
+ switch (display_info->bpc) {
+ case 12:
+ video->color_depth = COLOR_12;
+ break;
+ case 10:
+ video->color_depth = COLOR_10;
+ break;
+ case 8:
+ video->color_depth = COLOR_8;
+ break;
+ case 6:
+ video->color_depth = COLOR_6;
+ break;
+ default:
+ video->color_depth = COLOR_8;
+ break;
+ }
+ if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+ video->color_space = COLOR_YCBCR444;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+ video->color_space = COLOR_YCBCR422;
+ else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+ video->color_space = COLOR_RGB;
+ else
+ video->color_space = COLOR_RGB;
+
+ /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property isn't present, the "video_info" can keep the original
+* values and wouldn't be modified.
+*/
+ of_property_read_u32(d
Re: [PATCH 1/3] ARM: dts: exynos5422-odroidxu3: use cd-gpio method to detect sd-card
On 12.10.2015 00:46, Anand Moon wrote:
> From: Jaehoon Chung
>
> To detect sd-card use the cd-gpio method.
> It can decrease the interrupt for detecting sd-card.
>
> Signed-off-by: Jaehoon Chung
> Signed-off-by: Anand Moon
>
> ---
> Changes based on
> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> v4.4-next/dt-samsung branch
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 1af5bdc..26decbd 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -352,8 +352,10 @@
> samsung,dw-mshc-ciu-div = <3>;
> samsung,dw-mshc-sdr-timing = <0 4>;
> samsung,dw-mshc-ddr-timing = <0 2>;
> + cd-gpios = <&gpc2 2 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> pinctrl-names = "default";
> - pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus1 &sd2_bus4>;
> + pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_cd &sd2_bus4>;
Anand,
You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
pad correctly for Exynos5420 boards"). Why? There is no explanation in
the commit message about this.
Best regards,
Krzysztof
--
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 v4 00/26] ARM: pxa: magician: Rework HTC Magician support
Dne 11.10.2015 v 10:22 Robert Jarzmik napsal(a): > Petr Cvek writes: > >>> Thanks (a pozdrav :-), >>> >>> Pavel > Hi Petr, > > I'll start applying part of this serie today evening (my evening). > All Philipp's acked patches for a start. > > For the minor changes required by Philipp (comments, ...), if you just state > by > mail that you agree I'll make them inline before applying. Yes they are OK with me. Petr Cvek -- 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 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
On 12.10.2015 13:09, Yakir Yang wrote: > > > On 10/12/2015 11:51 AM, Krzysztof Kozlowski wrote: >> On 12.10.2015 11:43, Yakir Yang wrote: >>> On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote: On 12.10.2015 09:37, Yakir Yang wrote: > Hi Krzysztof, > > On 10/10/2015 11:46 PM, Yakir Yang wrote: >> Both hsync/vsync polarity and interlace mode can be parsed from >> drm display mode, and dynamic_range and ycbcr_coeff can be judge >> by the video code. >> >> But presumably Exynos still relies on the DT properties, so take >> good use of mode_fixup() in to achieve the compatibility hacks. >> >> Signed-off-by: Yakir Yang >> --- >> Changes in v6: None > +of_property_read_u32(dp_node, "hsync-active-high", > + &video->h_sync_polarity); > +of_property_read_u32(dp_node, "vsync-active-high", > + &video->v_sync_polarity); > +of_property_read_u32(dp_node, "interlaced", > + &video->interlaced); > +} > > > Sorry, forget to fix your previous comment here, would > remember to fix it to v7 version, wish v6 would collect > more comment/reviewed/ack. :) Right. You can send a v7 of only this patch. In the same time I would prefer not to chain-reply next version of entire patchset to cover letter of previous version. It confuses me because v6 appears UNDER v4 so I can't really find v6. I see v4 at the top of my email list. >>> Okay, I wish this chain-reply would make people easy to find the >>> previous comments, but actually it is little mess now. I would give >>> up this way to send patchset :) >>> In the same time the patchset is quite big. Put the latest version (with this issue above fixed!) on some repo and link it in cover letter. >>> Yeah, it's quite big now, I would like to back the patchset to previous >>> format, like: >>> >>> ---> [PATCH v6 00/17] Cover letter >>>|> [PATCH v6 01/17] >>>|> [PATCH ..] >>>|> [PATCH v6 05/17] >>> |> [PATCH v7 05/17] >>>|> [PATCH ..] >>>|> [PATCH v6 17/17] >>> >>> Is it right, and can resend the v6 to fix this chain-reply issue with >>> RESEND flag ([PATCH RESEND v6 ...]) ? >>> >>> ---> [PATCH RESEND v6 00/17] Cover letter >>>|> [PATCH RESEND v6 01/17] >>>|> [PATCH ..] >>>|> [PATCH RESEND v6 05/17] >>> |> [PATCH v7 05/17] >>>|> [PATCH ..] >>>|> [PATCH RESEND v6 17/17] >>> >> No, don't resend everything. I mean in this case with such big patchset >> if you want to fix one patch just send one email [PATCH v7 05/17] >> chained to proper id (cover letter or v6-05/17). Add a short note that >> this is resend of only one patch from the set. > > Oh, understand now, just keep this chain-reply no changes for now. > > > [PATCH v4 00/16] Cover letter >|> [PATCH v5 00/17] Covert letter >|> [PATCH ..] >| >|> [PATCH v6 00/17] Covert letter >|> [PATCH v6 01/17] >|> [PATCH ..] >|> [PATCH v6 17/17] >|> [PATCH v7 05/17] Yes, I think it is correct. Maybe just add a note (in patch changelog) that this is v7 of only fifth patch. Best regards, Krzysztof -- 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 v3] misc: mic: replace kfree with put_device
Handle a failed device_register(), replace kfree() with put_device(), which will call cosm/mbus/scif_release_dev(). Signed-off-by: Geliang Tang --- Changes in v3: - Add the same change to cosm_bus.c Changes in v2: - Just refresh this patch. --- drivers/misc/mic/bus/cosm_bus.c | 2 +- drivers/misc/mic/bus/mic_bus.c | 2 +- drivers/misc/mic/bus/scif_bus.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/misc/mic/bus/cosm_bus.c b/drivers/misc/mic/bus/cosm_bus.c index 1e36830..d31d6c6 100644 --- a/drivers/misc/mic/bus/cosm_bus.c +++ b/drivers/misc/mic/bus/cosm_bus.c @@ -100,7 +100,7 @@ cosm_register_device(struct device *pdev, struct cosm_hw_ops *hw_ops) ida_remove: ida_simple_remove(&cosm_index_ida, cdev->index); free_cdev: - kfree(cdev); + put_device(&cdev->dev); return ERR_PTR(ret); } EXPORT_SYMBOL_GPL(cosm_register_device); diff --git a/drivers/misc/mic/bus/mic_bus.c b/drivers/misc/mic/bus/mic_bus.c index c64955d..be37890 100644 --- a/drivers/misc/mic/bus/mic_bus.c +++ b/drivers/misc/mic/bus/mic_bus.c @@ -175,7 +175,7 @@ mbus_register_device(struct device *pdev, int id, struct dma_map_ops *dma_ops, goto free_mbdev; return mbdev; free_mbdev: - kfree(mbdev); + put_device(&mbdev->dev); return ERR_PTR(ret); } EXPORT_SYMBOL_GPL(mbus_register_device); diff --git a/drivers/misc/mic/bus/scif_bus.c b/drivers/misc/mic/bus/scif_bus.c index fd27021..ff6e01c 100644 --- a/drivers/misc/mic/bus/scif_bus.c +++ b/drivers/misc/mic/bus/scif_bus.c @@ -180,7 +180,7 @@ scif_register_device(struct device *pdev, int id, struct dma_map_ops *dma_ops, goto free_sdev; return sdev; free_sdev: - kfree(sdev); + put_device(&sdev->dev); return ERR_PTR(ret); } EXPORT_SYMBOL_GPL(scif_register_device); -- 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 v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
On 10/12/2015 11:51 AM, Krzysztof Kozlowski wrote: On 12.10.2015 11:43, Yakir Yang wrote: On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote: On 12.10.2015 09:37, Yakir Yang wrote: Hi Krzysztof, On 10/10/2015 11:46 PM, Yakir Yang wrote: Both hsync/vsync polarity and interlace mode can be parsed from drm display mode, and dynamic_range and ycbcr_coeff can be judge by the video code. But presumably Exynos still relies on the DT properties, so take good use of mode_fixup() in to achieve the compatibility hacks. Signed-off-by: Yakir Yang --- Changes in v6: None +of_property_read_u32(dp_node, "hsync-active-high", + &video->h_sync_polarity); +of_property_read_u32(dp_node, "vsync-active-high", + &video->v_sync_polarity); +of_property_read_u32(dp_node, "interlaced", + &video->interlaced); +} Sorry, forget to fix your previous comment here, would remember to fix it to v7 version, wish v6 would collect more comment/reviewed/ack. :) Right. You can send a v7 of only this patch. In the same time I would prefer not to chain-reply next version of entire patchset to cover letter of previous version. It confuses me because v6 appears UNDER v4 so I can't really find v6. I see v4 at the top of my email list. Okay, I wish this chain-reply would make people easy to find the previous comments, but actually it is little mess now. I would give up this way to send patchset :) In the same time the patchset is quite big. Put the latest version (with this issue above fixed!) on some repo and link it in cover letter. Yeah, it's quite big now, I would like to back the patchset to previous format, like: ---> [PATCH v6 00/17] Cover letter |> [PATCH v6 01/17] |> [PATCH ..] |> [PATCH v6 05/17] |> [PATCH v7 05/17] |> [PATCH ..] |> [PATCH v6 17/17] Is it right, and can resend the v6 to fix this chain-reply issue with RESEND flag ([PATCH RESEND v6 ...]) ? ---> [PATCH RESEND v6 00/17] Cover letter |> [PATCH RESEND v6 01/17] |> [PATCH ..] |> [PATCH RESEND v6 05/17] |> [PATCH v7 05/17] |> [PATCH ..] |> [PATCH RESEND v6 17/17] No, don't resend everything. I mean in this case with such big patchset if you want to fix one patch just send one email [PATCH v7 05/17] chained to proper id (cover letter or v6-05/17). Add a short note that this is resend of only one patch from the set. Oh, understand now, just keep this chain-reply no changes for now. > [PATCH v4 00/16] Cover letter |> [PATCH v5 00/17] Covert letter |> [PATCH ..] | |> [PATCH v6 00/17] Covert letter |> [PATCH v6 01/17] |> [PATCH ..] |> [PATCH v6 17/17] |> [PATCH v7 05/17] Of course you can just wait for some more comments and then send v7 of everything. I would choice to send it now :) Thanks, - Yakir Best regards, Krzysztof -- 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 v10 24/46] xfs: Add richacl support
On Mon, Oct 12, 2015 at 03:51:15AM +0200, Andreas Grünbacher wrote:
> 2015-10-12 2:10 GMT+02:00 Dave Chinner :
> > On Mon, Oct 12, 2015 at 12:58:35AM +0200, Andreas Gruenbacher wrote:
> >> diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig
> >> index 5d47b4d..05dd312 100644
> >> --- a/fs/xfs/Kconfig
> >> +++ b/fs/xfs/Kconfig
> >> @@ -52,6 +52,17 @@ config XFS_POSIX_ACL
> >>
> >> If you don't know what Access Control Lists are, say N.
> >>
> >> +config XFS_RICHACL
> >> +bool "XFS Rich Access Control Lists (EXPERIMENTAL)"
> >> +depends on XFS_FS
> >> +select FS_RICHACL
> >> +help
> >> + Richacls are an implementation of NFSv4 ACLs, extended by file
> >> masks
> >> + to cleanly integrate into the POSIX file permission model. To
> >> learn
> >> + more about them, see http://www.bestbits.at/richacl/.
> >> +
> >> + If you don't know what Richacls are, say N.
> >> +
> >
> > So now we have multiple compile time ACL configs that we have to
> > test. Personally, I see no reason for making either posix or rich
> > acls compile time dependent. How about we just change CONFIG_FS_XFS
> > to have "select FS_POSIX_ACL" and "select FS_RICHACL"
> > unconditionally, and then we can get rid of all the conditional
> > code?
>
> I'm sure neither kind of ACLs makes sense on many tiny systems, it
> should be possible to disable them. XFS may not make sense on those
> kinds of systems either, that is not my call to make though.
Well, the smallest systems that use XFS are typically 1-2 disk NAS
boxes, and I can see them wanting richacls. As it is, the xfs kernel
module is almost 1MB of object code, so it you have a small embedded
box you don't want XFS. Almost all distros turn on ACL support I'm
not sure that it makes sense to have these config options in XFS
anymore
> >> diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.h
> >> index 9590a06..8c6da45 100644
> >> --- a/fs/xfs/libxfs/xfs_format.h
> >> +++ b/fs/xfs/libxfs/xfs_format.h
> >> @@ -461,10 +461,18 @@ xfs_sb_has_ro_compat_feature(
> >> #define XFS_SB_FEAT_INCOMPAT_FTYPE (1 << 0)/* filetype in
> >> dirent */
> >> #define XFS_SB_FEAT_INCOMPAT_SPINODES(1 << 1)/* sparse
> >> inode chunks */
> >> #define XFS_SB_FEAT_INCOMPAT_META_UUID (1 << 2)/* metadata
> >> UUID */
> >> +
> >> +#ifdef CONFIG_XFS_RICHACL
> >> +#define XFS_SB_FEAT_INCOMPAT_RICHACL (1 << 3)/* richacls */
> >> +#else
> >> +#define XFS_SB_FEAT_INCOMPAT_RICHACL 0
> >> +#endif
> >> +
> >
> > Regardless of whether we build in richacl support, this is wrong.
> > Feature bits are on-disk format definitions, so it will always have
> > this value whether or not the kernel supports the feature.
>
> This is so that xfs_mount_validate_sb() will complain when mounting a
> richacl filesystem on a kernel which doesn't have richacl suport
> compiled in. The same effect can be had with extra code there of
> course.
If the kernel doesn't know about a feature, then it will report
"unknown feature". However, as of this patch set, the kernel will
know about the richacl feature, and so the correct error message
is to say "Rich ACLs not supported by this kernel".
Also, from a disk format perspective, this is a this is a read-only
compat feature, as kernels that don't have richacl support are still
able to mount and walk the filesystem without errors occurring. It's
only when allowing modifications are made that problems will arise,
so why did you make it an incompat feature?
> >> +int
> >> +xfs_set_richacl(struct inode *inode, struct richacl *acl)
> >> +{
> >> + struct xfs_inode *ip = XFS_I(inode);
> >> + umode_t mode = inode->i_mode;
> >> + int error;
> >> +
> >> + if (acl) {
> >> + /* Don't allow acls with unmapped identifiers. */
> >> + if (richacl_has_unmapped_identifiers(acl))
> >> + return -EINVAL;
> >> +
> >> + if (richacl_equiv_mode(acl, &mode) == 0) {
> >> + xfs_set_mode(inode, mode);
> >> + acl = NULL;
> >> + }
> >
> > Comment needed here - why does this now seem to accidentally fall
> > through to removing the ACL?
>
> Setting an ACL that is equivalent to a file mode is the same as
> removing any existing ACLs and doing a chmod to that equivalent file
> mode. It's the sams as with POSIX ACLs, and the code is the same as
> well. I'll add a comment though.
>
> > Also, why is this in the XFS specific
> > code when it's generic richacl functionality that is being checked?
>
> This turns into two non-atomic operations if we move it into generic code.
I don't follow you - this isn't an atomic operation to begin with...
> > Also, I really dislike the API where passing a NULL acl means to
> > "set this acl" actually means "remove the existing ACL". Why no
> > ->remove_acl method called from the generic code?
>
> It's not uncommon, it saves inode operations
Re: Updated scalable urandom patchkit
On Sun, Oct 11, 2015 at 08:16:01PM -0400, George Spelvin wrote: > > I'm not thrilled with incrementing the pointer from i to len, but mixing > at positions i+k to i+k+len. The whole LFSR scheme relies on a regular > pass structure. That part I'm not worried about. We still have a regular pass structure --- since for each CPU, we are still iterating over the pool in a regular fashion. > How about this instead: drop the hashed offset, and instead let each > writer do an atomic_add_return on the index, then iterate over the > "reserved" slots. Concurrent additions will at least do non-overlapping > writes until the numer equals the pool size. One atomic operation per byte that we're mixing in? That's quite expensive. > Personally, I hate the input_rotate. It's not that it's harmful, just > that it doesn't do much good compared to the cost; for the number of cycles > and context space required there are more efficient mixing operations. The input_rotate is useful for the input pool, for things like keyboard code so we can make sure they enter the pool at more points than just the low bits of each word. But for the output pools, it really doesn't make any sense. And we are getting to the point where we may end up having different mixing algorithms for the nonblocking pool, and in that case I have absolutely no trouble dropping the input_rotate part of the mixing algorithm for the non-blocking pool. > Or a small machine with a couple of concurrent /dev/urandom abusers. > Remember, it's globally readable, so it has to be resistance to malicious > abuse. One of the other ways we could solve this is by hanging a struct off the task structure, and if we detect that we have a /dev/urandom abuser, we give that process its own urandom pool, so any pissing that it does will be in its own pool. (So to speak.) Most processes don't actually use that much randomness, and I'm not that worried about in-kernel users of the nonblocking pool. Even with the most exec-heavy workload, setting up a new exec image is heavyweight enough that you're really not going to be contending on the lock. I also have trouble with someone spending on a system with 1K cpu cores and wasting all of their CPU power with running shell scripts that fork and exec a lot. :-) The reality is that most processes don't use /dev/urandom or getrandom(2) at all, and those that do, many of them only use it sparingly. So maybe the right answer is to do something simple which takes care of the abusers. > You can add rather than XOR, and we have atomic add primitives. Atomic-add primitives aren't portable either. The representation isn't guaranteed to be 32-bits, and some platforms an atomic int is only 24-bits wide (the top 8 bits being used for locking purposes). > There are several possible solutions that don't need separate pools > (including separate add-back pools, with a shared seeded pool that > is never touched by add-back), so I don't think it's necessary to > give up yet. Hmm, maybe. I'm a bit worried about the amount of complexity that this entails, and the reality is that the urandom pool or pools don't provide anything other than cryptogaphic randomness. At this point, I wonder if it might not be simpler to restrict the current nonblocking pool to kernel users, and for userspace users, the first time a process reads from /dev/urandom or calls getrandom(2), we create for them a ChaCha20 CRNG, which hangs off of the task structure. This would require about 72 bytes of state per process, but normally very few processes are reading from /dev/urandom or calling getrandom(2) from userspace. The CRNG would be initialized from the non-blocking pool, and is reseeded after, say, 2**24 cranks or five minutes. It's essentially an OpenBSD-style arc4random in the kernel. (Arguably the right answer is to put arc4random in libc, where it can automatically handle forks/clones/pthread automatically, but it seems pretty clear *that* train has left a long time ago.) I have a feeling this may be less code and complexity, and it nicely handles the case where we have a /dev/urandom abuser who feels that they want to call /dev/urandom in a tight loop, even on a 4 socket Xeon system. :-) - Ted -- 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: add __initbss section attribute
This attribute can make init data to be into .initbss section,
this will make the data to be NO_BITS in vmlinux, can shrink the
Image file size, and speed up the boot up time.
Signed-off-by: yalin wang
---
arch/arm/kernel/vmlinux.lds.S | 2 +-
arch/arm/mm/init.c| 1 +
include/asm-generic/sections.h| 1 +
include/asm-generic/vmlinux.lds.h | 11 ++-
include/linux/init.h | 1 +
include/linux/mm.h| 4 +++-
6 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde..ad6d740 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -330,7 +330,7 @@ SECTIONS
}
#endif
- BSS_SECTION(0, 0, 0)
+ BSS_SECTION(0, 0, 0, 0)
_end = .;
STABS_DEBUG
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 8a63b4c..50b881e 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -722,6 +722,7 @@ void free_initmem(void)
free_tcmmem();
poison_init_mem(__init_begin, __init_end - __init_begin);
+ poison_init_mem(__initbss_start, __initbss_start - __initbss_end);
if (!machine_is_integrator() && !machine_is_cintegrator())
free_initmem_default(-1);
}
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index b58fd66..a63ebe9 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -29,6 +29,7 @@ extern char _text[], _stext[], _etext[];
extern char _data[], _sdata[], _edata[];
extern char __bss_start[], __bss_stop[];
extern char __init_begin[], __init_end[];
+extern char __initbss_start[], __initbss_end[];
extern char _sinittext[], _einittext[];
extern char _end[];
extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[];
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index c4bd0e2..b3db62d 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -574,6 +574,14 @@
*(COMMON) \
}
+#define INITBSS(initbss_align) \
+ . = ALIGN(initbss_align); \
+ .initbss : AT(ADDR(.initbss) - LOAD_OFFSET) { \
+ VMLINUX_SYMBOL(__initbss_start) = .;\
+ *(.bss.init.data) \
+ VMLINUX_SYMBOL(__initbss_end) = .; \
+ }
+
/*
* DWARF debug sections.
* Symbols in the DWARF debugging sections are relative to
@@ -831,10 +839,11 @@
INIT_RAM_FS \
}
-#define BSS_SECTION(sbss_align, bss_align, stop_align) \
+#define BSS_SECTION(sbss_align, bss_align, initbss_align, stop_align)
\
. = ALIGN(sbss_align); \
VMLINUX_SYMBOL(__bss_start) = .;\
SBSS(sbss_align)\
BSS(bss_align) \
+ INITBSS(initbss_align) \
. = ALIGN(stop_align); \
VMLINUX_SYMBOL(__bss_stop) = .;
diff --git a/include/linux/init.h b/include/linux/init.h
index b449f37..f2960b2 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -41,6 +41,7 @@
discard it in modules) */
#define __init __section(.init.text) __cold notrace
#define __initdata __section(.init.data)
+#define __initbss __section(.bss.init.data)
#define __initconst__constsection(.init.rodata)
#define __exitdata __section(.exit.data)
#define __exit_call__used __section(.exitcall.exit)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index d30eea3..1f266f7 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
struct mempolicy;
struct anon_vma;
@@ -1722,10 +1723,11 @@ static inline void mark_page_reserved(struct page *page)
*/
static inline unsigned long free_initmem_default(int poison)
{
- extern char __init_begin[], __init_end[];
return free_reserved_area(&__init_begin, &__init_end,
poison, "unused kernel");
+ return free_reserved_area(&__initbss_start, &__initbss_end,
+ poison, "unused kernel");
}
static inline unsigned long get_num_physpages(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: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks
On 10/11/2015 08:49 PM, Hanjun Guo wrote: On 10/12/2015 11:08 AM, Pat Erley wrote: On 10/05/2015 10:12 AM, Al Stone wrote: On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote: On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote: On 09/30/2015 03:00 AM, Hanjun Guo wrote: On 2015/9/30 7:45, Al Stone wrote: NB: this patch set is for use against the linux-pm bleeding edge branch. [snip...] For this patch set, Reviewed-by: Hanjun Guo Thanks Hanjun Thanks, Hanjun! Series applied, thanks! Rafael Thanks, Rafael! Just decided to test out linux-next (to see the new nouveau cleanups). This change set prevents my Lenovo W510 from booting properly. Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to eventually replace the macro" Gets the system booting again. I'm attaching my dmesg from the failed boot, who wants the acpidump? [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1 [0.00] ACPI: Error parsing LAPIC address override entry [0.00] ACPI: Invalid BIOS MADT, disabling ACPI Seems the MADT revision is not right, could you dump the ACPI MADT (APIC) table and send it out? I will take a look :) Thanks Hanjun Here ya go, enjoy. Feel free to CC me on any patches that might fix it. apic.dat Description: Netscape Proxy Auto Config /* * Intel ACPI Component Architecture * AML/ASL+ Disassembler version 20150717-64 * Copyright (c) 2000 - 2015 Intel Corporation * * Disassembly of apic.dat, Sun Oct 11 20:55:40 2015 * * ACPI Data Table [APIC] * * Format: [HexOffset DecimalOffset ByteLength] FieldName : FieldValue */ [000h 4]Signature : "APIC"[Multiple APIC Description Table (MADT)] [004h 0004 4] Table Length : 00BC [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : FA [00Ah 0010 6] Oem ID : "LENOVO" [010h 0016 8] Oem Table ID : "TP-6N " [018h 0024 4] Oem Revision : 1450 [01Ch 0028 4] Asl Compiler ID : "LNVO" [020h 0032 4]Asl Compiler Revision : 0001 [024h 0036 4] Local Apic Address : FEE0 [028h 0040 4]Flags (decoded below) : 0001 PC-AT Compatibility : 1 [02Ch 0044 1]Subtable Type : 00 [Processor Local APIC] [02Dh 0045 1] Length : 08 [02Eh 0046 1] Processor ID : 00 [02Fh 0047 1]Local Apic ID : 00 [030h 0048 4]Flags (decoded below) : 0001 Processor Enabled : 1 [034h 0052 1]Subtable Type : 00 [Processor Local APIC] [035h 0053 1] Length : 08 [036h 0054 1] Processor ID : 01 [037h 0055 1]Local Apic ID : 01 [038h 0056 4]Flags (decoded below) : 0001 Processor Enabled : 1 [03Ch 0060 1]Subtable Type : 00 [Processor Local APIC] [03Dh 0061 1] Length : 08 [03Eh 0062 1] Processor ID : 02 [03Fh 0063 1]Local Apic ID : 02 [040h 0064 4]Flags (decoded below) : 0001 Processor Enabled : 1 [044h 0068 1]Subtable Type : 00 [Processor Local APIC] [045h 0069 1] Length : 08 [046h 0070 1] Processor ID : 03 [047h 0071 1]Local Apic ID : 03 [048h 0072 4]Flags (decoded below) : 0001 Processor Enabled : 1 [04Ch 0076 1]Subtable Type : 00 [Processor Local APIC] [04Dh 0077 1] Length : 08 [04Eh 0078 1] Processor ID : 04 [04Fh 0079 1]Local Apic ID : 04 [050h 0080 4]Flags (decoded below) : 0001 Processor Enabled : 1 [054h 0084 1]Subtable Type : 00 [Processor Local APIC] [055h 0085 1] Length : 08 [056h 0086 1] Processor ID : 05 [057h 0087 1]Local Apic ID : 05 [058h 0088 4]Flags (decoded below) : 0001 Processor Enabled : 1 [05Ch 0092 1]Subtable Type : 00 [Processor Local APIC] [05Dh 0093 1] Length : 08 [05Eh 0094 1] Processor ID : 06 [05Fh 0095 1]Local Apic ID : 06 [060h 0096 4]Flags (decoded below) : 0001 Processor Enabled : 1 [064h 0100 1]Subtable Type : 00 [Processor Local APIC] [065h 0101 1] Length : 08 [066h 0102 1] Processor ID : 07 [067h 0103 1]Local Apic ID : 07 [068h 0104 4]Flags (decoded below) : 0001 Processor Enabled : 1 [06Ch 0108 1]Subtable Type : 01
Re: [PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
On 12.10.2015 11:43, Yakir Yang wrote: > > > On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote: >> On 12.10.2015 09:37, Yakir Yang wrote: >>> Hi Krzysztof, >>> >>> On 10/10/2015 11:46 PM, Yakir Yang wrote: Both hsync/vsync polarity and interlace mode can be parsed from drm display mode, and dynamic_range and ycbcr_coeff can be judge by the video code. But presumably Exynos still relies on the DT properties, so take good use of mode_fixup() in to achieve the compatibility hacks. Signed-off-by: Yakir Yang --- Changes in v6: None >>> +of_property_read_u32(dp_node, "hsync-active-high", >>> + &video->h_sync_polarity); >>> +of_property_read_u32(dp_node, "vsync-active-high", >>> + &video->v_sync_polarity); >>> +of_property_read_u32(dp_node, "interlaced", >>> + &video->interlaced); >>> +} >>> >>> >>> Sorry, forget to fix your previous comment here, would >>> remember to fix it to v7 version, wish v6 would collect >>> more comment/reviewed/ack. :) >> Right. >> >> You can send a v7 of only this patch. >> >> In the same time I would prefer not to chain-reply next version of >> entire patchset to cover letter of previous version. It confuses me >> because v6 appears UNDER v4 so I can't really find v6. I see v4 at the >> top of my email list. > > Okay, I wish this chain-reply would make people easy to find the > previous comments, but actually it is little mess now. I would give > up this way to send patchset :) > >> In the same time the patchset is quite big. Put the latest version (with >> this issue above fixed!) on some repo and link it in cover letter. > > Yeah, it's quite big now, I would like to back the patchset to previous > format, like: > > ---> [PATCH v6 00/17] Cover letter > |> [PATCH v6 01/17] > |> [PATCH ..] > |> [PATCH v6 05/17] > |> [PATCH v7 05/17] > |> [PATCH ..] > |> [PATCH v6 17/17] > > Is it right, and can resend the v6 to fix this chain-reply issue with > RESEND flag ([PATCH RESEND v6 ...]) ? > > ---> [PATCH RESEND v6 00/17] Cover letter > |> [PATCH RESEND v6 01/17] > |> [PATCH ..] > |> [PATCH RESEND v6 05/17] > |> [PATCH v7 05/17] > |> [PATCH ..] > |> [PATCH RESEND v6 17/17] > No, don't resend everything. I mean in this case with such big patchset if you want to fix one patch just send one email [PATCH v7 05/17] chained to proper id (cover letter or v6-05/17). Add a short note that this is resend of only one patch from the set. Of course you can just wait for some more comments and then send v7 of everything. Best regards, Krzysztof -- 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/2] nilfs2: fix gcc unused-but-set-variable warnings
Fix the following build warnings:
$ make W=1
[...]
CC [M] fs/nilfs2/btree.o
fs/nilfs2/btree.c: In function 'nilfs_btree_split':
fs/nilfs2/btree.c:923:8: warning: variable 'newptr' set but not used
[-Wunused-but-set-variable]
__u64 newptr;
^
fs/nilfs2/btree.c:922:8: warning: variable 'newkey' set but not used
[-Wunused-but-set-variable]
__u64 newkey;
^
CC [M] fs/nilfs2/dat.o
fs/nilfs2/dat.c: In function 'nilfs_dat_prepare_end':
fs/nilfs2/dat.c:158:8: warning: variable 'start' set but not used
[-Wunused-but-set-variable]
__u64 start;
^
CC [M] fs/nilfs2/segment.o
fs/nilfs2/segment.c: In function 'nilfs_segctor_do_immediate_flush':
fs/nilfs2/segment.c:2433:6: warning: variable 'err' set but not used
[-Wunused-but-set-variable]
int err;
^
CC [M] fs/nilfs2/sufile.o
fs/nilfs2/sufile.c: In function 'nilfs_sufile_alloc':
fs/nilfs2/sufile.c:320:27: warning: variable 'ncleansegs' set but not used
[-Wunused-but-set-variable]
unsigned long nsegments, ncleansegs, nsus, cnt;
^
CC [M] fs/nilfs2/alloc.o
fs/nilfs2/alloc.c: In function 'nilfs_palloc_prepare_alloc_entry':
fs/nilfs2/alloc.c:478:38: warning: variable 'groups_per_desc_block' set but
not used [-Wunused-but-set-variable]
unsigned long n, entries_per_group, groups_per_desc_block;
^
Signed-off-by: Ryusuke Konishi
---
fs/nilfs2/alloc.c | 3 +--
fs/nilfs2/btree.c | 5 -
fs/nilfs2/dat.c | 2 --
fs/nilfs2/segment.c | 3 +--
fs/nilfs2/sufile.c | 3 +--
5 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/fs/nilfs2/alloc.c b/fs/nilfs2/alloc.c
index 8df0f3b..dd6c142 100644
--- a/fs/nilfs2/alloc.c
+++ b/fs/nilfs2/alloc.c
@@ -475,7 +475,7 @@ int nilfs_palloc_prepare_alloc_entry(struct inode *inode,
void *desc_kaddr, *bitmap_kaddr;
unsigned long group, maxgroup, ngroups;
unsigned long group_offset, maxgroup_offset;
- unsigned long n, entries_per_group, groups_per_desc_block;
+ unsigned long n, entries_per_group;
unsigned long i, j;
int pos, ret;
@@ -483,7 +483,6 @@ int nilfs_palloc_prepare_alloc_entry(struct inode *inode,
maxgroup = ngroups - 1;
group = nilfs_palloc_group(inode, req->pr_entry_nr, &group_offset);
entries_per_group = nilfs_palloc_entries_per_group(inode);
- groups_per_desc_block = nilfs_palloc_groups_per_desc_block(inode);
for (i = 0; i < ngroups; i += n) {
if (group >= ngroups) {
diff --git a/fs/nilfs2/btree.c b/fs/nilfs2/btree.c
index 919fd5b..f609a85 100644
--- a/fs/nilfs2/btree.c
+++ b/fs/nilfs2/btree.c
@@ -919,8 +919,6 @@ static void nilfs_btree_split(struct nilfs_bmap *btree,
int level, __u64 *keyp, __u64 *ptrp)
{
struct nilfs_btree_node *node, *right;
- __u64 newkey;
- __u64 newptr;
int nchildren, n, move, ncblk;
node = nilfs_btree_get_nonroot_node(path, level);
@@ -942,9 +940,6 @@ static void nilfs_btree_split(struct nilfs_bmap *btree,
if (!buffer_dirty(path[level].bp_sib_bh))
mark_buffer_dirty(path[level].bp_sib_bh);
- newkey = nilfs_btree_node_get_key(right, 0);
- newptr = path[level].bp_newreq.bpr_ptr;
-
if (move) {
path[level].bp_index -= nilfs_btree_node_get_nchildren(node);
nilfs_btree_node_insert(right, path[level].bp_index,
diff --git a/fs/nilfs2/dat.c b/fs/nilfs2/dat.c
index 0d5fada..7dc23f1 100644
--- a/fs/nilfs2/dat.c
+++ b/fs/nilfs2/dat.c
@@ -155,7 +155,6 @@ void nilfs_dat_commit_start(struct inode *dat, struct
nilfs_palloc_req *req,
int nilfs_dat_prepare_end(struct inode *dat, struct nilfs_palloc_req *req)
{
struct nilfs_dat_entry *entry;
- __u64 start;
sector_t blocknr;
void *kaddr;
int ret;
@@ -169,7 +168,6 @@ int nilfs_dat_prepare_end(struct inode *dat, struct
nilfs_palloc_req *req)
kaddr = kmap_atomic(req->pr_entry_bh->b_page);
entry = nilfs_palloc_block_get_entry(dat, req->pr_entry_nr,
req->pr_entry_bh, kaddr);
- start = le64_to_cpu(entry->de_start);
blocknr = le64_to_cpu(entry->de_blocknr);
kunmap_atomic(kaddr);
diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c
index c6abbad9..11c06e9 100644
--- a/fs/nilfs2/segment.c
+++ b/fs/nilfs2/segment.c
@@ -2430,7 +2430,6 @@ static void nilfs_segctor_thread_construct(struct
nilfs_sc_info *sci, int mode)
static void nilfs_segctor_do_immediate_flush(struct nilfs_sc_info *sci)
{
int mode = 0;
- int err;
spin_lock(&sci->sc_state_lock);
mode = (sci->sc_flush_request & FLUSH_DAT_BIT) ?
@@ -2438,7 +2437,7 @@ static void nilfs_segctor_do_immediate_flush(struct
nilfs_sc_info *sci)
spin_unlock(&sci->sc_state_lock);
if (mode) {
- err = nilfs_segctor_do_construct(sci, mode);
+
[PATCH 2/2] nilfs2: fix gcc uninitialized-variable warnings in powerpc build
Some false positive warnings are reported for powerpc build.
The following warnings are reported in
http://kisskb.ellerman.id.au/kisskb/buildresult/12519703/
CC fs/nilfs2/super.o
fs/nilfs2/super.c: In function 'nilfs_resize_fs':
fs/nilfs2/super.c:376:2: warning: 'blocknr' may be used uninitialized in this
function [-Wuninitialized]
fs/nilfs2/super.c:362:11: note: 'blocknr' was declared here
CC fs/nilfs2/recovery.o
fs/nilfs2/recovery.c: In function 'nilfs_salvage_orphan_logs':
fs/nilfs2/recovery.c:631:21: warning: 'sum' may be used uninitialized in this
function [-Wuninitialized]
fs/nilfs2/recovery.c:585:32: note: 'sum' was declared here
fs/nilfs2/recovery.c: In function 'nilfs_search_super_root':
fs/nilfs2/recovery.c:873:11: warning: 'sum' may be used uninitialized in this
function [-Wuninitialized]
Another similar warning is reported in
http://kisskb.ellerman.id.au/kisskb/buildresult/12520079/
CC fs/nilfs2/btree.o
fs/nilfs2/btree.c: In function 'nilfs_btree_convert_and_insert':
include/asm-generic/bitops/non-atomic.h:105:20: warning: 'bh' may be used
uninitialized in this function [-Wuninitialized]
fs/nilfs2/btree.c:1859:22: note: 'bh' was declared here
This cleans out these warnings by forcing the variables to be initialized.
Signed-off-by: Ryusuke Konishi
Reported-by: Geert Uytterhoeven
---
fs/nilfs2/btree.c| 2 +-
fs/nilfs2/recovery.c | 4 ++--
fs/nilfs2/super.c| 5 -
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/nilfs2/btree.c b/fs/nilfs2/btree.c
index f609a85..3a3821b 100644
--- a/fs/nilfs2/btree.c
+++ b/fs/nilfs2/btree.c
@@ -1851,7 +1851,7 @@ int nilfs_btree_convert_and_insert(struct nilfs_bmap
*btree,
__u64 key, __u64 ptr,
const __u64 *keys, const __u64 *ptrs, int n)
{
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
union nilfs_bmap_ptr_req dreq, nreq, *di, *ni;
struct nilfs_bmap_stats stats;
int ret;
diff --git a/fs/nilfs2/recovery.c b/fs/nilfs2/recovery.c
index ff00a0b..9b4f205 100644
--- a/fs/nilfs2/recovery.c
+++ b/fs/nilfs2/recovery.c
@@ -582,7 +582,7 @@ static int nilfs_do_roll_forward(struct the_nilfs *nilfs,
struct nilfs_recovery_info *ri)
{
struct buffer_head *bh_sum = NULL;
- struct nilfs_segment_summary *sum;
+ struct nilfs_segment_summary *sum = NULL;
sector_t pseg_start;
sector_t seg_start, seg_end; /* Starting/ending DBN of full segment */
unsigned long nsalvaged_blocks = 0;
@@ -814,7 +814,7 @@ int nilfs_search_super_root(struct the_nilfs *nilfs,
struct nilfs_recovery_info *ri)
{
struct buffer_head *bh_sum = NULL;
- struct nilfs_segment_summary *sum;
+ struct nilfs_segment_summary *sum = NULL;
sector_t pseg_start, pseg_end, sr_pseg_start = 0;
sector_t seg_start, seg_end; /* range of full segment (block number) */
sector_t b, end;
diff --git a/fs/nilfs2/super.c b/fs/nilfs2/super.c
index f47585b..c6b5008 100644
--- a/fs/nilfs2/super.c
+++ b/fs/nilfs2/super.c
@@ -361,7 +361,7 @@ static int nilfs_move_2nd_super(struct super_block *sb,
loff_t sb2off)
struct nilfs_super_block *nsbp;
sector_t blocknr, newblocknr;
unsigned long offset;
- int sb2i = -1; /* array index of the secondary superblock */
+ int sb2i; /* array index of the secondary superblock */
int ret = 0;
/* nilfs->ns_sem must be locked by the caller. */
@@ -372,6 +372,9 @@ static int nilfs_move_2nd_super(struct super_block *sb,
loff_t sb2off)
} else if (nilfs->ns_sbh[0]->b_blocknr > nilfs->ns_first_data_block) {
sb2i = 0;
blocknr = nilfs->ns_sbh[0]->b_blocknr;
+ } else {
+ sb2i = -1;
+ blocknr = 0;
}
if (sb2i >= 0 && (u64)blocknr << nilfs->ns_blocksize_bits == sb2off)
goto out; /* super block location is unchanged */
--
1.8.3.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: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks
On 10/12/2015 11:08 AM, Pat Erley wrote: On 10/05/2015 10:12 AM, Al Stone wrote: On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote: On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote: On 09/30/2015 03:00 AM, Hanjun Guo wrote: On 2015/9/30 7:45, Al Stone wrote: NB: this patch set is for use against the linux-pm bleeding edge branch. [snip...] For this patch set, Reviewed-by: Hanjun Guo Thanks Hanjun Thanks, Hanjun! Series applied, thanks! Rafael Thanks, Rafael! Just decided to test out linux-next (to see the new nouveau cleanups). This change set prevents my Lenovo W510 from booting properly. Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to eventually replace the macro" Gets the system booting again. I'm attaching my dmesg from the failed boot, who wants the acpidump? [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1 [0.00] ACPI: Error parsing LAPIC address override entry [0.00] ACPI: Invalid BIOS MADT, disabling ACPI Seems the MADT revision is not right, could you dump the ACPI MADT (APIC) table and send it out? I will take a look :) 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/
[PATCH 0/2] nilfs2: fix build warnings
Hi Andrew, Please send the following fixes to upstream: Ryusuke Konishi (2): nilfs2: fix gcc unused-but-set-variable warnings nilfs2: fix gcc uninitialized-variable warnings in powerpc build These prevent reported warnings in powerpc build and minor warnings during build with "W=1". Both were detected on the mainline. Thanks, Ryusuke Konishi -- fs/nilfs2/alloc.c| 3 +-- fs/nilfs2/btree.c| 7 +-- fs/nilfs2/dat.c | 2 -- fs/nilfs2/recovery.c | 4 ++-- fs/nilfs2/segment.c | 3 +-- fs/nilfs2/sufile.c | 3 +-- fs/nilfs2/super.c| 5 - 7 files changed, 10 insertions(+), 17 deletions(-) -- 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 net-next v2 1/2] hisilicon net: removes the once HANDEL_TX_MSG macro
On 2015/10/12 11:24, Joe Perches wrote: Hello Huang. On Mon, 2015-10-12 at 11:23 +0800, huangdaode wrote: This patch changes the code style to make the code more simple. also removes the once used HNADEL_TX_MSG macro, according to the HANDEL_TX_MSG typo review comments from Joe Perches. Signed-off-by: huangdaode Reviewed-by: Joe Perches I didn't review this. ' Hi Joe please refer to http://lists.openwall.net/netdev/2015/10/11/61 thanks. Please do not add signatures for another person when not specifically added by that person. . -- Best Regards Daode Huang -- 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 net-next v2 1/2] hisilicon net: removes the once HANDEL_TX_MSG macro
Hello Huang. On Mon, 2015-10-12 at 11:23 +0800, huangdaode wrote: > This patch changes the code style to make the code more simple. > also removes the once used HNADEL_TX_MSG macro, according to the HANDEL_TX_MSG typo > review comments from Joe Perches. > > Signed-off-by: huangdaode > Reviewed-by: Joe Perches I didn't review this. Please do not add signatures for another person when not specifically added by that person. -- 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 tip tree with the crypto tree
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/Makefile
between commit:
e38b6b7fcfd1 ("crypto: x86/sha - Add build support for Intel SHA Extensions
optimized SHA1 and SHA256")
from the crypto tree and commit:
7b956f035a9e ("x86/asm: Re-add parts of the manual CFI infrastructure")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/Makefile
index a8009c77918a,2dfaa72260b4..
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@@ -165,11 -171,9 +171,11 @@@ asinstr += $(call as-instr,pshufb %xmm0
asinstr += $(call as-instr,crc32l %eax$(comma)%eax,-DCONFIG_AS_CRC32=1)
avx_instr := $(call as-instr,vxorps
%ymm0$(comma)%ymm1$(comma)%ymm2,-DCONFIG_AS_AVX=1)
avx2_instr :=$(call as-instr,vpbroadcastb
%xmm0$(comma)%ymm1,-DCONFIG_AS_AVX2=1)
+sha1_ni_instr :=$(call as-instr,sha1msg1
%xmm0$(comma)%xmm1,-DCONFIG_AS_SHA1_NI=1)
+sha256_ni_instr :=$(call as-instr,sha256msg1
%xmm0$(comma)%xmm1,-DCONFIG_AS_SHA256_NI=1)
- KBUILD_AFLAGS += $(asinstr) $(avx_instr) $(avx2_instr) $(sha1_ni_instr)
$(sha256_ni_instr)
- KBUILD_CFLAGS += $(asinstr) $(avx_instr) $(avx2_instr) $(sha1_ni_instr)
$(sha256_ni_instr)
-KBUILD_AFLAGS += $(cfi) $(cfi-sigframe) $(cfi-sections) $(asinstr)
$(avx_instr) $(avx2_instr)
-KBUILD_CFLAGS += $(cfi) $(cfi-sigframe) $(cfi-sections) $(asinstr)
$(avx_instr) $(avx2_instr)
++KBUILD_AFLAGS += $(cfi) $(cfi-sigframe) $(cfi-sections) $(asinstr)
$(avx_instr) $(avx2_instr) $(sha1_ni_instr) $(sha256_ni_instr)
++KBUILD_CFLAGS += $(cfi) $(cfi-sigframe) $(cfi-sections) $(asinstr)
$(avx_instr) $(avx2_instr) $(sha1_ni_instr) $(sha256_ni_instr)
LDFLAGS := -m elf_$(UTS_MACHINE)
--
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 v5 0/5] Provide better MADT subtable sanity checks
On 10/05/2015 10:12 AM, Al Stone wrote: On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote: On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote: On 09/30/2015 03:00 AM, Hanjun Guo wrote: On 2015/9/30 7:45, Al Stone wrote: NB: this patch set is for use against the linux-pm bleeding edge branch. [snip...] For this patch set, Reviewed-by: Hanjun Guo Thanks Hanjun Thanks, Hanjun! Series applied, thanks! Rafael Thanks, Rafael! Just decided to test out linux-next (to see the new nouveau cleanups). This change set prevents my Lenovo W510 from booting properly. Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to eventually replace the macro" Gets the system booting again. I'm attaching my dmesg from the failed boot, who wants the acpidump? [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.3.0-rc4-next-20151009-linux+ (s0be@anvil) (gcc version 4.9.3 (Gentoo 4.9.3 p1.1, pie-0.6.2) ) #271 SMP Sun Oct 11 16:37:37 PDT 2015 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.3.0-rc4 root=UUID=815266d6-a8b9-4f63-a593-02fde178263f ro net.ifnames=0 rfkill.default_state=0 init=/sbin/init intel_iommu=on nouveau.pstate=1 nouveau.config=NvClkMode=3 zram.zram_num_devices=4 zram.num_devices=4 ro [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'lazy' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbba7bfff] usable [0.00] BIOS-e820: [mem 0xbba7c000-0xbba81fff] reserved [0.00] BIOS-e820: [mem 0xbba82000-0xbbb47fff] usable [0.00] BIOS-e820: [mem 0xbbb48000-0xbbb5afff] reserved [0.00] BIOS-e820: [mem 0xbbb5b000-0xbbbdbfff] ACPI NVS [0.00] BIOS-e820: [mem 0xbbbdc000-0xbbc0efff] reserved [0.00] BIOS-e820: [mem 0xbbc0f000-0xbbc5cfff] usable [0.00] BIOS-e820: [mem 0xbbc5d000-0xbbe67fff] reserved [0.00] BIOS-e820: [mem 0xbbe68000-0xbbee7fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbbee8000-0xbbf0efff] reserved [0.00] BIOS-e820: [mem 0xbbf0f000-0xbbf17fff] usable [0.00] BIOS-e820: [mem 0xbbf18000-0xbbf1efff] reserved [0.00] BIOS-e820: [mem 0xbbf1f000-0xbbf6bfff] usable [0.00] BIOS-e820: [mem 0xbbf6c000-0xbbf79fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbbf7a000-0xbbf7cfff] ACPI data [0.00] BIOS-e820: [mem 0xbbf7d000-0xbbf80fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbbf81000-0xbbf81fff] ACPI data [0.00] BIOS-e820: [mem 0xbbf82000-0xbbf8afff] ACPI NVS [0.00] BIOS-e820: [mem 0xbbf8b000-0xbbf8bfff] ACPI data [0.00] BIOS-e820: [mem 0xbbf8c000-0xbbf9efff] ACPI NVS [0.00] BIOS-e820: [mem 0xbbf9f000-0xbbffefff] ACPI data [0.00] BIOS-e820: [mem 0xbbfff000-0xbbff] usable [0.00] BIOS-e820: [mem 0xbc00-0xbdff] reserved [0.00] BIOS-e820: [mem 0xbf80-0xbfff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfeaff000-0xfeaf] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00043fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] DMI: LENOVO 4318CTO/4318CTO, BIOS 6NET84WW (1.45 ) 10/03/2012 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x44 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 disabled [0.00] 1 base 0 mask F8000 write-back [0.00] 2 base 08000 mask FC
[PATCH net-next v2 0/2] hisilicon net: fix some bugs in HNS drivers
This patchset fixes the two bugs in HNS driver, one is change the code style according to the review comments from Joe Perches, another is fixing the wrong mac_id judgement bug which is found during internal tests. change log: v2 1) remove first bug fix, which is fixed in another patch submitted by Arnd Bergmann 2) change the code sytyle according to Joe. v1 initial version. huangdaode (2): hisilicon net: removes the once HANDEL_TX_MSG macro hisilicon net: fix a bug on Hisilicon Network Subsystem drivers/net/ethernet/hisilicon/hns/hnae.c | 45 +++ drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 2 +- 2 files changed, 23 insertions(+), 24 deletions(-) -- 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 net-next v2 1/2] hisilicon net: removes the once HANDEL_TX_MSG macro
This patch changes the code style to make the code more simple.
also removes the once used HNADEL_TX_MSG macro, according to the
review comments from Joe Perches.
Signed-off-by: huangdaode
Reviewed-by: Joe Perches
---
drivers/net/ethernet/hisilicon/hns/hnae.c | 45 +++
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c
b/drivers/net/ethernet/hisilicon/hns/hnae.c
index f52e99a..40f5779 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.c
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
@@ -439,40 +439,39 @@ EXPORT_SYMBOL(hnae_ae_unregister);
static ssize_t handles_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- ssize_t s = 0;
+ char *s = buf;
struct hnae_ae_dev *hdev = cls_to_ae_dev(dev);
struct hnae_handle *h;
int i = 0, j;
list_for_each_entry_rcu(h, &hdev->handle_list, node) {
- s += sprintf(buf + s, "handle %d (eport_id=%u from %s):\n",
+ s += sprintf(s, "handle %d (eport_id=%u from %s):\n",
i++, h->eport_id, h->dev->name);
for (j = 0; j < h->q_num; j++) {
- s += sprintf(buf + s, "\tqueue[%d] on %p\n",
+ s += sprintf(s, "\tqueue[%d] on %p\n",
j, h->qs[i]->io_base);
-#define HANDEL_TX_MSG "\t\ttx_ring on %p:%u,%u,%u,%u,%u,%llu,%llu\n"
- s += sprintf(buf + s,
-HANDEL_TX_MSG,
-h->qs[i]->tx_ring.io_base,
-h->qs[i]->tx_ring.buf_size,
-h->qs[i]->tx_ring.desc_num,
-h->qs[i]->tx_ring.max_desc_num_per_pkt,
-h->qs[i]->tx_ring.max_raw_data_sz_per_desc,
-h->qs[i]->tx_ring.max_pkt_size,
-h->qs[i]->tx_ring.stats.sw_err_cnt,
-h->qs[i]->tx_ring.stats.io_err_cnt);
- s += sprintf(buf + s,
- "\t\trx_ring on %p:%u,%u,%llu,%llu,%llu\n",
- h->qs[i]->rx_ring.io_base,
- h->qs[i]->rx_ring.buf_size,
- h->qs[i]->rx_ring.desc_num,
- h->qs[i]->rx_ring.stats.sw_err_cnt,
- h->qs[i]->rx_ring.stats.io_err_cnt,
- h->qs[i]->rx_ring.stats.seg_pkt_cnt);
+ s += sprintf(s,
+ "\t\ttx_ring on
%p:%u,%u,%u,%u,%u,%llu,%llu\n",
+ h->qs[i]->tx_ring.io_base,
+ h->qs[i]->tx_ring.buf_size,
+ h->qs[i]->tx_ring.desc_num,
+ h->qs[i]->tx_ring.max_desc_num_per_pkt,
+ h->qs[i]->tx_ring.max_raw_data_sz_per_desc,
+ h->qs[i]->tx_ring.max_pkt_size,
+ h->qs[i]->tx_ring.stats.sw_err_cnt,
+ h->qs[i]->tx_ring.stats.io_err_cnt);
+ s += sprintf(s,
+ "\t\trx_ring on %p:%u,%u,%llu,%llu,%llu\n",
+ h->qs[i]->rx_ring.io_base,
+ h->qs[i]->rx_ring.buf_size,
+ h->qs[i]->rx_ring.desc_num,
+ h->qs[i]->rx_ring.stats.sw_err_cnt,
+ h->qs[i]->rx_ring.stats.io_err_cnt,
+ h->qs[i]->rx_ring.stats.seg_pkt_cnt);
}
}
- return s;
+ return s - buf;
}
static DEVICE_ATTR_RO(handles);
--
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 net-next v2 2/2] hisilicon net: fix a bug on Hisilicon Network Subsystem
This patch fixes the wrong judgement of mac_id when get port num.
Signed-off-by: huangdaode
Signed-off-by: yankejian
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index 95bf42a..e162e4a 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -179,7 +179,7 @@ static int hns_mac_get_inner_port_num(struct hns_mac_cb
*mac_cb,
return -EINVAL;
}
} else if (mac_cb->dsaf_dev->dsaf_mode < DSAF_MODE_MAX) {
- if (mac_cb->mac_id <= DSAF_MAX_PORT_NUM_PER_CHIP) {
+ if (mac_cb->mac_id >= DSAF_MAX_PORT_NUM_PER_CHIP) {
dev_err(mac_cb->dev,
"input invalid,%s mac%d vmid%d!\n",
mac_cb->dsaf_dev->ae_dev.name,
--
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: Re: [PATCH] panic: release stale console lock to always get the logbuf printed out
Hi Jan,
[auto build test ERROR on v4.3-rc4 -- if it's inappropriate base, please ignore]
config: arm64-allnoconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
kernel/printk/printk.c: In function 'printk_log_buf_drain':
>> kernel/printk/printk.c:2410:3: error: implicit declaration of function
>> 'zap_locks' [-Werror=implicit-function-declaration]
zap_locks();
^
cc1: some warnings being treated as errors
vim +/zap_locks +2410 kernel/printk/printk.c
2404 void printk_log_buf_drain(bool panic)
2405 {
2406 bool retry;
2407 unsigned long flags;
2408
2409 if (panic)
> 2410 zap_locks();
2411
2412 while (1) {
2413 raw_spin_lock_irqsave(&logbuf_lock, flags);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
bindeb-pkg error (was Re: kbuild misc changes for v4.3-rc1 )
Hi Michal, On Tue, Sep 8, 2015 at 11:38 AM, Michal Marek wrote: > Hi Linus, > > these are the non-core kbuild changes for 4.3-rc1: > - deb-pkg: > + module signing fix > + dtb files are added to the package > + do not require `hostname -f` to work during build > + make deb-pkg generates a source package, bindeb-pkg has been added > to only generate the binary package It would have been great to not change the functionality of the target. Instead you could have added srcdeb-pkg to generate both the source and binary. Other than that, I keep seeing these errors now: dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-deb: building package `linux-firmware-image-4.3.0-rc4+' in `../linux-firmware-image-4.3.0-rc4+_4.3.0-rc4+-8_powerpc.deb'. dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-deb: building package `linux-headers-4.3.0-rc4+' in `../linux-headers-4.3.0-rc4+_4.3.0-rc4+-8_powerpc.deb'. dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-deb: building package `linux-libc-dev' in `../linux-libc-dev_4.3.0-rc4+-8_powerpc.deb'. dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe dpkg-deb: building package `linux-image-4.3.0-rc4+' in `../linux-image-4.3.0-rc4+_4.3.0-rc4+-8_powerpc.deb'. dpkg-genchanges: warning: package linux-image-4.3.0-rc4 listed in files list but not in control info dpkg-genchanges: warning: package linux-firmware-image-4.3.0-rc4 listed in files list but not in control info dpkg-genchanges: warning: package linux-headers-4.3.0-rc4 listed in files list but not in control info dpkg-genchanges: binary-only upload (no source code included) Use of uninitialized value $b in string eq at /usr/share/perl5/Dpkg/Arch.pm line 399. Use of uninitialized value $arch in pattern match (m//) at /usr/share/perl5/Dpkg/Arch.pm line 335. Use of uninitialized value $arch in hash element at /usr/share/perl5/Dpkg/Arch.pm line 340. dpkg-genchanges: error: cannot fstat file ../linux-firmware-image-4.3.0-rc4_4.3.0-rc4-7_powerpc.deb: No such file or directory scripts/package/Makefile:97: recipe for target 'bindeb-pkg' failed make[1]: *** [bindeb-pkg] Error 2 Makefile:1226: recipe for target 'bindeb-pkg' failed make: *** [bindeb-pkg] Error 2 Any idea on how to fix this? Thanks, Pranith -- 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/5] mmc: sdhci-pxav3: enable usage of DAT3 pin as HW card detect
Hi Marcin,
On Sat, 10 Oct 2015 14:13:51 +0200
Marcin Wojtas wrote:
> Hi Jisheng,
>
>
> >>
> >> >>
> >> >> When using DAT3-based detection Armada 38x SDIO IP expects its internal
> >> >> clock to be always on, which had to be ensured twofold:
> >> >
> >> > What happen if runtime suspend disables its core clk and axi clk? I guess
> >> > dat3-based detection isn't compatible with runtime pm. If so, do we also
> >> > need to disable runtime pm in probe function?
> >>
> >> Is runtime resume supposed to be triggered by card detection? Is there
> >
> > I think so. Take marvell berlin for example, card insert => gpio interrupt
> > or => sdhci runtime resume.
> >
> >> a way to manually trigger runtime suspend and resume of sdhci? Anyway
> >
> > If runtime-pm is builtin and the host driver supports runtime-pm
> > (sdhci-pxav3
> > supports runtime-pm well), when there's no sdhc transactions, runtime
> > suspend
> > will be triggered automatically after some time (50ms?)
> >
> >> coreclk is not a problem, as it's not used by A38x.
> >
> > I checked A38x dts files, it's <&gateclk 17>. So the question is: what will
> > happen if <&gateclk 17> is disabled in runtime suspend? Is the dat3-based
> > CD still works? In theory, it should not work any more.
> >
>
> Actually in pxav3 driver there is one obligatory clock ("io") which
> can be either named in dts on not (like in armada38x.dtsi). "coreclk"
> is optional, however all this does not matter, as both are disabled in
Hmm, grep the dts, I think commit 8afdc9cca27f ("mmc: sdhci-pxav3: Get optional
core clock") mainly targets for Marvell Berlin SoCs, but the two clks for sdhci
in Berlin SoCs are coreclk and axiclk, rather than ioclk and coreclk, during
which the axiclk is optional. Will cook one patch to fix this.
> runtime_suspend function. I think that when we disable the gate clock,
> dat3 detection won't work, but I guess that card detection is not the
> only thing that wakes up the mmc subsystem and make runtime_pm useful.
Card insert is not the only thing can wake up mmc, mmc initiate sdhc
transactions will also wake up mmc.
Thanks,
Jisheng
>
> I will try to check how it works. If there's problem with detection I
> propose, in order not to spoil the code too much and not to loose all
> runtime_pm benefits, to avoid disabling/enabling clock in
> runtime_suspend/resume functions on a38x working with dat3 detection.
> In such case sdhci_runtime_suspend/resume would execute without
> problems and we will be sure that detection will work in such
> configuration.
>
> Best regards,
> Marcin
--
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: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift
On Sun, 2015-10-11 at 22:22 +0800, Fengguang Wu wrote: > > > > So do you mind adding linuxppc-...@lists.ozlabs.org ? :) > > > > It's pretty low traffic compared to lkml. > > Sure, I'm subscribing to it. :) Thanks. 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/
Re: [PATCH v6 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range
On 10/12/2015 08:49 AM, Krzysztof Kozlowski wrote: On 12.10.2015 09:37, Yakir Yang wrote: Hi Krzysztof, On 10/10/2015 11:46 PM, Yakir Yang wrote: Both hsync/vsync polarity and interlace mode can be parsed from drm display mode, and dynamic_range and ycbcr_coeff can be judge by the video code. But presumably Exynos still relies on the DT properties, so take good use of mode_fixup() in to achieve the compatibility hacks. Signed-off-by: Yakir Yang --- Changes in v6: None +of_property_read_u32(dp_node, "hsync-active-high", + &video->h_sync_polarity); +of_property_read_u32(dp_node, "vsync-active-high", + &video->v_sync_polarity); +of_property_read_u32(dp_node, "interlaced", + &video->interlaced); +} Sorry, forget to fix your previous comment here, would remember to fix it to v7 version, wish v6 would collect more comment/reviewed/ack. :) Right. You can send a v7 of only this patch. In the same time I would prefer not to chain-reply next version of entire patchset to cover letter of previous version. It confuses me because v6 appears UNDER v4 so I can't really find v6. I see v4 at the top of my email list. Okay, I wish this chain-reply would make people easy to find the previous comments, but actually it is little mess now. I would give up this way to send patchset :) In the same time the patchset is quite big. Put the latest version (with this issue above fixed!) on some repo and link it in cover letter. Yeah, it's quite big now, I would like to back the patchset to previous format, like: ---> [PATCH v6 00/17] Cover letter |> [PATCH v6 01/17] |> [PATCH ..] |> [PATCH v6 05/17] |> [PATCH v7 05/17] |> [PATCH ..] |> [PATCH v6 17/17] Is it right, and can resend the v6 to fix this chain-reply issue with RESEND flag ([PATCH RESEND v6 ...]) ? ---> [PATCH RESEND v6 00/17] Cover letter |> [PATCH RESEND v6 01/17] |> [PATCH ..] |> [PATCH RESEND v6 05/17] |> [PATCH v7 05/17] |> [PATCH ..] |> [PATCH RESEND v6 17/17] Thanks :-) - Yakir Best regards, Krzysztof Best regards, - Yakir Changes in v5: - Switch video timing type to "u32", so driver could use "of_property_read_u32" to get the backword timing values. Krzysztof suggest me that driver could use the "of_property_read_bool" to get backword timing values, but that interfacs would modify the original drm_display_mode timing directly (whether those properties exists or not). Changes in v4: - Provide backword compatibility with samsung. (Krzysztof) Changes in v3: - Dynamic parse video timing info from struct drm_display_mode and struct drm_display_info. (Thierry) Changes in v2: None -- 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 v5 0/7] arm64: berlin: add pinctrl support
On Sun, 11 Oct 2015 00:36:36 +0200 Antoine Tenart wrote: > Hi Jisheng, > > Please keep Acked-by tags when you submit a new version of a series. Got it. I dunno this before, will take care in the future. Thanks a lot for your review, Jisheng > > Thanks, > > Antoine > > On Fri, Oct 09, 2015 at 07:56:43PM +0800, Jisheng Zhang wrote: > > This series adds support for Marvell berlin4ct pin-controller, allowing > > to configure the pin muxing from the device tree. > > > > Since v4: > > - drop ARCH_BERLIN dependency for it has been met > > - drop COMPILE_TEST dependency but make berlin pinctrl driver visible > >if COMPILE_TEST=y, and let this change be a seperate commit. > > > > Since v3: > > - fix stupid build error: I missed local changes to berlin-bg4ct.c > > > > Since v2: > > - introduce new berlin_pinctrl_probe_regmap() to avoid duplicated code > > - renaming such as s/urt/uart etc. but keep the group name as URT* to keep > >consistent with HW/ASIC > > > > Since v1: > > - use generic name for pin functions > > - a new commit to add pinmux for uart0 > > - correct pinctrl usage in dts > > > > > > Jisheng Zhang (7): > > pinctrl: berlin: introduce berlin_pinctrl_probe_regmap() > > pinctrl: berlin: Make berlin pinctrl driver visible if COMPILE_TEST=y > > pinctrl: berlin: add the berlin4ct pinctrl driver > > arm64: berlin: add the pinctrl dependency for Marvell Berlin SoCs > > pinctrl: dt-binding: document berlin4ct SoC pinctrl > > arm64: dts: berlin4ct: add the pinctrl node > > arm64: dts: berlin4ct: add default pinmux for uart0 > > > > .../devicetree/bindings/pinctrl/berlin,pinctrl.txt | 5 +- > > arch/arm64/Kconfig.platforms | 1 + > > arch/arm64/boot/dts/marvell/berlin4ct.dtsi | 22 + > > drivers/pinctrl/berlin/Kconfig | 7 +- > > drivers/pinctrl/berlin/Makefile| 1 + > > drivers/pinctrl/berlin/berlin-bg4ct.c | 503 > > + > > drivers/pinctrl/berlin/berlin.c| 26 +- > > drivers/pinctrl/berlin/berlin.h| 4 + > > 8 files changed, 558 insertions(+), 11 deletions(-) > > create mode 100644 drivers/pinctrl/berlin/berlin-bg4ct.c > > > > -- > > 2.6.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] MAINTAINERS: add Mediatek usb3 phy driver
Add Mediatek usb3 phy driver to maintainer entry. Signed-off-by: Chunfeng Yun --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 7ba7ab7..be0055c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1291,6 +1291,13 @@ F: arch/arm/mach-mediatek/ N: mtk K: mediatek +ARM/Mediatek USB3 PHY DRIVER +M: Chunfeng Yun +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/phy/phy-mt65xx-usb3.c + ARM/MICREL KS8695 ARCHITECTURE M: Greg Ungerer 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/
Re: [PATCH 00/16] Divorcing irqdomain and device_node
On 10/12/2015 05:01 AM, Thomas Gleixner wrote:
On Tue, 6 Oct 2015, Marc Zyngier wrote:
[This patch series used to be called "Making the generic ACPI GSI
layer irqdomain aware", but as I've radically changed my approach to
this problem, I've decided to reset the counters...]
The irqdomain code is not entierely ACPI friendly, as it has some
built-in knowledge of the device-tree. Nothing too harmful, but enough
to scare the ARM ACPI developpers which end up with their own version
of the square wheel. And some of the ramifications actually run deeper
than initially expected.
This series adapts the irqdomain code to use 'struct fwnode_handle'
instead of 'struct device_node' as the identifier for a domain
(compatibility interfaces are of course added). It also introduces a
generic IRQ specifier that firmware interfaces (DT or ACPI) can
directly use to configure interrupts, and allow the ACPI GSI code to
be plugged into this.
As examples, we convert the ARM GIC ACPI support to use irqdomains as
originally intended, and rework the MSI code to also move away from
using device nodes when using irqdomains.
Overall, this gives us a way to use irqdomains on both DT and ACPI
enabled platforms, having very little changes made to the actual
drivers (other than the probing infrastructure). Because we keep the
flow of information between the various layers identical between ACPI
and DT, we immediately benefit from the existing infrastructure.
This has been test-booted on Juno, is based on 4.3-rc4, and available at:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/irq-domain-fwnode-v1
Marc Zyngier (16):
irqdomain: Use an accessor for the of_node field
irqdomain: Convert irqdomain->of_node to fwnode
irqdomain: Allow irq domain lookup by fwnode
irqdomain: Introduce a firmware-specific IRQ specifier structure
irqchip: Convert all alloc/xlate users from of_node to fwnode
irqdomain: Introduce irq_create_fwspec_mapping
irqdomain: Introduce irq_domain_create_{linear,tree}
irqdomain: Add a fwnode_handle allocator
acpi/gsi: Always perform an irq domain lookup
acpi/gsi: Add acpi_set_irq_model to initialize the GSI layer
irqchip/gic: Get rid of gic_init_bases()
irqchip/gic: Switch ACPI support to stacked domains
irqchip/gic: Kill the xlate method
acpi/gsi: Cleanup acpi_register_gsi
irqdomain: Introduce irq_domain_create_hierarchy
irqdomain/msi: Use fwnode instead of of_node
I really like this one way better than the previous attempts and I
couldn't find any real issue when going through them with a fine comb.
Fully agree, this version removes the dependency on DT for ACPI.
I'd like to get that into 4.4, so I have to ask for the opinion of
ACPI folks. Having an ack on those patches would be nice.
I'm reviewing this patch set, and will have a test today.
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/
[RFC] mm: fix a BUG, the page is allocated 2 times
Remove unlikely(order), because we are sure order is not zero if
code reach here, also add if (page == NULL), only allocate page again if
__rmqueue_smallest() failed or alloc_flags & ALLOC_HARDER == 0
Signed-off-by: yalin wang
---
mm/page_alloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0d6f540..de82e2c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2241,13 +2241,13 @@ struct page *buffered_rmqueue(struct zone
*preferred_zone,
spin_lock_irqsave(&zone->lock, flags);
page = NULL;
- if (unlikely(order) && (alloc_flags & ALLOC_HARDER)) {
+ if (alloc_flags & ALLOC_HARDER) {
page = __rmqueue_smallest(zone, order,
MIGRATE_HIGHATOMIC);
if (page)
trace_mm_page_alloc_zone_locked(page, order,
migratetype);
}
-
- page = __rmqueue(zone, order, migratetype, gfp_flags);
+ if (page == NULL)
+ page = __rmqueue(zone, order, migratetype, gfp_flags);
spin_unlock(&zone->lock);
if (!page)
goto failed;
--
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/
linux-next: manual merge of the jc_docs tree with Linus' tree
Hi Jonathan,
Today's linux-next merge of the jc_docs tree got a conflict in:
Documentation/Changes
between commit:
283e8ba2dfde ("MODSIGN: Change from CMS to PKCS#7 signing if the openssl is
too old")
from Linus' tree and commit:
1c3a54e257f7 ("Documentation/Changes: Add bc in "Current Minimal
Requirements" section")
from the jc_docs tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc Documentation/Changes
index f447f0516f07,268a849c4cc0..
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@@ -43,7 -43,8 +43,8 @@@ o udev 08
o grub 0.93# grub --version ||
grub-install --version
o mcelog 0.6 # mcelog --version
o iptables 1.4.2 # iptables -V
-o openssl & libcrypto1.0.1k # openssl version
+o openssl & libcrypto1.0.0 # openssl version
+ o bc 1.06.95 # bc --version
Kernel compilation
--
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] Input: cyapa: remove variable overwriting
> -Original Message-
> From: Sudip Mukherjee [mailto:sudipm.mukher...@gmail.com]
> Sent: 2015?9?29? 14:48
> To: Dmitry Torokhov
> Cc: Dudley Du; lkml; linux-in...@vger.kernel.org
> Subject: Re: [PATCH] Input: cyapa: remove variable overwriting
>
> On Mon, Sep 28, 2015 at 03:43:04PM -0700, Dmitry Torokhov wrote:
> > Hi Sudip,
> >
> > On Tue, Sep 15, 2015 at 3:06 AM, Sudip Mukherjee
> > wrote:
> > > Even if rotat_align is true or false the final value of
> > > cyapa->electrodes_rx is always cyapa->electrodes_y. remove the variable
> > > overwriting and in the process remove the variable rotat_align which is
> > > not required any more.
> > >
> > > Signed-off-by: Sudip Mukherjee
> > > ---
> > > drivers/input/mouse/cyapa_gen6.c | 10 +-
> > > 1 file changed, 1 insertion(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/input/mouse/cyapa_gen6.c
> b/drivers/input/mouse/cyapa_gen6.c
> > > index 5f19107..f0c614b 100644
> > > --- a/drivers/input/mouse/cyapa_gen6.c
> > > +++ b/drivers/input/mouse/cyapa_gen6.c
> > > @@ -196,7 +196,6 @@ static int cyapa_gen6_read_sys_info(struct cyapa
> *cyapa)
> > > u8 resp_data[PIP_READ_SYS_INFO_RESP_LENGTH];
> > > int resp_len;
> > > u16 product_family;
> > > - u8 rotat_align;
> > > int error;
> > >
> > > /* Get App System Information to determine Gen5 or Gen6. */
> > > @@ -241,14 +240,7 @@ static int cyapa_gen6_read_sys_info(struct cyapa
> *cyapa)
> > > memcpy(&cyapa->product_id[13], &resp_data[62], 2);
> > > cyapa->product_id[15] = '\0';
> > >
> > > - rotat_align = resp_data[68];
> > > - if (rotat_align) {
> > > - cyapa->electrodes_rx = cyapa->electrodes_y;
> > > - cyapa->electrodes_rx = cyapa->electrodes_y;
> > > - } else {
> > > - cyapa->electrodes_rx = cyapa->electrodes_x;
> > > - cyapa->electrodes_rx = cyapa->electrodes_y;
> > > - }
> > > + cyapa->electrodes_rx = cyapa->electrodes_y;
> >
> > II think it was probably a typo rather than rotat_align being not
> > needed. Dudley?
> maybe some copy paste error. I thought it might have been
> cyapa->electrodes_ry but there is nothing like that.
Thanks for the correction. It should be my copy issue.
The variable cyapa->electrodes_rx was used to store the real physical Rx
electrode direction.
Because the Rx direction in the signal data map may direction for the physical
Rx electrode direction.
so it must be rotated when read and use the signal data map data.
This variable was currently used in for read the baseline of the Gen5 trackpad
device.
And also it was used by the application to help display the real signal map on
the trackpad device.
Following is the correction of this code, I will submit the patch to fix this
thanks.
-if (rotat_align) {
+if (rotat_align)
cyapa->electrodes_rx = cyapa->electrodes_y;
-cyapa->electrodes_rx = cyapa->electrodes_y;
- } else {
+else
cyapa->electrodes_rx = cyapa->electrodes_x;
-cyapa->electrodes_rx = cyapa->electrodes_y;
- }
>
> regards
> sudip
This message and any attachments may contain Cypress (or its subsidiaries)
confidential information. If it has been received in error, please advise the
sender and immediately delete this message.
--
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 net-next 0/2] net: fix some bugs in HNS drivers
On 2015/10/11 20:02, David Miller wrote: From: huangdaode Date: Thu, 8 Oct 2015 14:17:23 +0800 This patchset fixes the two bugs in HNS driver, one is for fixing the compilation warning bug on arm 32-bit platform, another is fixing the wrong mac port judgement bug which is found during internal tests. This patch series does not apply to the net-next tree at all. Also, both patches should use a subsystem prefix of "hisilicon: " in the Subject lines. Thanks. . Thanks David, Because it conflicts with arnd's patches, which fixes this bug. in the mail, Joe Perches advised another fix, we will send out the patch soon. thanks -- Best Regards Daode Huang -- 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 net-next] RDS-TCP: Reset tcp callbacks if re-using an outgoing socket in rds_tcp_accept_one()
On 10/11/15 1:49 PM, Sowmini Varadhan wrote:
Consider the following "duelling syn" sequence between two peers A and B:
A B
SYN1 -->
<-- SYN2
SYN2ACK -->
Note that the SYN/ACK has already been sent out by TCP before
rds_tcp_accept_one() gets invoked as part of callbacks.
If the inet_addr(A) is numerically less than inet_addr(B),
the arbitration scheme in rds_tcp_accept_one() will prefer the
TCP connection triggered by SYN1, and will send a CLOSE for the
SYN2 (just after the SYN2ACK was sent).
Since B also follows the same arbitration scheme, it will send the SYN-ACK
for SYN1 that will set up a healthy ESTABLISHED connection on both sides.
B will also get a CLOSE for SYN2, which should result in the cleanup
of the TCP state machine for SYN2, but it should not trigger any
stale RDS-TCP callbacks (such as ->writespace, ->state_change etc),
that would disrupt the progress of the SYN2 based RDS-TCP connection.
Thus the arbitration scheme in rds_tcp_accept_one() should restore
rds_tcp callbacks for the winner before setting them up for the
new accept socket, and also make sure that conn->c_outgoing
is set to 0 so that we do not trigger any reconnect attempts on the
passive side of the tcp socket in the future, in conformance with
commit c82ac7e69efe ("net/rds: RDS-TCP: only initiate reconnect attempt
on outgoing TCP socket.")
Signed-off-by: Sowmini Varadhan
---
Looks fine to me.
Acked-by: Santosh Shilimkar
--
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 v6 00/25] Re-use nvram module
Hi Laurent, On Sun, 11 Oct 2015, Laurent Vivier wrote: > On 23/08/2015 12:41, Finn Thain wrote: ... > > This patch series has been compile-tested for arm, m68k, powerpc and > > x86. The nvram and thinkpad_acpi modules were regression tested on a > > ThinkPad T43. The /dev/nvram functionality was also regression tested > > on a G3 PowerMac. The nvram module was also tested on a PowerBook 520, > > Quadra 650 and Atari Falcon. AFAIK, no testing has been done on PPC64 > > as yet. > > For PPC64, tested on a PowerMac G5 (PowerMac11,2), kernel 4.3.0-rc4 > with nvram tools 1.2.24 (Fedora 22 ppc64). > > Tested-by: Laurent Vivier > > Tests done: > # modinfo nvram > filename: /lib/modules/4.3.0-rc4+/kernel/drivers/char/nvram.ko > alias: devname:nvram > alias: char-major-10-144 > license:GPL > depends: > intree: Y > vermagic: 4.3.0-rc4+ SMP mod_unload > > # modprobe nvram > [ 364.655577] Non-volatile memory driver v1.3 > > # nvram --partitions > # Sig Chk Len Name > 0 5a 82 0002 nvram > 1 5f 45 003e system > 2 70 bd 00c1 common > 3 a0 1e 0052 APL,MacOS75 > 4 a1 15 0081 APL,OSXPanic > 5 7f 45 002c > > # nvram --dump "nvram" > 0x 5a820002 6e767261 6d00 |Z...nvram...| > 0x0010 cae8613d 01c9 |..a=| > > # nvram --print-config=boot-volume > 1 > > # nvram --update-config=boot-volume=6 > > # rmmod nvram > > # nvram --print-config=boot-volume > 6 > > # reboot > > # nvram --print-config=boot-volume > 6 > Thanks very much for taking the trouble to test this series. I will add your Tested-By tag to the relevant powerpc patches and re-send. Regards, Finn -- 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 net-next] RDS: Invoke ->laddr_check() in rds_bind() for explicitly bound transports.
On 10/11/15 1:46 PM, Sowmini Varadhan wrote:
The IP address passed to rds_bind() should be vetted by the
transport's ->laddr_check() for a previously bound transport.
This needs to be done to avoid cases where, for example,
the application has asked for an IB transport,
but the IP address passed to bind is only usable on
ethernet interfaces.
Right. Probably it should go into stable as well.
Signed-off-by: Sowmini Varadhan
---
net/rds/bind.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/net/rds/bind.c b/net/rds/bind.c
index bc6b93e..6192566 100644
--- a/net/rds/bind.c
+++ b/net/rds/bind.c
@@ -196,7 +196,14 @@ int rds_bind(struct socket *sock, struct sockaddr *uaddr,
int addr_len)
goto out;
if (rs->rs_transport) { /* previously bound */
- ret = 0;
Minor comment. If you retain above line you can drop the below else.
+ trans = rs->rs_transport;
+ if (trans->laddr_check(sock_net(sock->sk),
+ sin->sin_addr.s_addr) != 0) {
+ ret = -ENOPROTOOPT;
+ rds_remove_bound(rs);
+ } else {
+ ret = 0;
+ }
Acked-by: Santosh Shilimkar
--
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] arm64: ioremap: add ioremap_cache macro
Add ioremap_cache macro, because some code will test if this macro
is defined or not, and will generate a generric version if not defined,
for example, memremap.c do like this.
Signed-off-by: yalin wang
---
arch/arm64/include/asm/io.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 44be1e0..d6b620c 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -172,6 +172,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr,
size_t size);
#define ioremap_wc(addr, size) __ioremap((addr), (size),
__pgprot(PROT_NORMAL_NC))
#define ioremap_wt(addr, size) __ioremap((addr), (size),
__pgprot(PROT_DEVICE_nGnRE))
#define iounmap__iounmap
+#define ioremap_cache ioremap_cache
/*
* io{read,write}{16,32}be() macros
--
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 3/3] fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000
Hi Alan,
thanks for your feedback!
On Fri, Oct 9, 2015 at 8:09 PM, atull wrote:
> On Thu, 8 Oct 2015, Moritz Fischer wrote:
>
>> --- /dev/null
>> +++ b/drivers/fpga/zynq-fpga.c
>> @@ -0,0 +1,478 @@
>> +/*
>> + * Copyright (c) 2011-2015 Xilinx Inc.
>> + * Copyright (c) 2015, National Instruments Corp.
>> + *
>> + * FPGA Manager Driver for Xilinx Zynq, heavily based on xdevcfg driver
>> + * in their vendor tree.
>> + *
>> + * 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 of the License.
>> + *
>> + * 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
>
> Hi Moritz,
>
> That was fast! I just have a couple of very minor comments...
>
> Please alphabetize the #includes.
>
>> +
>> +/* Offsets into SLCR regmap */
>> +#define SLCR_FPGA_RST_CTRL_OFFSET0x240 /* FPGA Software Reset Control */
>> +#define SLCR_LVL_SHFTR_EN_OFFSET 0x900 /* Level Shifters Enable */
>> +
>> +/* Constant Definitions */
>> +#define CTRL_OFFSET 0x00 /* Control Register */
>> +#define LOCK_OFFSET 0x04 /* Lock Register */
>> +#define INT_STS_OFFSET 0x0c /* Interrupt Status Register */
>> +#define INT_MASK_OFFSET 0x10 /* Interrupt Mask Register */
>> +#define STATUS_OFFSET0x14 /* Status Register */
>> +#define DMA_SRC_ADDR_OFFSET 0x18 /* DMA Source Address Register */
>> +#define DMA_DEST_ADDR_OFFSET 0x1c /* DMA Destination Address Reg */
>> +#define DMA_SRC_LEN_OFFSET 0x20 /* DMA Source Transfer Length */
>> +#define DMA_DEST_LEN_OFFSET 0x24 /* DMA Destination Transfer */
>> +#define UNLOCK_OFFSET0x34 /* Unlock Register */
>> +#define MCTRL_OFFSET 0x80 /* Misc. Control Register */
>
> Please fix up the indenting.
Will do.
>
>> +
>> +/* Control Register Bit definitions */
>> +#define CTRL_PCFG_PROG_B_MASKBIT(30) /* Program signal to reset
>> FPGA */
>> +#define CTRL_PCAP_PR_MASKBIT(27) /* Enable PCAP for PR */
>> +#define CTRL_PCAP_MODE_MASK BIT(26) /* Enable PCAP */
>> +
>> +/* Miscellaneous Control Register bit definitions */
>> +#define MCTRL_PCAP_LPBK_MASK BIT(4) /* Internal PCAP loopback */
>> +
>> +/* Status register bit definitions */
>> +#define STATUS_PCFG_INIT_MASKBIT(4) /* FPGA init status */
>> +
>> +/* Interrupt Status/Mask Register Bit definitions */
>> +#define IXR_DMA_DONE_MASKBIT(13) /* DMA command done */
>> +#define IXR_D_P_DONE_MASKBIT(12) /* DMA and PCAP cmd done */
>> +#define IXR_PCFG_DONE_MASK BIT(2) /* FPGA programmed */
>> +#define IXR_ERROR_FLAGS_MASK 0x00F0F860
>> +#define IXR_ALL_MASK 0xF8F7F87F
>> +
>> +/* Miscellaneous constant values */
>> +#define DMA_INVALID_ADDRESS GENMASK(31, 0) /* Invalid DMA address */
>> +#define UNLOCK_MASK 0x757bdf0d /* Used to unlock the device */
>> +
>> +/* Masks for controlling stuff in SLCR */
>> +#define LVL_SHFTR_DISABLE_ALL_MASK 0x0 /* Disable all Level shifters */
>> +#define LVL_SHFTR_ENABLE_PS_TO_PL0xa /* Enable all Level shifters */
>> +#define LVL_SHFTR_ENABLE_PL_TO_PS0xf /* Enable all Level shifters */
>> +#define FPGA_RST_ALL_MASK0xf /* Enable global resets */
>> +#define FPGA_RST_NONE_MASK 0x0 /* Disable global resets */
>> +
>
>> +static int zynq_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
>> + const char *buf, size_t count)
>> +{
>> + struct zynq_fpga_priv *priv;
>> + u32 ctrl, status;
>> + int err;
>> +
>> + priv = mgr->priv;
>> +
>> + err = clk_enable(priv->clk);
>> + if (err)
>> + return err;
>
> You might not even need to enable/disable the clock if not doing PR.
Yeah, you're probably right.
>
>> +
>> + /* only reset if we're not doing partial reconfig */
>> + if (!(flags & FPGA_MGR_PARTIAL_RECONFIG)) {
>> + /* assert AXI interface resets */
>> + regmap_write(priv->slcr, SLCR_FPGA_RST_CTRL_OFFSET,
>> + FPGA_RST_ALL_MASK);
>> +
>> + /* disable level shifters */
>> + regmap_write(priv->slcr, SLCR_LVL_SHFTR_EN_OFFSET,
>> + LVL_SHFTR_DISABLE_ALL_MASK);
>> + /* enable output level shifters */
>> + regmap_write(priv->slcr, SLCR_LVL_SHFTR_EN_OFFSET,
>> + LVL_SHFTR_ENABLE_PS_TO_PL);
>> +
>> + /* create a rising edge on PCFG_INIT. PCFG_INIT follows
>> + * PCFG_PROG_B, so we
Re: [PATCH v3 5/5] ARM: sun5i: Add C.H.I.P DTS
On Mon, Oct 12, 2015 at 1:20 AM, Maxime Ripard
wrote:
> On Fri, Oct 09, 2015 at 11:22:23PM +0800, Chen-Yu Tsai wrote:
>> On Fri, Oct 9, 2015 at 4:42 PM, Maxime Ripard
>> wrote:
>> > The C.H.I.P. is a small SBC with an Allwinner R8, 8GB of NAND, 512MB of
>> > RAM, USB host and OTG, a wifi / bluetooth combo chip, an audio/video jack
>> > and two connectors to plug additional boards on top of it.
>> >
>> > Signed-off-by: Maxime Ripard
>> > Reviewed-by: Hans de Goede
>> > ---
>> > arch/arm/boot/dts/Makefile | 3 +-
>> > arch/arm/boot/dts/sun5i-r8-chip.dts | 213
>> >
>> > 2 files changed, 215 insertions(+), 1 deletion(-)
>> > create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts
>> >
>> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> > index 342ab3116feb..bf165ed4e7fa 100644
>> > --- a/arch/arm/boot/dts/Makefile
>> > +++ b/arch/arm/boot/dts/Makefile
>> > @@ -600,7 +600,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
>> > sun5i-a13-olinuxino.dtb \
>> > sun5i-a13-olinuxino-micro.dtb \
>> > sun5i-a13-q8-tablet.dtb \
>> > - sun5i-a13-utoo-p66.dtb
>> > + sun5i-a13-utoo-p66.dtb \
>> > + sun5i-r8-chip.dtb
>> > dtb-$(CONFIG_MACH_SUN6I) += \
>> > sun6i-a31-app4-evb1.dtb \
>> > sun6i-a31-colombus.dtb \
>> > diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts
>> > b/arch/arm/boot/dts/sun5i-r8-chip.dts
>> > new file mode 100644
>> > index ..0d450a828372
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
>>
>> snip
>>
>> > +®_dcdc2 {
>> > + regulator-min-microvolt = <100>;
>> > + regulator-max-microvolt = <140>;
>> > + regulator-name = "cpuvdd";
>>
>> Other boards seem to follow the power pin names on the SoC and call
>> this "vdd-cpu".
>>
>> > + regulator-always-on;
>> > +};
>> > +
>> > +®_dcdc3 {
>> > + regulator-min-microvolt = <100>;
>> > + regulator-max-microvolt = <130>;
>> > + regulator-name = "corevdd";
>>
>> And this was named "vdd-int" or "vdd-int-dll" (for SoCs with separate
>> VDD_DLL pins).
>>
>> > + regulator-always-on;
>> > +};
>> > +
>> > +®_ldo1 {
>> > + regulator-name = "rtcvdd";
>>
>> And this one was "vdd-rtc".
>>
>> I know you followed the names set in the design doc. Just wondering if there
>> should be some convention on these.
>
> I think if we have a document that clearly reference them with some
> other name, we should just stick with the name used there, especially
> if it's only cosmetic, which is the case here.
That's a good rule to follow. :)
>> > +};
>> > +
>> > +®_ldo2 {
>> > + regulator-min-microvolt = <270>;
>> > + regulator-max-microvolt = <330>;
>> > + regulator-name = "avcc";
>> > + regulator-always-on;
>> > +};
>> > +
>> > +®_ldo5 {
>> > + regulator-min-microvolt = <180>;
>> > + regulator-max-microvolt = <180>;
>> > + regulator-name = "vcc-1v8";
>> > +};
>> > +
>> > +®_usb0_vbus {
>> > + pinctrl-0 = <&chip_vbus_pin>;
>> > + vin-supply = <®_vcc5v0>;
>> > + gpio = <&pio 1 10 GPIO_ACTIVE_HIGH>; /* PB10 */
>>
>> status = "okay"; ?
>
> Ah, yes, indeed.
>
>> The rest looks good.
>
> Is that an Ack from you if I add the status ?
Yes. Thanks!
ChenYu
--
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/5] power_supply: charger-manager: add missing of_node_put
2015-10-10 21:30 GMT+09:00 Julia Lawall :
> for_each_child_of_node performs an of_node_get on each iteration, so
> a break out of the loop requires an of_node_put.
>
> The semantic patch that fixes this problem is as follows
> (http://coccinelle.lip6.fr):
>
> //
> @@
> expression root,e;
> local idexpression child;
> @@
>
> for_each_child_of_node(root, child) {
>... when != of_node_put(child)
>when != e = child
> (
>return child;
> |
> + of_node_put(child);
> ? return ...;
> )
>...
> }
> //
>
> Signed-off-by: Julia Lawall
>
> ---
> drivers/power/charger-manager.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
--
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: staging: wilc1000: WILC1000_DYNAMICALLY_ALLOCATE_MEMROY
On 2015년 10월 09일 03:47, Greg KH wrote: On Thu, Oct 08, 2015 at 09:29:35PM +0300, Stanislav Kholmanskikh wrote: Hi! I noticed that drivers/staging/wilc1000/Kconfic defines: config WILC1000_DYNAMICALLY_ALLOCATE_MEMROY bool "Dynamically allocate memory in real time" ---help--- This choice supports dynamic allocation of the memory for the receive buffer. The driver will allocate the RX buffer when it is required. "MEMROY" looks suspicious. Is it a typo (MEMORY?) or by intent? Probably a typo, but be sure to see if it lines up with what the code expects before changing anything. Ideally in the end this option should be removed as the driver should only do dynamic allocation, no static allocation should be needed. I agree with Greg's opinion. The team is now restructuring the driver and they will be removed and changed. Thanks for your valuable opinion, Tony. thanks, greg k-h -- 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: staging: wilc1000: WILC1000_DYNAMICALLY_ALLOCATE_MEMROY
On 2015년 10월 09일 03:29, Stanislav Kholmanskikh wrote: Hi! I noticed that drivers/staging/wilc1000/Kconfic defines: config WILC1000_DYNAMICALLY_ALLOCATE_MEMROY bool "Dynamically allocate memory in real time" ---help--- This choice supports dynamic allocation of the memory for the receive buffer. The driver will allocate the RX buffer when it is required. "MEMROY" looks suspicious. Is it a typo (MEMORY?) or by intent? These parts will be wholly changed but I need to get important driver updates. It will be done soon. Thanks for your review, Tony. 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] sched: disable task group re-weighting on the desktop
On Mon, 2015-10-12 at 06:46 +1100, paul.sz...@sydney.edu.au wrote: > Dear Mike, > > Did you check whether setting min_- and max_interval e.g. as per > https://lkml.org/lkml/2015/10/11/34 > would help with your issue (instead of your "horrible gs destroying" > patch)? I spent a lot of MY time looking into YOUR problem, only to be accused of actively avoiding reproduction thereof, and now you toss another cute little dart my way. Looking into your problem wasn't a complete waste of my time, as it led me to something that actually looks interesting. Thanks for that, and goodbye. *PLONK* -Mike -- 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 v8 4/6] pci: altera: Add Altera PCIe MSI driver
On Kha, 2015-10-08 at 22:05 +0200, Corentin LABBE wrote:
> > This patch adds Altera PCIe MSI driver. This soft IP supports configurable
> > number of vectors, which is a dts parameter.
> >
> > Signed-off-by: Ley Foon Tan
> > Reviewed-by: Marc Zyngier
> > +
> > +static inline void msi_writel(struct altera_msi *msi, u32 value, u32 reg)
> > +{
> > + writel_relaxed(value, msi->csr_base + reg);
> > +}
> > +
> > +static inline u32 msi_readl(struct altera_msi *msi, u32 reg)
> > +{
> > + return readl_relaxed(msi->csr_base + reg);
> > +}
> > +
>
> You could set value and reg parameter as const
Noted.
>
> > +
> > +static int altera_irq_domain_alloc(struct irq_domain *domain, unsigned int
> > virq,
> > + unsigned int nr_irqs, void *args)
> > +{
> > + struct altera_msi *msi = domain->host_data;
> > + unsigned long bit;
> > + u32 mask;
> > +
> > + WARN_ON(nr_irqs != 1);
> > + mutex_lock(&msi->lock);
> > +
> > + bit = find_first_zero_bit(msi->used, msi->num_of_vectors);
> > + if (bit >= msi->num_of_vectors)
> > + return -ENOSPC;
> > +
> > + set_bit(bit, msi->used);
> > +
> > + mutex_unlock(&msi->lock);
> > +
> > + irq_domain_set_info(domain, virq, bit, &altera_msi_bottom_irq_chip,
> > + domain->host_data, handle_simple_irq,
> > + NULL, NULL);
> > +
> > + mask = msi_readl(msi, MSI_INTMASK);
> > + mask |= 1 << bit;
> > + msi_writel(msi, mask, MSI_INTMASK);
> > +
> > + return 0;
> > +}
>
> You do not unlock the mutex when returning -ENOSPC
> And again some parameter could be set as const
Good catch, will fix that.
Do you mean add the const for altera_irq_domain_alloc()?
It is defined by the struct irq_domain_ops.
Regards
Ley Foon
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply e-mail,
and delete the message and any attachments. Thank you.
Re: [PATCH v10 38/46] richacl: Add support for unmapped identifiers
2015-10-12 2:22 GMT+02:00 Dave Chinner : > This was used by the XFS support patch earlier in the series. Bisect > problem here... Yes, I'll fix that up as well. Thanks, Andreas -- 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 v10 24/46] xfs: Add richacl support
2015-10-12 2:10 GMT+02:00 Dave Chinner :
> On Mon, Oct 12, 2015 at 12:58:35AM +0200, Andreas Gruenbacher wrote:
>> diff --git a/fs/ext4/richacl.h b/fs/ext4/richacl.h
>> index fc7826f..f26fbdd 100644
>> --- a/fs/ext4/richacl.h
>> +++ b/fs/ext4/richacl.h
>> @@ -24,7 +24,6 @@
>>
>> extern struct richacl *ext4_get_richacl(struct inode *);
>> extern int ext4_set_richacl(struct inode *, struct richacl *);
>> -
>> extern int ext4_init_richacl(handle_t *, struct inode *, struct inode *);
>>
>> #else /* CONFIG_EXT4_FS_RICHACL */
>
> stray hunk.
Oops, thanks.
>> diff --git a/fs/xfs/Kconfig b/fs/xfs/Kconfig
>> index 5d47b4d..05dd312 100644
>> --- a/fs/xfs/Kconfig
>> +++ b/fs/xfs/Kconfig
>> @@ -52,6 +52,17 @@ config XFS_POSIX_ACL
>>
>> If you don't know what Access Control Lists are, say N.
>>
>> +config XFS_RICHACL
>> +bool "XFS Rich Access Control Lists (EXPERIMENTAL)"
>> +depends on XFS_FS
>> +select FS_RICHACL
>> +help
>> + Richacls are an implementation of NFSv4 ACLs, extended by file
>> masks
>> + to cleanly integrate into the POSIX file permission model. To
>> learn
>> + more about them, see http://www.bestbits.at/richacl/.
>> +
>> + If you don't know what Richacls are, say N.
>> +
>
> So now we have multiple compile time ACL configs that we have to
> test. Personally, I see no reason for making either posix or rich
> acls compile time dependent. How about we just change CONFIG_FS_XFS
> to have "select FS_POSIX_ACL" and "select FS_RICHACL"
> unconditionally, and then we can get rid of all the conditional
> code?
I'm sure neither kind of ACLs makes sense on many tiny systems, it
should be possible to disable them. XFS may not make sense on those
kinds of systems either, that is not my call to make though.
>> diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.h
>> index 9590a06..8c6da45 100644
>> --- a/fs/xfs/libxfs/xfs_format.h
>> +++ b/fs/xfs/libxfs/xfs_format.h
>> @@ -461,10 +461,18 @@ xfs_sb_has_ro_compat_feature(
>> #define XFS_SB_FEAT_INCOMPAT_FTYPE (1 << 0)/* filetype in dirent
>> */
>> #define XFS_SB_FEAT_INCOMPAT_SPINODES(1 << 1)/* sparse
>> inode chunks */
>> #define XFS_SB_FEAT_INCOMPAT_META_UUID (1 << 2)/* metadata
>> UUID */
>> +
>> +#ifdef CONFIG_XFS_RICHACL
>> +#define XFS_SB_FEAT_INCOMPAT_RICHACL (1 << 3)/* richacls */
>> +#else
>> +#define XFS_SB_FEAT_INCOMPAT_RICHACL 0
>> +#endif
>> +
>
> Regardless of whether we build in richacl support, this is wrong.
> Feature bits are on-disk format definitions, so it will always have
> this value whether or not the kernel supports the feature.
This is so that xfs_mount_validate_sb() will complain when mounting a
richacl filesystem on a kernel which doesn't have richacl suport
compiled in. The same effect can be had with extra code there of
course.
>> @@ -722,7 +737,10 @@ xfs_setattr_nonsize(
>>* Posix ACL code seems to care about this issue either.
>>*/
>> if ((mask & ATTR_MODE) && !(flags & XFS_ATTR_NOACL)) {
>> - error = posix_acl_chmod(inode, inode->i_mode);
>> + if (XFS_IS_RICHACL(inode))
>> + error = richacl_chmod(inode, inode->i_mode);
>> + else
>> + error = posix_acl_chmod(inode, inode->i_mode);
>> if (error)
>> return error;
>> }
>
> This sort of thing could do with a helper like:
>
> static inline int
> xfs_acl_chmod(struct inode *inode, int mode)
> {
> if (IS_RICHACL(inode))
> return richacl_chmod(inode, mode);
> return posix_acl_chmod(inode, mode);
> }
Alright.
>> +#include "xfs.h"
>> +#include "xfs_format.h"
>> +#include "xfs_log_format.h"
>> +#include "xfs_inode.h"
>> +#include "xfs_attr.h"
>> +
>> +#include
>> +
>> +struct richacl *
>> +xfs_get_richacl(struct inode *inode)
>> +{
>
> ...
>
> If we always build in ACL support, this can all go in xfs_acl.c.
>
>> + struct xfs_inode *ip = XFS_I(inode);
>> + struct richacl *acl;
>> + int size = XATTR_SIZE_MAX;
>> + void *value;
>> + int error;
>> +
>> + value = kmem_zalloc_large(size, KM_SLEEP);
>> + if (!value)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + error = xfs_attr_get(ip, XATTR_NAME_RICHACL, value, &size, ATTR_ROOT);
>> + if (error) {
>> + /*
>> + * If the attribute doesn't exist make sure we have a negative
>> + * cache entry, for any other error assume it is transient and
>> + * leave the cache entry as ACL_NOT_CACHED.
>> + */
>> + acl = (error == -ENOATTR) ? NULL : ERR_PTR(error);
>
> I rather dislike ternaries in code like this - it's hard to read the
> logic. Initalise acl to NULL, and then this simply becomes:
>
> if (error != -ENOATTR)
> acl = ERR_PTR(error);
As you prefer.
>> + } else
[PATCH] thp: use is_zero_pfn after pte_present check
Use is_zero_pfn on pteval only after pte_present check on pteval
(It might be better idea to introduce is_zero_pte where checks
pte_present first). Otherwise, it could work with swap or
migration entry and if pte_pfn's result is equal to zero_pfn
by chance, we lose user's data in __collapse_huge_page_copy.
So if you're luck, the application is segfaulted and finally you
could see below message when the application is exit.
BUG: Bad rss-counter state mm:88007f099300 idx:2 val:3
Signed-off-by: Minchan Kim
---
I found this bug with MADV_FREE hard test. Sometime, I saw
"Bad rss-counter" message with MM_SWAPENTS but it's really
rare, once a day if I was luck or once in five days if I was
unlucky so I am doing test still and just pass a few days but
I hope it will fix the issue.
mm/huge_memory.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 4b06b8db9df2..349590aa4533 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2665,15 +2665,25 @@ static int khugepaged_scan_pmd(struct mm_struct *mm,
for (_address = address, _pte = pte; _pte < pte+HPAGE_PMD_NR;
_pte++, _address += PAGE_SIZE) {
pte_t pteval = *_pte;
- if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) {
+ if (pte_none(pteval)) {
if (!userfaultfd_armed(vma) &&
++none_or_zero <= khugepaged_max_ptes_none)
continue;
else
goto out_unmap;
}
+
if (!pte_present(pteval))
goto out_unmap;
+
+ if (is_zero_pfn(pte_pfn(pteval))) {
+ if (!userfaultfd_armed(vma) &&
+ ++none_or_zero <= khugepaged_max_ptes_none)
+ continue;
+ else
+ goto out_unmap;
+ }
+
if (pte_write(pteval))
writable = true;
--
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/
平时最多也就联系了三千家，全球还有十几万客户在哪里？
您好: 您还在用ali平台开发外贸客户? 还在使用展会宣传企业和产品? 你out了!!! 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？ 加QQ2652697913给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。 -- 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] mm: memory hot-add: memory can not be added to movable zone defaultly
Hi Ishimatsu,
On 10/10/2015 02:13 AM, Yasuaki Ishimatsu wrote:
Hi Tang,
On Fri, 9 Oct 2015 15:59:38 +0800
Tang Chen wrote:
Hi,
I don't mean to offend, but I really think it is not necessary to do this.
hot-added memory will be added to ZONE_NORMAL by default. You can
modify it when you online memory. I think it is enough for users.
But we cannot automatically create movable memory even if we use udev rules.
Thus user must create original scrip to online memory as movable.
Do you think every user understand the rule that ZONE_NORMAL must be on the
left side of ZONE_MOVABLE?
I think memory hotplug users should understand this.
If we can change the behavir of kernel by sysctl, user can create
movable memory by only the following udev rule.
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
OK, that is fine. And I think it is better to add this to the commit
message.
Thanks.
Thanks,
Yasuaki Ishimatsu
And a sysctl interface is also unnecessary. I think one default behaviour
is enough for kernel. We'd better keep it in the current way, or change it
and document it. It just makes no sense to enable users to modify it.
Can you please share any use case of this sysctl interface ?
I suggest just keep the current implement. But I'm OK with that if other
reviewers or users could clarify it is useful. :)
And BTW, please don't cc the following reviewers. Their email addresses
have changed.
Cc: Zhang Yanfei
Cc: Hu Tao
Cc: Lai Jiangshan
Cc: Gu Zheng
Thanks. :)
On 10/09/2015 03:12 PM, Changsheng Liu wrote:
From: Changsheng Liu
After the user config CONFIG_MOVABLE_NODE,
When the memory is hot added, should_add_memory_movable() return 0
because all zones including movable zone are empty,
so the memory that was hot added will be added to the normal zone
and the normal zone will be created firstly.
But we want the whole node to be added to movable zone defaultly.
So we change should_add_memory_movable(): if the user config
CONFIG_MOVABLE_NODE and sysctl parameter hotadd_memory_as_movable and
the ZONE_NORMAL is empty or the pfn of the hot-added memory
is after the end of the ZONE_NORMAL it will always return 1
and all zones is empty at the same time,
so that the movable zone will be created firstly
and then the whole node will be added to movable zone defaultly.
If we want the node to be added to normal zone,
we can do it as follows:
"echo online_kernel > /sys/devices/system/memory/memoryXXX/state"
Signed-off-by: Changsheng Liu
Signed-off-by: Xiaofeng Yan
Tested-by: Dongdong Fan
Cc: Wang Nan
Cc: Zhang Yanfei
Cc: Dave Hansen
Cc: Yinghai Lu
Cc: Tang Chen
Cc: Hu Tao
Cc: Lai Jiangshan
Cc: Yasuaki Ishimatsu
Cc: Gu Zheng
Cc: Toshi Kani
Cc: Xishi Qiu
Signed-off-by: Andrew Morton
---
Documentation/memory-hotplug.txt |5 -
kernel/sysctl.c | 15 +++
mm/memory_hotplug.c | 23 +++
3 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index ce2cfcf..7e6b4f4 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -277,7 +277,7 @@ And if the memory block is in ZONE_MOVABLE, you can change
it to ZONE_NORMAL:
After this, memory block XXX's state will be 'online' and the amount of
available memory will be increased.
-Currently, newly added memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA).
+Currently, newly added memory is added as ZONE_NORMAL or ZONE_MOVABLE (for
powerpc, ZONE_DMA).
This may be changed in future.
@@ -319,6 +319,9 @@ creates ZONE_MOVABLE as following.
Size of memory not for movable pages (not for offline) is TOTAL - .
Size of memory for movable pages (for offline) is .
+And a sysctl parameter for assigning the hot added memory to ZONE_MOVABLE is
+supported. If the value of "kernel/hotadd_memory_as_movable" is 1,the hot added
+memory will be assigned to ZONE_MOVABLE defautly.
Note: Unfortunately, there is no information to show which memory block belongs
to ZONE_MOVABLE. This is TBD.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 19b62b5..855c48e 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -166,6 +166,10 @@ extern int unaligned_dump_stack;
extern int no_unaligned_warning;
#endif
+#ifdef CONFIG_MOVABLE_NODE
+extern int hotadd_memory_as_movable;
+#endif
+
#ifdef CONFIG_PROC_SYSCTL
#define SYSCTL_WRITES_LEGACY -1
@@ -1139,6 +1143,17 @@ static struct ctl_table kern_table[] = {
.proc_handler = timer_migration_handler,
},
#endif
+/*If the value of "kernel/hotadd_memory_as_movable" is 1,the hot added
+ * memory will be assigned to ZONE_MOVABLE defautly.*/
+#ifdef CONFIG_MOVABLE_NODE
+ {
+ .procname = "hotadd_memory_as_movable",
+ .data = &hotadd_memory_as_movable,
+ .maxlen
Re: [PATCH] mm: skip if required_kernelcore is larger than totalpages
On 2015/10/9 23:41, Yasuaki Ishimatsu wrote: > > On Thu, 8 Oct 2015 10:21:05 +0800 > Xishi Qiu wrote: > >> If kernelcore was not specified, or the kernelcore size is zero >> (required_movablecore >= totalpages), or the kernelcore size is larger > > Why does required_movablecore become larger than totalpages, when the > kernelcore size is zero? I read the code but I could not find that you > mention. > If user only set boot option movablecore, and the value is larger than totalpages, the calculation of kernelcore is zero, but we can't fill the zone only with kernelcore, so skip it. I have send a patch before this patch. "fix overflow in find_zone_movable_pfns_for_nodes()" ... required_movablecore = roundup(required_movablecore, MAX_ORDER_NR_PAGES); + required_movablecore = min(totalpages, required_movablecore); corepages = totalpages - required_movablecore; ... Thanks, Xishi Qiu > Thanks, > Yasuaki Ishimatsu > >> than totalpages, there is no ZONE_MOVABLE. We should fill the zone >> with both kernel memory and movable memory. >> >> Signed-off-by: Xishi Qiu >> --- >> mm/page_alloc.c | 7 +-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index af3c9bd..6a6da0d 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -5674,8 +5674,11 @@ static void __init >> find_zone_movable_pfns_for_nodes(void) >> required_kernelcore = max(required_kernelcore, corepages); >> } >> >> -/* If kernelcore was not specified, there is no ZONE_MOVABLE */ >> -if (!required_kernelcore) >> +/* >> + * If kernelcore was not specified or kernelcore size is larger >> + * than totalpages, there is no ZONE_MOVABLE. >> + */ >> +if (!required_kernelcore || required_kernelcore >= totalpages) >> goto out; >> >> /* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */ >> -- >> 2.0.0 >> >> >> -- >> To unsubscribe, send a message with 'unsubscribe linux-mm' in >> the body to majord...@kvack.org. For more info on Linux MM, >> see: http://www.linux-mm.org/ . >> Don't email: mailto:"d...@kvack.org";> em...@kvack.org > > . > -- 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] amba/coresight: make non-modular code explicitly non-modular
In a previous merge window, we made changes to allow better
delineation between modular and non-modular code in commit
0fd972a7d91d6e15393c449492a04d94c0b89351 ("module: relocate module_init
from init.h to module.h"). This allows us to now ensure module code
looks modular and non-modular code does not accidentally look modular
just to avoid suffering build breakage.
Here we target code that is, by nature of their Makefile and/or
Kconfig settings, only available to be built-in, but implicitly
presenting itself as being possibly modular by way of using modular
headers, macros, and functions.
The goal here is to remove that illusion of modularity from these
files, but in a way that leaves the actual runtime unchanged.
In doing so, we remove code that has never been tested and adds
no value to the tree. And we continue the process of expecting a
level of consistency between the Kconfig/Makefile of code and the
code in use itself.
The coresight drivers make extensive use of module_amba_driver, hence
why this is all grouped together. Build tested on the latest linux-next,
for ARCH=arm.
Note that the coresight drivers could in theory be unbound prior to
this commit, but there doesn't seem to be any case where that would
make sense, so we explicitly disable that now that we have deleted
the .remove functions that the unbind would have called.
Paul.
--
Cc: Alexandre Courbot
Cc: Mathieu Poirier
Cc: Russell King
Cc: Stephen Warren
Cc: Thierry Reding
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
Paul Gortmaker (3):
amba: create builtin_amba_driver to avoid registration boilerplate
drivers/hwtracing: make coresight-* explicitly non-modular
drivers/amba: make tegra-ahb.c explicitly non-modular
drivers/amba/tegra-ahb.c | 9 ++-
drivers/hwtracing/coresight/coresight-etb10.c | 26 +--
drivers/hwtracing/coresight/coresight-etm3x.c | 29 ++---
drivers/hwtracing/coresight/coresight-etm4x.c | 19 +++---
drivers/hwtracing/coresight/coresight-funnel.c | 25 +-
.../coresight/coresight-replicator-qcom.c | 19 +++---
drivers/hwtracing/coresight/coresight-replicator.c | 30 +-
drivers/hwtracing/coresight/coresight-tmc.c| 28 +---
drivers/hwtracing/coresight/coresight-tpiu.c | 25 +-
drivers/hwtracing/coresight/coresight.c| 3 ---
drivers/hwtracing/coresight/of_coresight.c | 1 -
include/linux/amba/bus.h | 9 +++
12 files changed, 60 insertions(+), 163 deletions(-)
--
2.6.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] drivers/amba: make tegra-ahb.c explicitly non-modular
The Kconfig currently controlling compilation of this code is:
drivers/amba/Kconfig:config TEGRA_AHB
drivers/amba/Kconfig: bool "Enable AHB driver for NVIDIA Tegra SoCs"
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity so that when reading the
driver there is no doubt it is builtin-only.
Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.
We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.
Cc: Russell King
Cc: Stephen Warren
Cc: Thierry Reding
Cc: Alexandre Courbot
Cc: linux-te...@vger.kernel.org
Signed-off-by: Paul Gortmaker
---
drivers/amba/tegra-ahb.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/amba/tegra-ahb.c b/drivers/amba/tegra-ahb.c
index b0b688c481e8..5b53ebfa4f9e 100644
--- a/drivers/amba/tegra-ahb.c
+++ b/drivers/amba/tegra-ahb.c
@@ -22,7 +22,7 @@
#include
#include
-#include
+#include
#include
#include
#include
@@ -301,9 +301,4 @@ static struct platform_driver tegra_ahb_driver = {
.pm = &tegra_ahb_pm,
},
};
-module_platform_driver(tegra_ahb_driver);
-
-MODULE_AUTHOR("Hiroshi DOYU ");
-MODULE_DESCRIPTION("Tegra AHB driver");
-MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:" DRV_NAME);
+builtin_platform_driver(tegra_ahb_driver);
--
2.6.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/3] amba: create builtin_amba_driver to avoid registration boilerplate
In commit f309d4443130bf814e991f836e919dca22df37ae ("platform_device:
better support builtin boilerplate avoidance") we introduced the
builtin_driver macro.
Here we use that support and extend it to amba driver registration,
so where a driver is clearly non-modular and builtin-only, we can
register it in a similar fashion. And existing code that is clearly
non-modular can be updated with the simple mapping of
module_amba_driver(...) ---> builtin_amba_driver(...)
We've essentially cloned the former to make the latter, and taken
out the remove/module_exit parts since those never get used in a
non-modular build of the code.
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Paul Gortmaker
---
include/linux/amba/bus.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 50fc66868402..0e8cb21c20e5 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -165,4 +165,13 @@ struct amba_device name##_device = {
\
#define module_amba_driver(__amba_drv) \
module_driver(__amba_drv, amba_driver_register, amba_driver_unregister)
+/*
+ * builtin_amba_driver() - Helper macro for drivers that don't do anything
+ * special in driver initcall. This eliminates a lot of boilerplate. Each
+ * driver may only use this macro once, and calling it replaces the instance
+ * device_initcall().
+ */
+#define builtin_amba_driver(__amba_drv) \
+ builtin_driver(__amba_drv, amba_driver_register)
+
#endif
--
2.6.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 2/3] drivers/hwtracing: make coresight-* explicitly non-modular
None of the Kconfig currently controlling compilation of any of
the files here are tristate, meaning that none of it currently
is being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the drivers there is no doubt they are builtin-only.
All drivers get mostly the same changes, so they are handled in batch.
The changes in this commit are as follows:
(1) convert from module_amba_driver to builtin_amba_driver
(2) delete module.h include where it is now unused
(3) relocate the description into the comments so we don't need
MODULE_DESCRIPTION and associated tags
(4) delete any ".remove" related functions that were added under
the presumption that module_exit would ever run here
(5) explicitly prevent anyone from mistakenly using the unbind
interface to call the (now removed) ".remove" functions, as that
never made sense for any of these drivers regardless.
The etm3x and etm4x use module_param_named, and have been adjusted
to just include moduleparam.h for that purpose.
Since module_amba_driver() uses the same init level priority as
builtin_amba_driver() the init ordering remains unchanged with
this commit.
Cc: Mathieu Poirier
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Paul Gortmaker
---
drivers/hwtracing/coresight/coresight-etb10.c | 26 +--
drivers/hwtracing/coresight/coresight-etm3x.c | 29 ++---
drivers/hwtracing/coresight/coresight-etm4x.c | 19 +++---
drivers/hwtracing/coresight/coresight-funnel.c | 25 +-
.../coresight/coresight-replicator-qcom.c | 19 +++---
drivers/hwtracing/coresight/coresight-replicator.c | 30 +-
drivers/hwtracing/coresight/coresight-tmc.c| 28 +---
drivers/hwtracing/coresight/coresight-tpiu.c | 25 +-
drivers/hwtracing/coresight/coresight.c| 3 ---
drivers/hwtracing/coresight/of_coresight.c | 1 -
10 files changed, 49 insertions(+), 156 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-etb10.c
b/drivers/hwtracing/coresight/coresight-etb10.c
index 77d0f9c1118d..12f03cffa1ac 100644
--- a/drivers/hwtracing/coresight/coresight-etb10.c
+++ b/drivers/hwtracing/coresight/coresight-etb10.c
@@ -1,5 +1,7 @@
/* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
*
+ * Description: CoreSight Embedded Trace Buffer driver
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
* only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,6 @@
*/
#include
-#include
#include
#include
#include
@@ -489,15 +490,6 @@ err_misc_register:
return ret;
}
-static int etb_remove(struct amba_device *adev)
-{
- struct etb_drvdata *drvdata = amba_get_drvdata(adev);
-
- misc_deregister(&drvdata->miscdev);
- coresight_unregister(drvdata->csdev);
- return 0;
-}
-
#ifdef CONFIG_PM
static int etb_runtime_suspend(struct device *dev)
{
@@ -534,17 +526,13 @@ static struct amba_id etb_ids[] = {
static struct amba_driver etb_driver = {
.drv = {
- .name = "coresight-etb10",
- .owner = THIS_MODULE,
- .pm = &etb_dev_pm_ops,
+ .name = "coresight-etb10",
+ .owner = THIS_MODULE,
+ .pm = &etb_dev_pm_ops,
+ .suppress_bind_attrs= true,
},
.probe = etb_probe,
- .remove = etb_remove,
.id_table = etb_ids,
};
-
-module_amba_driver(etb_driver);
-
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("CoreSight Embedded Trace Buffer driver");
+builtin_amba_driver(etb_driver);
diff --git a/drivers/hwtracing/coresight/coresight-etm3x.c
b/drivers/hwtracing/coresight/coresight-etm3x.c
index d630b7ece735..63f6113a6a3c 100644
--- a/drivers/hwtracing/coresight/coresight-etm3x.c
+++ b/drivers/hwtracing/coresight/coresight-etm3x.c
@@ -1,5 +1,7 @@
/* Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
*
+ * Description: CoreSight Program Flow Trace driver
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 and
* only version 2 as published by the Free Software Foundation.
@@ -11,7 +13,7 @@
*/
#include
-#include
+#include
#include
#include
#include
@@ -1877,17 +1879,6 @@ err_arch_supported:
return ret;
}
-static int etm_remove(struct amba_device *adev)
-{
- struct etm_drvdata *drvdata = amba_get_drvdata(adev);
-
- coresight_unregister(drvdata->csdev);
- if (--etm_count == 0)
- unregister_hotcpu_notifier(&etm_cpu_notifier);
-
- return 0;
-}
-
#ifdef CONFIG_PM
static int et
[PATCH] ARM: EXYNOS: Fix double of_node_put() when parsing child power domains
On each next iteration of for_each_compatible_node() the reference
counter for current device node is already decreased by the loop
iterator. The manual call to of_node_get() is required only on loop
break which is not happening here.
The double of_node_get() (with enabled CONFIG_OF_DYNAMIC) lead to
decreasing the counter below expected, initial value.
Signed-off-by: Krzysztof Kozlowski
Fixes: fe4034a3fad7 ("ARM: EXYNOS: Add missing of_node_put() when parsing power
domains")
---
arch/arm/mach-exynos/pm_domains.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 4a87e86dec45..7c21760f590f 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -200,15 +200,15 @@ no_clk:
args.args_count = 0;
child_domain = of_genpd_get_from_provider(&args);
if (IS_ERR(child_domain))
- goto next_pd;
+ continue;
if (of_parse_phandle_with_args(np, "power-domains",
"#power-domain-cells", 0, &args) != 0)
- goto next_pd;
+ continue;
parent_domain = of_genpd_get_from_provider(&args);
if (IS_ERR(parent_domain))
- goto next_pd;
+ continue;
if (pm_genpd_add_subdomain(parent_domain, child_domain))
pr_warn("%s failed to add subdomain: %s\n",
@@ -216,8 +216,6 @@ no_clk:
else
pr_info("%s has as child subdomain: %s.\n",
parent_domain->name, child_domain->name);
-next_pd:
- of_node_put(np);
}
return 0;
--
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 V1 2/3] taging: android: ion: Add ion driver for Hi6220 SoC platform
On 2015/10/10 23:00, Dan Carpenter wrote:
> On Sat, Oct 10, 2015 at 02:48:22PM +0800, Chen Feng wrote:
>> +static int hi6220_ion_probe(struct platform_device *pdev)
>> +{
>> +int i;
>> +int err = 0;
>> +static struct ion_platform_heap *p_heap;
>> +
>> +idev = ion_device_create(NULL);
>> +hi6220_set_platform_data(pdev);
>> +heaps = devm_kzalloc(&pdev->dev,
>> + sizeof(struct ion_heap *) * num_heaps,
>> + GFP_KERNEL);
>> +if (!heaps)
>> +return -ENOMEM;
>> +
>> +/*
>> + * create the heaps as specified in the dts file
>> + */
>> +for (i = 0; i < num_heaps; i++) {
>> +p_heap = heaps_data[i];
>> +heaps[i] = ion_heap_create(p_heap);
>> +if (IS_ERR_OR_NULL(heaps[i])) {
>> +err = PTR_ERR(heaps[i]);
>> +goto err_free_heaps;
>> +}
>> +
>> +ion_device_add_heap(idev, heaps[i]);
>> +
>> +pr_info("%s: adding heap %s of type %d with %lx@%lx\n",
>> +__func__, p_heap->name, p_heap->type,
>> +p_heap->base, (unsigned long)p_heap->size);
>> +}
>> +return err;
>> +
>> +err_free_heaps:
>> +ion_device_destroy(idev);
>> +for (i = 0; i < num_heaps; ++i) {
>> +ion_heap_destroy(heaps[i]);
>> +heaps[i] = NULL;
>> +}
>> +
>> +return err;
>> +}
>
> Thanks this is better but still not quite right. You have to unwind in
> the reverse order from how you allocated things.
>
> err_free_heaps:
> for (i = 0; i < num_heaps; ++i) {
> ion_heap_destroy(heaps[i]);
> heaps[i] = NULL;
> }
> err_destroy_idev:
> ion_device_destroy(idev);
>
> return err;
>
> And earlier it should be:
>
> idev = ion_device_create(NULL);
> hi6220_set_platform_data(pdev);
> heaps = devm_kzalloc(&pdev->dev,
>sizeof(struct ion_heap *) * num_heaps,
>GFP_KERNEL);
> - if (!heaps)
> - return -ENOMEM;
> + if (!heaps) {
> + err = -ENOMEM;
> + goto err_destroy_idev;
> + }
>
> Otherwise we leak some resources if we can't allocate "heaps".
>
Yeah,it's right. I will fix this.
> regards,
> dan carpenter
>
>
> .
>
--
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] rtc: at91rm9200: clear RTC alarm status flag prior to suspending
This patch is to clear the RTC alarm status flag prior to suspending
to avoid the erroneous wake-up activity.
Signed-off-by: Wenyou Yang
---
drivers/rtc/rtc-at91rm9200.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/rtc/rtc-at91rm9200.c b/drivers/rtc/rtc-at91rm9200.c
index cb62e21..b60fd47 100644
--- a/drivers/rtc/rtc-at91rm9200.c
+++ b/drivers/rtc/rtc-at91rm9200.c
@@ -495,6 +495,8 @@ static int at91_rtc_suspend(struct device *dev)
/* this IRQ is shared with DBGU and other hardware which isn't
* necessarily doing PM like we are...
*/
+ at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
+
at91_rtc_imr = at91_rtc_read_imr()
& (AT91_RTC_ALARM|AT91_RTC_SECEV);
if (at91_rtc_imr) {
--
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: [RFC v2 4/7] powerpc: atomic: Implement xchg_* and atomic{,64}_xchg_* variants
Hi Paul,
On Thu, Oct 01, 2015 at 11:03:01AM -0700, Paul E. McKenney wrote:
> On Thu, Oct 01, 2015 at 07:13:04PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 01, 2015 at 08:09:09AM -0700, Paul E. McKenney wrote:
> > > On Thu, Oct 01, 2015 at 02:24:40PM +0200, Peter Zijlstra wrote:
> >
> > > > I must say I'm somewhat surprised by this level of relaxation, I had
> > > > expected to only loose SMP barriers, not the program order ones.
> > > >
> > > > Is there a good argument for this?
> > >
> > > Yes, when we say "relaxed", we really mean relaxed. ;-)
> > >
> > > Both the CPU and the compiler are allowed to reorder around relaxed
> > > operations.
> >
> > Is this documented somewhere, because I completely missed this part.
>
> Well, yes, these need to be added to the documentation. I am assuming
Maybe it's good time for us to call it out which operation should be
a compiler barrier or a CPU barrier?
I had something in my mind while I was working on this series, not
really sure whether it's correct, but probably a start point:
All global and local atomic operations are at least atomic(no one can
observe the middle state) and volatile(compilers can't optimize out the
memory access). Based on this, there are four strictness levels, one
can rely on them:
RELAXED: neither a compiler barrier or a CPU barrier
LOCAL: a compiler barrier
PARTIAL: both a compiler barrier and a CPU barrier but not transitive
FULL: both compiler barrier and a CPU barrier, and transitive.
RELAXED includes all _relaxed variants and non-return atomics, LOCAL
includes all local atomics(local_* and {cmp}xchg_local), PARTIAL
includes _acquire and _release operations and FULL includes all fully
ordered global atomic operations.
Thoughts?
Regards,
Boqun
> that Will is looking to have the same effect as C11 memory_order_relaxed,
> which is relaxed in this sense. If he has something else in mind,
> he needs to tell us what it is and why. ;-)
>
> Thanx, Paul
>
signature.asc
Description: PGP signature
[PATCH] certs: add .gitignore to stop git nagging about x509_certificate_list
Currently we see this in "git status" if we build in the source dir: Untracked files: (use "git add ..." to include in what will be committed) certs/x509_certificate_list It looks like it used to live in kernel/ so we squash that .gitignore entry at the same time. I didn't bother to dig through git history to see when it moved, since it is just a minor annoyance at most. Cc: David Howells Cc: David Woodhouse Cc: keyri...@linux-nfs.org Signed-off-by: Paul Gortmaker --- [NB: Seen on linux-next tree from Friday.] certs/.gitignore | 4 kernel/.gitignore | 1 - 2 files changed, 4 insertions(+), 1 deletion(-) create mode 100644 certs/.gitignore diff --git a/certs/.gitignore b/certs/.gitignore new file mode 100644 index ..f51aea4a71ec --- /dev/null +++ b/certs/.gitignore @@ -0,0 +1,4 @@ +# +# Generated files +# +x509_certificate_list diff --git a/kernel/.gitignore b/kernel/.gitignore index 790d83c7d160..b3097bde4e9c 100644 --- a/kernel/.gitignore +++ b/kernel/.gitignore @@ -5,4 +5,3 @@ config_data.h config_data.gz timeconst.h hz.bc -x509_certificate_list -- 2.6.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/
