Re: [PATCH v2 06/27] brcm80211: move under broadcom vendor directory
Florian Fainelli writes: > On 18/11/15 11:19, Hauke Mehrtens wrote: >> On 11/18/2015 03:45 PM, Kalle Valo wrote: >>> Part of reorganising wireless drivers directory and Kconfig. Note that I >>> had to >>> edit Makefiles from subdirectories to use the new location. >>> >>> Signed-off-by: Kalle Valo >>> --- >> >> I would prefer to remove the brcm80211 directory in this process and create: >> drivers/net/wireless/broadcom/brcmfmac >> drivers/net/wireless/broadcom/brcmsmac >> drivers/net/wireless/broadcom/brcmutil >> drivers/net/wireless/broadcom/include >> >> This way we have one directory less. > > Would not that make keeping track of the previous and future history > harder for people contributing to these drivers? I could imagine that > for Arend and other Broadcom engineers, dealing with a simple level move > would be manageable, but having to account for a different directory > hierarchy could be a pain. > > What is the impact on compat-wireless after/before these changes by the way? It's called backports nowadays :) But I understood that as long as we have a separate kconfig option for the vendor directories (CONFIG_WLAN_VENDOR_*) it should be ok. For 4.3 we didn't have that for realtek directory and that caused pain for backports. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] User namespace mount updates
Am 19.11.2015 um 08:47 schrieb James Morris: > On Wed, 18 Nov 2015, Richard Weinberger wrote: > >> On Wed, Nov 18, 2015 at 4:13 PM, Al Viro wrote: >>> On Wed, Nov 18, 2015 at 09:05:12AM -0600, Seth Forshee wrote: >>> Yes, the host admin. I'm not talking about trusting the admin inside the container at all. >>> >>> Then why not have the same host admin just plain mount it when setting the >>> container up and be done with that? From the host namespace, before >>> spawning >>> the docker instance or whatever framework you are using. IDGI... >> >> Because hosting companies sell containers as "full virtual machines" >> and customers expect to be able mount stuff like disk images they upload. > > I don't think this is a valid reason for merging functionality into the > kernel. Erm, I don't want this in the kernel. That's why I've proposed the lklfuse approach. Thanks, //richard -- 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] HAVE_DMA_ATTRS: remove leftovers in Kconfig
The Kconfig option HAVE_DMA_ATTRS has been removed by
commit f6f306eeb7ea ("dma-mapping: always provide the dma_map_ops based
implementation"). Remove leftover references on this option.
Signed-off-by: Valentin Rothberg
---
arch/s390/Kconfig | 1 -
drivers/gpu/drm/vc4/Kconfig | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 840abf4c82af..c40202c6acc3 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -126,7 +126,6 @@ config S390
select HAVE_CMPXCHG_DOUBLE
select HAVE_CMPXCHG_LOCAL
select HAVE_DEBUG_KMEMLEAK
- select HAVE_DMA_ATTRS
select HAVE_DMA_API_DEBUG
select HAVE_DYNAMIC_FTRACE
select HAVE_DYNAMIC_FTRACE_WITH_REGS
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index 2d7d115ddf3f..584810474e5b 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -1,7 +1,7 @@
config DRM_VC4
tristate "Broadcom VC4 Graphics"
depends on ARCH_BCM2835 || COMPILE_TEST
- depends on DRM && HAVE_DMA_ATTRS
+ depends on DRM
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] comedi: dmm32at: Fix coding style - use BIT macro
On Wed, Nov 18, 2015 at 04:26:52PM +, Ian Abbott wrote: > >+#define DMM32AT_AI_CFG_SCINT_10US (BIT(5) & ~BIT(4)) > >+#define DMM32AT_AI_CFG_SCINT_5US(BIT(5) | BIT(4)) > > The values of DMM32AT_AI_CFG_SCINT_20US etc. are numerically > correct, but look a bit strange. The `(BIT(5) & ~BIT(4))` looks > especially strange and could be changed to `BIT(5)`. These are all > really shifted 2-bit values, so perhaps the BIT() macro isn't the > best representation. > BIT(5) & ~BIT(4) is silly. Don't do that. The original code was fine. 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/
Re: Hibernate resume bug around 3,18-rc2 - Full PAT support
Hi, Thanks for the quick answer > > Could you please try the most recent 4.3 kernel? There has been some > work related to this topic after 4.2 (large page pat handling done by > Toshi Kani and mtrr/pat handling by Luis Rodriguez). That means I will reset the bisection. Right? Is there any other info we can extract from there? So Do you want me to test 4.3 or 4.4-pre/rc*/latest linus tree. I assume 4.3 for now. I will do it later tonight. It will take 2 days at least to report back > > Another interesting information would be the exact hardware you are > using. Maybe we can see some similarities between yours and the other > two cases you referenced above. > It is an i7 Motherboard: ASROCK H97 PRO4 RETAIL CPU INTEL CORE I7-4790 3.60GHZ LGA1150 - BOX It has 16GB of RAM, one SSD and one HDD I have NO external graphics card Do you want me to run something on this like lspci, lsusb I upgraded the BIOS of the motherboard to the latest. This is not the problem though because I upgraded after the problem occurred as a counter measure in case I was hit by a buggy BIOS and linux had changed its behavior to be stricter. I experimented with ACPI compilers/decompilers and I was tempted to fix my ACPI tables but I didn't. I saw the kernel command line option acpi_os=!Windows2013 but I didn't try it. Do you thing I should try it? > Wow! Thanks for doing this work! > I would like this to be fixed so I am willing to do the testing. Vassilis -- 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 06/27] brcm80211: move under broadcom vendor directory
Hauke Mehrtens writes: > On 11/18/2015 03:45 PM, Kalle Valo wrote: >> Part of reorganising wireless drivers directory and Kconfig. Note that I had >> to >> edit Makefiles from subdirectories to use the new location. >> >> Signed-off-by: Kalle Valo >> --- > > I would prefer to remove the brcm80211 directory in this process and create: > drivers/net/wireless/broadcom/brcmfmac > drivers/net/wireless/broadcom/brcmsmac > drivers/net/wireless/broadcom/brcmutil > drivers/net/wireless/broadcom/include > > This way we have one directory less. I think this could be done separately. This patchset is big enough already, I would not like to make it anymore complicated. And I actually like the brcm80211 directory, I would not mind keeping it still. -- Kalle Valo -- 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/71] More fixes, cleanup and modernization for NCR5380 drivers
On Thursday 19 November 2015, Finn Thain wrote: > On Wed, 18 Nov 2015, Ondrej Zary wrote: > > On Wednesday 18 November 2015, Finn Thain wrote: > > > Like my previous work on the NCR5380 drivers, this patch series has > > > bug fixes, code cleanup and modernization. These drivers suffer from > > > mistakes, poor style and neglect and this long series addresses the > > > worst of it, covering all ten wrapper drivers and both of the core > > > driver forks. The combined size of the drivers is reduced by about 750 > > > LoC. > > > > > > This series continues to reduce divergence between the two core driver > > > forks, often by copying a bug fix from one to the other. Most patches > > > are larger for having to keep the two forks in sync. Making the same > > > change to both is churn if one of them is to be removed but neither > > > can be as yet. By the end of this series the diff between the two > > > forks is minimal, so it becomes clear what caused the fork and what > > > can be done about it. > > > > > > This patch series did benefit from scripts/checkpatch.pl but not too > > > much. Decades ago, these drivers started out with 4-space tabs and if > > > the 80 column limit were to be strictly enforced now, it would require > > > adding new functions and shortening identifiers. I would defer this > > > sort of activity until after the fork has been resolved. > > > > > > I have compile-tested all patches to all NCR5380 drivers (x86, ARM, > > > m68k) and regression tested mac_scsi and dmx3191d modules on suitable > > > hardware. Testing the mac_scsi and dmx3191d modules provides only > > > limited coverage. It would be good to see some testing of ISA cards > > > and Sun 3 and Atari hardware too (I don't have any). > > > > I have some NCR5380 ISA cards and can test them. > > Thanks Ondrej. I've no idea which ISA drivers are presently working in > mainline. Finding regressions may be more difficult than usual ;-) I remember that at least one of them never worked in Linux - HP C2502 card with 53C400A chip with no jumpers (magic-numbers-based configuration). The memory-mapped Canon FG2-5202 (53C400) did not work properly either. At least DTCT-436P used to work. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/7] User namespace mount updates
On Wed, 18 Nov 2015, Richard Weinberger wrote: > On Wed, Nov 18, 2015 at 4:13 PM, Al Viro wrote: > > On Wed, Nov 18, 2015 at 09:05:12AM -0600, Seth Forshee wrote: > > > >> Yes, the host admin. I'm not talking about trusting the admin inside the > >> container at all. > > > > Then why not have the same host admin just plain mount it when setting the > > container up and be done with that? From the host namespace, before > > spawning > > the docker instance or whatever framework you are using. IDGI... > > Because hosting companies sell containers as "full virtual machines" > and customers expect to be able mount stuff like disk images they upload. I don't think this is a valid reason for merging functionality into the kernel. -- James Morris -- 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] tools build: Clean CFLAGS and LDFLAGS for fixdep
Sometimes variables passed to tools/build is dangerous. For example, on my platform there is a gcc problem (gcc 4.8.1): It passes stackprotector-all feature check: $ gcc -fstack-protector-all./test.c $ echo $? 0 But requires LDFLAGS support if separete compiling and linking: $ gcc -fstack-protector-all -c ./test.c $ gcc ./test.o ./test.o: In function `main': test.c:(.text+0xb): undefined reference to `__stack_chk_guard' test.c:(.text+0x21): undefined reference to `__stack_chk_guard' collect2: error: ld returned 1 exit status $ gcc -fstack-protector-all ./test.o $ echo $? 0 $ gcc ./test.o -lssp $ echo $? 0 In this environment perf building throws an error: $ make BUILD: Doing 'make -j24' parallel build config/Makefile:344: No libunwind found. Please install libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR config/Makefile:403: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev config/Makefile:418: slang not found, disables TUI support. Please install slang-devel or libslang-dev config/Makefile:432: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev config/Makefile:564: No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static/libiberty-dev to gain symbol demangling config/Makefile:606: No numa.h found, disables 'perf bench numa mem' benchmark, please install numactl-devel/libnuma-devel/libnuma-dev CC fixdep.o LD fixdep-in.o LINK fixdep fixdep-in.o: In function `parse_dep_file': /kernel/tools/build/fixdep.c:47: undefined reference to `__stack_chk_guard' /kernel/tools/build/fixdep.c:117: undefined reference to `__stack_chk_guard' fixdep-in.o: In function `main': /kernel-hydrogen/tools/build/fixdep.c:156: undefined reference to `__stack_chk_guard' /kernel/tools/build/fixdep.c:168: undefined reference to `__stack_chk_guard' collect2: error: ld returned 1 exit status make[2]: *** [fixdep] Error 1 make[1]: *** [fixdep] Error 2 make: *** [all] Error 2 This is because CFLAGS in perf building pollutes CFLAGS used for fixdep, passes -fstack-protector-all to fixdep builder which is obviously not required. Since fixdep is a small host side tool, we should keep its CFLAGS/LDFLAGS simple anc clean. This patch clear CFLAGS and LDFLAGS passed to fixdep building, so such gcc problem won't block perf building. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa --- tools/build/Makefile.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/build/Makefile.include b/tools/build/Makefile.include index 4e09ad6..6254760 100644 --- a/tools/build/Makefile.include +++ b/tools/build/Makefile.include @@ -4,7 +4,7 @@ ifdef CROSS_COMPILE fixdep: else fixdep: - $(Q)$(MAKE) -C $(srctree)/tools/build fixdep + $(Q)$(MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= fixdep endif .PHONY: fixdep -- 1.8.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/71] ncr5380: Remove NCR5380_instance_name macro
On 11/18/2015 09:35 AM, Finn Thain wrote: This macro makes the code cryptic. Remove it. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c |2 +- drivers/scsi/g_NCR5380.c |7 --- drivers/scsi/g_NCR5380.h |2 -- 3 files changed, 5 insertions(+), 6 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 05/71] ncr5380: Remove NCR5380_local_declare and NCR5380_setup macros
On 11/18/2015 09:35 AM, Finn Thain wrote: The NCR5380_local_declare and NCR5380_setup macros exist to define and initialize a particular local variable, to provide the address of the chip registers needed for the driver's implementation of its NCR5380_read/write register access macros. In cumana_1 and macscsi, these macros generate pointless code like this, struct Scsi_Host *_instance; _instance = instance; In pas16, the use of NCR5380_read/write in pas16_hw_detect() requires that the io_port local variable has been defined and initialized, but the NCR5380_local_declare and NCR5380_setup macros can't be used for that purpose because the Scsi_Host struct has not yet been instantiated. Moreover, these macros were removed from atari_NCR5380.c long ago and now they constitute yet another discrepancy between the two core driver forks. Remove these "optimizations". Signed-off-by: Finn Thain --- Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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: [RESEND RFC/PATCH 0/8] Add MT8173 Video Encoder Driver and VPU Driver
On 11/17/2015 01:54 PM, Tiffany Lin wrote: > == > Introduction > == > > The purpose of this RFC is to discuss the driver for a hw video codec > embedded in the Mediatek's MT8173 SoCs. Mediatek Video Codec is able to > handle video encoding of in a range of formats. > > This RFC also include VPU driver. Mediatek Video Codec driver rely on > VPU driver to load, communicate with VPU. > > Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI. > MTK IOMMU and MTK SMI have not yet been merged, but we wanted to start > discussion about the driver earlier so it could be merged sooner. The > driver posted here is the initial version, so I suppose it will require > more work. I plan on reviewing this patch series (at least the non-dt parts). It's busy, though, and I don't know exactly when I get the chance. But just so you know that someone will be reviewing it. Regards, Hans > > [1]http://lists.infradead.org/pipermail/linux-mediatek/2015-October/002525.html > > == > Device interface > == > > In principle the driver bases on memory-to-memory framework: > it provides a single video node and each opened file handle gets its own > private context with separate buffer queues. Each context consist of 2 > buffer queues: OUTPUT (for source buffers, i.e. raw video frames) > and CAPTURE (for destination buffers, i.e. encoded video frames). > > The process of encoding video data from stream is a bit more complicated > than typical memory-to-memory processing. We base on memory-to-memory > framework and add the complicated part in our vb2 and v4l2 callback > functionss. So we can base on well done m2m memory-to-memory framework, > reduce duplicate code and make our driver code simple. > > == > VPU (Video Processor Unit) > == > The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs. > It is able to handle video decoding/encoding of in a range of formats. > The driver provides with VPU firmware download, memory management and > the communication interface between CPU and VPU. > For VPU initialization, it will create virtual memory for CPU access and > IOMMU address for vcodec hw device access. When a decode/encode instance > opens a device node, vpu driver will download vpu firmware to the device. > A decode/encode instant will decode/encode a frame using VPU > interface to interrupt vpu to handle decoding/encoding jobs. > > Please have a look at the code and comments will be very much appreciated. > > Andrew-CT Chen (3): > dt-bindings: Add a binding for Mediatek Video Processor Unit > arm64: dts: mediatek: Add node for Mediatek Video Processor Unit > media: platform: mtk-vpu: Support Mediatek VPU > > Daniel Hsiao (1): > media: platform: mtk-vcodec: Add Mediatek VP8 Video Encoder Driver > > Tiffany Lin (4): > dt-bindings: Add a binding for Mediatek Video Encoder > arm64: dts: mediatek: Add Video Encoder for MT8173 > media: platform: mtk-vcodec: Add Mediatek V4L2 Video Encoder Driver > media: platform: mtk-vcodec: Add Mediatek H264 Video Encoder Driver > > .../devicetree/bindings/media/mediatek-vcodec.txt | 58 + > .../devicetree/bindings/media/mediatek-vpu.txt | 27 + > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 58 + > drivers/media/platform/Kconfig | 19 + > drivers/media/platform/Makefile|5 + > drivers/media/platform/mtk-vcodec/Kconfig |5 + > drivers/media/platform/mtk-vcodec/Makefile | 12 + > drivers/media/platform/mtk-vcodec/common/Makefile | 12 + > .../media/platform/mtk-vcodec/common/venc_drv_if.c | 159 ++ > .../media/platform/mtk-vcodec/h264_enc/Makefile|9 + > .../platform/mtk-vcodec/h264_enc/venc_h264_if.c| 529 ++ > .../platform/mtk-vcodec/h264_enc/venc_h264_if.h| 53 + > .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c | 341 > .../platform/mtk-vcodec/include/venc_drv_base.h| 68 + > .../platform/mtk-vcodec/include/venc_drv_if.h | 187 +++ > .../platform/mtk-vcodec/include/venc_ipi_msg.h | 212 +++ > drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 441 + > drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1773 > > drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h | 28 + > .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 535 ++ > .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 122 ++ > .../media/platform/mtk-vcodec/mtk_vcodec_intr.c| 110 ++ > .../media/platform/mtk-vcodec/mtk_vcodec_intr.h| 30 + > drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h | 26 + > .../media/platform/mtk-vcodec/mtk_vcodec_util.c| 106 ++ > .../media/platform/mtk-vcodec/mtk_vcodec_util.h| 66 + > drivers/media/platform/mtk-vcodec/vp8_enc/Makefile |9 + > .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.c | 371 >
Re: [PATCH 03/71] ncr5380: Eliminate PDEBUG*, TDEBUG* and DTCDEBUG* macros
On 11/18/2015 09:34 AM, Finn Thain wrote:
Replace {P,T,DTC}DEBUG_INIT with NDEBUG_INIT. Remove dead debugging
code, including code that's conditional upon *DEBUG_TRANSFER.
Signed-off-by: Finn Thain
---
drivers/scsi/dtc.c | 18 ++
drivers/scsi/dtc.h | 27 ---
drivers/scsi/pas16.c | 21 +++--
drivers/scsi/pas16.h | 16
drivers/scsi/t128.c | 18 ++
drivers/scsi/t128.h | 16
6 files changed, 19 insertions(+), 97 deletions(-)
Reviewed-by: Hannes Reinecke
Cheers,
Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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 04/71] ncr5380: Remove more pointless macros
On 11/18/2015 09:34 AM, Finn Thain wrote: ASM macro is never defined. rtrc in pas16.c is not used. NCR5380_map_config, do_NCR5380_intr, do_t128_intr and do_pas16_intr are unused. NCR_NOT_SET harms readability. Remove them. Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.h |3 --- drivers/scsi/g_NCR5380.c | 29 ++--- drivers/scsi/g_NCR5380.h |5 - drivers/scsi/pas16.c | 16 drivers/scsi/pas16.h |5 - drivers/scsi/t128.h |4 6 files changed, 14 insertions(+), 48 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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/71] ncr5380: Remove redundant static variable initializers
On 11/18/2015 09:34 AM, Finn Thain wrote: Signed-off-by: Finn Thain --- drivers/scsi/NCR5380.c |2 +- drivers/scsi/dtc.c |4 ++-- drivers/scsi/g_NCR5380.c |4 ++-- drivers/scsi/pas16.c | 10 +- drivers/scsi/sun3_scsi.c |8 drivers/scsi/t128.c |4 ++-- 6 files changed, 16 insertions(+), 16 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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 01/71] atari_scsi: Fix SCSI host ID setting
On 11/18/2015 09:34 AM, Finn Thain wrote: The NVRAM location of this byte is 16, as documented in http://toshyp.atari.org/en/004009.html This was confirmed by Michael Schmitz, by setting the SCSI host ID under EmuTOS and then checking the value in /proc/driver/nvram and /dev/nvram under Linux. Signed-off-by: Finn Thain Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] lpfc: replaced kmalloc + memset with kzalloc
replacing kmalloc and memset by a single call of kzalloc
Signed-off-by: Saurabh Sengar
---
v2 : I didn't got any response for my initial patch,
I am sending it again on top of latest kernel(today's)
drivers/scsi/lpfc/lpfc_els.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index b6fa257..92dd204 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -4956,13 +4956,12 @@ lpfc_els_rcv_rdp(struct lpfc_vport *vport, struct
lpfc_iocbq *cmdiocb,
if (RDP_NPORT_ID_SIZE !=
be32_to_cpu(rdp_req->nport_id_desc.length))
goto rjt_logerr;
- rdp_context = kmalloc(sizeof(struct lpfc_rdp_context), GFP_KERNEL);
+ rdp_context = kzalloc(sizeof(struct lpfc_rdp_context), GFP_KERNEL);
if (!rdp_context) {
rjt_err = LSRJT_UNABLE_TPC;
goto error;
}
- memset(rdp_context, 0, sizeof(struct lpfc_rdp_context));
cmd = >iocb;
rdp_context->ndlp = lpfc_nlp_get(ndlp);
rdp_context->ox_id = cmd->unsli3.rcvsli3.ox_id;
--
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: dma-mappig: HAVE_DMA_ATTR leftovers
Thanks Valention, please send the fixup to Andrew. Looks like both instances were actually introduces after I prepared my patches. -- 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/
dma-mappig: HAVE_DMA_ATTR leftovers
Hi Christoph,
your commit f6f306eeb7ea ("dma-mapping: always provide the dma_map_ops
based implementation") has shown up in today's linux-next tree (i.e.,
next-20151119). The commit removes the Kconfig option HAVE_DMA_ATTR and
does some related clean-ups, but it leaves two references in Kconfig
untouched:
arch/s390/Kconfig:129: select HAVE_DMA_ATTRS
drivers/gpu/drm/vc4/Kconfig:4: depends on DRM && HAVE_DMA_ATTRS
Is there a patched queued somewhere to fix those leftovers? If not, I
can send a trivial patch that removes both.
I found the issue with scripts/checkkconfigsymbols.py by diffing
yesterday's and today's linux-next.
Best regards,
Valentin
--
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] PCI: iproc: Add iProc PCIe MSI support
Hi Marc,
On 11/18/2015 5:37 PM, Ray Jui wrote:
Hi Marc,
On 11/18/2015 12:48 AM, Marc Zyngier wrote:
On Tue, 17 Nov 2015 16:31:54 -0800
Ray Jui wrote:
Hi Ray,
A few comments below.
This patch adds PCIe MSI support for both PAXB and PAXC interfaces on
all iProc based platforms. The patch follows the latest trend in the
kernel to use MSI domain based implementation
This iProc event queue based MSI support should not be used with newer
platforms with integrated MSI support in the GIC (e.g., giv2m or
gicv3-its)
Signed-off-by: Ray Jui
Reviewed-by: Anup Patel
Reviewed-by: Vikram Prakash
Reviewed-by: Scott Branden
---
drivers/pci/host/Kconfig | 9 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-iproc-msi.c | 434
++
drivers/pci/host/pcie-iproc.c | 19 ++
drivers/pci/host/pcie-iproc.h | 12 ++
5 files changed, 475 insertions(+)
create mode 100644 drivers/pci/host/pcie-iproc-msi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f131ba9..972e906 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -126,6 +126,15 @@ config PCIE_IPROC
iProc family of SoCs. An appropriate bus interface driver
also needs
to be enabled
+config PCIE_IPROC_MSI
+bool "Broadcom iProc PCIe MSI support"
+depends on ARCH_BCM_IPROC && PCI_MSI
+select PCI_MSI_IRQ_DOMAIN
+default ARCH_BCM_IPROC
+help
+ Say Y here if you want to enable MSI support for Broadcom's iProc
+ PCIe controller
+
config PCIE_IPROC_PLATFORM
tristate "Broadcom iProc PCIe platform bus driver"
depends on ARCH_BCM_IPROC || (ARM && COMPILE_TEST)
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6..0e4e95e 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
+obj-$(CONFIG_PCIE_IPROC_MSI) += pcie-iproc-msi.o
obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
diff --git a/drivers/pci/host/pcie-iproc-msi.c
b/drivers/pci/host/pcie-iproc-msi.c
new file mode 100644
index 000..a55c707
--- /dev/null
+++ b/drivers/pci/host/pcie-iproc-msi.c
@@ -0,0 +1,434 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie-iproc.h"
+
+#define IPROC_MSI_INTS_EN_OFFSET 0x208
+#define IPROC_MSI_INTR_EN_SHIFT11
+#define IPROC_MSI_INTR_EN BIT(IPROC_MSI_INTR_EN_SHIFT)
+#define IPROC_MSI_INT_N_EVENT_SHIFT1
+#define IPROC_MSI_INT_N_EVENT BIT(IPROC_MSI_INT_N_EVENT_SHIFT)
+#define IPROC_MSI_EQ_EN_SHIFT 0
+#define IPROC_MSI_EQ_ENBIT(IPROC_MSI_EQ_EN_SHIFT)
+
+#define IPROC_MSI_EQ_MASK 0x3f
+
+/* number of queues in each event queue */
+#define IPROC_MSI_EQ_LEN 64
+
+/* size of each event queue memory region */
+#define EQ_MEM_REGION_SIZE SZ_4K
+
+/* size of each MSI message memory region */
+#define MSI_MSG_MEM_REGION_SIZE SZ_4K
+
+enum iproc_msi_reg {
+IPROC_MSI_EQ_PAGE = 0,
+IPROC_MSI_EQ_PAGE_UPPER,
+IPROC_MSI_PAGE,
+IPROC_MSI_PAGE_UPPER,
+IPROC_MSI_CTRL,
+IPROC_MSI_EQ_HEAD,
+IPROC_MSI_EQ_TAIL,
+IPROC_MSI_REG_SIZE,
+};
+
+/**
+ * iProc event queue based MSI
+ *
+ * Only meant to be used on platforms without MSI support integrated
into the
+ * GIC
+ *
+ * @pcie: pointer to iProc PCIe data
+ * @reg_offsets: MSI register offsets
+ * @irqs: pointer to an array that contains the interrupt IDs
+ * @nirqs: number of total interrupts
+ * @has_inten_reg: indicates the MSI interrupt enable register needs
to be
+ * set explicitly (required for some legacy platforms)
+ * @used: bitmap to track usage of MSI
+ * @inner_domain: inner IRQ domain
+ * @msi_domain: MSI IRQ domain
+ * @bitmap_lock: lock to protect access to the IRQ bitmap
+ * @n_eq_region: required number of 4K aligned memory region for MSI
event
+ * queues
+ * @n_msi_msg_region: required number of 4K aligned memory region
for MSI
+ * posted writes
+ * @eq_base: pointer to allocated memory region for MSI event queues
+ * @msi_base: pointer to allocated memory region for MSI posted writes
+ */
+struct iproc_msi {
+struct iproc_pcie
Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
Hi Alex,
On 11/19/2015 12:06 PM, Tian, Kevin wrote:
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, November 19, 2015 2:12 AM
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
{snip}
Hi!
At redhat we've been thinking about how to support vGPUs from multiple
vendors in a common way within QEMU. We want to enable code sharing
between vendors and give new vendors an easy path to add their own
support. We also have the complication that not all vGPU vendors are as
open source friendly as Intel, so being able to abstract the device
mediation and access outside of QEMU is a big advantage.
The proposal I'd like to make is that a vGPU, whether it is from Intel
or another vendor, is predominantly a PCI(e) device. We have an
interface in QEMU already for exposing arbitrary PCI devices, vfio-pci.
Currently vfio-pci uses the VFIO API to interact with "physical" devices
and system IOMMUs. I highlight /physical/ there because some of these
physical devices are SR-IOV VFs, which is somewhat of a fuzzy concept,
somewhere between fixed hardware and a virtual device implemented in
software. That software just happens to be running on the physical
endpoint.
Agree.
One clarification for rest discussion, is that we're talking about GVT-g vGPU
here which is a pure software GPU virtualization technique. GVT-d (note
some use in the text) refers to passing through the whole GPU or a specific
VF. GVT-d already falls into existing VFIO APIs nicely (though some on-going
effort to remove Intel specific platform stickness from gfx driver). :-)
Hi Alex, thanks for the discussion.
In addition to Kevin's replies, I have a high-level question: can VFIO
be used by QEMU for both KVM and Xen?
--
Thanks,
Jike
vGPUs are similar, with the virtual device created at a different point,
host software. They also rely on different IOMMU constructs, making use
of the MMU capabilities of the GPU (GTTs and such), but really having
similar requirements.
One important difference between system IOMMU and GPU-MMU here.
System IOMMU is very much about translation from a DMA target
(IOVA on native, or GPA in virtualization case) to HPA. However GPU
internal MMUs is to translate from Graphics Memory Address (GMA)
to DMA target (HPA if system IOMMU is disabled, or IOVA/GPA if system
IOMMU is enabled). GMA is an internal addr space within GPU, not
exposed to Qemu and fully managed by GVT-g device model. Since it's
not a standard PCI defined resource, we don't need abstract this capability
in VFIO interface.
The proposal is therefore that GPU vendors can expose vGPUs to
userspace, and thus to QEMU, using the VFIO API. For instance, vfio
supports modular bus drivers and IOMMU drivers. An intel-vfio-gvt-d
module (or extension of i915) can register as a vfio bus driver, create
a struct device per vGPU, create an IOMMU group for that device, and
register that device with the vfio-core. Since we don't rely on the
system IOMMU for GVT-d vGPU assignment, another vGPU vendor driver (or
extension of the same module) can register a "type1" compliant IOMMU
driver into vfio-core. From the perspective of QEMU then, all of the
existing vfio-pci code is re-used, QEMU remains largely unaware of any
specifics of the vGPU being assigned, and the only necessary change so
far is how QEMU traverses sysfs to find the device and thus the IOMMU
group leading to the vfio group.
GVT-g requires to pin guest memory and query GPA->HPA information,
upon which shadow GTTs will be updated accordingly from (GMA->GPA)
to (GMA->HPA). So yes, here a dummy or simple "type1" compliant IOMMU
can be introduced just for this requirement.
However there's one tricky point which I'm not sure whether overall
VFIO concept will be violated. GVT-g doesn't require system IOMMU
to function, however host system may enable system IOMMU just for
hardening purpose. This means two-level translations existing (GMA->
IOVA->HPA), so the dummy IOMMU driver has to request system IOMMU
driver to allocate IOVA for VMs and then setup IOVA->HPA mapping
in IOMMU page table. In this case, multiple VM's translations are
multiplexed in one IOMMU page table.
We might need create some group/sub-group or parent/child concepts
among those IOMMUs for thorough permission control.
There are a few areas where we know we'll need to extend the VFIO API to
make this work, but it seems like they can all be done generically. One
is that PCI BARs are described through the VFIO API as regions and each
region has a single flag describing whether mmap (ie. direct mapping) of
that region is possible. We expect that vGPUs likely need finer
granularity, enabling some areas within a BAR to be trapped and fowarded
as a read or write access for the vGPU-vfio-device module to emulate,
while other regions, like framebuffers or texture regions, are directly
mapped. I have prototype code to enable this already.
Yes in GVT-g one BAR resource might be
Re: [PATCH] tty/vt/keyboard: use memdup_user to simplify code
On 28 October 2015 at 11:56, Saurabh Sengar wrote:
> use memdup_user rather than duplicating implementation.
> found by coccinelle
>
> Signed-off-by: Saurabh Sengar
> ---
> drivers/tty/vt/keyboard.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
> index 6f0336f..f973bfc 100644
> --- a/drivers/tty/vt/keyboard.c
> +++ b/drivers/tty/vt/keyboard.c
> @@ -1706,16 +1706,12 @@ int vt_do_diacrit(unsigned int cmd, void __user *udp,
> int perm)
> return -EINVAL;
>
> if (ct) {
> - dia = kmalloc(sizeof(struct kbdiacr) * ct,
> - GFP_KERNEL);
> - if (!dia)
> - return -ENOMEM;
>
> - if (copy_from_user(dia, a->kbdiacr,
> - sizeof(struct kbdiacr) * ct)) {
> - kfree(dia);
> - return -EFAULT;
> - }
> + dia = memdup_user(a->kbdiacr,
> + sizeof(struct kbdiacr) * ct);
> + if (IS_ERR(dia))
> + return PTR_ERR(dia);
> +
> }
>
> spin_lock_irqsave(_event_lock, flags);
> --
> 1.9.1
>
Hi,
Is this patch rejected for some reason or is still in queue?
--
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] drivers: power: set IRQF_ONESHOT if no primary handler is specified
If no primary handler is specified for threaded_irq then a
default one is assigned which always returns IRQ_WAKE_THREAD.
This handler requires the IRQF_ONESHOT, because the source of
interrupt is not disabled.
Signed-off-by: Saurabh Sengar
---
drivers/power/max8903_charger.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/power/max8903_charger.c b/drivers/power/max8903_charger.c
index 6d39d52..17876ca 100644
--- a/drivers/power/max8903_charger.c
+++ b/drivers/power/max8903_charger.c
@@ -291,10 +291,10 @@ static int max8903_probe(struct platform_device *pdev)
if (pdata->dc_valid) {
ret = devm_request_threaded_irq(dev, gpio_to_irq(pdata->dok),
- NULL, max8903_dcin,
- IRQF_TRIGGER_FALLING |
- IRQF_TRIGGER_RISING,
- "MAX8903 DC IN", data);
+ NULL, max8903_dcin,
+ IRQF_TRIGGER_FALLING |
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ "MAX8903 DC IN", data);
if (ret) {
dev_err(dev, "Cannot request irq %d for DC (%d)\n",
gpio_to_irq(pdata->dok), ret);
@@ -304,10 +304,10 @@ static int max8903_probe(struct platform_device *pdev)
if (pdata->usb_valid) {
ret = devm_request_threaded_irq(dev, gpio_to_irq(pdata->uok),
- NULL, max8903_usbin,
- IRQF_TRIGGER_FALLING |
- IRQF_TRIGGER_RISING,
- "MAX8903 USB IN", data);
+ NULL, max8903_usbin,
+ IRQF_TRIGGER_FALLING |
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ "MAX8903 USB IN", data);
if (ret) {
dev_err(dev, "Cannot request irq %d for USB (%d)\n",
gpio_to_irq(pdata->uok), ret);
@@ -317,10 +317,10 @@ static int max8903_probe(struct platform_device *pdev)
if (pdata->flt) {
ret = devm_request_threaded_irq(dev, gpio_to_irq(pdata->flt),
- NULL, max8903_fault,
- IRQF_TRIGGER_FALLING |
- IRQF_TRIGGER_RISING,
- "MAX8903 Fault", data);
+ NULL, max8903_fault,
+ IRQF_TRIGGER_FALLING |
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ "MAX8903 Fault", data);
if (ret) {
dev_err(dev, "Cannot request irq %d for Fault (%d)\n",
gpio_to_irq(pdata->flt), ret);
--
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 v3 03/12] drm/rockchip: return a true clock rate to adjusted_mode
On 2015年11月19日 11:35, Chris Zhong wrote:
+
+ /*
+* Sometimes the clock driver can not set a accurate clock_rate for vop,
+* get the true rate of vop_dclk and set it back to adjusted_mode.
+*/
+ adjusted_mode->clock = clk_get_rate(vop->dclk) / 1000;
out:
ret_clk = clk_enable(vop->dclk);
if (ret_clk < 0) {
Hi Chris
How about use clk_round_rate to check the clock rate first?
I think we can check it on vop_crtc_mode_fixup.
Thanks.
- Ｍark Yao
--
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: kernel oops on mmotm-2015-10-15-15-20
On Thu, Nov 19, 2015 at 11:12:21AM +0900, Minchan Kim wrote: > On Tue, Nov 17, 2015 at 11:32:13AM +0200, Kirill A. Shutemov wrote: > > On Tue, Nov 17, 2015 at 04:35:39PM +0900, Minchan Kim wrote: > > > On Mon, Nov 16, 2015 at 12:54:53PM +0200, Kirill A. Shutemov wrote: > > > > On Mon, Nov 16, 2015 at 07:32:20PM +0900, Minchan Kim wrote: > > > > > On Mon, Nov 16, 2015 at 10:45:22AM +0200, Kirill A. Shutemov wrote: > > > > > > On Mon, Nov 16, 2015 at 10:45:21AM +0900, Minchan Kim wrote: > > > > > > > During the test with MADV_FREE on kernel I applied your patches, > > > > > > > I couldn't see any problem. > > > > > > > > > > > > > > However, in this round, I did another test which is same one > > > > > > > I attached but a liitle bit different because it doesn't do > > > > > > > (memcg things/kill/swapoff) for testing program long-live test. > > > > > > > > > > > > Could you share updated test? > > > > > > > > > > It's part of my testing suite so I should factor it out. > > > > > I will send it when I go to office tomorrow. > > > > > > > > Thanks. > > > > > > > > > > And could you try to reproduce it on clean mmotm-2015-11-10-15-53? > > > > > > > > > > Befor leaving office, I queued it up and result is below. > > > > > It seems you fixed already but didn't apply it to mmotm yet. Right? > > > > > Anyway, please confirm and say to me what I should add more patches > > > > > into mmotm-2015-11-10-15-53 for follow up your recent many bug > > > > > fix patches. > > > > > > > > The two my patches which are not in the mmotm-2015-11-10-15-53 release: > > > > > > > > http://lkml.kernel.org/g/1447236557-68682-1-git-send-email-kirill.shute...@linux.intel.com > > > > http://lkml.kernel.org/g/1447236567-68751-1-git-send-email-kirill.shute...@linux.intel.com > > > > > > 1. mm: fix __page_mapcount() > > > 2. thp: fix leak due split_huge_page() vs. exit race > > > > > > If I missed some patches, let me know it. > > > > > > I applied above two patches based on mmotm-2015-11-10-15-53 and tested > > > again. > > > But unfortunately, the result was below. > > > > > > Now, I am making test program I can send to you but it seems to be not > > > easy > > > because small changes for factoring it out from testing suite seems to > > > change > > > something(ex, timing) and makes hard to reproduce. I will try it again. > > > > Your test suite seems generate quite a few bug reports. Don't mind make > > whole > > suite public? > > It's tough due to including company internal stuffs. > That's why I try to factor the part I can share out but unfortunatel, > I couldn't grab a time for retrying until now. :( > > > > > > page:ea240080 count:2 mapcount:1 mapping:88007eff3321 > > > index:0x60e02 > > > flags: 0x40040018(uptodate|dirty|swapbacked) > > > page dumped because: VM_BUG_ON_PAGE(!PageLocked(page)) > > > page->mem_cgroup:880077cf0c00 > > > [ cut here ] > > > kernel BUG at mm/huge_memory.c:3272! > > > invalid opcode: [#1] SMP > > > Dumping ftrace buffer: > > >(ftrace buffer empty) > > > Modules linked in: > > > CPU: 8 PID: 59 Comm: khugepaged Not tainted 4.3.0-mm1-kirill+ #8 > > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs > > > 01/01/2011 > > > task: 880073441a40 ti: 88007344c000 task.ti: 88007344c000 > > > RIP: 0010:[] [] > > > split_huge_page_to_list+0x8fb/0x910 > > > RSP: 0018:88007344f968 EFLAGS: 00010286 > > > RAX: 0021 RBX: ea240080 RCX: > > > RDX: 0001 RSI: 0246 RDI: 821df4d8 > > > RBP: 88007344f9e8 R08: R09: 880bc600 > > > R10: 8163e2c0 R11: 4b47 R12: ea240080 > > > R13: ea240088 R14: ea240080 R15: > > > FS: () GS:88007830() > > > knlGS: > > > CS: 0010 DS: ES: CR0: 8005003b > > > CR2: 7ffd59edcd68 CR3: 01808000 CR4: 06a0 > > > Stack: > > > cccd ea240080 88007344fa00 ea240088 > > > 88007344fa00 88007344f9e8 810f0200 > > > ea24 ea240080 > > > Call Trace: > > > [] ? __lock_page+0xa0/0xb0 > > > [] deferred_split_scan+0x115/0x240 > > > [] ? list_lru_count_one+0x1c/0x30 > > > [] shrink_slab.part.42+0x1e3/0x350 > > > [] shrink_zone+0x26a/0x280 > > > [] do_try_to_free_pages+0x12d/0x3b0 > > > [] try_to_free_pages+0xb4/0x140 > > > [] __alloc_pages_nodemask+0x459/0x920 > > > [] ? trace_event_raw_event_tick_stop+0xd0/0xd0 > > > [] khugepaged+0x155/0x1b10 > > > [] ? prepare_to_wait_event+0xf0/0xf0 > > > [] ? __split_huge_pmd_locked+0x4e0/0x4e0 > > > [] kthread+0xc9/0xe0 > > > [] ? kthread_park+0x60/0x60 > > > [] ret_from_fork+0x3f/0x70 > > > [] ? kthread_park+0x60/0x60 > > > Code: ff ff 48 c7 c6 00 cd 77 81 4c 89 f7 e8 df ce fc ff 0f
Re: [RFD] Functional dependencies between devices
On 11/17/2015 02:55 PM, Mark Brown wrote: > On Tue, Nov 17, 2015 at 01:49:17PM +0100, Andrzej Hajda wrote: > > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much > easier to read and reply to. > >> On 10/27/2015 04:24 PM, Rafael J. Wysocki wrote: >> this scenario: >> - many clock providers, irq domains are not provided by devices, > That seems like something we can and possibly should change if we want. > >> - there are also dependencies between clock providers, ie. some clock >> provider >> requires clocks provided by another clock provider, so the entity is also >> not a >> device driver, > This is going to be really common but I'm not sure I see a problem with > it in terms of what Raphael is proposing - could you go into more detail > on the problem you see here? If clock provider is not a device driver and it depends on clocks of another clock provider you cannot 'translate' this dependency as dependency between devices, so this RFD does not cover them. Additionally if you look into kernel there are many calls in form 'clk_get(NULL, name)', it suggests that not only clock providers are consumers without underlying device driver. Regards Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation
On Wed, Nov 18, 2015 at 04:34:30PM +0100, Vlastimil Babka wrote: > On 11/09/2015 08:23 AM, Joonsoo Kim wrote: > > CMA allocation should be guaranteed to succeed by definition, but, > > unfortunately, it would be failed sometimes. It is hard to track down > > the problem, because it is related to page reference manipulation and > > we don't have any facility to analyze it. > > Reminds me of the PeterZ's VM_PINNED patchset. What happened to it? > https://lwn.net/Articles/600502/ > > > This patch adds tracepoints to track down page reference manipulation. > > With it, we can find exact reason of failure and can fix the problem. > > Following is an example of tracepoint output. > > > > <...>-9018 [004]92.678375: page_ref_set: pfn=0x17ac9 flags=0x0 > > count=1 mapcount=0 mapping=(nil) mt=4 val=1 > > <...>-9018 [004]92.678378: kernel_stack: > > => get_page_from_freelist (81176659) > > => __alloc_pages_nodemask (81176d22) > > => alloc_pages_vma (811bf675) > > => handle_mm_fault (8119e693) > > => __do_page_fault (810631ea) > > => trace_do_page_fault (81063543) > > => do_async_page_fault (8105c40a) > > => async_page_fault (817581d8) > > [snip] > > <...>-9018 [004]92.678379: page_ref_mod: pfn=0x17ac9 > > flags=0x40048 count=2 mapcount=1 mapping=0x880015a78dc1 mt=4 val=1 > > [snip] > > ... > > ... > > <...>-9131 [001]93.174468: test_pages_isolated: start_pfn=0x17800 > > end_pfn=0x17c00 fin_pfn=0x17ac9 ret=fail > > [snip] > > <...>-9018 [004]93.174843: page_ref_mod_and_test: pfn=0x17ac9 > > flags=0x40068 count=0 mapcount=0 mapping=0x880015a78dc1 mt=4 val=-1 > > ret=1 > > => release_pages (8117c9e4) > > => free_pages_and_swap_cache (811b0697) > > => tlb_flush_mmu_free (81199616) > > => tlb_finish_mmu (8119a62c) > > => exit_mmap (811a53f7) > > => mmput (81073f47) > > => do_exit (810794e9) > > => do_group_exit (81079def) > > => SyS_exit_group (81079e74) > > => entry_SYSCALL_64_fastpath (817560b6) > > > > This output shows that problem comes from exit path. In exit path, > > to improve performance, pages are not freed immediately. They are gathered > > and processed by batch. During this process, migration cannot be possible > > and CMA allocation is failed. This problem is hard to find without this > > page reference tracepoint facility. > > Yeah but when you realized it was this problem, what was the fix? Probably not > remove batching from exit path? Shouldn't CMA in this case just try waiting > for > the pins to go away, which would eventually happen? And for long-term pins, > VM_PINNED would make sure the pages are migrated away from CMA pageblocks > first? > > So I'm worried that this is quite nontrivial change for a very specific > usecase. This patch is not to solve the problem but just to expose what is culprit. For using VM_PINNED, firstly, we should know where are long-term pins. There are obviously clear places which will be first target if we use VM_PINNED but somewhere are vague. For vague places, this patch will help finding there. Even we don't use VM_PINNED, this patch will expose current obstacle which can help to understand current problems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] lib: Introduce 2 bit ops api: all_is_bit_{one,zero}
This patch introduces 2 lightweight bit api.
all_bit_is_zero return 1 if the bit string is all zero.
The addr is the start address, the size is the bit size of the bit string.
all_bit_is_one is the opposite.
Signed-off-by: Jia He
---
lib/find_bit.c | 50 ++
1 file changed, 50 insertions(+)
diff --git a/lib/find_bit.c b/lib/find_bit.c
index 18072ea..1d56d8d 100644
--- a/lib/find_bit.c
+++ b/lib/find_bit.c
@@ -131,6 +131,56 @@ unsigned long find_last_bit(const unsigned long *addr,
unsigned long size)
EXPORT_SYMBOL(find_last_bit);
#endif
+#ifndef all_bit_is_zero
+/*
+ * return val: 1 means all bit is zero
+ */
+unsigned int all_bit_is_zero(const unsigned long *addr, unsigned size)
+{
+ unsigned long idx;
+ unsigned long mask = size;
+
+ if (unlikely(size == 0))
+ return 1;
+
+ if (size > BITS_PER_LONG) {
+ for (idx = 0; idx * BITS_PER_LONG < size; idx++)
+ if (addr[idx])
+ return 0;
+
+ mask = size - (idx - 1) * BITS_PER_LONG;
+ }
+
+ return !(*addr & BITMAP_LAST_WORD_MASK(mask));
+}
+EXPORT_SYMBOL(all_bit_is_zero);
+#endif
+
+#ifndef all_bit_is_one
+/*
+ * return val: 1 means all bit is one
+ */
+unsigned int all_bit_is_one(const unsigned long *addr, unsigned size)
+{
+ unsigned long idx;
+ unsigned long mask = size;
+
+ if (unlikely(size == 0))
+ return 1;
+
+ if (size > BITS_PER_LONG) {
+ for (idx = 0; idx * BITS_PER_LONG < size; idx++)
+ if (~addr[idx])
+ return 0;
+
+ mask = size - (idx - 1) * BITS_PER_LONG;
+ }
+
+ return !(~(*addr) & BITMAP_LAST_WORD_MASK(mask));
+}
+EXPORT_SYMBOL(all_bit_is_one);
+#endif
+
#ifdef __BIG_ENDIAN
/* include/linux/byteorder does not support "unsigned long" type */
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] linux/bitmap: Move 2 mask macro from bitmap.h to bitops.h
This patch moves the mask macro to bitops.h and then the new introduced api in find_bit.c can use it. Signed-off-by: Jia He --- include/linux/bitmap.h | 3 --- include/linux/bitops.h | 4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h index 9653fdb..15524f6 100644 --- a/include/linux/bitmap.h +++ b/include/linux/bitmap.h @@ -172,9 +172,6 @@ extern unsigned int bitmap_ord_to_pos(const unsigned long *bitmap, unsigned int extern int bitmap_print_to_pagebuf(bool list, char *buf, const unsigned long *maskp, int nmaskbits); -#define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 1))) -#define BITMAP_LAST_WORD_MASK(nbits) (~0UL >> (-(nbits) & (BITS_PER_LONG - 1))) - #define small_const_nbits(nbits) \ (__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG) diff --git a/include/linux/bitops.h b/include/linux/bitops.h index 2b8ed12..b881028 100644 --- a/include/linux/bitops.h +++ b/include/linux/bitops.h @@ -24,6 +24,10 @@ #define GENMASK_ULL(h, l) \ (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h +/* For bitmap ops*/ +#define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 1))) +#define BITMAP_LAST_WORD_MASK(nbits) (~0UL >> (-(nbits) & (BITS_PER_LONG - 1))) + extern unsigned int __sw_hweight8(unsigned int w); extern unsigned int __sw_hweight16(unsigned int w); extern unsigned int __sw_hweight32(unsigned int w); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] linux/bitmap: Replace find_fisrt_{zero_}bit with the new lightweight api
This is to replace find_fisrt_{zero_}bit with the new lightweight api
all_bit_is_{one,zero} in bitmap_{full,empty}
Signed-off-by: Jia He
---
include/linux/bitmap.h | 4 ++--
include/linux/bitops.h | 3 +++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index 15524f6..8877a68 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -281,7 +281,7 @@ static inline int bitmap_empty(const unsigned long *src,
unsigned nbits)
if (small_const_nbits(nbits))
return ! (*src & BITMAP_LAST_WORD_MASK(nbits));
- return find_first_bit(src, nbits) == nbits;
+ return all_bit_is_zero(src, nbits);
}
static inline int bitmap_full(const unsigned long *src, unsigned int nbits)
@@ -289,7 +289,7 @@ static inline int bitmap_full(const unsigned long *src,
unsigned int nbits)
if (small_const_nbits(nbits))
return ! (~(*src) & BITMAP_LAST_WORD_MASK(nbits));
- return find_first_zero_bit(src, nbits) == nbits;
+ return all_bit_is_one(src, nbits);
}
static __always_inline int bitmap_weight(const unsigned long *src, unsigned
int nbits)
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index b881028..e34f2ff 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -214,6 +214,9 @@ static inline unsigned long __ffs64(u64 word)
return __ffs((unsigned long)word);
}
+extern unsigned int all_bit_is_one(const unsigned long *addr, unsigned size);
+extern unsigned int all_bit_is_zero(const unsigned long *addr, unsigned size);
+
#ifdef __KERNEL__
#ifndef set_mask_bits
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] Improve bitmap_empty and bitmap_full
find_fisrt_{zero_}bit are too heavy for bitmap_{full,empty}. We don't
need to calculate and compare the position of bitmap. This set of patch
instroduces lightweight api and replaces the heavy one.
v2: Move the declarations to linux/bitops.h for compilation
Jia He (3):
Move 2 mask macro from bitmap.h to bitops.h
Introduce 2 bit ops api: all_is_bit_{one,zero}
Replace find_fisrt_{zero_}bit with the new lightweight api
include/linux/bitmap.h | 7 ++-
include/linux/bitops.h | 7 +++
lib/find_bit.c | 50 ++
3 files changed, 59 insertions(+), 5 deletions(-)
--
2.5.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] usb: gadget: Add the console support for usb-to-serial port
>
>> +{
>> + struct gscons_info *info = gserial_cons.data;
>> + int port_num = gserial_cons.index;
>> + struct usb_request *req;
>> + struct gs_port *port;
>> + struct usb_ep *ep;
>> +
>> + if (port_num >= MAX_U_SERIAL_PORTS || port_num < 0) {
>> + pr_err("%s: port num [%d] exceeds the range.\n",
>> +__func__, port_num);
>> + return -ENXIO;
>> + }
>> +
>> + port = ports[port_num].port;
>> + if (!port) {
>> + pr_err("%s: serial line [%d] not allocated.\n",
>> +__func__, port_num);
>> + return -ENODEV;
>> + }
>> +
>> + if (!port->port_usb) {
>> + pr_err("%s: no port usb.\n", __func__);
>> + return -ENODEV;
>> + }
>> +
>> + ep = port->port_usb->in;
>> + if (!ep) {
>> + pr_err("%s: no usb endpoint.\n", __func__);
>> + return -ENXIO;
>> + }
>
> Looking at the caller, gserial_connect(), none of the error
> conditions above look possible.
>
I re-look the code and do some tests, I found the checking is
necessary. Cause we get the port number from the console->index, if
the cmdline is not set the ttyGS0 as the console, the console->index
will be -1 that is a wrong value. Also the serial.c file will create 1
usb-to-seial port as default (default n_ports = 1), so we need to
check the port and the endpoint of the port. So I think here checking
is necessary and I have tested it.
--
Baolin.wang
Best Regards
--
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] hid: usbhid: hid-core: fix recursive deadlock
On Wed, 18 Nov 2015 17:58:56 -0600 Josh Cartwright wrote: > On Wed, Nov 18, 2015 at 11:05:44PM +0200, Ioan-Adrian Ratiu wrote: > > On Wed, 18 Nov 2015 21:37:42 +0100 (CET) > > Jiri Kosina wrote: > > > > > On Wed, 18 Nov 2015, Ioan-Adrian Ratiu wrote: > > > > > > > The critical section protected by usbhid->lock in hid_ctrl() is too > > > > big and in rare cases causes a recursive deadlock because of its call > > > > to hid_input_report(). > > > > > > > > This deadlock reproduces on newer wacom tablets like 056a:033c because > > > > the wacom driver in its irq handler ends up calling hid_hw_request() > > > > from wacom_intuos_schedule_prox_event() in wacom_wac.c. What this means > > > > is that it submits a report to reschedule a proximity read through a > > > > sync ctrl call which grabs the lock in hid_ctrl(struct urb *urb) > > > > before calling hid_input_report(). When the irq kicks in on the same > > > > cpu, it also tries to grab the lock resulting in a recursive deadlock. > > > > > > > > The proper fix is to shrink the critical section in hid_ctrl() to > > > > protect only the instructions which modify usbhid, thus move the lock > > > > after the hid_input_report() call and the deadlock dissapears. > > > > > > I think the proper fix actually is to spin_lock_irqsave() in hid_ctrl(), > > > isn't it? > > > > > > > That was my first attempt, yes, but the deadlock still happens with > > interrupts disabled. It is very weird, I know. > > I think your best course of action is to figure out why this is the > case, instead of continuing with trying to solve the symptoms. Do you > have actual callstacks showing the cases where you hit? That might be > useful to share (your lockdep picture cuts out the callstacks). > > Also, have you tried without the PREEMPT_RT patch in the picture at all? > > Josh Yes, of course I tried it without PREEMPT_RT_FULL :) This happens on vanilla mainline kernels (only after 4.4-rc1 which introduced support for this kind of tablets). I also backported all the wacom patches to 4.1 non-RT and the same deadlock happens. I've sent another email with some lockdep traces and printk's on a running vanilla linux-next, maybe it didn't get through, here are the links again: First part of lockdep report: http://imgur.com/clLsCWe Second part: http://imgur.com/Wa2PzRl Here are some printk's of mine while reproducing + debugging the issue: http://imgur.com/SETOHT7 I'll continue to research this more in depth, but progress is slow because I don't have much time, I'm doing this in my spare time because it's my girlfriend's tablet. -- 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: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction
On 2015/11/19 14:37, Ingo Molnar wrote: * Wangnan (F) wrote: perf cmdline is # ./pref record -g -F 9 --call-graph dwarf ./test_dwarf_unwind Use default events, precise_ip == 2 so uses PEBS. Testetd 'cycles', 'cycles:p' and 'cycles:pp'. Only 'cycles:pp' captures sample at callq. So maybe a PEBS problem? Well, that's how our PEBS sampling works: we roll back the instruction pointer to point at the instruction generating the sample. The state itself is post-instruction. Just for curiosity: how the interrupted process continue to execute, when the PC saved in pt_regs still pointed to 'callq' but SP and stack has already changes? Do we fix it in kernel, or by hardware? Thank you. -- 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: vfxxx: Include support for dspi[23] functionality.
Verified too, looks good to me.
Acked-by: Stefan Agner
--
Stefan
On 2015-11-18 19:54, Cory Tusar wrote:
> Extend the existing Vybrid DSPI devicetree implementation to also
> describe the dspi2 and dspi3 functional blocks.
>
> Signed-off-by: Cory Tusar
> ---
> arch/arm/boot/dts/vfxxx.dtsi | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 1cca43a..858e60a 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -453,6 +453,30 @@
> status = "disabled";
> };
>
> + dspi2: dspi2@400ac000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-dspi";
> + reg = <0x400ac000 0x1000>;
> + interrupts = <69 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < VF610_CLK_DSPI2>;
> + clock-names = "dspi";
> + spi-num-chipselects = <2>;
> + status = "disabled";
> + };
> +
> + dspi3: dspi3@400ad000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-dspi";
> + reg = <0x400ad000 0x1000>;
> + interrupts = <70 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < VF610_CLK_DSPI3>;
> + clock-names = "dspi";
> + spi-num-chipselects = <2>;
> + status = "disabled";
> + };
> +
> adc1: adc@400bb000 {
> compatible = "fsl,vf610-adc";
> reg = <0x400bb000 0x1000>;
--
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: [BUG REPORT] perf tools: x86_64: Broken calllchain when sampling taken at 'callq' instruction
* Wangnan (F) wrote: > >perf cmdline is > > > ># ./pref record -g -F 9 --call-graph dwarf ./test_dwarf_unwind > > > >Use default events, precise_ip == 2 so uses PEBS. > > > > Testetd 'cycles', 'cycles:p' and 'cycles:pp'. Only 'cycles:pp' captures > sample at callq. So maybe a PEBS problem? Well, that's how our PEBS sampling works: we roll back the instruction pointer to point at the instruction generating the sample. The state itself is post-instruction. So dwarf unwind has to take this into account. Should the kernel pass in the original (uncorrected) RIP as well, perhaps? Thanks, Ingo -- 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: vfxxx: Fix dspi[01] spi-num-chipselects.
On 2015-11-18 19:54, Cory Tusar wrote: > Per the Vybrid Reference Manual (section 3.8.6.1), dspi0 has 6 chip > select signals associated with it, while dspi1 has only 4. That is right, verified by in my RM! Acked-by: Stefan Agner > > Signed-off-by: Cory Tusar > --- > arch/arm/boot/dts/vfxxx.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi > index 6736bae..1cca43a 100644 > --- a/arch/arm/boot/dts/vfxxx.dtsi > +++ b/arch/arm/boot/dts/vfxxx.dtsi > @@ -158,7 +158,7 @@ > interrupts = <67 IRQ_TYPE_LEVEL_HIGH>; > clocks = < VF610_CLK_DSPI0>; > clock-names = "dspi"; > - spi-num-chipselects = <5>; > + spi-num-chipselects = <6>; > status = "disabled"; > }; > > @@ -170,7 +170,7 @@ > interrupts = <68 IRQ_TYPE_LEVEL_HIGH>; > clocks = < VF610_CLK_DSPI1>; > clock-names = "dspi"; > - spi-num-chipselects = <5>; > + spi-num-chipselects = <4>; > status = "disabled"; > }; -- 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] include: asm-generic: page.h: Remove useless get_user_page and free_user_page
On Thursday 19 November 2015 01:10 AM, Chen Gang wrote: > From ba7c00c4cb976109b6a35812ce9649aaeda81e2d Mon Sep 17 00:00:00 2001 > From: Chen Gang > Date: Thu, 19 Nov 2015 03:24:42 +0800 > Subject: [PATCH] include: asm-generic: page.h: Remove useless get_user_page > and free_user_page > > They are not symmetric with each other, neither are used in real world > (can not be found by grep command in source code root directory), so > remove them. > > Signed-off-by: Chen Gang > --- > arch/arc/include/asm/page.h | 3 --- > arch/arm/include/asm/page-nommu.h | 3 --- > arch/frv/include/asm/page.h | 3 --- > arch/m68k/include/asm/page_mm.h | 3 --- > arch/m68k/include/asm/page_no.h | 3 --- > arch/openrisc/include/asm/page.h | 3 --- > include/asm-generic/page.h| 3 --- > 7 files changed, 21 deletions(-) So this is one huge patch touching several arches with potential to cause conflicts when merged. Can u divy them up and then the maintainers can simply merge them individually given there is no common dependency ! -- 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/4] mtd: brcmnand: improve memory management
On Wed, 18 Nov 2015, Brian Norris wrote:
> On Wed, Nov 18, 2015 at 11:04:11PM +0100, Julia Lawall wrote:
> > This patch addresses several related memory management issues in the probe
> > function:
> >
> > 1. for_each_available_child_of_node performs an of_node_get on each
> > iteration, so a break out of the loop requires an of_node_put.
> >
> > A simplified version of the semantic patch that fixes this problem is as
> > follows (http://coccinelle.lip6.fr):
> >
> > //
> > @@
> > expression root,e;
> > local idexpression child;
> > @@
> >
> > for_each_available_child_of_node(root, child) {
> >... when != of_node_put(child)
> >when != e = child
> > (
> >return child;
> > |
> > + of_node_put(child);
> > ? return ...;
> > )
> >...
> > }
> > //
>
> Good catch again
>
> > 2. The devm_kzalloc'd data is not used if brcmnand_init_cs fails. Free it
> > immediately, using devm_kfree in this case, instead of waiting for the
> > remove function.
>
> Same
>
> > 3. If the continue is not taken, then host is added to a list, that has a
> > lifetime beyond the end of the for_each_available_child_of_node loop body.
> > Thus, of_node_get is needed on child, which is referenced by host. A
> > corresponding of_node_put is needed in the remove function.
>
> This one's a bit silly. We really shouldn't be keeping the reference in
> 'host' at all. Also, as of commit 215a02fd3087 ("mtd: grab a reference to
> the MTD of_node before registering it"), the MTD core will actually be
> refcounting the node for us, too, so this isn't really necessary.
>
> I have a patch to remove brcmnand_host::of_node (appended below), which
> should make this step obsolete, and be more obvious that no extra
> of_node_get()'ing is required.
OK. Should I resend my patch without this change?
julia
> > Signed-off-by: Julia Lawall
> >
> > ---
> >
> > One could consider whether the of_node_get should be on host->of_node,
> > which looks more similar to the thing that is stored in the list. I used
> > child, to be more similar to the of_node_put in the same function.
> >
> > drivers/mtd/nand/brcmnand/brcmnand.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> > b/drivers/mtd/nand/brcmnand/brcmnand.c
> > index 2a437c7..b0cb55d 100644
> > --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> > +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> > @@ -2237,16 +2237,20 @@ int brcmnand_probe(struct platform_device *pdev,
> > struct brcmnand_soc *soc)
> > struct brcmnand_host *host;
> >
> > host = devm_kzalloc(dev, sizeof(*host), GFP_KERNEL);
> > - if (!host)
> > + if (!host) {
> > + of_node_put(child);
> > return -ENOMEM;
>
> In code reading, I noticed that we don't actually cleanup for prior
> iterations of brcmnand_init_cs() here. i.e., if we're exiting here, we
> should be doing nand_release() on all previously-registered chips.
>
> > + }
> > host->pdev = pdev;
> > host->ctrl = ctrl;
> > host->of_node = child;
> >
> > ret = brcmnand_init_cs(host);
> > - if (ret)
> > + if (ret) {
> > + devm_kfree(dev, host);
> > continue; /* Try all chip-selects */
> > -
> > + }
> > + of_node_get(child);
> > list_add_tail(>node, >host_list);
> > }
> > }
> > @@ -2264,8 +2268,10 @@ int brcmnand_remove(struct platform_device *pdev)
> > struct brcmnand_controller *ctrl = dev_get_drvdata(>dev);
> > struct brcmnand_host *host;
> >
> > - list_for_each_entry(host, >host_list, node)
> > + list_for_each_entry(host, >host_list, node) {
> > + of_node_put(host->of_node);
> > nand_release(>mtd);
> > + }
> >
> > dev_set_drvdata(>dev, NULL);
> >
>
> Patch to kill off some of this:
>
> ---8<---
> From 6c51a9ef1325e7b06a7623c1fbca1adf6eeb8253 Mon Sep 17 00:00:00 2001
> From: Brian Norris
> Date: Wed, 18 Nov 2015 14:33:24 -0800
> Subject: [PATCH] mtd: brcmnand: drop brcmnand_host::of_node field
>
> We don't actually need to stash a copy of this device_node indefinitely;
> we only need it in brcmnand_init_cs().
>
> Signed-off-by: Brian Norris
> Cc:
> Cc: Kamal Dasu
> ---
> drivers/mtd/nand/brcmnand/brcmnand.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index c395b4a75fb1..351438a62aaa 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -176,7 +176,6 @@ struct brcmnand_cfg {
>
> struct brcmnand_host {
> struct list_headnode;
> - struct device_node
[PATCH perf/core v2] perf: Make perf_exec_path always returns malloc'd string
Since system_path() returns malloc'd string if given path is
not an absolute path, perf_exec_path sometimes returns static
string and sometimes returns malloc'd string depends on the
environment variables or command options.
This causes a memory leak because caller can not free the
returned string.
This fixes perf_exec_path and system_path to always return
malloc'd string, so caller can always free it.
Signed-off-by: Masami Hiramatsu
---
Changes in v2:
- do not change the behavior if strdup is failed.
---
tools/perf/util/exec_cmd.c | 21 +++--
tools/perf/util/exec_cmd.h |5 +++--
tools/perf/util/help.c |6 --
3 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/exec_cmd.c b/tools/perf/util/exec_cmd.c
index 7adf4ad..1099e92 100644
--- a/tools/perf/util/exec_cmd.c
+++ b/tools/perf/util/exec_cmd.c
@@ -9,17 +9,17 @@
static const char *argv_exec_path;
static const char *argv0_path;
-const char *system_path(const char *path)
+char *system_path(const char *path)
{
static const char *prefix = PREFIX;
struct strbuf d = STRBUF_INIT;
if (is_absolute_path(path))
- return path;
+ return strdup(path);
strbuf_addf(, "%s/%s", prefix, path);
path = strbuf_detach(, NULL);
- return path;
+ return (char *)path;
}
const char *perf_extract_argv0_path(const char *argv0)
@@ -52,17 +52,16 @@ void perf_set_argv_exec_path(const char *exec_path)
/* Returns the highest-priority, location to look for perf programs. */
-const char *perf_exec_path(void)
+char *perf_exec_path(void)
{
- const char *env;
+ char *env;
if (argv_exec_path)
- return argv_exec_path;
+ return strdup(argv_exec_path);
env = getenv(EXEC_PATH_ENVIRONMENT);
- if (env && *env) {
- return env;
- }
+ if (env && *env)
+ return strdup(env);
return system_path(PERF_EXEC_PATH);
}
@@ -83,9 +82,11 @@ void setup_path(void)
{
const char *old_path = getenv("PATH");
struct strbuf new_path = STRBUF_INIT;
+ char *tmp = perf_exec_path();
- add_path(_path, perf_exec_path());
+ add_path(_path, tmp);
add_path(_path, argv0_path);
+ free(tmp);
if (old_path)
strbuf_addstr(_path, old_path);
diff --git a/tools/perf/util/exec_cmd.h b/tools/perf/util/exec_cmd.h
index bc4b915..48b4175 100644
--- a/tools/perf/util/exec_cmd.h
+++ b/tools/perf/util/exec_cmd.h
@@ -3,10 +3,11 @@
extern void perf_set_argv_exec_path(const char *exec_path);
extern const char *perf_extract_argv0_path(const char *path);
-extern const char *perf_exec_path(void);
extern void setup_path(void);
extern int execv_perf_cmd(const char **argv); /* NULL terminated */
extern int execl_perf_cmd(const char *cmd, ...);
-extern const char *system_path(const char *path);
+/* perf_exec_path and system_path return malloc'd string, caller must free it
*/
+extern char *perf_exec_path(void);
+extern char *system_path(const char *path);
#endif /* __PERF_EXEC_CMD_H */
diff --git a/tools/perf/util/help.c b/tools/perf/util/help.c
index 86c37c4..fa1fc4a 100644
--- a/tools/perf/util/help.c
+++ b/tools/perf/util/help.c
@@ -159,7 +159,7 @@ void load_command_list(const char *prefix,
struct cmdnames *other_cmds)
{
const char *env_path = getenv("PATH");
- const char *exec_path = perf_exec_path();
+ char *exec_path = perf_exec_path();
if (exec_path) {
list_commands_in_dir(main_cmds, exec_path, prefix);
@@ -187,6 +187,7 @@ void load_command_list(const char *prefix,
sizeof(*other_cmds->names), cmdname_compare);
uniq(other_cmds);
}
+ free(exec_path);
exclude_cmds(other_cmds, main_cmds);
}
@@ -203,13 +204,14 @@ void list_commands(const char *title, struct cmdnames
*main_cmds,
longest = other_cmds->names[i]->len;
if (main_cmds->cnt) {
- const char *exec_path = perf_exec_path();
+ char *exec_path = perf_exec_path();
printf("available %s in '%s'\n", title, exec_path);
printf("");
mput_char('-', strlen(title) + strlen(exec_path));
putchar('\n');
pretty_print_string_list(main_cmds, longest);
putchar('\n');
+ free(exec_path);
}
if (other_cmds->cnt) {
--
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] ACPI / x86: introduce acpi_os_readable() support
From: Chen Yu
This patch implements acpi_os_readable(). The function is used by ACPICA
AML debugger to validate user specified pointers for dumping the memory as
ACPICA descriptor objects.
Signed-off-by: Chen Yu
Tested-by: Lv Zheng
Signed-off-by: Lv Zheng
---
arch/x86/Kconfig |1 +
arch/x86/include/asm/acenv.h |1 +
arch/x86/kernel/acpi/boot.c | 44 +
drivers/acpi/Kconfig |3 +++
drivers/acpi/osl.c| 12 ++
include/acpi/platform/aclinux.h |1 -
include/acpi/platform/aclinuxex.h |5 -
7 files changed, 61 insertions(+), 6 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 96d058a..25585ee 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -19,6 +19,7 @@ config X86
def_bool y
select ACPI_LEGACY_TABLES_LOOKUPif ACPI
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
+ select ACPI_MEMORY_ACCESS_CHECK_SUPPORT if ACPI
select ANON_INODES
select ARCH_CLOCKSOURCE_DATA
select ARCH_DISCARD_MEMBLOCK
diff --git a/arch/x86/include/asm/acenv.h b/arch/x86/include/asm/acenv.h
index 1b010a8..a2a2849 100644
--- a/arch/x86/include/asm/acenv.h
+++ b/arch/x86/include/asm/acenv.h
@@ -20,6 +20,7 @@
int __acpi_acquire_global_lock(unsigned int *lock);
int __acpi_release_global_lock(unsigned int *lock);
+bool __acpi_memory_readable(void *pointer, size_t length);
#define ACPI_ACQUIRE_GLOBAL_LOCK(facs, Acq) \
((Acq) = __acpi_acquire_global_lock(>global_lock))
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index e759076..4a5e22e 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -1699,6 +1699,50 @@ int __acpi_release_global_lock(unsigned int *lock)
return old & 0x1;
}
+bool __acpi_memory_readable(void *pointer, size_t length)
+{
+ unsigned long obj_start, obj_end;
+ unsigned long start_pfn, end_pfn;
+
+ /*
+* All direct mapped PFNs should have been recorded by the mapped
+* PFN ranges. But pfn_range_is_mapped() requires the following
+* sanity checks to be performed before invoking.
+*/
+ obj_start = ACPI_TO_INTEGER(pointer);
+ obj_end = obj_start + length;
+
+ /*
+* ACPICA core doesn't validate if the object is wrapped over, so
+* we should.
+*/
+ if (length && (obj_end - 1) < obj_start)
+ return false;
+
+ /*
+* None direct mapping ranges contain holes. For example, high
+* kernel map holes (lower than _text or higher than _brk_end).
+* Converting a virtual address that belongs to the high map hole
+* results in a valid PFN because its low map has been recorded as
+* a mapped range.
+*/
+ if (obj_start < PAGE_OFFSET ||
+ obj_start >= (unsigned long)high_memory ||
+ (length && (obj_end - 1) >= (unsigned long)high_memory))
+ return false;
+
+ /*
+* It is required to pass a range (end_pfn - start_pfn > 0) to
+* pfn_range_is_mapped().
+*/
+ start_pfn = PFN_DOWN(__pa(obj_start));
+ end_pfn = PFN_UP(__pa(obj_end));
+ if (unlikely(end_pfn == start_pfn))
+ end_pfn++;
+
+ return pfn_range_is_mapped(start_pfn, end_pfn);
+}
+
void __init arch_reserve_mem_area(acpi_physical_address addr, size_t size)
{
e820_add_region(addr, size, E820_ACPI);
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index c4d4a05..73b45f9 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -57,6 +57,9 @@ config ACPI_SYSTEM_POWER_STATES_SUPPORT
config ACPI_CCA_REQUIRED
bool
+config ACPI_MEMORY_ACCESS_CHECK_SUPPORT
+ bool
+
config ACPI_DEBUGGER
bool "In-kernel debugger"
select ACPI_DEBUG
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index ce5ac00..edec035 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1582,6 +1582,18 @@ acpi_status acpi_os_get_line(char *buffer, u32
buffer_length, u32 *bytes_read)
}
EXPORT_SYMBOL(acpi_os_get_line);
+#ifdef CONFIG_ACPI_MEMORY_ACCESS_CHECK_SUPPORT
+u8 acpi_os_readable(void *pointer, acpi_size length)
+{
+ return __acpi_memory_readable(pointer, length) ? TRUE : FALSE;
+}
+#else
+u8 acpi_os_readable(void *pointer, acpi_size length)
+{
+ return TRUE;
+}
+#endif
+
acpi_status acpi_os_wait_command_ready(void)
{
int ret;
diff --git a/include/acpi/platform/aclinux.h b/include/acpi/platform/aclinux.h
index e21857d..b3c493e 100644
--- a/include/acpi/platform/aclinux.h
+++ b/include/acpi/platform/aclinux.h
@@ -148,7 +148,6 @@
/*
* OSL interfaces used by debugger/disassembler
*/
-#define ACPI_USE_ALTERNATE_PROTOTYPE_acpi_os_readable
#define ACPI_USE_ALTERNATE_PROTOTYPE_acpi_os_writable
#define ACPI_USE_ALTERNATE_PROTOTYPE_acpi_os_initialize_command_signals
#define
[PATCH v3 5/6] tools/power/acpi: Add userspace AML interface support
This patch adds a userspace tool to access Linux kernel AML debugger interface. Tow modes are supported by this tool: 1. Interactive: Users are able to launch a debugging shell to talk with in-kernel AML debugger. Note that it's user duty to ensure kernel runtime integrity by using this debugging tool: A. Some control methods evaluated by the users may result in kernel panics if those control methods shouldn't be evaluated by the OSPMs according to the current BIOS/OS configurations. B. Currently if a single stepping evaluation couldn't run to an end, then the synchronization primitives acquired by the evaluation may block normal OSPM control method evaluations. 2. Batch: Users are able to execute debugger commands in a script. Note that in addition to the above duties, it's user duty to ensure script runtime integrity by using this debugging tool in this mode: C. Currently only those commands that are not used for single stepping are suitable to be used in this mode. D. If the execution of the command may cause a failure that could result in an endless kernel execution, the execution of the script may also get blocked. To exit the utility, currently "exit/quit" commands are recommended, but ctrl-C" can also be used. Signed-off-by: Lv Zheng --- tools/power/acpi/Makefile| 16 +- tools/power/acpi/tools/acpidbg/Makefile | 27 ++ tools/power/acpi/tools/acpidbg/acpidbg.c | 438 ++ 3 files changed, 473 insertions(+), 8 deletions(-) create mode 100644 tools/power/acpi/tools/acpidbg/Makefile create mode 100644 tools/power/acpi/tools/acpidbg/acpidbg.c diff --git a/tools/power/acpi/Makefile b/tools/power/acpi/Makefile index e882c83..a8bf908 100644 --- a/tools/power/acpi/Makefile +++ b/tools/power/acpi/Makefile @@ -10,18 +10,18 @@ include ../../scripts/Makefile.include -all: acpidump ec -clean: acpidump_clean ec_clean -install: acpidump_install ec_install -uninstall: acpidump_uninstall ec_uninstall +all: acpidbg acpidump ec +clean: acpidbg_clean acpidump_clean ec_clean +install: acpidbg_install acpidump_install ec_install +uninstall: acpidbg_uninstall acpidump_uninstall ec_uninstall -acpidump ec: FORCE +acpidbg acpidump ec: FORCE $(call descend,tools/$@,all) -acpidump_clean ec_clean: +acpidbg_clean acpidump_clean ec_clean: $(call descend,tools/$(@:_clean=),clean) -acpidump_install ec_install: +acpidbg_install acpidump_install ec_install: $(call descend,tools/$(@:_install=),install) -acpidump_uninstall ec_uninstall: +acpidbg_uninstall acpidump_uninstall ec_uninstall: $(call descend,tools/$(@:_uninstall=),uninstall) .PHONY: FORCE diff --git a/tools/power/acpi/tools/acpidbg/Makefile b/tools/power/acpi/tools/acpidbg/Makefile new file mode 100644 index 000..352df4b --- /dev/null +++ b/tools/power/acpi/tools/acpidbg/Makefile @@ -0,0 +1,27 @@ +# tools/power/acpi/tools/acpidbg/Makefile - ACPI tool Makefile +# +# Copyright (c) 2015, Intel Corporation +# Author: Lv Zheng +# +# 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. + +include ../../Makefile.config + +TOOL = acpidbg +vpath %.c \ + ../../../../../drivers/acpi/acpica\ + ../../common\ + ../../os_specific/service_layers\ + . +CFLAGS += -DACPI_APPLICATION -DACPI_SINGLE_THREAD -DACPI_DEBUGGER\ + -I.\ + -I../../../../../drivers/acpi/acpica\ + -I../../../../../include +LDFLAGS += -lpthread +TOOL_OBJS = \ + acpidbg.o + +include ../../Makefile.rules diff --git a/tools/power/acpi/tools/acpidbg/acpidbg.c b/tools/power/acpi/tools/acpidbg/acpidbg.c new file mode 100644 index 000..d070fcc --- /dev/null +++ b/tools/power/acpi/tools/acpidbg/acpidbg.c @@ -0,0 +1,438 @@ +/* + * ACPI AML interfacing userspace utility + * + * Copyright (C) 2015, Intel Corporation + * Authors: Lv Zheng + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include + +/* Headers not included by include/acpi/platform/aclinux.h */ +#include +#include +#include +#include + +#define ACPI_AML_FILE "/sys/kernel/debug/acpi/acpidbg" +#define ACPI_AML_SEC_TICK 1 +#define ACPI_AML_USEC_PEEK 200 +#define ACPI_AML_BUF_SIZE 4096 + +#define ACPI_AML_BATCH_WRITE_CMD 0x00 /* Write command to kernel */ +#define ACPI_AML_BATCH_READ_LOG0x01 /* Read log from kernel */ +#define ACPI_AML_BATCH_WRITE_LOG 0x02 /* Write log to console */ + +#define ACPI_AML_LOG_START 0x00 +#define ACPI_AML_PROMPT_START 0x01 +#define ACPI_AML_PROMPT_STOP 0x02 +#define ACPI_AML_LOG_STOP 0x03 +#define ACPI_AML_PROMPT_ROLL
[PATCH v3 6/6] ACPI / debugger: Add module support for ACPI debugger
This patch converts AML debugger into a loadable module.
Note that, it implements driver unloading at the level dependent on the
module reference count. Which means if ACPI debugger is being used by a
userspace program, "rmmod acpi_dbg" should result in failure.
Signed-off-by: Lv Zheng
---
drivers/acpi/Kconfig | 12 ++-
drivers/acpi/Makefile|2 +-
drivers/acpi/acpi_dbg.c | 80 --
drivers/acpi/bus.c |3 +-
drivers/acpi/osl.c | 207 --
include/linux/acpi.h | 71
include/linux/acpi_dbg.h | 52
7 files changed, 338 insertions(+), 89 deletions(-)
delete mode 100644 include/linux/acpi_dbg.h
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 4de3517..c4d4a05 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -60,13 +60,23 @@ config ACPI_CCA_REQUIRED
config ACPI_DEBUGGER
bool "In-kernel debugger"
select ACPI_DEBUG
- depends on DEBUG_FS
help
Enable in-kernel debugging facilities: statistics, internal
object dump, single step control method execution.
This is still under development, currently enabling this only
results in the compilation of the ACPICA debugger files.
+if ACPI_DEBUGGER
+
+config ACPI_DEBUGGER_USER
+ tristate "Userspace debugger accessiblity"
+ depends on DEBUG_FS
+ help
+ Export /sys/kernel/debug/acpi/acpidbg for userspace utilities
+ to access the debugger functionalities.
+
+endif
+
config ACPI_SLEEP
bool
depends on SUSPEND || HIBERNATION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 102b5e6..c6f236f 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -50,7 +50,6 @@ acpi-y+= sysfs.o
acpi-y += property.o
acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
-acpi-$(CONFIG_ACPI_DEBUGGER) += acpi_dbg.o
acpi-$(CONFIG_ACPI_NUMA) += numa.o
acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
acpi-y += acpi_lpat.o
@@ -80,6 +79,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
obj-$(CONFIG_ACPI_BGRT)+= bgrt.o
obj-$(CONFIG_ACPI_CPPC_LIB)+= cppc_acpi.o
+obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
# processor has its own "processor." module_param namespace
processor-y:= processor_driver.o
diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c
index abc23b2..381beb2 100644
--- a/drivers/acpi/acpi_dbg.c
+++ b/drivers/acpi/acpi_dbg.c
@@ -21,7 +21,7 @@
#include
#include
#include
-#include
+#include
#include "internal.h"
#define ACPI_AML_BUF_ALIGN (sizeof (acpi_size))
@@ -307,7 +307,7 @@ static int acpi_aml_readb_kern(void)
* the debugger output and store the output into the debugger interface
* buffer. Return the size of stored logs or errno.
*/
-ssize_t acpi_aml_write_log(const char *msg)
+static ssize_t acpi_aml_write_log(const char *msg)
{
int ret = 0;
int count = 0, size = 0;
@@ -337,7 +337,6 @@ again:
}
return size > 0 ? size : ret;
}
-EXPORT_SYMBOL(acpi_aml_write_log);
/*
* acpi_aml_read_cmd() - Capture debugger input
@@ -348,7 +347,7 @@ EXPORT_SYMBOL(acpi_aml_write_log);
* the debugger input commands and store the input commands into the
* debugger interface buffer. Return the size of stored commands or errno.
*/
-ssize_t acpi_aml_read_cmd(char *msg, size_t count)
+static ssize_t acpi_aml_read_cmd(char *msg, size_t count)
{
int ret = 0;
int size = 0;
@@ -390,7 +389,6 @@ again:
}
return size > 0 ? size : ret;
}
-EXPORT_SYMBOL(acpi_aml_read_cmd);
static int acpi_aml_thread(void *unsed)
{
@@ -427,7 +425,7 @@ static int acpi_aml_thread(void *unsed)
* This function should be used to implement acpi_os_execute() which is
* used by the ACPICA debugger to create the debugger thread.
*/
-int acpi_aml_create_thread(acpi_osd_exec_callback function, void *context)
+static int acpi_aml_create_thread(acpi_osd_exec_callback function, void
*context)
{
struct task_struct *t;
@@ -449,30 +447,27 @@ int acpi_aml_create_thread(acpi_osd_exec_callback
function, void *context)
mutex_unlock(_aml_io.lock);
return 0;
}
-EXPORT_SYMBOL(acpi_aml_create_thread);
-int acpi_aml_wait_command_ready(void)
+static int acpi_aml_wait_command_ready(bool single_step,
+ char *buffer, size_t length)
{
acpi_status status;
- if (!acpi_gbl_method_executing)
- acpi_os_printf("\n%1c ", ACPI_DEBUGGER_COMMAND_PROMPT);
- else
+ if (single_step)
acpi_os_printf("\n%1c ", ACPI_DEBUGGER_EXECUTE_PROMPT);
+ else
+ acpi_os_printf("\n%1c ",
[PATCH v3 3/6] ACPICA: Debugger: Fix runtime stub issues of ACPI_DEBUGGER_EXEC using different stub mechanism
The ACPI_DEBUGGER_EXEC is a problem now when the debugger code is compiled
but runtime disabled. They actually will get executed in this situation.
Although such executions are harmless if we can correctly make
acpi_db_single_step() a runtime stub, users may still do not want to see the
debugger print messages logged into OSPMs' kernel logs when a debugger
driver is not loaded to enable the debugger during runtime.
This patch fixes this issue by introducing new stub mechanism instead of
ACPI_DEBUGGER_EXEC. Lv Zheng.
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/acdebug.h | 34 --
drivers/acpi/acpica/acmacros.h | 11 ---
drivers/acpi/acpica/dbdisply.c | 12
drivers/acpi/acpica/dbxface.c | 30 ++
drivers/acpi/acpica/dscontrol.c | 10 ++
drivers/acpi/acpica/dsutils.c | 16
drivers/acpi/acpica/dswexec.c | 16 +++-
include/acpi/acpixf.h | 23 +++
8 files changed, 106 insertions(+), 46 deletions(-)
diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h
index 86474d8..dcaa15d 100644
--- a/drivers/acpi/acpica/acdebug.h
+++ b/drivers/acpi/acpica/acdebug.h
@@ -80,9 +80,15 @@ struct acpi_db_execute_walk {
/*
* dbxface - external debugger interfaces
*/
-acpi_status
-acpi_db_single_step(struct acpi_walk_state *walk_state,
- union acpi_parse_object *op, u32 op_type);
+ACPI_DBR_DEPENDENT_RETURN_OK(acpi_status
+acpi_db_single_step(struct acpi_walk_state
+*walk_state,
+union acpi_parse_object *op,
+u32 op_type))
+ ACPI_DBR_DEPENDENT_RETURN_VOID(void
+ acpi_db_signal_break_point(struct
+ acpi_walk_state
+ *walk_state))
/*
* dbcmds - debug commands and output routines
@@ -182,11 +188,15 @@ void acpi_db_display_method_info(union acpi_parse_object
*op);
void acpi_db_decode_and_display_object(char *target, char *output_type);
-void
-acpi_db_display_result_object(union acpi_operand_object *obj_desc,
- struct acpi_walk_state *walk_state);
+ACPI_DBR_DEPENDENT_RETURN_VOID(void
+ acpi_db_display_result_object(union
+acpi_operand_object
+*obj_desc,
+struct
+acpi_walk_state
+*walk_state))
-acpi_status acpi_db_display_all_methods(char *display_count_arg);
+ acpi_status acpi_db_display_all_methods(char *display_count_arg);
void acpi_db_display_arguments(void);
@@ -198,9 +208,13 @@ void acpi_db_display_calling_tree(void);
void acpi_db_display_object_type(char *object_arg);
-void
-acpi_db_display_argument_object(union acpi_operand_object *obj_desc,
- struct acpi_walk_state *walk_state);
+ACPI_DBR_DEPENDENT_RETURN_VOID(void
+ acpi_db_display_argument_object(union
+
acpi_operand_object
+ *obj_desc,
+ struct
+ acpi_walk_state
+ *walk_state))
/*
* dbexec - debugger control method execution
diff --git a/drivers/acpi/acpica/acmacros.h b/drivers/acpi/acpica/acmacros.h
index e85366c..bad5bca 100644
--- a/drivers/acpi/acpica/acmacros.h
+++ b/drivers/acpi/acpica/acmacros.h
@@ -401,17 +401,6 @@
#endif
/*
- * Some code only gets executed when the debugger is built in.
- * Note that this is entirely independent of whether the
- * DEBUG_PRINT stuff (set by ACPI_DEBUG_OUTPUT) is on, or not.
- */
-#ifdef ACPI_DEBUGGER
-#define ACPI_DEBUGGER_EXEC(a) a
-#else
-#define ACPI_DEBUGGER_EXEC(a)
-#endif
-
-/*
* Macros used for ACPICA utilities only
*/
diff --git a/drivers/acpi/acpica/dbdisply.c b/drivers/acpi/acpica/dbdisply.c
index 672977e..c42ce8a 100644
--- a/drivers/acpi/acpica/dbdisply.c
+++ b/drivers/acpi/acpica/dbdisply.c
@@ -679,6 +679,12 @@ acpi_db_display_result_object(union acpi_operand_object
*obj_desc,
struct acpi_walk_state *walk_state)
{
+#ifndef ACPI_APPLICATION
+ if (acpi_gbl_db_thread_id != acpi_os_get_thread_id()) {
+ return;
+ }
+#endif
+
/* Only display if single stepping */
if
[PATCH v3 2/6] ACPICA: Debugger: Convert some mechanisms to OSPM specific
The following mechanisms are OSPM specific: 1. Redirect output destination to console: no file redirection will be needed by an in-kernel debugger, there is even no file can be accessed when the debugger is running in the kernel mode. 2. Output command prompts: programs other than acpiexec can have different prompt characters and the prompt characters may be implemented as a special character sequence to form a char device IO protocol. 3. Command ready/complete handshake: OSPM debugger may wait more conditions to implement OSPM specific semantics (for example, FIFO full/empty conditions for O_NONBLOCK or IO open/close conditions). Leaving such OSPM specific stuffs in the ACPICA debugger core blocks Linux debugger IO driver implementation. Several new OSL APIs are provided by this patch: 1. acpi_os_initialize_command_signals: initialize command handshake mechanism or any other OSPM specific stuffs. 2. acpi_os_terminate_command_signals: reversal of acpi_os_initialize_command_signals. 3. acpi_os_wait_command_ready: putting debugger task into wait state when a command is not ready. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wait_event() or wait_for_multiple_object() may be used to implement this API. 4. acpi_os_notify_command_complete: putting user task into running state when a command has been completed. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wake_up() or set_event() may be used to implement this API. This patch also converts current command signaling implementation into a generic debugger layer (osgendbg.c) to be used by the existing OSPMs or acpiexec, in return, Linux can have chance to implement its own command handshake mechanism. This patch also implements acpiexec batch mode in a multi-threading mode comaptible style as a demo (this can be confirmed by configuring acpiexec into DEBUGGER_MULTI_THREADED mode where the batch mode is still working). Lv Zheng. Note that the OSPM specific command handshake mechanism is required by Linux kernel because: 1. Linux kernel trends to use wait queue to synchronize two threads, using mutexes to achieve that will cause false "dead lock" warnings. 2. The command handshake mechanism implemented by ACPICA is implemented in this way because of a design issue in debugger IO streaming. Debugger IO outputs are simply cached using a giant buffer, this should be tuned by Linux in the future. Signed-off-by: Lv Zheng --- drivers/acpi/acpica/acdebug.h |2 +- drivers/acpi/acpica/acglobal.h|5 -- drivers/acpi/acpica/dbinput.c | 97 - drivers/acpi/acpica/dbxface.c | 63 +++- drivers/acpi/acpica/utmutex.c | 17 --- include/acpi/acpiosxf.h | 18 ++- include/acpi/acpixf.h | 11 + include/acpi/platform/aclinux.h |4 ++ include/acpi/platform/aclinuxex.h | 19 9 files changed, 89 insertions(+), 147 deletions(-) diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h index c928ba4..86474d8 100644 --- a/drivers/acpi/acpica/acdebug.h +++ b/drivers/acpi/acpica/acdebug.h @@ -257,7 +257,7 @@ acpi_db_command_dispatch(char *input_buffer, void ACPI_SYSTEM_XFACE acpi_db_execute_thread(void *context); -acpi_status acpi_db_user_commands(char prompt, union acpi_parse_object *op); +acpi_status acpi_db_user_commands(void); char *acpi_db_get_next_token(char *string, char **next, acpi_object_type * return_type); diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index faa9760..3977134 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -326,7 +326,6 @@ ACPI_GLOBAL(struct acpi_external_file *, acpi_gbl_external_file_list); #ifdef ACPI_DEBUGGER ACPI_INIT_GLOBAL(u8, acpi_gbl_abort_method, FALSE); -ACPI_INIT_GLOBAL(u8, acpi_gbl_method_executing, FALSE); ACPI_INIT_GLOBAL(acpi_thread_id, acpi_gbl_db_thread_id, ACPI_INVALID_THREAD_ID); ACPI_GLOBAL(u8, acpi_gbl_db_opt_no_ini_methods); @@ -345,7 +344,6 @@ ACPI_GLOBAL(acpi_object_type, acpi_gbl_db_arg_types[ACPI_DEBUGGER_MAX_ARGS]); /* These buffers should all be the same size */ -ACPI_GLOBAL(char, acpi_gbl_db_line_buf[ACPI_DB_LINE_BUFFER_SIZE]); ACPI_GLOBAL(char, acpi_gbl_db_parsed_buf[ACPI_DB_LINE_BUFFER_SIZE]); ACPI_GLOBAL(char, acpi_gbl_db_scope_buf[ACPI_DB_LINE_BUFFER_SIZE]); ACPI_GLOBAL(char, acpi_gbl_db_debug_filename[ACPI_DB_LINE_BUFFER_SIZE]); @@ -360,9 +358,6 @@ ACPI_GLOBAL(u16, acpi_gbl_node_type_count_misc); ACPI_GLOBAL(u32, acpi_gbl_num_nodes); ACPI_GLOBAL(u32, acpi_gbl_num_objects); -ACPI_GLOBAL(acpi_mutex, acpi_gbl_db_command_ready); -ACPI_GLOBAL(acpi_mutex, acpi_gbl_db_command_complete); - #endif /* ACPI_DEBUGGER */
[PATCH v3 4/6] ACPI / debugger: Add IO interface to access debugger functionalities
This patch adds /sys/kernel/debug/acpi/acpidbg, which can be used by
userspace programs to access ACPICA debugger functionalities.
Known issue:
1. IO flush support
acpi_os_notify_command_complete() and acpi_os_wait_command_ready() can
be used by acpi_dbg module to implement .flush() filesystem operation.
While this patch doesn't go that far. It then becomes userspace tool's
duty now to flush old commands before executing new batch mode commands.
Signed-off-by: Lv Zheng
---
drivers/acpi/Kconfig |3 +-
drivers/acpi/Makefile |1 +
drivers/acpi/acpi_dbg.c | 779 +
drivers/acpi/bus.c|2 +
drivers/acpi/osl.c| 55 ++-
include/acpi/platform/aclinux.h |2 -
include/acpi/platform/aclinuxex.h | 10 -
include/linux/acpi_dbg.h | 52 +++
8 files changed, 887 insertions(+), 17 deletions(-)
create mode 100644 drivers/acpi/acpi_dbg.c
create mode 100644 include/linux/acpi_dbg.h
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 25dbb76..4de3517 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -58,8 +58,9 @@ config ACPI_CCA_REQUIRED
bool
config ACPI_DEBUGGER
- bool "In-kernel debugger (EXPERIMENTAL)"
+ bool "In-kernel debugger"
select ACPI_DEBUG
+ depends on DEBUG_FS
help
Enable in-kernel debugging facilities: statistics, internal
object dump, single step control method execution.
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 675eaf3..102b5e6 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -50,6 +50,7 @@ acpi-y+= sysfs.o
acpi-y += property.o
acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
+acpi-$(CONFIG_ACPI_DEBUGGER) += acpi_dbg.o
acpi-$(CONFIG_ACPI_NUMA) += numa.o
acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
acpi-y += acpi_lpat.o
diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c
new file mode 100644
index 000..abc23b2
--- /dev/null
+++ b/drivers/acpi/acpi_dbg.c
@@ -0,0 +1,779 @@
+/*
+ * ACPI AML interfacing support
+ *
+ * Copyright (C) 2015, Intel Corporation
+ * Authors: Lv Zheng
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* #define DEBUG */
+#define pr_fmt(fmt) "ACPI : AML: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "internal.h"
+
+#define ACPI_AML_BUF_ALIGN (sizeof (acpi_size))
+#define ACPI_AML_BUF_SIZE PAGE_SIZE
+
+#define circ_count(circ) \
+ (CIRC_CNT((circ)->head, (circ)->tail, ACPI_AML_BUF_SIZE))
+#define circ_count_to_end(circ) \
+ (CIRC_CNT_TO_END((circ)->head, (circ)->tail, ACPI_AML_BUF_SIZE))
+#define circ_space(circ) \
+ (CIRC_SPACE((circ)->head, (circ)->tail, ACPI_AML_BUF_SIZE))
+#define circ_space_to_end(circ) \
+ (CIRC_SPACE_TO_END((circ)->head, (circ)->tail, ACPI_AML_BUF_SIZE))
+
+#define ACPI_AML_OPENED0x0001
+#define ACPI_AML_CLOSED0x0002
+#define ACPI_AML_IN_USER 0x0004 /* user space is writing cmd */
+#define ACPI_AML_IN_KERN 0x0008 /* kernel space is reading cmd */
+#define ACPI_AML_OUT_USER 0x0010 /* user space is reading log */
+#define ACPI_AML_OUT_KERN 0x0020 /* kernel space is writing log */
+#define ACPI_AML_USER (ACPI_AML_IN_USER | ACPI_AML_OUT_USER)
+#define ACPI_AML_KERN (ACPI_AML_IN_KERN | ACPI_AML_OUT_KERN)
+#define ACPI_AML_BUSY (ACPI_AML_USER | ACPI_AML_KERN)
+#define ACPI_AML_OPEN (ACPI_AML_OPENED | ACPI_AML_CLOSED)
+
+struct acpi_aml_io {
+ wait_queue_head_t wait;
+ unsigned long flags;
+ unsigned long users;
+ struct mutex lock;
+ struct task_struct *thread;
+ char out_buf[ACPI_AML_BUF_SIZE] __aligned(ACPI_AML_BUF_ALIGN);
+ struct circ_buf out_crc;
+ char in_buf[ACPI_AML_BUF_SIZE] __aligned(ACPI_AML_BUF_ALIGN);
+ struct circ_buf in_crc;
+ acpi_osd_exec_callback function;
+ void *context;
+ unsigned long usages;
+};
+
+static struct acpi_aml_io acpi_aml_io;
+static bool acpi_aml_initialized;
+static struct file *acpi_aml_active_reader;
+static struct dentry *acpi_aml_dentry;
+
+static inline bool __acpi_aml_running(void)
+{
+ return acpi_aml_io.thread ? true : false;
+}
+
+static inline bool __acpi_aml_access_ok(unsigned long flag)
+{
+ /*
+* The debugger interface is in opened state (OPENED && !CLOSED),
+* then it is allowed to access the debugger buffers from either
+* user space or the kernel space.
+* In addition, for the kernel space, only the debugger thread
+
[PATCH v3 0/6] ACPICA / debugger: Add in-kernel AML debugger support
This patchset enables ACPICA debugger for Linux kernel and implements a userspace utility to access it. A. Build the AML debugger In order to build the kernel support of AML debugger, the following kconfig items should be enabled: CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUGGER=y CONFIG_DEBUG_FS=y CONFIG_ACPI_DEBUGGER_USER=m The userspace tool can be found at tools/power/acpi/tools/acpidbg. To build this utility, staying in tools folder and type "make acpi". B. Load the AML debugger during runtime In order to use the in-kernel AML debugger, the following command should be executed using root user: # modprobe acpi_dbg # mount -t debugfs none /sys/kernel/debug # acpidbg C. Batch mode In order to support scripts, the userspace utility also supports single command batch mode: # acpidbg -b "help" # acpidbg -b "tables" # acpidbg -b "find _LID" # acpidbg -b "execute \_SB.LID0._LID" You can find the documentation about the ACPICA debugger commands in: https://acpica.org/sites/acpica/files/acpica-reference_17.pdf (The latest document can be found at https://acpica.org/documentation) And refer to the chapter - ACPICA debugger reference to obtain the full description of the debugger commands. Note that not all commands are supported by an in-kernel AML debugger. D. Unload the AML debugger during runtime After terminating all acpidbg instances, the following command can be executed to remove the AML debugger from kernel: # rmmod acpi_dbg The following tasks are not completed: 1. .flush() support in the kernel debugger IO driver. 2. multi-commands batch mode. v2: 1. Fix a help message issue for the userspace acpidbg utility (this is a typo fix). 2. Fix a batch mode issue by adding "\n" to the prompt sequence (this was lost due to too many rebase cycles). 3. Fix kconfig dependency for an intermediate patch (this is only useful in case the latter patches are reverted). 4. Add more accurate runtime debugger stub mechanism and remove old ACPI_DEBUGGER_EXEC() stub mechanism. 5. Add x86 acpi_os_readable() support. v3: 1. Remove acpi_os_readable() support from this patchset. It's sent separately. 2. Delete some deprecated comments. Colin Ian King (1): ACPICA: Debugger: Remove unnecessary status check Lv Zheng (5): ACPICA: Debugger: Convert some mechanisms to OSPM specific ACPICA: Debugger: Fix runtime stub issues of ACPI_DEBUGGER_EXEC using different stub mechanism ACPI / debugger: Add IO interface to access debugger functionalities tools/power/acpi: Add userspace AML interface support ACPI / debugger: Add module support for ACPI debugger drivers/acpi/Kconfig | 13 +- drivers/acpi/Makefile|1 + drivers/acpi/acpi_dbg.c | 805 ++ drivers/acpi/acpica/acdebug.h| 36 +- drivers/acpi/acpica/acglobal.h |5 - drivers/acpi/acpica/acmacros.h | 11 - drivers/acpi/acpica/dbdisply.c | 12 + drivers/acpi/acpica/dbinput.c| 100 +--- drivers/acpi/acpica/dbxface.c| 93 ++-- drivers/acpi/acpica/dscontrol.c | 10 +- drivers/acpi/acpica/dsutils.c| 16 +- drivers/acpi/acpica/dswexec.c| 16 +- drivers/acpi/acpica/utmutex.c| 17 - drivers/acpi/bus.c |1 + drivers/acpi/osl.c | 250 +- include/acpi/acpiosxf.h | 18 +- include/acpi/acpixf.h| 34 ++ include/acpi/platform/aclinux.h |2 + include/acpi/platform/aclinuxex.h|9 + include/linux/acpi.h | 71 +++ tools/power/acpi/Makefile| 16 +- tools/power/acpi/tools/acpidbg/Makefile | 27 + tools/power/acpi/tools/acpidbg/acpidbg.c | 438 23 files changed, 1792 insertions(+), 209 deletions(-) create mode 100644 drivers/acpi/acpi_dbg.c create mode 100644 tools/power/acpi/tools/acpidbg/Makefile create mode 100644 tools/power/acpi/tools/acpidbg/acpidbg.c -- 1.7.10 -- 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 1/6] ACPICA: Debugger: Remove unnecessary status check
From: Colin Ian King
ACPICA commit f9d5c6c9a25e9f5ac05458bfcd8b381e21bb2ba5
ACPICA BZ 1205. Colin Ian King.
Link: https://bugs.acpica.org/show_bug.cgi?id=1205
Link: https://github.com/acpica/acpica/commit/f9d5c6c9
Signed-off-by: Colin Ian King
Signed-off-by: Bob Moore
Signed-off-by: Lv Zheng
---
drivers/acpi/acpica/dbinput.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/acpi/acpica/dbinput.c b/drivers/acpi/acpica/dbinput.c
index 0480254..fe93f67 100644
--- a/drivers/acpi/acpica/dbinput.c
+++ b/drivers/acpi/acpica/dbinput.c
@@ -1246,9 +1246,6 @@ acpi_status acpi_db_user_commands(char prompt, union
acpi_parse_object *op)
* and wait for the command to complete.
*/
acpi_os_release_mutex(acpi_gbl_db_command_ready);
- if (ACPI_FAILURE(status)) {
- return (status);
- }
status =
acpi_os_acquire_mutex(acpi_gbl_db_command_complete,
--
1.7.10
--
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 5/5] misc: eeprom_93xx46: Add support for a GPIO 'select' line.
On 19.11.2015 05:29, Cory Tusar wrote:
> This commit adds support to the eeprom_93x46 driver allowing a GPIO line
> to function as a 'select' or 'enable' signal prior to accessing the
> EEPROM.
>
> Signed-off-by: Cory Tusar
> ---
> drivers/misc/eeprom/eeprom_93xx46.c | 26 ++
> include/linux/eeprom_93xx46.h | 1 +
> 2 files changed, 27 insertions(+)
>
> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
> b/drivers/misc/eeprom/eeprom_93xx46.c
> index 0386b03..375951f 100644
> --- a/drivers/misc/eeprom/eeprom_93xx46.c
> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
> @@ -10,11 +10,14 @@
>
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
Please double check, adding only linux/of_gpio.h header should work,
linux/gpio.h and linux/gpio/consumer.h are redundant.
> #include
> #include
> #include
> @@ -344,6 +347,20 @@ static ssize_t eeprom_93xx46_store_erase(struct device
> *dev,
> static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
>
> #ifdef CONFIG_OF
> +static void select_assert(void *context)
> +{
> + struct eeprom_93xx46_dev *edev = context;
> +
> + gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 1);
I would suggest to use gpio_set_value()
> +}
> +
> +static void select_deassert(void *context)
> +{
> + struct eeprom_93xx46_dev *edev = context;
> +
> + gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 0);
Same here.
> +}
> +
> static const struct of_device_id eeprom_93xx46_of_table[] = {
> { .compatible = "eeprom-93xx46", },
> { .compatible = "atmel,at93c46d", .data = _at93c46d_data, },
> @@ -385,6 +402,15 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
> if (of_property_read_bool(np, "read-only"))
> pd->flags |= EE_READONLY;
>
> + ret = of_get_named_gpio(np, "select-gpios", 0);
gpios or gpio? I see only one requested gpio.
> + if (ret < 0) {
> + pd->select_gpio = -1;
> + } else {
> + pd->select_gpio = ret;
> + pd->prepare = select_assert;
> + pd->finish = select_deassert;
> + }
> +
> if (of_id->data) {
> const struct eeprom_93xx46_devtype_data *data = of_id->data;
>
> diff --git a/include/linux/eeprom_93xx46.h b/include/linux/eeprom_93xx46.h
> index 92fa4c3..aa472c7 100644
> --- a/include/linux/eeprom_93xx46.h
> +++ b/include/linux/eeprom_93xx46.h
> @@ -21,4 +21,5 @@ struct eeprom_93xx46_platform_data {
>*/
> void (*prepare)(void *);
> void (*finish)(void *);
> + unsigned int select_gpio;
Same questions as in v2 4/5.
> };
>
--
With best wishes,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: qcom: pmic-gpio/mpp: of_irq_count() == npins
On Wed, Nov 18, 2015 at 11:33:17AM -0800, Stephen Boyd wrote: > The number of interrupts is always equal to the number of pins > provided by the PMIC gpio and MPP hardware blocks. Count the > number of irqs to figure out the number of pins instead of adding > more compatible strings or doing math on the reg property. This > should make the code more generic and ease the number of changes > we have to make to the driver for each new pmic revision. > > Cc: "Ivan T. Ivanov" > Cc: Bjorn Andersson > Signed-off-by: Stephen Boyd > --- This is pretty nice. Reviewed-by: Andy Gross -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/5] misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device.
On 19.11.2015 05:29, Cory Tusar wrote:
> Atmel devices in this family have some quirks not found in other similar
> chips - they do not support a sequential read of the entire EEPROM
> contents, and the control word sent at the start of each operation
> varies in bit length.
>
> This commit adds quirk support to the driver and modifies the read
> implementation to support non-sequential reads for consistency with
> other misc/eeprom drivers.
>
> Tested on a custom Freescale VF610-based platform, with an AT93C46D
> device attached via dspi2. The spi-gpio driver was used to allow the
> necessary non-byte-sized transfers.
>
> Signed-off-by: Cory Tusar
> ---
> drivers/misc/eeprom/eeprom_93xx46.c | 128
> ++--
> include/linux/eeprom_93xx46.h | 6 ++
> 2 files changed, 98 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
> b/drivers/misc/eeprom/eeprom_93xx46.c
> index 1f29d9a..0386b03 100644
> --- a/drivers/misc/eeprom/eeprom_93xx46.c
> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
> @@ -27,6 +27,15 @@
> #define ADDR_ERAL0x20
> #define ADDR_EWEN0x30
>
> +struct eeprom_93xx46_devtype_data {
> + unsigned int quirks;
> +};
> +
> +static const struct eeprom_93xx46_devtype_data atmel_at93c46d_data = {
> + .quirks = EEPROM_93XX46_QUIRK_SINGLE_WORD_READ |
> + EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH,
> +};
> +
> struct eeprom_93xx46_dev {
> struct spi_device *spi;
> struct eeprom_93xx46_platform_data *pdata;
> @@ -35,6 +44,16 @@ struct eeprom_93xx46_dev {
> int addrlen;
> };
>
> +static inline bool has_quirk_single_word_read(struct eeprom_93xx46_dev *edev)
> +{
> + return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_SINGLE_WORD_READ);
bool return type will do the work, please remove !!.
> +}
> +
> +static inline bool has_quirk_instruction_length(struct eeprom_93xx46_dev
> *edev)
> +{
> + return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH);
Same here.
> +}
> +
> static ssize_t
> eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj,
> struct bin_attribute *bin_attr,
> @@ -42,58 +61,73 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject
> *kobj,
> {
> struct eeprom_93xx46_dev *edev;
> struct device *dev;
> - struct spi_message m;
> - struct spi_transfer t[2];
> - int bits, ret;
> - u16 cmd_addr;
> + ssize_t ret = 0;
>
> dev = container_of(kobj, struct device, kobj);
> edev = dev_get_drvdata(dev);
>
> - cmd_addr = OP_READ << edev->addrlen;
> + mutex_lock(>lock);
>
> - if (edev->addrlen == 7) {
> - cmd_addr |= off & 0x7f;
> - bits = 10;
> - } else {
> - cmd_addr |= (off >> 1) & 0x3f;
> - bits = 9;
> - }
> + if (edev->pdata->prepare)
> + edev->pdata->prepare(edev);
>
> - dev_dbg(>spi->dev, "read cmd 0x%x, %d Hz\n",
> - cmd_addr, edev->spi->max_speed_hz);
> + while (count) {
> + struct spi_message m;
> + struct spi_transfer t[2] = { { 0 } };
Just { 0 };
> + u16 cmd_addr = OP_READ << edev->addrlen;
> + size_t nbytes = count;
> + int bits;
> + int err;
> +
> + if (edev->addrlen == 7) {
> + cmd_addr |= off & 0x7f;
> + bits = 10;
> + if (has_quirk_single_word_read(edev))
> + nbytes = 1;
> + } else {
> + cmd_addr |= (off >> 1) & 0x3f;
> + bits = 9;
> + if (has_quirk_single_word_read(edev))
> + nbytes = 2;
> + }
>
> - spi_message_init();
> - memset(t, 0, sizeof(t));
> + dev_dbg(>spi->dev, "read cmd 0x%x, %d Hz\n",
> + cmd_addr, edev->spi->max_speed_hz);
>
> - t[0].tx_buf = (char *)_addr;
> - t[0].len = 2;
> - t[0].bits_per_word = bits;
> - spi_message_add_tail([0], );
> + spi_message_init();
>
> - t[1].rx_buf = buf;
> - t[1].len = count;
> - t[1].bits_per_word = 8;
> - spi_message_add_tail([1], );
> + t[0].tx_buf = (char *)_addr;
> + t[0].len = 2;
> + t[0].bits_per_word = bits;
> + spi_message_add_tail([0], );
>
> - mutex_lock(>lock);
> + t[1].rx_buf = buf;
> + t[1].len = count;
> + t[1].bits_per_word = 8;
> + spi_message_add_tail([1], );
>
> - if (edev->pdata->prepare)
> - edev->pdata->prepare(edev);
> + err = spi_sync(edev->spi, );
> + /* have to wait at least Tcsl ns */
> + ndelay(250);
>
> - ret = spi_sync(edev->spi, );
> - /* have to wait at least Tcsl ns */
> - ndelay(250);
> - if (ret) {
> - dev_err(>spi->dev,
Re: [PATCH v2 3/5] misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings.
Hi Cory,
On 19.11.2015 05:29, Cory Tusar wrote:
> This commit implements bindings in the eeprom_93xx46 driver allowing
> device word size and read-only attributes to be specified via
> devicetree.
>
> Signed-off-by: Cory Tusar
> ---
> drivers/misc/eeprom/eeprom_93xx46.c | 62
> +
> 1 file changed, 62 insertions(+)
>
> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
> b/drivers/misc/eeprom/eeprom_93xx46.c
> index e1bf0a5..1f29d9a 100644
> --- a/drivers/misc/eeprom/eeprom_93xx46.c
> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
> @@ -13,6 +13,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -294,12 +296,71 @@ static ssize_t eeprom_93xx46_store_erase(struct device
> *dev,
> }
> static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id eeprom_93xx46_of_table[] = {
> + { .compatible = "eeprom-93xx46", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
> +
Please move this declaration closer to struct spi_driver
eeprom_93xx46_driver below.
Also you can avoid #ifdef here, if you write
.of_match_table = of_match_ptr(eeprom_93xx46_of_table)
Whenever possible please avoid #ifdef's in .c files.
> +static int eeprom_93xx46_probe_dt(struct spi_device *spi)
> +{
> + struct device_node *np = spi->dev.of_node;
> + struct eeprom_93xx46_platform_data *pd;
> + u32 tmp;
> + int ret;
> +
> + if (!of_match_device(eeprom_93xx46_of_table, >dev))
> + return 0;
> +
> + pd = devm_kzalloc(>dev, sizeof(*pd), GFP_KERNEL);
> + if (!pd)
> + return -ENOMEM;
> +
> + ret = of_property_read_u32(np, "data-size", );
> + if (ret < 0) {
> + dev_err(>dev, "data-size property not found\n");
> + goto error_free;
Because you use devm_* resource allocation in .probe, just return error.
Plus I would suggest to change "data-size" property to an optional one,
here I mean that if it is omitted, then by default consider pd->flags |=
EE_ADDR8.
> + }
> +
> + if (tmp == 8) {
> + pd->flags |= EE_ADDR8;
> + } else if (tmp == 16) {
> + pd->flags |= EE_ADDR16;
> + } else {
> + dev_err(>dev, "invalid data-size (%d)\n", tmp);
> + goto error_free;
Same here.
> + }
> +
> + if (of_property_read_bool(np, "read-only"))
> + pd->flags |= EE_READONLY;
> +
> + spi->dev.platform_data = pd;
> +
> + return 1;
On success please return 0.
> +error_free:
> + devm_kfree(>dev, pd);
> + return ret;
> +}
> +
> +#else
> +static inline int eeprom_93xx46_probe_dt(struct spi_device *spi)
> +{
> + return 0;
> +}
> +#endif
> +
I actually don't see a point to have #ifdef CONFIG_OF here.
Instead please add a check for !spi->dev.of_node at the beginning of
eeprom_93xx46_probe_dt() or in .probe()
> static int eeprom_93xx46_probe(struct spi_device *spi)
> {
> struct eeprom_93xx46_platform_data *pd;
> struct eeprom_93xx46_dev *edev;
> int err;
>
> + err = eeprom_93xx46_probe_dt(spi);
> + if (err < 0)
> + return err;
> +
> pd = spi->dev.platform_data;
> if (!pd) {
> dev_err(>dev, "missing platform data\n");
> @@ -370,6 +431,7 @@ static int eeprom_93xx46_remove(struct spi_device *spi)
> static struct spi_driver eeprom_93xx46_driver = {
> .driver = {
> .name = "93xx46",
> + .of_match_table = eeprom_93xx46_of_table,
> },
> .probe = eeprom_93xx46_probe,
> .remove = eeprom_93xx46_remove,
>
--
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 4.3 kallsyms_lookup_name not returning per_cpu symbol values
Take that back, I just reproduced it again. Seems to affect random
symbols not just per cpu. I'll research some more.
On 11/18/15, Jeffrey Merkey wrote:
> I tracked this down and it turns out to be a page mapping problem with
> one of the sound drivers on the system trashing memory. It's a bug,
> but a bug in a vendor supplied driver.
>
> Jeff
>
> On 11/18/15, Jeffrey Merkey wrote:
>> kallsyms_lookup_name is not returning per_cpu symbols when called.
>> The symbols show up when you run something with the kallsyms_iter
>> struct but not through the regular interface. I have looked through
>> the code and I am not able to determine with certainty if its designed
>> this way or just busted. Any help with this would be appreciated.
>>
>> The following code does display the per_cpu symbols, they just don't
>> seem to show up when called from kallsyms_lookup_name.
>>
>>
>> struct kallsym_iter mdb_iter;
>> int mdb_kallsyms(char *str, int (*print)(char *s, ...))
>> {
>> register loff_t pos = 0;
>> register struct kallsym_iter *iter = _iter;
>>
>> if (!print)
>>return 0;
>>
>> // set to beginning of the kallsyms list
>> reset_iter(iter, 0);
>> while (1)
>> {
>>// search the kallsyms list
>>if (!update_iter(iter, pos++))
>> break;
>>
>>if (!iter->name[0])
>>continue;
>>
>>// if an exclusion search was specified, skip non-matching entries
>>if (str && *str && !strstr(iter->name, str))
>> continue;
>>
>>if (iter->module_name[0])
>>{
>> if (print("%0*lx %c %s [%s]\n", (int)(2*sizeof(void*)),
>>iter->value, iter->type, iter->name,
>>iter->module_name))
>> return 1;
>>}
>>else
>>{
>> if (print("%0*lx %c %s\n", (int)(2*sizeof(void*)),
>>iter->value, iter->type, iter->name))
>> return 1;
>>}
>> }
>> return 0;
>> }
>> EXPORT_SYMBOL_GPL(mdb_kallsyms);
>>
>
--
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: Hibernate resume bug around 3,18-rc2 - Full PAT support
On 18/11/15 22:43, Vassilis Virvilis wrote: > Hi, > > I have been hit by a hibernate/resume bug. Other people may have too: > The following links are consistent with my observations > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1490494 > https://bugs.archlinux.org/task/44807 > > Some observations: > 1) The first few rapid hibernation / resume cycles do not fail. > > 2) If the computer is loaded (eclipse + chromium + firefox/iceweasel + > thunderbird/icedove + Konsole) helps to reproduce and lock up during resume > > 3) Long hibernation times (overnight) helps to reproduce and lock up > during resume > > 4) For the bad commits (where the lockup during resume takes place) - > the image loading during resume is significantly faster. It is fast and > then it locks. > > How I hit the problem and what I have done: > > I am running debian unstable > > Debian went from 3.16 to 3.19 - hence the problem raised its ugly head. > I upgraded diligently up to 4.2.6 - The problem persists Could you please try the most recent 4.3 kernel? There has been some work related to this topic after 4.2 (large page pat handling done by Toshi Kani and mtrr/pat handling by Luis Rodriguez). Another interesting information would be the exact hardware you are using. Maybe we can see some similarities between yours and the other two cases you referenced above. > I added no_console_suspend initcall_debug to the kernel command line - > see attached image of the lockup. > > I added the drm.debug=0xe but it didn't produce any interesting (ok I > know who I am to judge?) and the runs did not have it so I took it out > again. > > I reproduced with hibernating and resuming back to KDE and or back to > text console. > > I switched to the VGA console and the resume problem persists. > > I started kernel bisection from 3.16 to 3.19 following > https://wiki.debian.org/DebianKernel/GitBisect > > One month and 25 kernels later see below for the bisect log Wow! Thanks for doing this work! Juergen > > I hit some untestable kernel that weren't booting. They were hanging at > "Loading ramdisk..." before any actual kernel message. > > Looks like the first bad / untestable commit is from Juergen Gross / > Thomas Gleixner Merge branch 'x86-mm-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip [full PAT support] > > Full disclaimer: I may have fucked up the bisection. Finding bad commits > was semi easy - finding good commits needs a run time for 2-3 days. > > I would really appreciate some help and directions to nail this down. > > > Regards > > Vassilis Virvilis > > > > bill@localhost:~/Downloads/linux$ git bisect log > git bisect start > # good: [19583ca584d6f574384e17fe7613dfaeadcdc4a6] Linux 3.16 > git bisect good 19583ca584d6f574384e17fe7613dfaeadcdc4a6 > # bad: [bfa76d49576599a4b9f9b7a71f23d73d6dcff735] Linux 3.19 > git bisect bad bfa76d49576599a4b9f9b7a71f23d73d6dcff735 > # good: [754c780953397dd5ee5191b7b3ca67e09088ce7a] Merge branch > 'for-v3.18' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping > git bisect good 754c780953397dd5ee5191b7b3ca67e09088ce7a > # bad: [7ef58b32f571bffb7763c6252ad7527562081f34] Merge tag > 'devicetree-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux > git bisect bad 7ef58b32f571bffb7763c6252ad7527562081f34 > # good: [53429290a054b30e4683297409fc4627b2592315] Merge > git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc > git bisect good 53429290a054b30e4683297409fc4627b2592315 > # good: [3a647c1d7ab08145cee4b650f5e797d168846c51] Merge tag > 'drivers-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > git bisect good 3a647c1d7ab08145cee4b650f5e797d168846c51 > # bad: [1366f5d3129f2abde606214de7afc3dd61781fa3] Merge branch > 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs > git bisect bad 1366f5d3129f2abde606214de7afc3dd61781fa3 > # good: [151cd97630f87451cab412e40750d0e5f7581c98] Merge tag > 'defconfig-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc > git bisect good 151cd97630f87451cab412e40750d0e5f7581c98 > # good: [ecb50f0afd35a51ef487e8a54b976052eb03d729] Merge branch > 'irq-core-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect good ecb50f0afd35a51ef487e8a54b976052eb03d729 > # bad: [3a5dc1fafb016560315fe45bb4ef8bde259dd1bc] Merge branch > 'x86-microcode-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect bad 3a5dc1fafb016560315fe45bb4ef8bde259dd1bc > # good: [b6444bd0a18eb47343e16749ce80a6ebd521f124] Merge branch > 'x86-boot-for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect good b6444bd0a18eb47343e16749ce80a6ebd521f124 > # bad: [a023748d53c10850650fe86b1c4a7d421d576451] Merge branch > 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip > git bisect bad a023748d53c10850650fe86b1c4a7d421d576451 > # good:
[PATCH v9] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
Signed-off-by: Bharat Kumar Gogada
Signed-off-by: Ravi Kiran Gummaluri
Acked-by: Rob Herring
---
Changes for v9:
- Modified logic in nwl_irq_domain_alloc to check availabilty of contiguous
hw irq for multi MSI.
- Removed allocation of page for MSI address, using dummy address.
---
.../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 68 ++
drivers/pci/host/Kconfig | 10 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/pcie-xilinx-nwl.c | 1100
4 files changed, 1179 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..3b2a9ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,68 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+ interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location,
+ configuration sapce, and length
+- reg-names: Must include the following entries:
+ "breg": bridge registers
+ "pcireg": PCIe controller registers
+ "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+ "msi1, msi0": interrupt asserted when msi is received
+ "intx": interrupt that is asserted when an legacy interrupt is received
+ "misc": interrupt asserted when miscellaneous is received
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+ mapping of the PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+ supported by hardware)
+ Please refer to the standard PCI bus binding document for a more
+ detailed explanation
+- msi-controller: indicates that this is MSI controller node
+- msi-parent: MSI parent of the root complex itself
+- legacy-interrupt-controller: Interrupt controller device node for Legacy
interrupts
+ - interrupt-controller: identifies the node as an interrupt controller
+ - #interrupt-cells: should be set to 1
+ - #address-cells: specifies the number of cells needed to encode an
+ address. The value must be 0.
+
+
+Example:
+
+
+nwl_pcie: pcie@fd0e {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ compatible = "xlnx,nwl-pcie-2.11";
+ #interrupt-cells = <1>;
+ msi-controller;
+ device_type = "pci";
+ interrupt-parent = <>;
+ interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
+ interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0x0 0x0 0x0 0x1 _intc 0x1>,
+ <0x0 0x0 0x0 0x2 _intc 0x2>,
+ <0x0 0x0 0x0 0x3 _intc 0x3>,
+ <0x0 0x0 0x0 0x4 _intc 0x4>;
+
+ msi-parent = <_pcie>;
+ reg = <0x0 0xfd0e 0x1000>,
+ <0x0 0xfd48 0x1000>,
+ <0x0 0xe000 0x100>;
+ reg-names = "breg", "pcireg", "cfg";
+ ranges = <0x0200 0x 0xe100 0x 0xe100 0
0x0f00>;
+
+ pcie_intc: legacy-interrupt-controller {
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ };
+
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..24cbcba 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,16 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF
+config PCIE_XILINX_NWL
+ bool "NWL PCIe Core"
+ depends on ARCH_ZYNQMP
+ select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+ help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller. The controller can act as Root Port
+or End Point. The current option selection will only
+support root port enabling.
+
config PCIE_DW
bool
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6a56df7 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
Re: Linux 4.3 kallsyms_lookup_name not returning per_cpu symbol values
I tracked this down and it turns out to be a page mapping problem with
one of the sound drivers on the system trashing memory. It's a bug,
but a bug in a vendor supplied driver.
Jeff
On 11/18/15, Jeffrey Merkey wrote:
> kallsyms_lookup_name is not returning per_cpu symbols when called.
> The symbols show up when you run something with the kallsyms_iter
> struct but not through the regular interface. I have looked through
> the code and I am not able to determine with certainty if its designed
> this way or just busted. Any help with this would be appreciated.
>
> The following code does display the per_cpu symbols, they just don't
> seem to show up when called from kallsyms_lookup_name.
>
>
> struct kallsym_iter mdb_iter;
> int mdb_kallsyms(char *str, int (*print)(char *s, ...))
> {
> register loff_t pos = 0;
> register struct kallsym_iter *iter = _iter;
>
> if (!print)
>return 0;
>
> // set to beginning of the kallsyms list
> reset_iter(iter, 0);
> while (1)
> {
>// search the kallsyms list
>if (!update_iter(iter, pos++))
> break;
>
>if (!iter->name[0])
> continue;
>
>// if an exclusion search was specified, skip non-matching entries
>if (str && *str && !strstr(iter->name, str))
> continue;
>
>if (iter->module_name[0])
>{
> if (print("%0*lx %c %s [%s]\n", (int)(2*sizeof(void*)),
> iter->value, iter->type, iter->name,
> iter->module_name))
> return 1;
>}
>else
>{
> if (print("%0*lx %c %s\n", (int)(2*sizeof(void*)),
> iter->value, iter->type, iter->name))
> return 1;
>}
> }
> return 0;
> }
> EXPORT_SYMBOL_GPL(mdb_kallsyms);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 06/12] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
Hi Chris,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.4-rc1 next-20151118]
[cannot apply to rockchip/for-next]
url:
https://github.com/0day-ci/linux/commits/Chris-Zhong/Add-mipi-dsi-support-for-rk3288/20151119-114228
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: xtensa-allmodconfig (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=xtensa
All warnings (new ones prefixed by >>):
In file included from arch/xtensa/include/generated/asm/div64.h:1:0,
from include/linux/kernel.h:136,
from include/linux/clk.h:16,
from drivers/gpu/drm/bridge/dw_mipi_dsi.c:10:
drivers/gpu/drm/bridge/dw_mipi_dsi.c: In function
'dw_mipi_dsi_get_hcomponent_lbcc':
include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer
types lacks a cast
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:9: note: in expansion of macro
>> 'do_div'
frac = do_div(lbcc, dsi->mode->clock);
^
drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:2: warning: right shift count >=
width of type
frac = do_div(lbcc, dsi->mode->clock);
^
In file included from arch/xtensa/include/generated/asm/div64.h:1:0,
from include/linux/kernel.h:136,
from include/linux/clk.h:16,
from drivers/gpu/drm/bridge/dw_mipi_dsi.c:10:
include/asm-generic/div64.h:48:11: warning: passing argument 1 of
'__div64_32' from incompatible pointer type
__rem = __div64_32(&(n), __base); \
^
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:9: note: in expansion of macro
>> 'do_div'
frac = do_div(lbcc, dsi->mode->clock);
^
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument
is of type 'u32 *'
extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
^
vim +/do_div +819 drivers/gpu/drm/bridge/dw_mipi_dsi.c
803 static void dw_mipi_dsi_command_mode_config(struct dw_mipi_dsi *dsi)
804 {
805 dsi_write(dsi, DSI_TO_CNT_CFG, HSTX_TO_CNT(1000) |
LPRX_TO_CNT(1000));
806 dsi_write(dsi, DSI_BTA_TO_CNT, 0xd00);
807 dsi_write(dsi, DSI_CMD_MODE_CFG, CMD_MODE_ALL_LP);
808 dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
809 }
810
811 /* Get lane byte clock cycles. */
812 static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
813 u32 hcomponent)
814 {
815 u32 frac, lbcc;
816
817 lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
818
> 819 frac = do_div(lbcc, dsi->mode->clock);
820 if (frac)
821 lbcc++;
822
823 return lbcc;
824 }
825
826 static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)
827 {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH 1/2] usb: doc: dwc3-xilinx: Add devicetree bindings
Hi, Rob Herring writes: > On Wed, Nov 18, 2015 at 5:02 PM, Felipe Balbi wrote: >> >> Hi, >> >> Rob Herring writes: >>> On Wed, Nov 18, 2015 at 06:20:31PM +0530, Subbaraya Sundeep Bhatta wrote: This patch adds binding doc for Xilinx DWC3 glue driver. Signed-off-by: Subbaraya Sundeep Bhatta >>> >>> I really dislike how the DWC3 binding has been done. The sub-node here >>> is pointless. The only thing the outer node does is add clocks which >>> should simply be part of the DWC3 node. Presumably the IP block needs >>> some clocks... >>> >>> Anyway, it's self-contained within the DWC3, so I won't make you clean >>> up the mess. >> >> heh, it's definitely not pointless. We get a lot of free goodies by >> doing it that way. I'm just not going to repeat it once again. But in >> summary: >> >> a) we force people to write glue layers for *only* their HW specific >> details >> >> b) there's really no way to abuse dwc3 core because there's no symbol >> exported from dwc3 core to glue > > Both are doable independent of DT. > >> c) PM (both system sleep and runtime) becomes a lot simpler with core >> only caring about what PM details delivered by SNPS (e.g. Hibernation >> mode from DWC3) and glue only has to consider the SoC integration parts >> of PM (for OMAP that would be PRCM details, hwmod, etc). > > No doubt OMAP is special. not only OMAP. Every single SoC will integrate a particular IP in its own way. >> I'm definitely not going to change dwc3 because it has made my life a >> lot saner. Definitely a lot saner than MUSB. Besides, DTS is supposed to >> describe the HW and that's, really, how the HW is. > > So reading the description, the DWC3 has no clocks? of course it has, and you have registers in DWC3 to change some of the parents of the clocks it uses internally. >> There's a piece of HW which is somewhat platform agnostic and delivered >> by SNPS as a black box (SNPS customers don't touch SNPS RTL) and there's >> another piece of HW which bridges this dwc3 to the platform specific >> details and integration context of the platform (for OMAP that would the >> SYSCONFIG/SYSSTATUS registers, Clock autogating, PRCM, etc, etc etc). > > It is a black box, but with dozens of configuration options typically. all of which are detected within the driver. For those which can't be, we have bindings. >> So you _do_ in fact, have two separate pieces of HW which are SW visible >> and controllable independently. They each have their own IRQs (though in >> some SoCs they share the same line), they're own address space, yada >> yada yada. > > When that is the case, I have no problem with this split, but I don't > see any of these examples in this particular case. So how should the > binding look when there is no vendor specific glue? Are we supposed to > keep the binding structure to appease the needs of the driver? If there really is *no* vendor specific glue, nothing prevents them from patching dwc3 to understand *OPTIONAL* clocks and use dwc3 directly. As long as it doesn't break any of the platforms currently supported and doesn't look ugly, fine with me. In fact, there's one company which has been using dwc3 without a glue layer. I forgot who told me they didn't need a glue layer, but it's in the archives. -- balbi signature.asc Description: PGP signature
Re: [PATCH 2/5] arm64: cpufeature: Track unsigned fields
Hi
From my curiosity,
can you please clarify your criteria regarding which fields of a register
should be signed or unsigned?
I guessed that the fields marked with FTR_LOWER_SAFE or FTR_HIGHER_SAFE could
be unsigned,
but it seems to be not always true looking at your patch.
Anyhow, for example,
On 11/19/2015 02:08 AM, Suzuki K. Poulose wrote:
Some of the feature bits have unsigned values and need
to be treated accordingly to avoid errors. Adds the property
to the feature bits and use the appropriate field extract helpers.
Reported-by: AKASHI Takahiro
Cc: Ard Biesheuvel
Signed-off-by: Suzuki K. Poulose
---
arch/arm64/include/asm/cpufeature.h | 10 --
arch/arm64/kernel/cpufeature.c | 37 ++-
2 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 7a16102..29c3f5d 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -46,8 +46,12 @@ enum ftr_type {
#define FTR_STRICTtrue/* SANITY check strict matching required */
#define FTR_NONSTRICT false /* SANITY check ignored */
+#define FTR_SIGNED true/* Value should be treated as signed */
+#define FTR_UNSIGNED false /* Value should be treated as unsigned */
+
struct arm64_ftr_bits {
- boolstrict; /* CPU Sanity check: strict matching required
? */
+ boolsign; /* Value is signed ? */
+ boolstrict; /* CPU Sanity check: strict matching required ?
*/
enum ftr_type type;
u8 shift;
u8 width;
@@ -142,7 +146,9 @@ static inline u64 arm64_ftr_mask(struct arm64_ftr_bits
*ftrp)
static inline s64 arm64_ftr_value(struct arm64_ftr_bits *ftrp, u64 val)
{
- return cpuid_feature_extract_field_width(val, ftrp->shift, ftrp->width);
+ return ftrp->sign ?
+ cpuid_feature_extract_field_width(val, ftrp->shift,
ftrp->width) :
+ cpuid_feature_extract_unsigned_field_width(val, ftrp->shift,
ftrp->width);
}
static inline bool id_aa64mmfr0_mixed_endian_el0(u64 mmfr0)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index c8cf892..0669c63 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -44,8 +44,9 @@ unsigned int compat_elf_hwcap2 __read_mostly;
DECLARE_BITMAP(cpu_hwcaps, ARM64_NCAPS);
-#define ARM64_FTR_BITS(STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
+#define __ARM64_FTR_BITS(SIGNED, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
{ \
+ .sign = SIGNED, \
.strict = STRICT, \
.type = TYPE, \
.shift = SHIFT, \
@@ -53,6 +54,14 @@ DECLARE_BITMAP(cpu_hwcaps, ARM64_NCAPS);
.safe_val = SAFE_VAL, \
}
+/* Define a feature with signed values */
+#define ARM64_FTR_BITS(STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
+ __ARM64_FTR_BITS(FTR_SIGNED, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL)
+
+/* Define a feature with unsigned value */
+#define U_ARM64_FTR_BITS(STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL) \
+ __ARM64_FTR_BITS(FTR_UNSIGNED, STRICT, TYPE, SHIFT, WIDTH, SAFE_VAL)
+
#define ARM64_FTR_END \
{ \
.width = 0, \
@@ -99,7 +108,7 @@ static struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
* Differing PARange is fine as long as all peripherals and memory are
mapped
* within the minimum PARange of all CPUs
*/
- ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE,
ID_AA64MMFR0_PARANGE_SHIFT, 4, 0),
+ U_ARM64_FTR_BITS(FTR_NONSTRICT, FTR_LOWER_SAFE,
ID_AA64MMFR0_PARANGE_SHIFT, 4, 0),
ARM64_FTR_END,
};
BigEnd, bits[11:8], is 0b for "No mixed-endian support", and 0b0001 for
"Mixed-endian support". But can any other value be possible? If not, why signed?
If there are some hidden (or undocumented) specifications, as Ard mentioned,
that's fine.
Please ignore my comments.
Thanks,
-Takahiro AKASHI
@@ -115,18 +124,18 @@ static struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
};
static struct arm64_ftr_bits ftr_ctr[] = {
- ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 31, 1, 1),/* RAO */
+ U_ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RAO */
ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, 28, 3, 0),
- ARM64_FTR_BITS(FTR_STRICT, FTR_HIGHER_SAFE, 24, 4, 0), /* CWG */
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 20, 4, 0), /* ERG */
- ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, 16, 4, 1), /* DminLine */
+ U_ARM64_FTR_BITS(FTR_STRICT, FTR_HIGHER_SAFE, 24, 4, 0),/* CWG
*/
+
Re: [PATCH v4 3/3] ARM: dts: rockchip: Add the OTP gpio pinctrl
Hi Caesar, Am Donnerstag, 19. November 2015, 10:44:02 schrieb Caesar Wang: > 在 2015年10月25日 15:55, Heiko Stübner 写道: > > Am Freitag, 23. Oktober 2015, 08:25:08 schrieb Doug Anderson: > >> On Fri, Oct 23, 2015 at 4:25 AM, Caesar Wang wrote: > >>> Add the "init" anf "sleep" pinctrl as the OTP gpio state. > >>> We need the OTP pin is gpio state before resetting the TSADC controller, > >>> since the tshut polarity will generate a high signal. > >>> > >>> "init" pinctrl property is defined by Doug's Patch[0]. > >>> > >>> Patch[0]: > >>> https://patchwork.kernel.org/patch/7454311/ > >>> > >>> Signed-off-by: Caesar Wang > >>> Reviewed-by: Douglas Anderson > >>> --- > >>> > >>> Changes in v4: None > >>> > >>> Changes in v3: > >>>- Add the "sleep" pinctrl as the gpio state in PATCH[3/3] > >>> > >>> Changes in v2: > >>>- Add some commits for more obvious in PATCH[2/2] > >>> > >>> Changes in v1: > >>>- As the Doug comments, drop the thermal driver patchs since > >>> > >>> we can with pinctrl changing to work. > >>> > >>>- As the Doug's patch to add the 'init' property. > >>> > >>> arch/arm/boot/dts/rk3288.dtsi | 10 -- > >>> 1 file changed, 8 insertions(+), 2 deletions(-) > >> I realized that the subject of this patch should probably contain the > >> word rk3288, but I presume Heiko would rather add that himself than > >> for you to spin this again. ;) > > yep :-) ... no need to respin for such an easy change > > That's seem this patch didn't merge into your v4.5-armsoc/soc branch.:-) > > I guess this patch should merge into kernel-4.4 since the Patch[1/3] / > [2/3] have been merged into 4.4-rc1.:-P thanks for the reminder :-) It seems I didn't get a notice when the core thermal changes were merged, so this patch seems to have dropped of my radar. It is clearly a fix for a real issue, so I've added it to my fixes branch for 4.4. Heiko -- 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] drm/tegra: fix locking of SET_TILING ioctl
On Tue, Nov 17, 2015 at 7:02 PM, Daniel Vetter wrote: > On Thu, Nov 12, 2015 at 04:09:56PM +0900, Alexandre Courbot wrote: >> drm_gem_object_unreference() now expects obj->dev->struct_mutex to be >> held. Use the newly-introduced drm_gem_object_unreference_unlocked() >> which handles locking for us. > > This rule has been really old, I simply made the checking more anal in > > commit ef4c6270bf2867e2f8032e9614d1a8cfc6c71663 > Author: Daniel Vetter > Date: Thu Oct 15 09:36:25 2015 +0200 > > drm/gem: Check locking in drm_gem_object_unreference > > With the above added this is: > > Reviewed-by: Daniel Vetter http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7
On 19.11.2015 13:18, Tomasz Figa wrote: > Hi Krzysztof, > > Good idea, just a couple of nits inline. Other than that: > > Acked-by: Tomasz Figa > > 2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski : >> Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS >> so it is built also on ARMv7. This does not bring any kind of benefit. >> There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like >> multi_v7 for ARMv7). >> >> Instead build clock drivers only for respective SoC's architecture. >> >> Signed-off-by: Krzysztof Kozlowski >> --- >> drivers/clk/samsung/Kconfig | 13 + >> drivers/clk/samsung/Makefile | 4 ++-- >> 2 files changed, 15 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig >> index 84196ecdaa12..5f138fc4d84d 100644 >> --- a/drivers/clk/samsung/Kconfig >> +++ b/drivers/clk/samsung/Kconfig >> @@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG >> bool >> select COMMON_CLK >> >> +# ARMv7 SoCs: > > nit: I'm not aware of any recent upgrade of the S3C24xx line-up to > ARMv7 cores. ;) I'd suggest "32-bit ARM SoCs" or just "ARM SoCs"... okay > >> config S3C2410_COMMON_CLK >> bool >> select COMMON_CLK_SAMSUNG >> @@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK >> bool >> select COMMON_CLK_SAMSUNG >> >> +# ARMv8 SoCs: > > and then here "64-bit ARM SoCs" or "ARM64 SoCs", whichever you prefer. > I'd lean towards simple "ARM" and "ARM64". ARM64 sounds good. > >> +config EXYNOS5433_COMMON_CLK >> + bool >> + depends on ARM64 || COMPILE_TEST >> + default ARCH_EXYNOS > > nit: bool and default can be combined into def_bool ARCH_EXYNOS > Right. >> + select COMMON_CLK_SAMSUNG >> + >> +config EXYNOS7_COMMON_CLK >> + bool >> + depends on ARM64 || COMPILE_TEST >> + default ARCH_EXYNOS > > nit: See above. > > However, I don't think we can disable compilation of particular 64-bit > SoCs, so maybe there isn't much sense in splitting their clock drivers > into separate symbols? To me it does not really matter. Indeed as you said one cannot disable building of one particular Exynos SoCs. However we could still want not build some parts of such SoCs (like clock, pinctrl etc). I don't see much benefit for such case except when someone would like to drastically reduce the size of kernel image (for whatever reasons he has.). On the other hand having separate symbols causes duplication and obfuscates a little the Kconfig/Makefile. I like keeping things simple so one symbol for all ARM64 Exynos clocks sounds good. Sylwester preferred current approach. You and Pankaj seem to prefer one symbol-way. Should we make a voting? :) 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 v2] drm/tegra: fix locking of SET_TILING ioctl
Commit ef4c6270bf28 made the check of whether struct_mutex is held more verbose, and this triggers a warning when calling drm_gem_object_unreference() from tegra_gem_set_tiling() which does not acquire that lock. Use drm_gem_object_unreference_unlocked() instead to ensure locking is handled correctly. Signed-off-by: Alexandre Courbot Reviewed-by: Daniel Vetter --- v2: fix commit log according to Daniel's comments, add review tag. drivers/gpu/drm/tegra/drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c index cc48334ef164..c0ae89865958 100644 --- a/drivers/gpu/drm/tegra/drm.c +++ b/drivers/gpu/drm/tegra/drm.c @@ -683,7 +683,7 @@ static int tegra_gem_set_tiling(struct drm_device *drm, void *data, bo->tiling.mode = mode; bo->tiling.value = value; - drm_gem_object_unreference(gem); + drm_gem_object_unreference_unlocked(gem); return 0; } -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v13 4/6] fpga: add fpga bridge framework
Hi Alan, while trying to implement something that works for Zynq along these lines I stumbled upon some minor stuff. On Tue, Nov 3, 2015 at 9:11 AM, wrote: > + * Return: 0 on success, negative error code otherwise. > + */ > +int fpga_bridge_register(struct device *dev, const char *name, > +struct fpga_bridge_ops *br_ops, void *priv) const struct fpga_bridge_ops > +int fpga_bridge_register(struct device *dev, const char *name, > +struct fpga_bridge_ops *br_ops, void *priv); const struct fpga_bridge_ops Cheers, Moritz -- 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] cpufreq, intel_pstate.c, Fix rounding errors
On 18-11-15, 10:55, Prarit Bhargava wrote:
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index 2e31d09..686f024 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1233,6 +1233,8 @@ static int intel_pstate_set_policy(struct
> cpufreq_policy *policy)
> struct cpudata *cpu;
> int i;
> #endif
> + int max_policy_calc;
> +
> pr_debug("intel_pstate: %s max %u policy->max %u\n", __func__,
>policy->cpuinfo.max_freq, policy->max);
> if (!policy->cpuinfo.max_freq)
> @@ -1249,7 +1251,10 @@ static int intel_pstate_set_policy(struct
> cpufreq_policy *policy)
> limits = _limits;
> limits->min_policy_pct = (policy->min * 100) / policy->cpuinfo.max_freq;
> limits->min_policy_pct = clamp_t(int, limits->min_policy_pct, 0 , 100);
> - limits->max_policy_pct = (policy->max * 100) / policy->cpuinfo.max_freq;
> +
> + max_policy_calc = (policy->max * 1000) / policy->cpuinfo.max_freq;
> + limits->max_policy_pct = DIV_ROUND_UP(max_policy_calc, 10);
> +
Nice catch, but why can't we do this instead:
limits->max_policy_pct = DIV_ROUND_UP(policy->max * 100,
policy->cpuinfo.max_freq);
> limits->max_policy_pct = clamp_t(int, limits->max_policy_pct, 0 , 100);
>
> /* Normalize user input to [min_policy_pct, max_policy_pct] */
> @@ -1269,6 +1274,7 @@ static int intel_pstate_set_policy(struct
> cpufreq_policy *policy)
> int_tofp(100));
> limits->max_perf = div_fp(int_tofp(limits->max_perf_pct),
> int_tofp(100));
> + limits->max_perf = round_up(limits->max_perf, 8);
Perhaps you should fix this in a separate patch.
--
viresh
--
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: stats for v4.4-rc1
Hi all, As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20151103 was the first linux-next after the merge window opened.) Commits in v4.4-rc1 (relative to v4.3):11528 Commits in next-20151103: 10823 Commits with the same SHA1: 9957 Commits with the same patch_id: 404 (1) Commits with the same subject line: 51 (1) (1) not counting those in the lines above. So commits in -rc1 that were in next-20151103: 10412 90% Some breakdown of the list of extra commits (relative to next-20151103) in -rc1: Top ten first word of commit summary: 136 drm 116 btrfs 40 mips 36 cxlflash 34 kvm 28 hpsa 27 perf 27 net 24 megaraid_sas 17 vfio Top ten authors: 32 mro...@linux.vnet.ibm.com 30 a.ha...@samsung.com 24 sumit.sax...@avagotech.com 24 quwen...@cn.fujitsu.com 17 sreekanth.re...@avagotech.com 17 dste...@suse.com 16 jcmvb...@gmail.com 16 chuck.le...@oracle.com 15 eduma...@google.com 15 don.br...@pmcs.com Top ten commiters: 107 martin.peter...@oracle.com 94 da...@davemloft.net 69 jbottom...@odin.com 54 c...@fb.com 48 dste...@suse.com 45 bske...@redhat.com 42 torva...@linux-foundation.org 41 r...@linux-mips.org 32 pbonz...@redhat.com 30 rost...@goodmis.org There are also 411 commits in next-20151103 that didn't make it into v4.4-rc1. Top ten first word of commit summary: 52 mm 23 orangefs 23 arm 18 page-flags 17 arm-soc 15 soc 15 ocfs2 12 thp 12 nfsd 11 media Top ten authors: 63 kirill.shute...@linux.intel.com 30 a...@linux-foundation.org 20 hub...@omnibond.com 19 minc...@kernel.org 19 jlay...@poochiereds.net 13 o...@lixom.net 11 sb...@codeaurora.org 8 ryan.d...@oracle.com 8 pankaj.du...@samsung.com 7 mathieu.poir...@linaro.org Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Top ten commiters: 199 s...@canb.auug.org.au 24 hub...@omnibond.com 20 bfie...@redhat.com 20 agr...@codeaurora.org 13 o...@lixom.net 12 a...@arndb.de 11 w...@the-dreams.de 11 mche...@osg.samsung.com 9 kg...@kernel.org 8 peter.c...@freescale.com Those commits by me are from the quilt series (mainly Andrew's mmotm tree). -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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 10/71] atari_NCR5380: Remove RESET_BOOT, CONFIG_ATARI_SCSI_TOSHIBA_DELAY and CONFIG_ATARI_SCSI_RESET_BOOT
Hi Finn, Am 19.11.2015 um 17:05 schrieb Finn Thain: > w > On Thu, 19 Nov 2015, Michael Schmitz wrote: > >> Hi Finn, >> >> Am 18.11.2015 um 21:35 schrieb Finn Thain: >> >>> The bus reset may raise an interrupt. That would be new behaviour for >>> atari_scsi only when CONFIG_ATARI_SCSI_RESET_BOOT=n. The ST DMA >>> interrupt is not assigned to atari_scsi at this stage, so >>> CONFIG_ATARI_SCSI_RESET_BOOT=y may well be problematic already. >> >> I can confirm that the bus reset at boot has never been problematic in >> the past. It's been enabled in my kernels as long as I've used the >> driver (must be getting close to 20 years now). > > That's good to know. I'm not sure why it was configurable in the first > place (long delays?). The new algorithm (the one I copied from NCR5380.c) The longer delays (and possibly a reset at boot) were only necessary for certain CD-ROM drives. I don't think I have ever seen such a device, and it's a bit unlikely any of these still survive. Reset at boot before proper driver init can probably go away now. > does not allow the user to prevent a possible scsi bus reset at driver > init time. The scsi bus reset only takes place if the driver discovers > that the bus was already wedged when it started. (It proved useful when I > was introducing faults for EH testing, BTW.) Much saner approach, I'm sure. Don't forget the driver was written before sophisticated error handling came along. Reset at boot and keep your fingers crossed was the strategy in these days. Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS
On 19.11.2015 13:23, Tomasz Figa wrote: > Hi Krzysztof, > > 2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski : >> The ARMv8 Exynos family SoCs in Linux kernel are currently: >> - Exynos5433 (controlled by ARCH_EXYNOS), >> - Exynos7 (controlled by ARCH_EXYNOS7). >> >> It duplicates Kconfig symbols unnecessarily, so consolidate them into >> one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS >> symbol. >> >> The commit should not bring any visible functional change. > > I think this basically matches the general recommendation for ARM64, > so excluding the single nitpick inline and assuming that, after this > patch, grep ARCH_EXYNOS7 gives no results: > > Reviewed-by: Tomasz Figa > >> >> Signed-off-by: Krzysztof Kozlowski >> --- >> arch/arm64/Kconfig.platforms| 11 ++- >> arch/arm64/boot/dts/exynos/Makefile | 2 +- >> arch/arm64/configs/defconfig| 2 +- >> 3 files changed, 4 insertions(+), 11 deletions(-) >> >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms >> index 4043c35962cc..afa19baca94e 100644 >> --- a/arch/arm64/Kconfig.platforms >> +++ b/arch/arm64/Kconfig.platforms >> @@ -13,21 +13,14 @@ config ARCH_BERLIN >> This enables support for Marvell Berlin SoC Family >> >> config ARCH_EXYNOS >> - bool >> - help >> - This enables support for Samsung Exynos SoC family >> - >> -config ARCH_EXYNOS7 >> - bool "ARMv8 based Samsung Exynos7" >> - select ARCH_EXYNOS >> + bool "ARMv8 based Samsung Exynos SoC family" >> select COMMON_CLK_SAMSUNG >> select HAVE_S3C2410_WATCHDOG if WATCHDOG >> select HAVE_S3C_RTC if RTC_CLASS >> select PINCTRL >> select PINCTRL_EXYNOS >> - >> help >> - This enables support for Samsung Exynos7 SoC family >> + This enables support for Samsung Exynos ARMv8 SoC family > > nit: Sounds a little bit strange. Maybe "This enables support for > ARMv8 based Samsung Exynos SoC family"? Sure, sounds better. Thanks for feedback! BR, 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 v3 2/5] dt-bindings: soc: add document for rockchip reboot notifier driver
Hi Andy,
Am Donnerstag, 19. November 2015, 09:17:37 schrieb Andy Yan:
> Hi Rob:
>
> On 2015年11月19日 06:59, Rob Herring wrote:
> > On Wed, Nov 18, 2015 at 05:53:30PM +0800, Andy Yan wrote:
> >> Add devicetree binding document for rockchip reboot nofifier driver
> > Just reading the subject this is way too specific to the Linux driver
> > needs rather than a h/w description. Please don't create fake DT nodes
> > just to bind to drivers. Whatever is is probably what should have
> > the DT node. Let the driver for it create child devices if you need
> > that.
>
> This is note a fake DT nodes, we really need it to tell the driver
> which register to use to store the reboot mode. Because rockchip
> use different register file to store the reboot mode on different
> platform, on rk3066,rk3188, rk3288,it use one of the PMU
> register, on
> the incoming RK3036, it use one of the GRF register, and it use
> one of
> the PMUGRF register for arm64 platform rk3368. On the other hand, the
> PMU/GRF/PMUGRF register file are mapped as "syscon", then referenced
> by other DT nodes by phandle. So maybe let it as a separate DT
> node here
> is better.
or alternatively we could do something similar to what the bl-switcher
cupfreq-driver does. Take a look at
drivers/cpufreq/arm_big_little.c
drivers/clk/clk-mb86s7x.c
We already have the core restart-handler code in the clock-tree, so could
maybe simply do the
platform_device_register_simple("rockchip-reboot", -1, NULL, 0);
in that common code?
Though I'm not yet sure how to get the platform-data. I guess one option would
be to do things like the 3288 suspend code does (arch/arm/mach-rockchip/pm.c
at the bottom), by having the per-soc-data in the driver and then matching
against the pmu. Because the pmu is not part of the clock controller binding
(and probably also shouldn't be).
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/5] Make cpuid <-> nodeid mapping persistent.
Hi, Sorry for the terrible delay for this patch-set. But unfortunately, they are still not fully tested for the memory-less node case. Please help to review first. Will soon do the tests. 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 v3 06/12] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
Hi Chris,
[auto build test WARNING on: drm/drm-next]
[also build test WARNING on: v4.4-rc1 next-20151118]
[cannot apply to: rockchip/for-next]
url:
https://github.com/0day-ci/linux/commits/Chris-Zhong/Add-mipi-dsi-support-for-rk3288/20151119-114228
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: sparc-allyesconfig (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=sparc
All warnings (new ones prefixed by >>):
drivers/gpu/drm/bridge/dw_mipi_dsi.c: In function
'dw_mipi_dsi_dcs_short_write':
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:525:4: warning: format '%d' expects
>> argument of type 'int', but argument 3 has type 'size_t' [-Wformat=]
msg->tx_len);
^
drivers/gpu/drm/bridge/dw_mipi_dsi.c: In function
'dw_mipi_dsi_dcs_long_write':
drivers/gpu/drm/bridge/dw_mipi_dsi.c:542:4: warning: format '%d' expects
argument of type 'int', but argument 3 has type 'size_t' [-Wformat=]
msg->tx_len);
^
vim +525 drivers/gpu/drm/bridge/dw_mipi_dsi.c
509 if (ret < 0) {
510 dev_err(dsi->dev, "failed to write command FIFO\n");
511 return ret;
512 }
513
514 return 0;
515 }
516
517 static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
518 const struct mipi_dsi_msg *msg)
519 {
520 const u16 *tx_buf = msg->tx_buf;
521 u32 val = GEN_HDATA(*tx_buf) | GEN_HTYPE(msg->type);
522
523 if (msg->tx_len > 2) {
524 dev_err(dsi->dev, "too long tx buf length %d for short
write\n",
> 525 msg->tx_len);
526 return -EINVAL;
527 }
528
529 return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
530 }
531
532 static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
533const struct mipi_dsi_msg *msg)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH v3 1/5] x86, memhp, numa: Online memory-less nodes at boot time.
For now, x86 does not support memory-less node. A node without memory
will not be onlined, and the cpus on it will be mapped to the other
online nodes with memory in init_cpu_to_node(). The reason of doing this
is to ensure each cpu has mapped to a node with memory, so that it will
be able to allocate local memory for that cpu.
But we don't have to do it in this way.
In this series of patches, we are going to construct cpu <-> node mapping
for all possible cpus at boot time, which is a 1-1 mapping. It means the
cpu will be mapped to the node it belongs to, and will never be changed.
If a node has only cpus but no memory, the cpus on it will be mapped to
a memory-less node. And the memory-less node should be onlined.
This patch allocate pgdats for all memory-less nodes and online them at
boot time. Then build zonelists for these nodes. As a result, when cpus
on these memory-less nodes try to allocate memory from local node, it
will automatically fall back to the proper zones in the zonelists.
---
arch/x86/mm/numa.c | 30 --
include/linux/mmzone.h | 1 +
mm/page_alloc.c| 2 +-
3 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c3b3f65..3537c31 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -704,22 +704,22 @@ void __init x86_numa_init(void)
numa_init(dummy_numa_init);
}
-static __init int find_near_online_node(int node)
+static void __init init_memory_less_node(int nid)
{
- int n, val;
- int min_val = INT_MAX;
- int best_node = -1;
+ unsigned long zones_size[MAX_NR_ZONES] = {0};
+ unsigned long zholes_size[MAX_NR_ZONES] = {0};
- for_each_online_node(n) {
- val = node_distance(node, n);
+ /* Allocate and initialize node data. Memory-less node is now online.*/
+ alloc_node_data(nid);
+ free_area_init_node(nid, zones_size, 0, zholes_size);
- if (val < min_val) {
- min_val = val;
- best_node = n;
- }
- }
-
- return best_node;
+ /*
+* Build zonelist so that when the cpus try to allocate memory on local
+* node, which has no memory, it will fall back to the best near node.
+* No need to rebuild zonelist for the other nodes since memory-less
+* node has no memory. And no need to lock at boot time.
+*/
+ build_zonelists(NODE_DATA(nid));
}
/*
@@ -748,8 +748,10 @@ void __init init_cpu_to_node(void)
if (node == NUMA_NO_NODE)
continue;
+
if (!node_online(node))
- node = find_near_online_node(node);
+ init_memory_less_node(node);
+
numa_set_node(cpu, node);
}
}
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e23a9e7..9c4d4d5 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -736,6 +736,7 @@ static inline bool is_dev_zone(const struct zone *zone)
extern struct mutex zonelists_mutex;
void build_all_zonelists(pg_data_t *pgdat, struct zone *zone);
+void build_zonelists(pg_data_t *pgdat);
void wakeup_kswapd(struct zone *zone, int order, enum zone_type classzone_idx);
bool zone_watermark_ok(struct zone *z, unsigned int order,
unsigned long mark, int classzone_idx, int alloc_flags);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 17a3c66..761f302 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4144,7 +4144,7 @@ static void set_zonelist_order(void)
current_zonelist_order = user_zonelist_order;
}
-static void build_zonelists(pg_data_t *pgdat)
+void build_zonelists(pg_data_t *pgdat)
{
int j, node, load;
enum zone_type i;
--
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: [PATCH 2/2] can: m_can: Add CAN clock generated by UPLLCK support
Hi Marc,
> -Original Message-
> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> Sent: 2015年11月18日 18:23
> To: Yang, Wenyou; Wolfgang Grandegger
> Cc: linux-...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Ferre, Nicolas
> Subject: Re: [PATCH 2/2] can: m_can: Add CAN clock generated by UPLLCK
> support
>
> On 11/18/2015 11:04 AM, Wenyou Yang wrote:
> > As said SAMA5D2 datasheet, it is recommended to use the CAN clock at
> > frequencies of 20, 40 or 80 MHz. To achieve these frequencies, PMC
> > GCK3 must select the UPLLCK(480 MHz) as source clock and divide by 24,
> > 12 or 6. In this patch the CAN clock at 20 MHz.
> >
> > As it is configured through DT, it doesn't affect the M_CAN without
> > configuring CAN clock and its generated clock.
> >
> > Signed-off-by: Wenyou Yang
>
> NACK
>
> Please do this setup in your SoC code, where you setup the clock
> infrastructure or
> have a look at Documentation/devicetree/bindings/clock/clock-bindings.txt
> "Assigned clock parents and rates"
Thank you for your advice. I will do this setup via DT.
>
> > ---
> >
> > drivers/net/can/m_can/m_can.c | 16 +++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/can/m_can/m_can.c
> > b/drivers/net/can/m_can/m_can.c index fd1caa0..2ca47db 100644
> > --- a/drivers/net/can/m_can/m_can.c
> > +++ b/drivers/net/can/m_can/m_can.c
> > @@ -269,6 +269,8 @@ enum m_can_mram_cfg {
> > #define TX_BUF_XTD BIT(30)
> > #define TX_BUF_RTR BIT(29)
> >
> > +#define AT91_CAN_CLK_FREQ 2000
> > +
> > /* address offset and element number for each FIFO/Buffer in the
> > Message RAM */ struct mram_cfg {
> > u16 off;
> > @@ -1188,7 +1190,7 @@ static int m_can_plat_probe(struct platform_device
> *pdev)
> > struct m_can_priv *priv;
> > struct resource *res;
> > void __iomem *addr;
> > - struct clk *hclk, *cclk;
> > + struct clk *hclk, *cclk, *upll_clk;
> > int irq, ret;
> >
> > hclk = devm_clk_get(>dev, "hclk"); @@ -1198,6 +1200,18 @@
> > static int m_can_plat_probe(struct platform_device *pdev)
> > return -ENODEV;
> > }
> >
> > + upll_clk = devm_clk_get(>dev, "upllclk");
> > + if (!IS_ERR(upll_clk)) {
> > + ret = clk_set_parent(cclk, upll_clk);
> > + if (!ret) {
> > + ret = clk_set_rate(cclk, AT91_CAN_CLK_FREQ);
> > + if (ret) {
> > + dev_err(>dev, "failed to set gck\n");
> > + return -ENODEV;
> > + }
> > + }
> > + }
> > +
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "m_can");
> > addr = devm_ioremap_resource(>dev, res);
> > irq = platform_get_irq_byname(pdev, "int0");
> >
>
> regards,
> Marc
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions| Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917- |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Best Regards,
Wenyou Yang
Re: [PATCH v3 06/12] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
Hi Chris,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.4-rc1 next-20151118]
[cannot apply to rockchip/for-next]
url:
https://github.com/0day-ci/linux/commits/Chris-Zhong/Add-mipi-dsi-support-for-rk3288/20151119-114228
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: openrisc-allmodconfig (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=openrisc
All warnings (new ones prefixed by >>):
drivers/gpu/drm/bridge/dw_mipi_dsi.c: In function
'dw_mipi_dsi_get_hcomponent_lbcc':
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:9: warning: comparison of distinct
>> pointer types lacks a cast
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:2: warning: right shift count >=
>> width of type
>> drivers/gpu/drm/bridge/dw_mipi_dsi.c:819:2: warning: passing argument 1 of
>> '__div64_32' from incompatible pointer type
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but argument
is of type 'u32 *'
vim +819 drivers/gpu/drm/bridge/dw_mipi_dsi.c
803 static void dw_mipi_dsi_command_mode_config(struct dw_mipi_dsi *dsi)
804 {
805 dsi_write(dsi, DSI_TO_CNT_CFG, HSTX_TO_CNT(1000) |
LPRX_TO_CNT(1000));
806 dsi_write(dsi, DSI_BTA_TO_CNT, 0xd00);
807 dsi_write(dsi, DSI_CMD_MODE_CFG, CMD_MODE_ALL_LP);
808 dsi_write(dsi, DSI_MODE_CFG, ENABLE_CMD_MODE);
809 }
810
811 /* Get lane byte clock cycles. */
812 static u32 dw_mipi_dsi_get_hcomponent_lbcc(struct dw_mipi_dsi *dsi,
813 u32 hcomponent)
814 {
815 u32 frac, lbcc;
816
817 lbcc = hcomponent * dsi->lane_mbps * MSEC_PER_SEC / 8;
818
> 819 frac = do_div(lbcc, dsi->mode->clock);
820 if (frac)
821 lbcc++;
822
823 return lbcc;
824 }
825
826 static void dw_mipi_dsi_line_timer_config(struct dw_mipi_dsi *dsi)
827 {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH v3 3/5] x86, acpi, cpu-hotplug: Introduce cpuid_to_apicid[] array to store persistent cpuid <-> apicid mapping.
From: Gu Zheng
This patch finishes step 2.
In this patch, we introduce a new static array named cpuid_to_apicid[],
which is large enough to store info for all possible cpus.
And then, we modify the cpuid calculation. In generic_processor_info(),
it simply finds the next unused cpuid. And it is also why the cpuid <-> nodeid
mapping changes with node hotplug.
After this patch, we find the next unused cpuid, map it to an apicid,
and store the mapping in cpuid_to_apicid[], so that cpuid <-> apicid
mapping will be persistent.
And finally we will use this array to make cpuid <-> nodeid persistent.
cpuid <-> apicid mapping is established at local apic registeration time.
But non-present or disabled cpus are ignored.
In this patch, we establish all possible cpuid <-> apicid mapping when
registering local apic.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/x86/include/asm/mpspec.h | 1 +
arch/x86/kernel/acpi/boot.c | 6 ++---
arch/x86/kernel/apic/apic.c | 61 ---
3 files changed, 61 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
index b07233b..db902d8 100644
--- a/arch/x86/include/asm/mpspec.h
+++ b/arch/x86/include/asm/mpspec.h
@@ -86,6 +86,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
#endif
int generic_processor_info(int apicid, int version);
+int __generic_processor_info(int apicid, int version, bool enabled);
#define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_LOCAL_APIC)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index e759076..0ce06ee 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -174,15 +174,13 @@ static int acpi_register_lapic(int id, u8 enabled)
return -EINVAL;
}
- if (!enabled) {
+ if (!enabled)
++disabled_cpus;
- return -EINVAL;
- }
if (boot_cpu_physical_apicid != -1U)
ver = apic_version[boot_cpu_physical_apicid];
- return generic_processor_info(id, ver);
+ return __generic_processor_info(id, ver, enabled);
}
static int __init
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 29915cf..d0a2f32 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1988,7 +1988,53 @@ void disconnect_bsp_APIC(int virt_wire_setup)
apic_write(APIC_LVT1, value);
}
-static int __generic_processor_info(int apicid, int version, bool enabled)
+/*
+ * The number of allocated logical CPU IDs. Since logical CPU IDs are allocated
+ * contiguously, it equals to current allocated max logical CPU ID plus 1.
+ * All allocated CPU ID should be in [0, nr_logical_cpuidi), so the maximum of
+ * nr_logical_cpuids is nr_cpu_ids.
+ *
+ * NOTE: Reserve 0 for BSP.
+ */
+static int nr_logical_cpuids = 1;
+
+/*
+ * Used to store mapping between logical CPU IDs and APIC IDs.
+ */
+static int cpuid_to_apicid[] = {
+ [0 ... NR_CPUS - 1] = -1,
+};
+
+/*
+ * Should use this API to allocate logical CPU IDs to keep nr_logical_cpuids
+ * and cpuid_to_apicid[] synchronized.
+ */
+static int allocate_logical_cpuid(int apicid)
+{
+ int i;
+
+ /*
+* cpuid <-> apicid mapping is persistent, so when a cpu is up,
+* check if the kernel has allocated a cpuid for it.
+*/
+ for (i = 0; i < nr_logical_cpuids; i++) {
+ if (cpuid_to_apicid[i] == apicid)
+ return i;
+ }
+
+ /* Allocate a new cpuid. */
+ if (nr_logical_cpuids >= nr_cpu_ids) {
+ WARN_ONCE(1, "Only %d processors supported."
+"Processor %d/0x%x and the rest are ignored.\n",
+nr_cpu_ids - 1, nr_logical_cpuids, apicid);
+ return -1;
+ }
+
+ cpuid_to_apicid[nr_logical_cpuids] = apicid;
+ return nr_logical_cpuids++;
+}
+
+int __generic_processor_info(int apicid, int version, bool enabled)
{
int cpu, max = nr_cpu_ids;
bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
@@ -2069,8 +2115,17 @@ static int __generic_processor_info(int apicid, int
version, bool enabled)
* for BSP.
*/
cpu = 0;
- } else
- cpu = cpumask_next_zero(-1, cpu_present_mask);
+
+ /* Logical cpuid 0 is reserved for BSP. */
+ cpuid_to_apicid[0] = apicid;
+ } else {
+ cpu = allocate_logical_cpuid(apicid);
+ if (cpu < 0) {
+ if (enabled)
+ disabled_cpus++;
+ return -EINVAL;
+ }
+ }
/*
* Validate version
--
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
[PATCH v3 5/5] x86, acpi, cpu-hotplug: Set persistent cpuid <-> nodeid mapping when booting.
From: Gu Zheng
This patch finishes step 4.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/ia64/kernel/acpi.c | 2 +-
arch/x86/kernel/acpi/boot.c | 2 +-
drivers/acpi/bus.c| 3 ++
drivers/acpi/processor_core.c | 65 +++
include/linux/acpi.h | 2 ++
5 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c
index b1698bc..7db5563 100644
--- a/arch/ia64/kernel/acpi.c
+++ b/arch/ia64/kernel/acpi.c
@@ -796,7 +796,7 @@ int acpi_isa_irq_to_gsi(unsigned isa_irq, u32 *gsi)
* ACPI based hotplug CPU support
*/
#ifdef CONFIG_ACPI_HOTPLUG_CPU
-static int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+int acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
/*
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 0ce06ee..7d45261 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -696,7 +696,7 @@ static void __init acpi_set_irq_model_ioapic(void)
#ifdef CONFIG_ACPI_HOTPLUG_CPU
#include
-static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
+void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
{
#ifdef CONFIG_ACPI_NUMA
int nid;
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index a212cef..d59e1cd 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -1094,6 +1094,9 @@ static int __init acpi_init(void)
acpi_debugfs_init();
acpi_sleep_proc_init();
acpi_wakeup_device_init();
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+ acpi_set_processor_mapping();
+#endif
return 0;
}
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 824b98b..45580ff 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -261,6 +261,71 @@ int acpi_get_cpuid(acpi_handle handle, int type, u32
acpi_id)
}
EXPORT_SYMBOL_GPL(acpi_get_cpuid);
+#ifdef CONFIG_ACPI_HOTPLUG_CPU
+static bool map_processor(acpi_handle handle, int *phys_id, int *cpuid)
+{
+ int type;
+ u32 acpi_id;
+ acpi_status status;
+ acpi_object_type acpi_type;
+ unsigned long long tmp;
+ union acpi_object object = { 0 };
+ struct acpi_buffer buffer = { sizeof(union acpi_object), };
+
+ status = acpi_get_type(handle, _type);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ switch (acpi_type) {
+ case ACPI_TYPE_PROCESSOR:
+ status = acpi_evaluate_object(handle, NULL, NULL, );
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = object.processor.proc_id;
+ break;
+ case ACPI_TYPE_DEVICE:
+ status = acpi_evaluate_integer(handle, "_UID", NULL, );
+ if (ACPI_FAILURE(status))
+ return false;
+ acpi_id = tmp;
+ break;
+ default:
+ return false;
+ }
+
+ type = (acpi_type == ACPI_TYPE_DEVICE) ? 1 : 0;
+
+ *phys_id = __acpi_get_phys_id(handle, type, acpi_id, false);
+ *cpuid = acpi_map_cpuid(*phys_id, acpi_id);
+ if (*cpuid == -1)
+ return false;
+
+ return true;
+}
+
+static acpi_status __init
+set_processor_node_mapping(acpi_handle handle, u32 lvl, void *context,
+ void **rv)
+{
+ u32 apic_id;
+ int cpu_id;
+
+ if (!map_processor(handle, _id, _id))
+ return AE_ERROR;
+
+ acpi_map_cpu2node(handle, cpu_id, apic_id);
+ return AE_OK;
+}
+
+void __init acpi_set_processor_mapping(void)
+{
+ /* Set persistent cpu <-> node mapping for all processors. */
+ acpi_walk_namespace(ACPI_TYPE_PROCESSOR, ACPI_ROOT_OBJECT,
+ ACPI_UINT32_MAX, set_processor_node_mapping,
+ NULL, NULL, NULL);
+}
+#endif
+
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
static int get_ioapic_id(struct acpi_subtable_header *entry, u32 gsi_base,
u64 *phys_addr, int *ioapic_id)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 0548339..c07f541 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -194,6 +194,8 @@ static inline bool invalid_phys_cpuid(phys_cpuid_t phys_id)
/* Arch dependent functions for cpu hotplug support */
int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, int *pcpu);
int acpi_unmap_cpu(int cpu);
+void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid);
+void __init acpi_set_processor_mapping(void);
#endif /* CONFIG_ACPI_HOTPLUG_CPU */
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
RE: [PATCH 1/2] can: m_can: Increase delay to ensure written INIT accepted
Hi Marc,
Thank you for prompt feedback.
> -Original Message-
> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> Sent: 2015年11月18日 18:26
> To: Yang, Wenyou; Wolfgang Grandegger
> Cc: linux-...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Ferre, Nicolas
> Subject: Re: [PATCH 1/2] can: m_can: Increase delay to ensure written INIT
> accepted
>
> On 11/18/2015 11:04 AM, Wenyou Yang wrote:
> > Increase the delay time until the value written to INIT can be read
> > back to ensure that the previous value written to INIT has been
> > accepted.
I tested it again with different clock frequencies, it works without this
patch. Maybe I made a mistake.
Sorry about it.
Please ignore.
> >
> > Signed-off-by: Wenyou Yang
>
> The patch looks ok, can you please add to your commit message which SoCs are
> affected by this problem.
>
> > ---
> >
> > drivers/net/can/m_can/m_can.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/can/m_can/m_can.c
> > b/drivers/net/can/m_can/m_can.c index ef65517..fd1caa0 100644
> > --- a/drivers/net/can/m_can/m_can.c
> > +++ b/drivers/net/can/m_can/m_can.c
> > @@ -320,7 +320,7 @@ static inline void m_can_config_endisable(const struct
> m_can_priv *priv,
> > bool enable)
> > {
> > u32 cccr = m_can_read(priv, M_CAN_CCCR);
> > - u32 timeout = 10;
> > + u32 timeout = 1000;
> > u32 val = 0;
> >
> > if (enable) {
> >
>
> Marc
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions| Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917- |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Best Regards,
Wenyou Yang
[PATCH v3 4/5] x86, acpi, cpu-hotplug: Enable MADT APIs to return disabled apicid.
From: Gu Zheng
This patch finishes step 3.
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
So, in order to setup persistent cpuid <-> nodeid mapping for all possible CPUs,
we should:
1. Setup cpuid <-> apicid mapping for all possible CPUs, which has been done in
step 1.
2. Setup cpuid <-> nodeid mapping for all possible CPUs. But before that, we
should
obtain all apicids from MADT.
All processors' apicids can be obtained by _MAT method or from MADT in ACPI.
The current code ignores disabled processors and returns -ENODEV.
After this patch, a new parameter will be added to MADT APIs so that caller
is able to control if disabled processors are ignored.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
drivers/acpi/acpi_processor.c | 5 +++-
drivers/acpi/processor_core.c | 57 +++
2 files changed, 40 insertions(+), 22 deletions(-)
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 6979186..d30111a 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -300,8 +300,11 @@ static int acpi_processor_get_info(struct acpi_device
*device)
* Extra Processor objects may be enumerated on MP systems with
* less than the max # of CPUs. They should be ignored _iff
* they are physically not present.
+*
+* NOTE: Even if the processor has a cpuid, it may not present because
+* cpuid <-> apicid mapping is persistent now.
*/
- if (invalid_logical_cpuid(pr->id)) {
+ if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
int ret = acpi_processor_hotadd_init(pr);
if (ret)
return ret;
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 33a38d6..824b98b 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -32,12 +32,12 @@ static struct acpi_table_madt *get_madt_table(void)
}
static int map_lapic_id(struct acpi_subtable_header *entry,
-u32 acpi_id, phys_cpuid_t *apic_id)
+u32 acpi_id, phys_cpuid_t *apic_id, bool ignore_disabled)
{
struct acpi_madt_local_apic *lapic =
container_of(entry, struct acpi_madt_local_apic, header);
- if (!(lapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (ignore_disabled && !(lapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (lapic->processor_id != acpi_id)
@@ -48,12 +48,13 @@ static int map_lapic_id(struct acpi_subtable_header *entry,
}
static int map_x2apic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
+ bool ignore_disabled)
{
struct acpi_madt_local_x2apic *apic =
container_of(entry, struct acpi_madt_local_x2apic, header);
- if (!(apic->lapic_flags & ACPI_MADT_ENABLED))
+ if (ignore_disabled && !(apic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration && (apic->uid == acpi_id)) {
@@ -65,12 +66,13 @@ static int map_x2apic_id(struct acpi_subtable_header *entry,
}
static int map_lsapic_id(struct acpi_subtable_header *entry,
- int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id)
+ int device_declaration, u32 acpi_id, phys_cpuid_t *apic_id,
+ bool ignore_disabled)
{
struct acpi_madt_local_sapic *lsapic =
container_of(entry, struct acpi_madt_local_sapic, header);
- if (!(lsapic->lapic_flags & ACPI_MADT_ENABLED))
+ if (ignore_disabled && !(lsapic->lapic_flags & ACPI_MADT_ENABLED))
return -ENODEV;
if (device_declaration) {
@@ -87,12 +89,13 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
* Retrieve the ARM CPU physical identifier (MPIDR)
*/
static int map_gicc_mpidr(struct acpi_subtable_header *entry,
- int device_declaration,
[PATCH v3 2/5] x86, acpi, cpu-hotplug: Enable acpi to register all possible cpus at boot time.
From: Gu Zheng
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
workqueue does not update wq_numa_possible_cpumask.
So here is the problem:
Assume we have the following cpuid <-> nodeid in the beginning:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 2 | 30-44, 90-104
node 3 | 45-59, 105-119
and we hot-remove node2 and node3, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
and we hot-add node4 and node5, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 4 | 30-59
node 5 | 90-119
But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the like.
When a pool workqueue is initialized, if its cpumask belongs to a node, its
pool->node will be mapped to that node. And memory used by this workqueue will
also be allocated on that node.
static struct worker_pool *get_unbound_pool(const struct workqueue_attrs
*attrs){
...
/* if cpumask is contained inside a NUMA node, we belong to that node */
if (wq_numa_enabled) {
for_each_node(node) {
if (cpumask_subset(pool->attrs->cpumask,
wq_numa_possible_cpumask[node])) {
pool->node = node;
break;
}
}
}
Since wq_numa_possible_cpumask is not updated, it could be mapped to an offline
node,
which will lead to memory allocation failure:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
It happens here:
create_worker(struct worker_pool *pool)
|--> worker = alloc_worker(pool->node);
static struct worker *alloc_worker(int node)
{
struct worker *worker;
worker = kzalloc_node(sizeof(*worker), GFP_KERNEL, node); --> Here,
useing the wrong node.
..
return worker;
}
[Solution]
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <->
apicid
mapping. So the key point is obtaining all cpus' apicid.
apicid can be obtained by _MAT (Multiple APIC Table Entry) method or found in
MADT (Multiple APIC Description Table). So we finish the job in the following
steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
This is done by introducing an extra parameter to generic_processor_info to
let the
caller control if disabled cpus are ignored.
2. Introduce a new array storing all possible cpuid <-> apicid mapping. And
also modify
the way cpuid is calculated. Establish all possible cpuid <-> apicid mapping
when
registering local apic. Store the mapping in this array.
3. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus'
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
This patch finished step 1.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
---
arch/x86/kernel/apic/apic.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 2f69e3b..29915cf 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1988,7
[PATCH v3 0/5] Make cpuid <-> nodeid mapping persistent.
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will change if node hotplug happens. But
workqueue does not update wq_numa_possible_cpumask.
So here is the problem:
Assume we have the following cpuid <-> nodeid in the beginning:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 2 | 30-44, 90-104
node 3 | 45-59, 105-119
and we hot-remove node2 and node3, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
and we hot-add node4 and node5, it becomes:
Node | CPU
node 0 | 0-14, 60-74
node 1 | 15-29, 75-89
node 4 | 30-59
node 5 | 90-119
But in wq_numa_possible_cpumask, cpu30 is still mapped to node2, and the like.
When a pool workqueue is initialized, if its cpumask belongs to a node, its
pool->node will be mapped to that node. And memory used by this workqueue will
also be allocated on that node.
static struct worker_pool *get_unbound_pool(const struct workqueue_attrs
*attrs){
...
/* if cpumask is contained inside a NUMA node, we belong to that node */
if (wq_numa_enabled) {
for_each_node(node) {
if (cpumask_subset(pool->attrs->cpumask,
wq_numa_possible_cpumask[node])) {
pool->node = node;
break;
}
}
}
Since wq_numa_possible_cpumask is not updated, it could be mapped to an offline
node,
which will lead to memory allocation failure:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
It happens here:
create_worker(struct worker_pool *pool)
|--> worker = alloc_worker(pool->node);
static struct worker *alloc_worker(int node)
{
struct worker *worker;
worker = kzalloc_node(sizeof(*worker), GFP_KERNEL, node); --> Here,
useing the wrong node.
..
return worker;
}
[Solution]
There are four mappings in the kernel:
1. nodeid (logical node id) <-> pxm
2. apicid (physical cpu id) <-> nodeid
3. cpuid (logical cpu id) <-> apicid
4. cpuid (logical cpu id) <-> nodeid
1. pxm (proximity domain) is provided by ACPI firmware in SRAT, and nodeid <->
pxm
mapping is setup at boot time. This mapping is persistent, won't change.
2. apicid <-> nodeid mapping is setup using info in 1. The mapping is setup at
boot
time and CPU hotadd time, and cleared at CPU hotremove time. This mapping is
also
persistent.
3. cpuid <-> apicid mapping is setup at boot time and CPU hotadd time. cpuid is
allocated, lower ids first, and released at CPU hotremove time, reused for
other
hotadded CPUs. So this mapping is not persistent.
4. cpuid <-> nodeid mapping is also setup at boot time and CPU hotadd time, and
cleared at CPU hotremove time. As a result of 3, this mapping is not
persistent.
To fix this problem, we establish cpuid <-> nodeid mapping for all the possible
cpus at boot time, and make it persistent. And according to init_cpu_to_node(),
cpuid <-> nodeid mapping is based on apicid <-> nodeid mapping and cpuid <->
apicid
mapping. So the key point is obtaining all cpus' apicid.
apicid can be obtained by _MAT (Multiple APIC Table Entry) method or found in
MADT (Multiple APIC Description Table). So we finish the job in the following
steps:
1. Enable apic registeration flow to handle both enabled and disabled cpus.
This is done by introducing an extra parameter to generic_processor_info to
let the
caller control if disabled cpus are ignored.
2. Introduce a new array storing all possible cpuid <-> apicid mapping. And
also modify
the way cpuid is calculated. Establish all possible cpuid <-> apicid mapping
when
registering local apic. Store the mapping in this array.
3. Enable _MAT and MADT relative apis to return non-presnet or disabled cpus'
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
For previous discussion, please refer to:
https://lkml.org/lkml/2015/2/27/145
https://lkml.org/lkml/2015/3/25/989
https://lkml.org/lkml/2015/5/14/244
https://lkml.org/lkml/2015/7/7/200
https://lkml.org/lkml/2015/9/27/209
Change log v2 -> v3:
1. Online memory-less nodes at boot time to map cpus of memory-less nodes.
2. Build zonelists for memory-less nodes so that memory allocator will fall
Re: [PATCH 2/2] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS
Hi Krzysztof, 2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski : > The ARMv8 Exynos family SoCs in Linux kernel are currently: > - Exynos5433 (controlled by ARCH_EXYNOS), > - Exynos7 (controlled by ARCH_EXYNOS7). > > It duplicates Kconfig symbols unnecessarily, so consolidate them into > one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS > symbol. > > The commit should not bring any visible functional change. I think this basically matches the general recommendation for ARM64, so excluding the single nitpick inline and assuming that, after this patch, grep ARCH_EXYNOS7 gives no results: Reviewed-by: Tomasz Figa > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm64/Kconfig.platforms| 11 ++- > arch/arm64/boot/dts/exynos/Makefile | 2 +- > arch/arm64/configs/defconfig| 2 +- > 3 files changed, 4 insertions(+), 11 deletions(-) > > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 4043c35962cc..afa19baca94e 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -13,21 +13,14 @@ config ARCH_BERLIN > This enables support for Marvell Berlin SoC Family > > config ARCH_EXYNOS > - bool > - help > - This enables support for Samsung Exynos SoC family > - > -config ARCH_EXYNOS7 > - bool "ARMv8 based Samsung Exynos7" > - select ARCH_EXYNOS > + bool "ARMv8 based Samsung Exynos SoC family" > select COMMON_CLK_SAMSUNG > select HAVE_S3C2410_WATCHDOG if WATCHDOG > select HAVE_S3C_RTC if RTC_CLASS > select PINCTRL > select PINCTRL_EXYNOS > - > help > - This enables support for Samsung Exynos7 SoC family > + This enables support for Samsung Exynos ARMv8 SoC family nit: Sounds a little bit strange. Maybe "This enables support for ARMv8 based Samsung Exynos SoC family"? Best regards, Tomasz -- 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: enhance ONFI table reliability/stable
>
> Hi Bean,
>
> I was sorting through old email and I found this.
>
> On Tue, Jul 21, 2015 at 02:42:34PM +, Bean Huo 霍斌斌 (beanhuo)
> wrote:
> > Hi,
> >
> > Recently, I faced some case about ONFI table reliability, now it used CRC.
> > If there is bit flips in ONFI parameter pages, parameter backup page will be
> taken.
> > For latest linux,default read three copys.
> >
> > chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
> > for (i = 0; i < 3; i++) {
> > for (j = 0; j < sizeof(*p); j++)
> > ((uint8_t *)p)[j] = chip->read_byte(mtd);
> > if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
> > le16_to_cpu(p->crc)) {
> > break;
> > }
> > }
> >
> > However ,with technoogy improvement,for TLC and new generatin MLC,I
> > think, three copys of
>
> Ha, "improvement" :)
>
> > Parameter tables is not powerful enough.my question is that if there
> > is a good method to protect and corrent parameter page. For example,we
> > can use linux software BCH ecc. Any suggections and input be
> > welcomed,if you having any concerns about this,don't free tell me.
>
> I recall this being brought up at my old job, and I all I can say is...
> (please pardon my censored language)
Yes , you ever told about this. I just follow.
Sorry for my rude following.
I only want to share my one suggestion about using software ECC to protect
ONFI table that read from NAND. I want to hear every MTD expert 's valuable
Feedback on this. if OK, I can do it.
> ...that is complete and utter bulls***. An ONFI standard that can't guarantee
> "reliable enough" parameter pages is no standard at all.
>
> To step back a bit: How would one expect to store and retrieve ECC parity
> data? ...on the NAND flash? But to do that, we have to know the geometry
> parameters of said NAND flash. How do we figure out the geometry? From the
> ONFI parameter pages! Nice Catch 22 you have there.
>
> Please encourage your employer never to produce "ONFI-compliant" flash that
> are this bad.
>
> Regards,
> Brian
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH] lz4: fix wrong compress buffer size for 64-bits
The current lz4 compress buffer is 16kb on 32-bits, 32kb on 64-bits system. But, lz4 needs only 16kb on both. On 64-bits, this causes wasted cpu cycles for additional memset during every compression. In case of lz4hc, the current buffer size is (256kb + 8) on 32-bits, (512kb + 16) on 64-bits. But, lz4hc needs only (256kb + 2 * pointer) on both. This patch fixes these wrong compress buffer sizes for 64-bits. Cc: Chanho Min Cc: Yann Collet Cc: Kyungsik Lee Signed-off-by: Bongkyu Kim --- include/linux/lz4.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/lz4.h b/include/linux/lz4.h index 4356686..6b784c5 100644 --- a/include/linux/lz4.h +++ b/include/linux/lz4.h @@ -9,8 +9,8 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#define LZ4_MEM_COMPRESS (4096 * sizeof(unsigned char *)) -#define LZ4HC_MEM_COMPRESS (65538 * sizeof(unsigned char *)) +#define LZ4_MEM_COMPRESS (16384) +#define LZ4HC_MEM_COMPRESS (262144 + (2 * sizeof(unsigned char *))) /* * lz4_compressbound() -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7
Hi Krzysztof, Good idea, just a couple of nits inline. Other than that: Acked-by: Tomasz Figa 2015-11-16 10:36 GMT+09:00 Krzysztof Kozlowski : > Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS > so it is built also on ARMv7. This does not bring any kind of benefit. > There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like > multi_v7 for ARMv7). > > Instead build clock drivers only for respective SoC's architecture. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/clk/samsung/Kconfig | 13 + > drivers/clk/samsung/Makefile | 4 ++-- > 2 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig > index 84196ecdaa12..5f138fc4d84d 100644 > --- a/drivers/clk/samsung/Kconfig > +++ b/drivers/clk/samsung/Kconfig > @@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG > bool > select COMMON_CLK > > +# ARMv7 SoCs: nit: I'm not aware of any recent upgrade of the S3C24xx line-up to ARMv7 cores. ;) I'd suggest "32-bit ARM SoCs" or just "ARM SoCs"... > config S3C2410_COMMON_CLK > bool > select COMMON_CLK_SAMSUNG > @@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK > bool > select COMMON_CLK_SAMSUNG > > +# ARMv8 SoCs: and then here "64-bit ARM SoCs" or "ARM64 SoCs", whichever you prefer. I'd lean towards simple "ARM" and "ARM64". > +config EXYNOS5433_COMMON_CLK > + bool > + depends on ARM64 || COMPILE_TEST > + default ARCH_EXYNOS nit: bool and default can be combined into def_bool ARCH_EXYNOS > + select COMMON_CLK_SAMSUNG > + > +config EXYNOS7_COMMON_CLK > + bool > + depends on ARM64 || COMPILE_TEST > + default ARCH_EXYNOS nit: See above. However, I don't think we can disable compilation of particular 64-bit SoCs, so maybe there isn't much sense in splitting their clock drivers into separate symbols? Best regards, Tomasz -- 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: [1/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7
Hi Krzysztof, On 11/16/2015 07:06 AM, Krzysztof Kozlowski wrote: Currently the Exynos5433 (ARMv8 SoC) clock driver depends on ARCH_EXYNOS so it is built also on ARMv7. This does not bring any kind of benefit. There won't be a single kernel image for ARMv7 and ARMv8 SoCs (like multi_v7 for ARMv7). Instead build clock drivers only for respective SoC's architecture. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Chanwoo Choi Acked-by: Sylwester Nawrocki Tested $SUBJECT patch on exynos7-espresso board, so Tested-by: Alim Akhtar --- drivers/clk/samsung/Kconfig | 13 + drivers/clk/samsung/Makefile | 4 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig index 84196ecdaa12..5f138fc4d84d 100644 --- a/drivers/clk/samsung/Kconfig +++ b/drivers/clk/samsung/Kconfig @@ -2,6 +2,7 @@ config COMMON_CLK_SAMSUNG bool select COMMON_CLK +# ARMv7 SoCs: config S3C2410_COMMON_CLK bool select COMMON_CLK_SAMSUNG @@ -24,3 +25,15 @@ config S3C2443_COMMON_CLK bool select COMMON_CLK_SAMSUNG +# ARMv8 SoCs: +config EXYNOS5433_COMMON_CLK + bool + depends on ARM64 || COMPILE_TEST + default ARCH_EXYNOS + select COMMON_CLK_SAMSUNG + +config EXYNOS7_COMMON_CLK + bool + depends on ARM64 || COMPILE_TEST + default ARCH_EXYNOS + select COMMON_CLK_SAMSUNG diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 5f6833ea355d..a31332a24ef4 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -10,11 +10,11 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5260) += clk-exynos5260.o obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o -obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos5433.o +obj-$(CONFIG_EXYNOS5433_COMMON_CLK)+= clk-exynos5433.o obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-clkout.o -obj-$(CONFIG_ARCH_EXYNOS7) += clk-exynos7.o +obj-$(CONFIG_EXYNOS7_COMMON_CLK) += clk-exynos7.o obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o -- 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: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, November 19, 2015 2:12 AM > > [cc +qemu-devel, +paolo, +gerd] > > On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote: > > Hi all, > > > > We are pleased to announce another update of Intel GVT-g for Xen. > > > > Intel GVT-g is a full GPU virtualization solution with mediated > > pass-through, starting from 4th generation Intel Core(TM) processors > > with Intel Graphics processors. A virtual GPU instance is maintained > > for each VM, with part of performance critical resources directly > > assigned. The capability of running native graphics driver inside a > > VM, without hypervisor intervention in performance critical paths, > > achieves a good balance among performance, feature, and sharing > > capability. Xen is currently supported on Intel Processor Graphics > > (a.k.a. XenGT); and the core logic can be easily ported to other > > hypervisors. > > > > > > Repositories > > > > Kernel: https://github.com/01org/igvtg-kernel (2015q3-3.18.0 branch) > > Xen: https://github.com/01org/igvtg-xen (2015q3-4.5 branch) > > Qemu: https://github.com/01org/igvtg-qemu (xengt_public2015q3 branch) > > > > > > This update consists of: > > > > - XenGT is now merged with KVMGT in unified repositories(kernel and > > qemu), but > currently > >different branches for qemu. XenGT and KVMGT share same iGVT-g core > > logic. > > Hi! > > At redhat we've been thinking about how to support vGPUs from multiple > vendors in a common way within QEMU. We want to enable code sharing > between vendors and give new vendors an easy path to add their own > support. We also have the complication that not all vGPU vendors are as > open source friendly as Intel, so being able to abstract the device > mediation and access outside of QEMU is a big advantage. > > The proposal I'd like to make is that a vGPU, whether it is from Intel > or another vendor, is predominantly a PCI(e) device. We have an > interface in QEMU already for exposing arbitrary PCI devices, vfio-pci. > Currently vfio-pci uses the VFIO API to interact with "physical" devices > and system IOMMUs. I highlight /physical/ there because some of these > physical devices are SR-IOV VFs, which is somewhat of a fuzzy concept, > somewhere between fixed hardware and a virtual device implemented in > software. That software just happens to be running on the physical > endpoint. Agree. One clarification for rest discussion, is that we're talking about GVT-g vGPU here which is a pure software GPU virtualization technique. GVT-d (note some use in the text) refers to passing through the whole GPU or a specific VF. GVT-d already falls into existing VFIO APIs nicely (though some on-going effort to remove Intel specific platform stickness from gfx driver). :-) > > vGPUs are similar, with the virtual device created at a different point, > host software. They also rely on different IOMMU constructs, making use > of the MMU capabilities of the GPU (GTTs and such), but really having > similar requirements. One important difference between system IOMMU and GPU-MMU here. System IOMMU is very much about translation from a DMA target (IOVA on native, or GPA in virtualization case) to HPA. However GPU internal MMUs is to translate from Graphics Memory Address (GMA) to DMA target (HPA if system IOMMU is disabled, or IOVA/GPA if system IOMMU is enabled). GMA is an internal addr space within GPU, not exposed to Qemu and fully managed by GVT-g device model. Since it's not a standard PCI defined resource, we don't need abstract this capability in VFIO interface. > > The proposal is therefore that GPU vendors can expose vGPUs to > userspace, and thus to QEMU, using the VFIO API. For instance, vfio > supports modular bus drivers and IOMMU drivers. An intel-vfio-gvt-d > module (or extension of i915) can register as a vfio bus driver, create > a struct device per vGPU, create an IOMMU group for that device, and > register that device with the vfio-core. Since we don't rely on the > system IOMMU for GVT-d vGPU assignment, another vGPU vendor driver (or > extension of the same module) can register a "type1" compliant IOMMU > driver into vfio-core. From the perspective of QEMU then, all of the > existing vfio-pci code is re-used, QEMU remains largely unaware of any > specifics of the vGPU being assigned, and the only necessary change so > far is how QEMU traverses sysfs to find the device and thus the IOMMU > group leading to the vfio group. GVT-g requires to pin guest memory and query GPA->HPA information, upon which shadow GTTs will be updated accordingly from (GMA->GPA) to (GMA->HPA). So yes, here a dummy or simple "type1" compliant IOMMU can be introduced just for this requirement. However there's one tricky point which I'm not sure whether overall VFIO concept will be violated. GVT-g doesn't require system IOMMU to function, however host system may enable system IOMMU just
Re: [PATCH 10/71] atari_NCR5380: Remove RESET_BOOT, CONFIG_ATARI_SCSI_TOSHIBA_DELAY and CONFIG_ATARI_SCSI_RESET_BOOT
w
On Thu, 19 Nov 2015, Michael Schmitz wrote:
> Hi Finn,
>
> Am 18.11.2015 um 21:35 schrieb Finn Thain:
>
> > The bus reset may raise an interrupt. That would be new behaviour for
> > atari_scsi only when CONFIG_ATARI_SCSI_RESET_BOOT=n. The ST DMA
> > interrupt is not assigned to atari_scsi at this stage, so
> > CONFIG_ATARI_SCSI_RESET_BOOT=y may well be problematic already.
>
> I can confirm that the bus reset at boot has never been problematic in
> the past. It's been enabled in my kernels as long as I've used the
> driver (must be getting close to 20 years now).
That's good to know. I'm not sure why it was configurable in the first
place (long delays?). The new algorithm (the one I copied from NCR5380.c)
does not allow the user to prevent a possible scsi bus reset at driver
init time. The scsi bus reset only takes place if the driver discovers
that the bus was already wedged when it started. (It proved useful when I
was introducing faults for EH testing, BTW.)
--
>
> Cheers,
>
>
> Michael
>
>
> > Regardless, do_reset() now raises and clears the interrupt within
> > local_irq_save/restore which should avoid problems.
> >
> > Signed-off-by: Finn Thain
> >
> > ---
> > drivers/scsi/Kconfig | 17 ---
> > drivers/scsi/NCR5380.c | 17 +--
> > drivers/scsi/NCR5380.h |1
> > drivers/scsi/atari_NCR5380.c | 22 +-
> > drivers/scsi/atari_scsi.c| 60 +--
> > drivers/scsi/mac_scsi.c | 65
> > ++-
> > drivers/scsi/sun3_scsi.c | 47 ---
> > 7 files changed, 51 insertions(+), 178 deletions(-)
> >
> > Index: linux/drivers/scsi/Kconfig
> > ===
> > --- linux.orig/drivers/scsi/Kconfig 2015-11-18 19:25:56.0 +1100
> > +++ linux/drivers/scsi/Kconfig 2015-11-18 19:33:15.0 +1100
> > @@ -1624,23 +1624,6 @@ config ATARI_SCSI
> > ST-DMA, replacing ACSI). It does NOT support other schemes, like
> > in the Hades (without DMA).
> >
> > -config ATARI_SCSI_TOSHIBA_DELAY
> > - bool "Long delays for Toshiba CD-ROMs"
> > - depends on ATARI_SCSI
> > - help
> > - This option increases the delay after a SCSI arbitration to
> > - accommodate some flaky Toshiba CD-ROM drives. Say Y if you intend to
> > - use a Toshiba CD-ROM drive; otherwise, the option is not needed and
> > - would impact performance a bit, so say N.
> > -
> > -config ATARI_SCSI_RESET_BOOT
> > - bool "Reset SCSI-devices at boottime"
> > - depends on ATARI_SCSI
> > - help
> > - Reset the devices on your Atari whenever it boots. This makes the
> > - boot process fractionally longer but may assist recovery from errors
> > - that leave the devices with SCSI operations partway completed.
> > -
> > config MAC_SCSI
> > tristate "Macintosh NCR5380 SCSI"
> > depends on MAC && SCSI=y
> > Index: linux/drivers/scsi/atari_NCR5380.c
> > ===
> > --- linux.orig/drivers/scsi/atari_NCR5380.c 2015-11-18 19:33:13.0
> > +1100
> > +++ linux/drivers/scsi/atari_NCR5380.c 2015-11-18 19:33:15.0
> > +1100
> > @@ -674,13 +674,14 @@ static void prepare_info(struct Scsi_Hos
> > "base 0x%lx, irq %d, "
> > "can_queue %d, cmd_per_lun %d, "
> > "sg_tablesize %d, this_id %d, "
> > -"flags { %s}, "
> > +"flags { %s%s}, "
> > "options { %s} ",
> > instance->hostt->name, instance->io_port, instance->n_io_port,
> > instance->base, instance->irq,
> > instance->can_queue, instance->cmd_per_lun,
> > instance->sg_tablesize, instance->this_id,
> > hostdata->flags & FLAG_TAGGED_QUEUING ? "TAGGED_QUEUING " : "",
> > +hostdata->flags & FLAG_TOSHIBA_DELAY ? "TOSHIBA_DELAY " : "",
> > #ifdef DIFFERENTIAL
> > "DIFFERENTIAL "
> > #endif
> > @@ -860,6 +861,7 @@ static int __init NCR5380_init(struct Sc
> >
> > static int NCR5380_maybe_reset_bus(struct Scsi_Host *instance)
> > {
> > + struct NCR5380_hostdata *hostdata = shost_priv(instance);
> > int pass;
> >
> > for (pass = 1; (NCR5380_read(STATUS_REG) & SR_BSY) && pass <= 6;
> > ++pass) {
> > @@ -878,6 +880,14 @@ static int NCR5380_maybe_reset_bus(struc
> > case 4:
> > shost_printk(KERN_ERR, instance, "bus busy, attempting
> > reset\n");
> > do_reset(instance);
> > + /* Wait after a reset; the SCSI standard calls for
> > +* 250ms, we wait 500ms to be on the safe side.
> > +* But some Toshiba CD-ROMs need ten times that.
> > +*/
> > + if (hostdata->flags & FLAG_TOSHIBA_DELAY)
> > +
Re: [2/2] arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS
Hi Krzysztof, On 11/16/2015 07:06 AM, Krzysztof Kozlowski wrote: The ARMv8 Exynos family SoCs in Linux kernel are currently: - Exynos5433 (controlled by ARCH_EXYNOS), - Exynos7 (controlled by ARCH_EXYNOS7). It duplicates Kconfig symbols unnecessarily, so consolidate them into one ARCH_EXYNOS. Future SoCs could fall also under the ARCH_EXYNOS symbol. The commit should not bring any visible functional change. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Chanwoo Choi Reviewed-by: Pankaj Dubey Tested on exynos7-espresso board, so Tested-by: Alim Akhtar --- arch/arm64/Kconfig.platforms| 11 ++- arch/arm64/boot/dts/exynos/Makefile | 2 +- arch/arm64/configs/defconfig| 2 +- 3 files changed, 4 insertions(+), 11 deletions(-) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 4043c35962cc..afa19baca94e 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -13,21 +13,14 @@ config ARCH_BERLIN This enables support for Marvell Berlin SoC Family config ARCH_EXYNOS - bool - help - This enables support for Samsung Exynos SoC family - -config ARCH_EXYNOS7 - bool "ARMv8 based Samsung Exynos7" - select ARCH_EXYNOS + bool "ARMv8 based Samsung Exynos SoC family" select COMMON_CLK_SAMSUNG select HAVE_S3C2410_WATCHDOG if WATCHDOG select HAVE_S3C_RTC if RTC_CLASS select PINCTRL select PINCTRL_EXYNOS - help - This enables support for Samsung Exynos7 SoC family + This enables support for Samsung Exynos ARMv8 SoC family config ARCH_LAYERSCAPE bool "ARMv8 based Freescale Layerscape SoC family" diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile index 20310e5b6d6f..50c9b9383cfa 100644 --- a/arch/arm64/boot/dts/exynos/Makefile +++ b/arch/arm64/boot/dts/exynos/Makefile @@ -1,4 +1,4 @@ -dtb-$(CONFIG_ARCH_EXYNOS7) += exynos7-espresso.dtb +dtb-$(CONFIG_ARCH_EXYNOS) += exynos7-espresso.dtb always:= $(dtb-y) subdir-y := $(dts-dirs) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index bdd7aa358d2a..a396fa7c69a5 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -33,7 +33,7 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_IOSCHED_DEADLINE is not set CONFIG_ARCH_BCM_IPROC=y CONFIG_ARCH_BERLIN=y -CONFIG_ARCH_EXYNOS7=y +CONFIG_ARCH_EXYNOS=y CONFIG_ARCH_LAYERSCAPE=y CONFIG_ARCH_HISI=y CONFIG_ARCH_MEDIATEK=y -- 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] KVM: x86: MMU: Add helper function to clear a bit in unsync child bitmap
On 2015/11/19 11:46, Xiao Guangrong wrote:
Actually, some people prefer to put braces when one of the
if/else-if/else cases has multiple lines. You can see
some examples in kernel/sched/core.c: see hrtick_start(),
sched_fork(), free_sched_domain().
In our case, I thought putting braces would align the else-if
and else and make the code look a bit nicer, but I know this
may be just a matter of personal feeling.
In short, unless the maintainer, Paolo for this file, has any
preference, both ways will be accepted.
The reason why i pointed this out is that it is the style documented
in Documentation/CodingStyle:
| Do not unnecessarily use braces where a single statement will do.
|
|if (condition)
|action();
|
Ah, this is a different thing. For this case, there is a consensus
and checkpatch will complain if we don't obey the rule.
What I explained was:
if (condition) {
line1;
line2; // multiple lines
} else if {
single-line-statement; -- (*1)
} else
single-line-statement; -- (*2)
For (*1) and (*2), especially for (*1), some people put braces.
Actually, Ingo Molnar hated this braces-style too much and blamed
many developers who used this style (include me, that why i was
nervous to see this style :( ).
I think he likes the coding style of kernel/sched/core.c very much,
as you know. Actually that is one reason why I took it as an example.
Let's just choose the way which Paolo prefers for this time, I don't
know which is better.
Thank you,
Takuya
--
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 v7] net: ethernet: add driver for Aurora VLSI NB8800 Ethernet controller
From: Mans Rullgard
Date: Wed, 18 Nov 2015 17:29:24 +
> +static int nb8800_poll(struct napi_struct *napi, int budget)
> +{
> + struct net_device *dev = napi->dev;
> + struct nb8800_priv *priv = netdev_priv(dev);
> + struct nb8800_rx_desc *rxd;
> + int work = 0;
> + int last = priv->rx_eoc;
> + int next;
...
> + next = (last + 1) % RX_DESC_COUNT;
You should look at what the assembler looks like for these modulo
operations.
They will be much simpler (ie. one instruction) if you use unsigned
variables to hold the queue indices.
Please fix this in the entire driver.
--
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/
[RESEND PATCH] powerpc/powernv: Drop owner assignment from platform_driver
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
arch/powerpc/platforms/powernv/opal-prd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/opal-prd.c
b/arch/powerpc/platforms/powernv/opal-prd.c
index 4ece8e40dd54..e315e704cca7 100644
--- a/arch/powerpc/platforms/powernv/opal-prd.c
+++ b/arch/powerpc/platforms/powernv/opal-prd.c
@@ -434,7 +434,6 @@ static const struct of_device_id opal_prd_match[] = {
static struct platform_driver opal_prd_driver = {
.driver = {
.name = "opal-prd",
- .owner = THIS_MODULE,
.of_match_table = opal_prd_match,
},
.probe = opal_prd_probe,
--
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/
[RESEND PATCH] vfio: Drop owner assignment from platform_driver
platform_driver does not need to set an owner because
platform_driver_register() will set it.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Baptiste Reynal
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/vfio/platform/vfio_platform.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/vfio/platform/vfio_platform.c
b/drivers/vfio/platform/vfio_platform.c
index f1625dcfbb23..b1cc3a768784 100644
--- a/drivers/vfio/platform/vfio_platform.c
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -92,7 +92,6 @@ static struct platform_driver vfio_platform_driver = {
.remove = vfio_platform_remove,
.driver = {
.name = "vfio-platform",
- .owner = THIS_MODULE,
},
};
--
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/
[RESEND PATCH] nfc: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/nfc/nxp-nci/i2c.c | 1 -
drivers/nfc/pn544/i2c.c| 1 -
drivers/nfc/st-nci/i2c.c | 1 -
drivers/nfc/st21nfca/i2c.c | 1 -
4 files changed, 4 deletions(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index df4333c7ee0f..9ddeff62bd12 100644
--- a/drivers/nfc/nxp-nci/i2c.c
+++ b/drivers/nfc/nxp-nci/i2c.c
@@ -446,7 +446,6 @@ MODULE_DEVICE_TABLE(acpi, acpi_id);
static struct i2c_driver nxp_nci_i2c_driver = {
.driver = {
.name = NXP_NCI_I2C_DRIVER_NAME,
- .owner = THIS_MODULE,
.acpi_match_table = ACPI_PTR(acpi_id),
.of_match_table = of_match_ptr(of_nxp_nci_i2c_match),
},
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index fa75c53f3fa5..a095523309cf 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -1162,7 +1162,6 @@ MODULE_DEVICE_TABLE(of, of_pn544_i2c_match);
static struct i2c_driver pn544_hci_i2c_driver = {
.driver = {
.name = PN544_HCI_I2C_DRIVER_NAME,
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(of_pn544_i2c_match),
.acpi_match_table = ACPI_PTR(pn544_hci_i2c_acpi_match),
},
diff --git a/drivers/nfc/st-nci/i2c.c b/drivers/nfc/st-nci/i2c.c
index 15e3ce2d274c..9c369ff3a52b 100644
--- a/drivers/nfc/st-nci/i2c.c
+++ b/drivers/nfc/st-nci/i2c.c
@@ -370,7 +370,6 @@ MODULE_DEVICE_TABLE(of, of_st_nci_i2c_match);
static struct i2c_driver st_nci_i2c_driver = {
.driver = {
- .owner = THIS_MODULE,
.name = ST_NCI_I2C_DRIVER_NAME,
.of_match_table = of_match_ptr(of_st_nci_i2c_match),
},
diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
index a98da33e680a..9e628de6a154 100644
--- a/drivers/nfc/st21nfca/i2c.c
+++ b/drivers/nfc/st21nfca/i2c.c
@@ -681,7 +681,6 @@ MODULE_DEVICE_TABLE(of, of_st21nfca_i2c_match);
static struct i2c_driver st21nfca_hci_i2c_driver = {
.driver = {
- .owner = THIS_MODULE,
.name = ST21NFCA_HCI_I2C_DRIVER_NAME,
.of_match_table = of_match_ptr(of_st21nfca_i2c_match),
},
--
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/
[RESEND PATCH] hid: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
Acked-by: Benjamin Tissoires
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/hid/i2c-hid/i2c-hid.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 10bd8e6e4c9c..55d8f9d25696 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -1184,7 +1184,6 @@ MODULE_DEVICE_TABLE(i2c, i2c_hid_id_table);
static struct i2c_driver i2c_hid_driver = {
.driver = {
.name = "i2c_hid",
- .owner = THIS_MODULE,
.pm = _hid_pm,
.acpi_match_table = ACPI_PTR(i2c_hid_acpi_match),
.of_match_table = of_match_ptr(i2c_hid_of_match),
--
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/
[RESEND PATCH] gpio: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/gpio/gpio-adnp.c | 1 -
drivers/gpio/gpio-max7300.c| 1 -
drivers/gpio/gpio-max732x.c| 1 -
drivers/gpio/gpio-mc9s08dz60.c | 1 -
drivers/gpio/gpio-pcf857x.c| 1 -
drivers/gpio/gpio-sx150x.c | 1 -
6 files changed, 6 deletions(-)
diff --git a/drivers/gpio/gpio-adnp.c b/drivers/gpio/gpio-adnp.c
index d3d0a90fe542..85223aac8c55 100644
--- a/drivers/gpio/gpio-adnp.c
+++ b/drivers/gpio/gpio-adnp.c
@@ -547,7 +547,6 @@ MODULE_DEVICE_TABLE(of, adnp_of_match);
static struct i2c_driver adnp_i2c_driver = {
.driver = {
.name = "gpio-adnp",
- .owner = THIS_MODULE,
.of_match_table = adnp_of_match,
},
.probe = adnp_i2c_probe,
diff --git a/drivers/gpio/gpio-max7300.c b/drivers/gpio/gpio-max7300.c
index 0cc2c279ab5c..1ae9ba851c9a 100644
--- a/drivers/gpio/gpio-max7300.c
+++ b/drivers/gpio/gpio-max7300.c
@@ -65,7 +65,6 @@ MODULE_DEVICE_TABLE(i2c, max7300_id);
static struct i2c_driver max7300_driver = {
.driver = {
.name = "max7300",
- .owner = THIS_MODULE,
},
.probe = max7300_probe,
.remove = max7300_remove,
diff --git a/drivers/gpio/gpio-max732x.c b/drivers/gpio/gpio-max732x.c
index 8c5252c6c327..2eb0f36ca89f 100644
--- a/drivers/gpio/gpio-max732x.c
+++ b/drivers/gpio/gpio-max732x.c
@@ -749,7 +749,6 @@ static int max732x_remove(struct i2c_client *client)
static struct i2c_driver max732x_driver = {
.driver = {
.name = "max732x",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(max732x_of_table),
},
.probe = max732x_probe,
diff --git a/drivers/gpio/gpio-mc9s08dz60.c b/drivers/gpio/gpio-mc9s08dz60.c
index d62b4f8182bf..0a1505df3338 100644
--- a/drivers/gpio/gpio-mc9s08dz60.c
+++ b/drivers/gpio/gpio-mc9s08dz60.c
@@ -131,7 +131,6 @@ MODULE_DEVICE_TABLE(i2c, mc9s08dz60_id);
static struct i2c_driver mc9s08dz60_i2c_driver = {
.driver = {
- .owner = THIS_MODULE,
.name = "mc9s08dz60",
},
.probe = mc9s08dz60_probe,
diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
index 1d4d9bc8b69d..eced5d0432c3 100644
--- a/drivers/gpio/gpio-pcf857x.c
+++ b/drivers/gpio/gpio-pcf857x.c
@@ -447,7 +447,6 @@ static int pcf857x_remove(struct i2c_client *client)
static struct i2c_driver pcf857x_driver = {
.driver = {
.name = "pcf857x",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(pcf857x_of_table),
},
.probe = pcf857x_probe,
diff --git a/drivers/gpio/gpio-sx150x.c b/drivers/gpio/gpio-sx150x.c
index 76f920173a2f..9f8d82cb2d31 100644
--- a/drivers/gpio/gpio-sx150x.c
+++ b/drivers/gpio/gpio-sx150x.c
@@ -680,7 +680,6 @@ static int sx150x_remove(struct i2c_client *client)
static struct i2c_driver sx150x_driver = {
.driver = {
.name = "sx150x",
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(sx150x_of_match),
},
.probe= sx150x_probe,
--
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/
[RESEND PATCH] char: ipmi: Drop owner assignment from i2c_driver
i2c_driver does not need to set an owner because i2c_register_driver()
will set it.
Signed-off-by: Krzysztof Kozlowski
---
The coccinelle script which generated the patch was sent here:
http://www.spinics.net/lists/kernel/msg2029903.html
---
drivers/char/ipmi/ipmi_ssif.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
index 90e624662257..5f1c3d08ba65 100644
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -1959,7 +1959,6 @@ MODULE_DEVICE_TABLE(i2c, ssif_id);
static struct i2c_driver ssif_i2c_driver = {
.class = I2C_CLASS_HWMON,
.driver = {
- .owner = THIS_MODULE,
.name = DEVICE_NAME
},
.probe = ssif_probe,
--
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] ARM: dts: vfxxx: Include support for dspi[23] functionality.
Extend the existing Vybrid DSPI devicetree implementation to also
describe the dspi2 and dspi3 functional blocks.
Signed-off-by: Cory Tusar
---
arch/arm/boot/dts/vfxxx.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 1cca43a..858e60a 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -453,6 +453,30 @@
status = "disabled";
};
+ dspi2: dspi2@400ac000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,vf610-dspi";
+ reg = <0x400ac000 0x1000>;
+ interrupts = <69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < VF610_CLK_DSPI2>;
+ clock-names = "dspi";
+ spi-num-chipselects = <2>;
+ status = "disabled";
+ };
+
+ dspi3: dspi3@400ad000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,vf610-dspi";
+ reg = <0x400ad000 0x1000>;
+ interrupts = <70 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = < VF610_CLK_DSPI3>;
+ clock-names = "dspi";
+ spi-num-chipselects = <2>;
+ status = "disabled";
+ };
+
adc1: adc@400bb000 {
compatible = "fsl,vf610-adc";
reg = <0x400bb000 0x1000>;
--
2.4.10
--
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] ARM: dts: vfxxx: Fix dspi[01] spi-num-chipselects.
Per the Vybrid Reference Manual (section 3.8.6.1), dspi0 has 6 chip select signals associated with it, while dspi1 has only 4. Signed-off-by: Cory Tusar --- arch/arm/boot/dts/vfxxx.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi index 6736bae..1cca43a 100644 --- a/arch/arm/boot/dts/vfxxx.dtsi +++ b/arch/arm/boot/dts/vfxxx.dtsi @@ -158,7 +158,7 @@ interrupts = <67 IRQ_TYPE_LEVEL_HIGH>; clocks = < VF610_CLK_DSPI0>; clock-names = "dspi"; - spi-num-chipselects = <5>; + spi-num-chipselects = <6>; status = "disabled"; }; @@ -170,7 +170,7 @@ interrupts = <68 IRQ_TYPE_LEVEL_HIGH>; clocks = < VF610_CLK_DSPI1>; clock-names = "dspi"; - spi-num-chipselects = <5>; + spi-num-chipselects = <4>; status = "disabled"; }; -- 2.4.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/7] pinctrl: Add new compatible string to GPIO controller driver
This compatible string should be used for all new iproc based future
SoCs having the same GPIO controller hardware.
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
index 498a58a..d0d788f 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
@@ -646,6 +646,7 @@ static const struct of_device_id cygnus_gpio_of_match[] = {
{ .compatible = "brcm,cygnus-ccm-gpio" },
{ .compatible = "brcm,cygnus-asiu-gpio" },
{ .compatible = "brcm,cygnus-crmu-gpio" },
+ { .compatible = "brcm,iproc-gpio" },
{ }
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/7] dts: define ngpios property in gpio controller's node
Add ngpios property in cygnus ASIU, CCM and CRMU gpio controller's node
Signed-off-by: Pramod Kumar
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 2778533..59c4330 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -101,6 +101,7 @@
compatible = "brcm,cygnus-crmu-gpio";
reg = <0x03024800 0x50>,
<0x03024008 0x18>;
+ ngpios = <6>;
#gpio-cells = <2>;
gpio-controller;
};
@@ -127,6 +128,7 @@
compatible = "brcm,cygnus-ccm-gpio";
reg = <0x1800a000 0x50>,
<0x0301d164 0x20>;
+ ngpios = <24>;
#gpio-cells = <2>;
gpio-controller;
interrupts = ;
@@ -245,6 +247,7 @@
gpio_asiu: gpio@180a5000 {
compatible = "brcm,cygnus-asiu-gpio";
reg = <0x180a5000 0x668>;
+ ngpios = <146>;
#gpio-cells = <2>;
gpio-controller;
--
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/
