Re: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500
On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote: > On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote: > > > > > It's not a dmaengine driver. It's a serial UART driver that happens to > > > use a dedicated DMA engine. > > > > Then I see no reason for it to use dmaengine APIs. The framework allows > > people to share a controller for many clients, but if you have dedicated > > one then you may use it directly > > Well... the engine is shared by a few UARTs, they have dedicated rings > but there's a common set of regs for interrupt handling etc. > > That said, I still think it could be contained within a UART driver, > there's little benefit in adding the framework overhead, esp since > these are really weak cores, any overhead will be felt. > > Ben. > > > > It's unclear whether it should be split into two drivers, or just have > > > the serial driver directly use the dma engine since that engine is > > > dedicated in HW to only work on those UARTs and nothing else... > > > > > > Cheers, > > > Ben. Initially we wanted to have a single driver, however we had an informal discussion with one of the maintainer and based on the feedback, followed the Linux DMA and UART architecture. If this seperate DMA-engine driver adds more overhead than benifit, we will merge them into a single UART driver and resubmitt the patches. Vinod, can this dma-controller driver sit under dma subsystem?. or better to move it under UART framework. Thank you. -- Sudheer
Re: [PATCH v3] of: overlay: user space synchronization
Hi Frank,
On Fri, Oct 19, 2018 at 2:06 AM Frank Rowand wrote:
> On 10/18/18 12:32, Rob Herring wrote:
> > On Tue, Oct 16, 2018 at 05:34:26PM -0700, frowand.l...@gmail.com wrote:
> >> Provide a sysfs file, /sys/firmware/devicetree/tree_version, to allow
> >> user space to determine if the live devicetree has remained unchanged
> >> while a series of one or more accesses of /proc/device-tree/ occur.
> >>
> >> The use of both (1) dynamic devicetree modifications and (2) overlay
> >> apply and removal are not supported during the same boot cycle. Thus
> >> non-overlay dynamic modifications are not reflected in the value of
> >> tree_version.
> >
> > I'd prefer to see some sort of information on overlays exported and user
> > space can check if that changed. IIRC, Pantelis had a series to do that
> > along with a kill switch to prevent further modifications. At least some
> > of that series only had minor issues to fix.
>
> The kill switch addresses a different concern, which was from the security
> community. The kill switch is on my todo list.
>
> I don't remember exactly what info the overlay information export patch
> provided. I'll have to go find it and re-read it.
I'm still forward porting the overlay configfs interface, cfr.
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/renesas-overlays
E.g. after loading r8a7791-koelsch-exio-b-scifa3.dtbo, it changes like:
--- tree /sys/firmware/devicetree old 2018-10-19 08:49:24.073441000 +0200
+++ tree /sys/firmware/devicetree new 2018-10-19 08:49:33.173397000 +0200
@@ -1237,6 +1237,11 @@
│ │ │ │ ├── groups
│ │ │ │ ├── name
│ │ │ │ └── phandle
+│ │ │ ├── scifa3
+│ │ │ │ ├── function
+│ │ │ │ ├── groups
+│ │ │ │ ├── name
+│ │ │ │ └── phandle
│ │ │ ├── scif_clk
│ │ │ │ ├── function
│ │ │ │ ├── groups
@@ -1510,6 +1515,8 @@
│ │ │ ├── interrupts
│ │ │ ├── name
│ │ │ ├── phandle
+│ │ │ ├── pinctrl-0
+│ │ │ ├── pinctrl-names
│ │ │ ├── power-domains
│ │ │ ├── reg
│ │ │ ├── resets
@@ -2277,6 +2284,7 @@
│ │ ├── scifa1
│ │ ├── scifa2
│ │ ├── scifa3
+│ │ ├── scifa3_pins
│ │ ├── scifa4
│ │ ├── scifa5
│ │ ├── scifb0
The above hunks are for /sys/firmware/devicetree/base/.
@@ -2778,6 +2786,14 @@
│ │ └── target
│ └── __symbols__
│ └── target
+├── 2
+│ ├── can_remove
+│ ├── fragment@0
+│ │ └── target
+│ ├── fragment@1
+│ │ └── target
+│ └── __symbols__
+│ └── target
└── enable
The above hunk is for /sys/firmware/devicetree/overlays/
# ls -l /sys/firmware/devicetree/overlays/
total 0
drwxr-xr-x 6 root root0 okt 19 08:49 1
drwxr-xr-x 5 root root0 okt 19 08:49 2
-rw-r--r-- 1 root root 4096 okt 19 08:49 enable
1 is from the DT unit tests,
2 is from r8a7791-koelsch-exio-b-scifa3.dtbo,
enable is the kill switch.
Note that after removing overlay 2, and loading a new overlay, the new one is
again called number 2. But the subdir date is newer.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [LKP] [mm/memory.c] 6558038e45: general_protection_fault:#[##]
On 10/18/2018 06:26 AM, Andrew Morton wrote:
On Wed, 17 Oct 2018 09:36:00 +0800 kernel test robot
wrote:
FYI, we noticed the following commit (built with gcc-6):
commit: 6558038e4540a22ee4f99a5def74791189102bc0 ("mm/memory.c: recheck page table
entry with page table lock held")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu qemu64,+ssse3 -smp 4 -m 4G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
mm-recheck-page-table-entry-with-page-table-lock-held-fix.patch ("mm:
fix the crash observed with syzkaller run") will most likely fix this.
Was it applied during this testing?
It wasn't applied during this testing.
Best Regards,
Rong Chen
Re: [GIT] Sparc
On Thu, Oct 18, 2018 at 04:33:23PM -0700, David Miller wrote: > > The main bit here is fixing how fallback system calls are handled in > the sparc vDSO. > > Unfortunately, I fat fingered the commit and some perf debugging hacks > slipped into the vDSO fix, which I revert in the very next commit. > > Please pull, thanks a lot! > > The following changes since commit c343db455eb3105f11bb5ac290d77ab2006b0209: > > Merge branch 'parisc-4.19-3' of > git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux (2018-10-17 > 14:01:00 +0200) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc.git Now merged, thanks. greg k-h
linux-next: Tree for Oct 19
Hi all, News: I will not be doing linux-next releases next week. Unfortunately this will probably be the first week of the merge window. :-( Changes since 20181018: The net-next tree gained a conflict against the net tree and a build failure due to an interaction with the rdma tree for which I applied a merge fix patch. The kvm tree gained a conflict against the tip tree. Non-merge commits (relative to Linus' tree): 11382 10233 files changed, 562372 insertions(+), 243395 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 291 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (fa520c47eaa1 fscache: Fix out of bound read in long cookie keys) Merging fixes/master (eb81bfb224ce Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging kbuild-current/fixes (5318321d367c samples: disable CONFIG_SAMPLES for UML) Merging arc-current/for-curr (56d02dd9e794 ARC: IOC: panic if kernel was started with previously enabled IOC) Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() offset check) Merging arm64-fixes/for-next/fixes (ca2b497253ad arm64: perf: Reject stand-alone CHAIN events for PMUv3) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (ac1788cc7da4 powerpc/numa: Skip onlining a offline node in kdump path) Merging sparc/master (27faeebd0081 sparc: Revert unintended perf changes.) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (6b839b6cf9ea r8169: fix NAPI handling under high load) Merging bpf/master (bd8be2cf8b69 Merge branch 'nfp-fix-pedit-set-action-offloads') Merging ipsec/master (9d200fd1 xfrm: policy: use hlist rcu variants on insert) Merging netfilter/master (cb20f2d2c050 netfilter: xt_nat: fix DNAT target for shifted portmap ranges) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD queue size) Merging mac80211/master (8d0be26c781a mac80211_hwsim: fix module init error paths for netlink) Merging rdma-fixes/for-rc (a3671a4f973e RDMA/ucma: Fix Spectre v1 vulnerability) Merging sound-current/for-linus (709ae62e8e6d ALSA: hda/realtek - Cannot adjust speaker's volume on Dell XPS 27 7760) Merging sound-asoc-fixes/for-linus (98027961025e Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4) Merging regulator-fixes/for-linus (35a7f35ad1b1 Linux 4.19-rc8) Merging spi-fixes/for-linus (bc7a6ca6f446 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (2edab4df98d9 PCI: Expand the "PF" acronym in Kconfig help text) Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4) Merging tty.current/tty-linus (202dc3cc10b4 serial: sh-sci: Fix receive on SCIFA/SCIFB variants with DMA) Merging usb.current/usb-linus (9ae24af36691 usb: gadget: storage: Fix Spectre v1 vulnerability) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of dwc2_check_core_endianness) Merging usb-serial-fixes/usb-linus (0238df646e62 Linux 4.19-rc7) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb:
Fw: PROBLEM: Keyboard not responding after resuming from suspend/hibernate
On Fri, 31 Aug 2018 21:53:11 +0300 Numan Demirdöğen wrote: >If I put laptop to suspend or hibernate by closing lid, power >manager or any other method and then I resume/wake up laptop, keyboard >is not responding. My laptop is a Sony Vaio VPCEH2F1E. > >Steps to produce bug: >1. Boot >2. Put laptop to sleep >3. Resume > >What I expect to happen: Keyboard responds to key press. >What happens: Keyboard does not respond but mouse and trackball are >working. > >git bisect point 9d659ae14b545c4296e812c70493bfdc999b5c1c as the first >bad commit. > >Bad commit link: >https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=9d659ae14b545c4296e812c70493bfdc999b5c1c > > Link to actual bug report: >https://bugzilla.kernel.org/show_bug.cgi?id=195471 > >awk -f ver_linux >Linux korsan 4.18.5-arch1-1-ARCH #1 SMP PREEMPT Fri Aug 24 12:48:58 >UTC 2018 x86_64 GNU/Linux GNU C8.2.0 >GNU Make 4.2.1 >Binutils 2.31.1 >Util-linux 2.32.1 >Mount 2.32.1 >Module-init-tools 25 >E2fsprogs 1.44.4 >Jfsutils 1.1.15 >Reiserfsprogs 3.6.27 >Xfsprogs 4.17.0 >Pcmciautils018 >Linux C Library2.28 >Dynamic linker (ldd) 2.28 >Linux C++ Library 6.0.25 >Procps 3.3.15 >Kbd2.0.4 >Console-tools 2.0.4 >Sh-utils 8.29 >Udev 239 >Wireless-tools 30 >Modules Loaded ac agpgart ahci arc4 ath ath3k ath9k >ath9k_common ath9k_hw atkbd battery bluetooth bpfilter ccm cdrom >cfg80211 coretemp crc16 crc32c_generic crc32c_intel crc32_pclmul >crct10dif_pclmul cryptd drm drm_kms_helper ecdh_generic ehci_hcd >ehci_pci evdev ext4 fb_sys_fops fscrypto fuse ghash_clmulni_intel >gpio_ich hid hid_generic i2c_algo_bit i2c_i801 i8042 i915 input_leds >intel_cstate intel_gtt intel_powerclamp intel_rapl intel_rapl_perf >intel_uncore iptable_filter iptable_mangle iptable_nat ip_tables >irqbypass iTCO_vendor_support iTCO_wdt jbd2 kvm kvm_intel led_class >libahci libata libcrc32c libps2 lpc_ich mac80211 mac_hid mbcache mei >mei_me mousedev msr nf_conntrack nf_conntrack_ipv4 nf_defrag_ipv4 >nf_nat nf_nat_ipv4 pcc_cpufreq psmouse rfkill rtc_cmos scsi_mod sd_mod >serio serio_raw snd snd_hda_codec snd_hda_codec_conexant >snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_core snd_hda_intel >snd_hwdep snd_pcm snd_timer sony_laptop soundcore sr_mod syscopyarea >sysfillrect sysimgblt usb_common usbcore usbhid x86_pkg_temp_thermal >x_tables > >dmesg | grep i8042 >[0.574078] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] >at 0x60,0x64 irq 1,12 [0.575936] serio: i8042 KBD port at >0x60,0x64 irq 1 [0.576143] serio: i8042 AUX port at 0x60,0x64 irq >12 [0.618880] input: AT Translated Set 2 keyboard >as /devices/platform/i8042/serio0/input/input3 [ 11.248435] input: >AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input5 > >cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 0: 8 0 0 0 IO-APIC > 2-edge timer 1: 0 0 0 10286 > IO-APIC 1-edge i8042 8: 0 0 > 0 1 IO-APIC 8-edge rtc0 9: 0 > 9479 0 0 IO-APIC 9-fasteoi acpi 12: > 0 0 370114 0 IO-APIC 12-edge i8042 > 16: 197457 0 0 0 IO-APIC > 16-fasteoi ehci_hcd:usb1, ath9k 19: 0 0 > 0 0 IO-APIC 19-fasteoi i801_smbus 23: > 0 0 71055 0 IO-APIC 23-fasteoi > ehci_hcd:usb2 24: 0 74549 0 0 > PCI-MSI 512000-edge ahci[:00:1f.2] 25: 0 > 14 0 0 PCI-MSI 360448-edge mei_me > 26: 0 0 138870 0 PCI-MSI > 32768-edge i915 27: 0 0 0 > 330 PCI-MSI 442368-edge snd_hda_intel:card0 >NMI: 24 22 25 21 Non-maskable >interrupts LOC: 534734 446934 603337 440320 Local >timer interrupts SPU: 0 0 0 0 >Spurious interrupts PMI: 24 22 25 21 >Performance monitoring interrupts IWI: 26 12 >43115 22 IRQ work interrupts RTR: 0 >0 0 0 APIC ICR read retries RES: 95282 >76970 60242 46409 Rescheduling interrupts CAL: >66746 75300 70554 69119 Function call interrupts >TLB: 50929 54528 51413 48017 TLB shootdowns >TRM: 0 0 0 0 Thermal event >interrupts THR: 0 0 0 0 >Threshold APIC interrupts DFR: 0 0 >0 0 Deferred Error APIC interrupts MCE: 0 >0 0 0 Machine check exceptions MCP: >18 19
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On 2018/10/19 3:33, Boris Brezillon wrote: On Thu, 18 Oct 2018 13:09:05 +0800 Jianxin Pan wrote: From: Liang Yang Add initial support for the Amlogic NAND flash controller which found in the Meson-GXBB/GXL/AXG SoCs. Signed-off-by: Liang Yang Signed-off-by: Yixun Lan Signed-off-by: Jianxin Pan --- drivers/mtd/nand/raw/Kconfig | 10 + drivers/mtd/nand/raw/Makefile |1 + drivers/mtd/nand/raw/meson_nand.c | 1370 + 3 files changed, 1381 insertions(+) create mode 100644 drivers/mtd/nand/raw/meson_nand.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index c7efc31..223b041 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -541,4 +541,14 @@ config MTD_NAND_TEGRA is supported. Extra OOB bytes when using HW ECC are currently not supported. +config MTD_NAND_MESON + tristate "Support for NAND controller on Amlogic's Meson SoCs" + depends on ARCH_MESON || COMPILE_TEST + depends on COMMON_CLK_AMLOGIC + select COMMON_CLK_REGMAP_MESON + select MFD_SYSCON + help + Enables support for NAND controller on Amlogic's Meson SoCs. + This controller is found on Meson GXBB, GXL, AXG SoCs. + endif # MTD_NAND diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index 57159b3..a2cc2fe 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -56,6 +56,7 @@ obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand/ obj-$(CONFIG_MTD_NAND_QCOM) += qcom_nandc.o obj-$(CONFIG_MTD_NAND_MTK)+= mtk_ecc.o mtk_nand.o obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o +obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o nand-objs += nand_onfi.o diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c new file mode 100644 index 000..bcaac53 --- /dev/null +++ b/drivers/mtd/nand/raw/meson_nand.c @@ -0,0 +1,1370 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Amlogic Meson Nand Flash Controller Driver + * + * Copyright (c) 2018 Amlogic, inc. + * Author: Liang Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define NFC_REG_CMD0x00 +#define NFC_CMD_DRD(0x8 << 14) +#define NFC_CMD_IDLE (0xc << 14) +#define NFC_CMD_DWR(0x4 << 14) +#define NFC_CMD_CLE(0x5 << 14) +#define NFC_CMD_ALE(0x6 << 14) +#define NFC_CMD_ADL((0 << 16) | (3 << 20)) +#define NFC_CMD_ADH((1 << 16) | (3 << 20)) +#define NFC_CMD_AIL((2 << 16) | (3 << 20)) +#define NFC_CMD_AIH((3 << 16) | (3 << 20)) +#define NFC_CMD_SEED ((8 << 16) | (3 << 20)) +#define NFC_CMD_M2N((0 << 17) | (2 << 20)) +#define NFC_CMD_N2M((1 << 17) | (2 << 20)) +#define NFC_CMD_RB BIT(20) +#define NFC_CMD_IO6((0xb << 10) | (1 << 18)) + +#define NFC_REG_CFG0x04 +#define NFC_REG_DADR 0x08 +#define NFC_REG_IADR 0x0c +#define NFC_REG_BUF0x10 +#define NFC_REG_INFO 0x14 +#define NFC_REG_DC 0x18 +#define NFC_REG_ADR0x1c +#define NFC_REG_DL 0x20 +#define NFC_REG_DH 0x24 +#define NFC_REG_CADR 0x28 +#define NFC_REG_SADR 0x2c +#define NFC_REG_PINS 0x30 +#define NFC_REG_VER0x38 + +#define NFC_RB_IRQ_EN BIT(21) +#define NFC_INT_MASK (3 << 20) + +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages) \ + ( \ + (cmd_dir) | \ + ((ran) << 19) | \ + ((bch) << 14) | \ + ((short_mode) << 13) | \ + (((page_size) & 0x7f) << 6) | \ + ((pages) & 0x3f)\ + ) + +#define GENCMDDADDRL(adl, addr)((adl) | ((addr) & 0x)) +#define GENCMDDADDRH(adh, addr)((adh) | (((addr) >> 16) & 0x)) +#define GENCMDIADDRL(ail, addr)((ail) | ((addr) & 0x)) +#define GENCMDIADDRH(aih, addr)((aih) | (((addr) >> 16) & 0x)) + +#define RB_STA(x) (1 << (26 + (x))) +#define DMA_DIR(dir) ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N) + +#define ECC_CHECK_RETURN_FF(-1) + +#define NAND_CE0 (0xe << 10) +#define NAND_CE1 (0xd << 10) + +#define DMA_BUSY_TIMEOUT 0x10 +#define CMD_FIFO_EMPTY_TIMEOUT 1000 + +#define
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On 2018/10/18 22:24, Boris Brezillon wrote:
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
+static int meson_nfc_exec_op(struct nand_chip *chip,
+const struct nand_operation *op, bool check_only)
+{
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ struct meson_nfc *nfc = nand_get_controller_data(chip);
+ const struct nand_op_instr *instr = NULL;
+ int ret = 0, cmd;
+ unsigned int op_id;
+ int i;
+
+ for (op_id = 0; op_id < op->ninstrs; op_id++) {
+ instr = &op->instrs[op_id];
+ switch (instr->type) {
+ case NAND_OP_CMD_INSTR:
+ if (instr->ctx.cmd.opcode == NAND_CMD_STATUS)
+ meson_nfc_cmd_idle(nfc, nfc->timing.twb);
Hm, I don't want drivers to base their decisions on the opcode value.
There's a ->delay_ns field in the instruction object, can't you use
that one instead? Also, I don't understand why this is only needed for
the STATUS command. It should normally be applied to all instructions.
em, it should be applied to all instructions.
i will fix it and use instr->delay_ns instead.
+ cmd = nfc->param.chip_select | NFC_CMD_CLE;
+ cmd |= instr->ctx.cmd.opcode & 0xff;
+ writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ if (instr->ctx.cmd.opcode == NAND_CMD_STATUS)
+ meson_nfc_cmd_idle(nfc, nfc->timing.twhr);
+ break;
+
+ case NAND_OP_ADDR_INSTR:
+ for (i = 0; i < instr->ctx.addr.naddrs; i++) {
+ cmd = nfc->param.chip_select | NFC_CMD_ALE;
+ cmd |= instr->ctx.addr.addrs[i] & 0xff;
+ writel(cmd, nfc->reg_base + NFC_REG_CMD);
+ }
+ break;
+
+ case NAND_OP_DATA_IN_INSTR:
+ meson_nfc_read_buf(mtd, instr->ctx.data.buf.in,
+ instr->ctx.data.len);
+ break;
+
+ case NAND_OP_DATA_OUT_INSTR:
+ meson_nfc_write_buf(mtd, instr->ctx.data.buf.out,
+ instr->ctx.data.len);
+ break;
+
+ case NAND_OP_WAITRDY_INSTR:
+ meson_nfc_queue_rb(nfc, instr->ctx.waitrdy.timeout_ms);
+ break;
+ }
+ }
+ return ret;
+}
.
Re: [PATCH] tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x
On Fri, 2018-10-19 at 10:14 +0530, Nayna Jain wrote:
>
> On 10/17/2018 10:02 PM, Tomas Winkler wrote:
> > diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c
> > b/drivers/char/tpm/tpm_i2c_nuvoton.c
> > index caa86b19c76d..f74f451baf6a 100644
> > --- a/drivers/char/tpm/tpm_i2c_nuvoton.c
> > +++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
> > @@ -369,6 +369,7 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8
> > *buf, size_t len)
> > struct device *dev = chip->dev.parent;
> > struct i2c_client *client = to_i2c_client(dev);
> > u32 ordinal;
> > + unsigned long duration;
> > size_t count = 0;
> > int burst_count, bytes2write, retries, rc = -EIO;
> >
> > @@ -455,10 +456,12 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8
> > *buf, size_t len)
> > return rc;
> > }
> > ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
> > - rc = i2c_nuvoton_wait_for_data_avail(chip,
> > -tpm_calc_ordinal_duration(chip,
> > - ordinal),
> > -&priv->read_queue);
> > + if (chip->flags & TPM_CHIP_FLAG_TPM2)
> > + duration = tpm2_calc_ordinal_duration(chip, ordinal);
> > + else
> > + duration = tpm_calc_ordinal_duration(chip, ordinal);
> > +
> > + rc = i2c_nuvoton_wait_for_data_avail(chip, duration, &priv->read_queue);
> > if (rc) {
> > dev_err(dev, "%s() timeout command duration\n", __func__);
> > i2c_nuvoton_ready(chip);
>
> I only have Nuvoton TPM 2.0, tested for that.
>
> Reviewed-by: Nayna Jain
> Tested-by: Nayna Jain (For TPM 2.0)
That's what we needed as TPM 1.2 should be unchanged.
Really appreciate the quick response. I will rebase the series on to of
this patch.
Thanks
Tomas
Re: [PATCH v4 3/6] clocksource: exynos_mct: Refactor resources allocation
On Thu, 18 Oct 2018 at 11:57, Marek Szyprowski wrote: > > Move interrupts allocation from exynos4_timer_resources() into separate > function together with the interrupt number parsing code from > mct_init_dt(), so the code for managing interrupts is kept together. > While touching exynos4_timer_resources() function, move of_iomap() to it. > No functional changes. > > Signed-off-by: Marek Szyprowski > Reviewed-by: Chanwoo Choi > Tested-by: Chanwoo Choi > --- > drivers/clocksource/exynos_mct.c | 50 +++- > 1 file changed, 30 insertions(+), 20 deletions(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH v4 4/6] clocksource: exynos_mct: Add arch_timer cooperation mode for ARM64
On Thu, 18 Oct 2018 at 11:57, Marek Szyprowski wrote: > > To get ARM Architected Timers working on Samsung Exynos SoCs, one has to > first configure and enable Exynos Multi-Core Timer, because they both > share some common hardware blocks (global system counter). This patch > adds a mode of cooperation with arch_timer driver, so kernel can use > CP15 based timer interface via arch_timer driver, which is mandatory > on ARM64. In such mode MCT driver only enables its clocks and starts > global timer. Everything else will be handled by arch_timer driver. > > Signed-off-by: Marek Szyprowski > Reviewed-by: Chanwoo Choi > Tested-by: Chanwoo Choi > --- > drivers/clocksource/exynos_mct.c | 10 ++ > 1 file changed, 10 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads
On 18/10/2018 22:46, Andy Lutomirski wrote: >> [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker() >> >> Sebastian > I think we need an entirely new API: > > user_mm_ctx_t ctx = user_mm_ctx_get(); > > ... > > use_user_mm_ctx(ctx); > unuse_user_mm_ctx(ctx); > > ... > > user_mm_ctx_put(ctx); > > and ctx will store a copy of mm and PKRU. > That looks like a good API in general. The ffs_user_copy_worker that Sebastian mentioned seems to be used by AIO, in which case of course it has to happen in a kernel thread. But while the API is good, deciding on the desired semantics is "interesting". The submitting thread might be changing PKRU between the time the I/O operation is submitted and the time it is completed, for example. You could look up the task's PKRU at use_mm time, except that the task might have disappeared... In the end just using PKRU=0 makes some sense and it only should be documented that some kernel services will ignore PKRU. Paolo
[PATCH v2 2/3] iio: adc: Add ad7124 support
The ad7124-4 and ad7124-8 are a family of 4 and 8 channel sigma-delta ADCs with 24-bit precision and reference. Three power modes are available which in turn affect the output data rate: * Full power: 9.38 SPS to 19,200 SPS * Mid power: 2.34 SPS to 4800 SPS * Low power: 1.17 SPS to 2400 SPS The ad7124-4 can be configured to have four differential inputs, while ad7124-8 can have 8. Moreover, ad7124 also supports per channel configuration. Each configuration consists of gain, reference source, output data rate and bipolar/unipolar configuration. Datasheets: Link: http://www.analog.com/media/en/technical-documentation/data-sheets/AD7124-4.pdf Link: http://www.analog.com/media/en/technical-documentation/data-sheets/ad7124-8.pdf Signed-off-by: Stefan Popa --- Changes in v2: - Nothing changed. MAINTAINERS | 7 + drivers/iio/adc/Kconfig | 11 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/ad7124.c | 655 +++ 4 files changed, 674 insertions(+) create mode 100644 drivers/iio/adc/ad7124.c diff --git a/MAINTAINERS b/MAINTAINERS index f642044..3a1bfcb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -839,6 +839,13 @@ S: Supported F: drivers/iio/dac/ad5758.c F: Documentation/devicetree/bindings/iio/dac/ad5758.txt +ANALOG DEVICES INC AD7124 DRIVER +M: Stefan Popa +L: linux-...@vger.kernel.org +W: http://ez.analog.com/community/linux-device-drivers +S: Supported +F: drivers/iio/adc/ad7124.c + ANALOG DEVICES INC AD9389B DRIVER M: Hans Verkuil L: linux-me...@vger.kernel.org diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index a52fea8..148a10f 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -10,6 +10,17 @@ config AD_SIGMA_DELTA select IIO_BUFFER select IIO_TRIGGERED_BUFFER +config AD7124 + tristate "Analog Devices AD7124 and similar sigma-delta ADCs driver" + depends on SPI_MASTER + select AD_SIGMA_DELTA + help + Say yes here to build support for Analog Devices AD7124-4 and AD7124-8 + SPI analog to digital converters (ADC). + + To compile this driver as a module, choose M here: the module will be + called ad7124. + config AD7266 tristate "Analog Devices AD7265/AD7266 ADC driver" depends on SPI_MASTER diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index a6e6a0b..76168b2 100644 --- a/drivers/iio/adc/Makefile +++ b/drivers/iio/adc/Makefile @@ -5,6 +5,7 @@ # When adding new entries keep the list in alphabetical order obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o +obj-$(CONFIG_AD7124) += ad7124.o obj-$(CONFIG_AD7266) += ad7266.o obj-$(CONFIG_AD7291) += ad7291.o obj-$(CONFIG_AD7298) += ad7298.o diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c new file mode 100644 index 000..c6d9798 --- /dev/null +++ b/drivers/iio/adc/ad7124.c @@ -0,0 +1,655 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * AD7124 SPI ADC driver + * + * Copyright 2018 Analog Devices Inc. + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +/* AD7124 registers */ +#define AD7124_COMMS 0x00 +#define AD7124_STATUS 0x00 +#define AD7124_ADC_CONTROL 0x01 +#define AD7124_DATA0x02 +#define AD7124_IO_CONTROL_10x03 +#define AD7124_IO_CONTROL_20x04 +#define AD7124_ID 0x05 +#define AD7124_ERROR 0x06 +#define AD7124_ERROR_EN0x07 +#define AD7124_MCLK_COUNT 0x08 +#define AD7124_CHANNEL(x) (0x09 + (x)) +#define AD7124_CONFIG(x) (0x19 + (x)) +#define AD7124_FILTER(x) (0x21 + (x)) +#define AD7124_OFFSET(x) (0x29 + (x)) +#define AD7124_GAIN(x) (0x31 + (x)) + +/* AD7124_STATUS */ +#define AD7124_STATUS_POR_FLAG_MSK BIT(4) + +/* AD7124_ADC_CONTROL */ +#define AD7124_ADC_CTRL_PWR_MSKGENMASK(7, 6) +#define AD7124_ADC_CTRL_PWR(x) FIELD_PREP(AD7124_ADC_CTRL_PWR_MSK, x) +#define AD7124_ADC_CTRL_MODE_MSK GENMASK(5, 2) +#define AD7124_ADC_CTRL_MODE(x)FIELD_PREP(AD7124_ADC_CTRL_MODE_MSK, x) + +/* AD7124_CHANNEL_X */ +#define AD7124_CHANNEL_EN_MSK BIT(15) +#define AD7124_CHANNEL_EN(x) FIELD_PREP(AD7124_CHANNEL_EN_MSK, x) +#define AD7124_CHANNEL_SETUP_MSK GENMASK(14, 12) +#define AD7124_CHANNEL_SETUP(x)FIELD_PREP(AD7124_CHANNEL_SETUP_MSK, x) +#define AD7124_CHANNEL_AINP_MSKGENMASK(9, 5) +#define AD7124_CHANNEL_AINP(x) FIELD_PREP(AD7124_CHANNEL_AINP_MSK, x) +#define AD7124_CHANNEL_AINM_MSKGENMASK(4, 0) +#define AD7124_CHANNEL_AINM(x) FIELD_PREP(AD7124_CHANNEL_AINM_MSK, x) + +/* AD7124_CONFIG_X */ +#define AD7124_CONFIG_BIPOLAR_MSK BIT(11) +#define AD7124_CONFIG_BIPOLAR(x) FI
[PATCH v2 1/3] iio: ad_sigma_delta: Allow to provide custom data register address
From: Lars-Peter Clausen
Some newer devices from the Sigma-Delta ADC family do have their data
register at a different address than the current default address. Add a
parameter to the ad_sigma_delta_info struct which allows to override the
default address.
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Stefan Popa
---
Changes in v2:
- Added this commit.
drivers/iio/adc/ad_sigma_delta.c | 22 +-
include/linux/iio/adc/ad_sigma_delta.h | 3 +++
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/adc/ad_sigma_delta.c b/drivers/iio/adc/ad_sigma_delta.c
index fc95107..ff5f2da 100644
--- a/drivers/iio/adc/ad_sigma_delta.c
+++ b/drivers/iio/adc/ad_sigma_delta.c
@@ -278,6 +278,7 @@ int ad_sigma_delta_single_conversion(struct iio_dev
*indio_dev,
{
struct ad_sigma_delta *sigma_delta = iio_device_get_drvdata(indio_dev);
unsigned int sample, raw_sample;
+ unsigned int data_reg;
int ret = 0;
if (iio_buffer_enabled(indio_dev))
@@ -305,7 +306,12 @@ int ad_sigma_delta_single_conversion(struct iio_dev
*indio_dev,
if (ret < 0)
goto out;
- ret = ad_sd_read_reg(sigma_delta, AD_SD_REG_DATA,
+ if (sigma_delta->info->data_reg != 0)
+ data_reg = sigma_delta->info->data_reg;
+ else
+ data_reg = AD_SD_REG_DATA;
+
+ ret = ad_sd_read_reg(sigma_delta, data_reg,
DIV_ROUND_UP(chan->scan_type.realbits + chan->scan_type.shift,
8),
&raw_sample);
@@ -392,6 +398,7 @@ static irqreturn_t ad_sd_trigger_handler(int irq, void *p)
struct iio_dev *indio_dev = pf->indio_dev;
struct ad_sigma_delta *sigma_delta = iio_device_get_drvdata(indio_dev);
unsigned int reg_size;
+ unsigned int data_reg;
uint8_t data[16];
int ret;
@@ -401,18 +408,23 @@ static irqreturn_t ad_sd_trigger_handler(int irq, void *p)
indio_dev->channels[0].scan_type.shift;
reg_size = DIV_ROUND_UP(reg_size, 8);
+ if (sigma_delta->info->data_reg != 0)
+ data_reg = sigma_delta->info->data_reg;
+ else
+ data_reg = AD_SD_REG_DATA;
+
switch (reg_size) {
case 4:
case 2:
case 1:
- ret = ad_sd_read_reg_raw(sigma_delta, AD_SD_REG_DATA,
- reg_size, &data[0]);
+ ret = ad_sd_read_reg_raw(sigma_delta, data_reg, reg_size,
+ &data[0]);
break;
case 3:
/* We store 24 bit samples in a 32 bit word. Keep the upper
* byte set to zero. */
- ret = ad_sd_read_reg_raw(sigma_delta, AD_SD_REG_DATA,
- reg_size, &data[1]);
+ ret = ad_sd_read_reg_raw(sigma_delta, data_reg, reg_size,
+ &data[1]);
break;
}
diff --git a/include/linux/iio/adc/ad_sigma_delta.h
b/include/linux/iio/adc/ad_sigma_delta.h
index 730ead1..7e84351 100644
--- a/include/linux/iio/adc/ad_sigma_delta.h
+++ b/include/linux/iio/adc/ad_sigma_delta.h
@@ -39,6 +39,8 @@ struct iio_dev;
* if there is just one read-only sample data shift register.
* @addr_shift: Shift of the register address in the communications register.
* @read_mask: Mask for the communications register having the read bit set.
+ * @data_reg: Address of the data register, if 0 the default address of 0x3
will
+ * be used.
*/
struct ad_sigma_delta_info {
int (*set_channel)(struct ad_sigma_delta *, unsigned int channel);
@@ -47,6 +49,7 @@ struct ad_sigma_delta_info {
bool has_registers;
unsigned int addr_shift;
unsigned int read_mask;
+ unsigned int data_reg;
};
/**
--
2.7.4
[PATCH v2 3/3] dt-bindings: iio: adc: Add docs for ad7124
Add support for Analog Devices AD7124 4-channels and 8-channels ADC.
Signed-off-by: Stefan Popa
---
Changes in v2:
- Nothing changed.
.../devicetree/bindings/iio/adc/adi,ad7124.txt | 96 ++
MAINTAINERS| 1 +
2 files changed, 97 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7124.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7124.txt
b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.txt
new file mode 100644
index 000..77a7b92
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7124.txt
@@ -0,0 +1,96 @@
+Analog Devices AD7124 ADC device driver
+
+Required properties for the AD7124:
+ - compatible: Must be one of "adi,ad7124-4" or "adi,ad7124-8"
+ - reg: SPI chip select number for the device
+ - spi-max-frequency: Max SPI frequency to use
+ see: Documentation/devicetree/bindings/spi/spi-bus.txt
+ - clocks: phandle to the master clock (mclk)
+ see: Documentation/devicetree/bindings/clock/clock-bindings.txt
+ - clock-names: Must be "mclk".
+ - interrupts: IRQ line for the ADC
+ see:
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+
+ - adi,channels: List of external channels connected to the ADC:
+ Required properties:
+ * #address-cells: Must be 2.
+ * #size-cells: Must be 0.
+
+ The child nodes of this node represent the external channels which are
+ connected to the ADC.
+
+ Each child node represents one channel and has the following
+ properties:
+ Required properties:
+ * reg: Pins the channel is connected to. The first
value specifies
+ the positive input pin, the second value the negative
input pin.
+ * adi,channel-number: It can have up to 4 channels on
ad7124-4 and
+ 8 channels on ad7124-8, numbered from 0 to 15.
+
+ Optional properties:
+ * adi,bipolar: If set the channel is used in bipolar
mode.
+ * adi,reference-select: Select the reference source to
use when
+ converting on the the specific channel. Valid values
are:
+ 0: REFIN1(+)/REFIN1(−).
+ 1: REFIN2(+)/REFIN2(−).
+ 3: AVDD
+ If this field is left empty, internal reference is
selected.
+ * adi,gain: Select the gain when converting on the
specific channel.
+ Valid values are: 1, 2, 4, 8, 16, 32, 64, 128.
+ If this field is left empty, gain of 1 is selected.
+ * adi,odr-hz: The output data rate can be programmed
from:
+ 9 to 19200 for full power mode (when the master clock
is 614.4 kHz)
+ 2 to 4800 for mid power mode (when the master clock
is 153.6 kHz)
+ 1 to 2400 for low power mode (when the master clock
is 76.8 kHz)
+ If this field is left empty, odr of 9 is selected.
+
+Optional properties:
+ - refin1-supply: refin1 supply can be used as reference for conversion.
+ - refin2-supply: refin2 supply can be used as reference for conversion.
+ - avdd-supply: avdd supply can be used as reference for conversion.
+
+Example:
+ adc@0 {
+ compatible = "adi,ad7124-4";
+ reg = <0>;
+ spi-max-frequency = <500>;
+ interrupts = <25 2>;
+ interrupt-parent = <&gpio>;
+ refin1-supply = <&adc_vref>;
+ clocks = <&ad7124_mclk>;
+ clock-names = "mclk";
+
+ adi,channels {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0 1>;
+ adi,channel-number = <0>;
+ adi,reference-select = <0>;
+ adi,gain = <2>;
+ adi,odr-hz = <10>;
+ };
+
+ channel@1 {
+ reg = <2 3>;
+ adi,bipolar;
+ adi,channel-number = <1>;
+ adi,reference-select = <0>;
+ adi,gain = <4>;
+ adi,odr-hz = <50>;
+ };
+
+ channel@2 {
+ reg = <4 5>;
+ adi,channel-number = <2>;
+ adi,gain = <128>;
+ adi,odr-hz = <19200>;
+ };
+
Re: [Patch v3 05/13] x86/smt: Create cpu_smt_enabled static key for SMT specific code
On Wed, Oct 17, 2018 at 10:59:33AM -0700, Tim Chen wrote: > diff --git a/kernel/cpu.c b/kernel/cpu.c > index 3adecda..ad28afc 100644 > --- a/kernel/cpu.c > +++ b/kernel/cpu.c > @@ -349,6 +349,8 @@ EXPORT_SYMBOL_GPL(cpu_hotplug_enable); > #ifdef CONFIG_HOTPLUG_SMT > enum cpuhp_smt_control cpu_smt_control __read_mostly = CPU_SMT_ENABLED; > EXPORT_SYMBOL_GPL(cpu_smt_control); > +DEFINE_STATIC_KEY_TRUE(cpu_smt_enabled); > +EXPORT_SYMBOL_GPL(cpu_smt_enabled); We already have sched_smt_present; please merge the two. It is pointless having this twice.
Re: [Patch v3 00/13] Provide process property based options to enable Spectre v2 userspace-userspace protection
On Wed, Oct 17, 2018 at 10:59:28AM -0700, Tim Chen wrote: > Application to application exploit is in general difficult due to address > space layout randomization in applications and the need to know an Does the BTB attack on KASLR not work for userspace?
Re: [RFC PATCH 0/7] Introduce thermal pressure
* Thara Gopinath wrote: > > Yeah, so I'd definitely suggest to not integrate this averaging into > > pelt.c in the fashion presented, because: > > > > - This couples your thermal throttling averaging to the PELT decay > >half-time AFAICS, which would break the other user every time the > >decay is changed/tuned. > > Let me pose the question in this manner. Today rt utilization, dl > utilization etc is tracked via PELT. The inherent idea is that, a cpu > has some capacity stolen by let us say rt task and so subtract the > capacity utilized by the rt task from cpu when calculating the > remaining capacity for a CFS task. Now, the idea behind thermal > pressure is that, the maximum available capacity of a cpu is limited > due to a thermal event, so take it out of the remaining capacity of a > cpu for a CFS task (at-least to start with). If utilization for rt > task, dl task etc is calculated via PELT and the capacity constraint > due to thermal event calculated by another averaging algorithm, there > can be some mismatch in the "capacity stolen" calculations, right? > Isnt't it better to track all the events that can limit the capacity of > a cpu via one algorithm ? So what unifies RT and DL utilization is that those are all direct task loads independent of external factors. Thermal load is more of a complex physical property of the combination of various internal and external factors: the whole system workload running (not just that single task), the thermal topology of the hardware, external temperatures, the hardware's and the governor's policy regarding thermal loads, etc. etc. So while obviously when effective capacity of a CPU is calculated then these will all be subtracted from the maximum capacity of the CPU, but I think the thermal load metric and the averaging itself is probably dissimilar enough to not be calculated via the PELT half-life for example. For example a reasonable future property would be match the speed of decay in the averaging to the observed speed of decay via temperature sensors? Most temperature sensors do a certain amount of averaging themselves as well - and some platforms might not expose temperatures at all, only 'got thermally throttled' / 'running at full speed' kind of feedback. Anyway, this doesn't really impact the concept, it's an implementational detail, and much of this could be resolved if the averaging code in pelt.c was librarized a bit - and that's really what you did there in a fashion, I just think it should probably be abstracted out more clearly. (I have no clear implementational suggestions right now, other than 'try and see how it works out - it might be a bad idea'.) Thanks, Ingo
Re: [PATCH] smartpqi: Fix timeout of smartpqi probe stage
Just Ping. This is a very serious issue. The OS boot from this raid controller couldn't find bock devices after installing OS. I think this patch should be merged asap. Feng Li 于2018年10月12日周五 上午11:13写道： > > I use 'HPE Smart Array E208i-a SR Gen10 Controller', and pass through > the SAS controller from ESXi 6.0U1 to VM, which is installed CentOS 7.4/7.5. > The disk is not found. > > The error log is "controller not ready after 30 seconds." > > Add some logs, and could check the probe stage needs nearly 36s to match the > status. > > Signed-off-by: Li Feng > --- > drivers/scsi/smartpqi/smartpqi_sis.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/smartpqi/smartpqi_sis.c > b/drivers/scsi/smartpqi/smartpqi_sis.c > index 5141bd4c9..bc7efdacb 100644 > --- a/drivers/scsi/smartpqi/smartpqi_sis.c > +++ b/drivers/scsi/smartpqi/smartpqi_sis.c > @@ -59,7 +59,7 @@ > > #define SIS_CTRL_KERNEL_UP 0x80 > #define SIS_CTRL_KERNEL_PANIC 0x100 > -#define SIS_CTRL_READY_TIMEOUT_SECS 30 > +#define SIS_CTRL_READY_TIMEOUT_SECS 90 > #define SIS_CTRL_READY_RESUME_TIMEOUT_SECS 90 > #define SIS_CTRL_READY_POLL_INTERVAL_MSECS 10 > > -- > 2.11.0 -- Thanks and Best Regards, Feng Li(Alex)
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On 2018/10/19 4:39, Boris Brezillon wrote:
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
+static int meson_nfc_calc_set_timing(struct meson_nfc *nfc,
+const struct nand_sdr_timings *timings)
+{
+ struct nand_timing *timing = &nfc->timing;
+ int div, bt_min, bt_max, bus_timing;
+ int ret;
+
+ div = DIV_ROUND_UP((timings->tRC_min / 1000), NFC_CLK_CYCLE);
+ ret = clk_set_rate(nfc->device_clk, 10 / div);
+ if (ret) {
+ dev_err(nfc->dev, "failed to set nand clock rate\n");
+ return ret;
+ }
+
+ timing->twb = DIV_ROUND_UP(PSEC_TO_NSEC(timings->tWB_max),
+ div * NFC_CLK_CYCLE);
+ timing->tadl = DIV_ROUND_UP(PSEC_TO_NSEC(timings->tADL_min),
+ div * NFC_CLK_CYCLE);
+ timing->twhr = DIV_ROUND_UP(PSEC_TO_NSEC(timings->tWHR_min),
+ div * NFC_CLK_CYCLE);
+
+ bt_min = (timings->tREA_max + NFC_DEFAULT_DELAY) / div;
+ bt_max = (NFC_DEFAULT_DELAY + timings->tRHOH_min
+ + timings->tRC_min / 2) / div;
+
+ bt_min = DIV_ROUND_UP(bt_min, 1000);
+ bt_max = DIV_ROUND_UP(bt_max, 1000);
+
+ if (bt_max < bt_min)
+ return -EINVAL;
+
+ bus_timing = (bt_min + bt_max) / 2 + 1;
+
+ writel((1 << 21), nfc->reg_base + NFC_REG_CFG);
+ writel((NFC_CLK_CYCLE - 1) | (bus_timing << 5),
+ nfc->reg_base + NFC_REG_CFG);
+
+ writel((1 << 31), nfc->reg_base + NFC_REG_CMD);
+
+ return 0;
+}
+
+static int
+meson_nfc_setup_data_interface(struct nand_chip *nand, int csline,
+ const struct nand_data_interface *conf)
+{
+ struct meson_nfc *nfc = nand_get_controller_data(nand);
+ const struct nand_sdr_timings *timings;
+
+ timings = nand_get_sdr_timings(conf);
+ if (IS_ERR(timings))
+ return -ENOTSUPP;
+
+ if (csline == NAND_DATA_IFACE_CHECK_ONLY)
+ return 0;
Hm, before saying you supporting the requested timing, you should make
sure they are actually supported. I'd recommend splitting this in 2
steps:
1/ calc timings
2/ store the timings in the chip priv struct so that they can be
applied next time ->select_chip() is called.
ok, i will try to split.
+
+ meson_nfc_calc_set_timing(nfc, timings);
> You should not set the timing from ->setup_data_interface(), just
calculate them, make sure they are supported and store the state in the
private chip struct. Applying those timings should be done in
->select_chip(), so that you can support 2 chips with different timings.
em, i will fix it.
+ return 0;
+}
.
Re: [PATCH 2/2] mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask
On Thu 18-10-18 19:11:47, Andrew Morton wrote: > On Wed, 26 Sep 2018 16:22:27 +0200 Michal Hocko wrote: > > > > MPOL_PREFERRED is handled by policy_node() before we call > > > __alloc_pages_nodemask. > > > __GFP_THISNODE is applied only when we are not using > > > __GFP_DIRECT_RECLAIM which is handled in alloc_hugepage_direct_gfpmask > > > now. > > > Lastly MPOL_BIND wasn't handled explicitly but in the end the removed > > > late check would remove __GFP_THISNODE for it as well. So in the end we > > > are doing the same thing unless I miss something > > > > Forgot to add. One notable exception would be that the previous code > > would allow to hit > > WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); > > in policy_node if the requested node (e.g. cpu local one) was outside of > > the mbind nodemask. This is not possible now. We haven't heard about any > > such warning yet so it is unlikely that it happens though. > > Perhaps a changelog addition is needed to cover the above? : THP allocation mode is quite complex and it depends on the defrag : mode. This complexity is hidden in alloc_hugepage_direct_gfpmask from a : large part currently. The NUMA special casing (namely __GFP_THISNODE) is : however independent and placed in alloc_pages_vma currently. This both : adds an unnecessary branch to all vma based page allocation requests and : it makes the code more complex unnecessarily as well. Not to mention : that e.g. shmem THP used to do the node reclaiming unconditionally : regardless of the defrag mode until recently. This was not only : unexpected behavior but it was also hardly a good default behavior and I : strongly suspect it was just a side effect of the code sharing more than : a deliberate decision which suggests that such a layering is wrong. : : Moreover the oriinal code allowed to trigger : WARN_ON_ONCE(policy->mode == MPOL_BIND && (gfp & __GFP_THISNODE)); : in policy_node if the requested node (e.g. cpu local one) was outside of : the mbind nodemask. This is not possible now. We haven't heard about any : such warning yet so it is unlikely that it happens but still a signal of : a wrong code layering. : : Get rid of the thp special casing from alloc_pages_vma and move the logic : to alloc_hugepage_direct_gfpmask. __GFP_THISNODE is applied to : the resulting gfp mask only when the direct reclaim is not requested and : when there is no explicit numa binding to preserve the current logic. : : This allows for removing alloc_hugepage_vma as well. Better? > I assume that David's mbind() concern has gone away. Either I've misunderstood it or it was not really a real issue. -- Michal Hocko SUSE Labs
Re: [PATCH V2 1/5] mm/hugetlb: Enable PUD level huge page migration
I planed to get to review this earlier but been busy. Anyway, this patch
should be applied only after movability one to prevent from
(theoretical) bisectability issues.
I would probably fold it into the one which defines arch specific hook.
On Fri 12-10-18 09:29:55, Anshuman Khandual wrote:
> Architectures like arm64 have PUD level HugeTLB pages for certain configs
> (1GB huge page is PUD based on ARM64_4K_PAGES base page size) that can be
> enabled for migration. It can be achieved through checking for PUD_SHIFT
> order based HugeTLB pages during migration.
>
> Signed-off-by: Anshuman Khandual
> ---
> include/linux/hugetlb.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index 6b68e34..9c1b77f 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -483,7 +483,8 @@ static inline bool hugepage_migration_supported(struct
> hstate *h)
> {
> #ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
> if ((huge_page_shift(h) == PMD_SHIFT) ||
> - (huge_page_shift(h) == PGDIR_SHIFT))
> + (huge_page_shift(h) == PUD_SHIFT) ||
> + (huge_page_shift(h) == PGDIR_SHIFT))
> return true;
> else
> return false;
> --
> 2.7.4
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/4] Adds -Wshadow=local on KBUILD_HOSTCFLAGS
On Fri, Oct 19, 2018 at 11:41:31AM +0900, Masahiro Yamada wrote: > Adding -Wshadow to KBUILD_HOSTCFLAGS emits another warning in Kconfig. > Of course, it is easy to fix. > But, I just started to think this option is a kind of harsh... What is more, if we added -Wshadow to KBUILD_HOSTCFLAGS, then there'll be a difference in build options between host and target kernel in that the host kernel build will be stricter wrt shadowing. Thus, it is a maintainer decision, IMHO. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Fri, 19 Oct 2018 15:29:05 +0800
Liang Yang wrote:
> > How about defining that the HW returns an array of __le64 instead and then
> > define the following macros which you can use after converting in the
> > CPU endianness
> >
> > #define ECC_GET_PROTECTED_OOB_BYTE(x, y)(((x) >> (8 * (1 + y)) &
> > GENMASK(7, 0))
> > #define ECC_COMPLETEBIT(31)
> > #define ECC_ERR_CNT(x) (((x) >> 24) & GENMASK(5, 0))
> >
> > (I'm not entirely sure the field positions are correct, but I'll let you
> > check that).
> >
> ok. i think it should be:
>
> #define ECC_GET_PROTECTED_OOB_BYTE(x, y) (((x) >> (8 * y) &
> GENMASK(7, 0))
>
> if x represents the u64 and y represents the index of the u64.
Absolutely.
>
>
>
> >> +
> >> +#define PER_INFO_BYTE (sizeof(struct meson_nfc_info_format))
> >> +
> >> +struct meson_nfc_nand_chip {
> >> + struct list_head node;
> >> + struct nand_chip nand;
> >> + bool is_scramble;
> >
> > I think I already mentioned the NAND_NEED_SCRAMBLING flag []. Please
> > drop this field and test (chip->flags & NAND_NEED_SCRAMBLING) instead.
> >
> em, i use NAND_NEED_SCRAMBLING and is_scramble is set:
> static int meson_nand_attach_chip(struct nand_chip *nand)
> {
> ..
> meson_chip->is_scramble =
> (nand->options & NAND_NEED_SCRAMBLING) ? 1 : 0;
> ..
> }
Why do you need to add a new field then? Just test
nand->options & NAND_NEED_SCRAMBLING directly or provide a helper
function that does that.
Re: [PATCH 4/6] mm: introduce page->dma_pinned_flags, _count
On Wed 17-10-18 17:03:03, John Hubbard wrote: > On 10/17/18 4:09 AM, Michal Hocko wrote: > > On Tue 16-10-18 18:48:23, John Hubbard wrote: > > [...] > >> It's hard to say exactly what the active/inactive/unevictable list should > >> be when DMA is done and put_user_page*() is called, because we don't know > >> if some device read, wrote, or ignored any of those pages. Although if > >> put_user_pages_dirty() is called, that's an argument for "active", at > >> least. > > > > Any reason to not use putback_lru_page? > > That does help with which LRU to use. I guess I'd still need to track whether > a page was on an LRU when get_user_pages() was called, because it seems > that that is not necessarily always the case. And putback_lru_page() > definitely > wants to deal with a page that *was* previously on an LRU. Well, if you ever g-u-p pages which are never going to go to LRU then sure (e.g. hugetlb pages). -- Michal Hocko SUSE Labs
Re: [PATCH 4.14 00/41] 4.14.78-stable review
On Thu, Oct 18, 2018 at 06:41:32PM -0700, Nathan Chancellor wrote: > On Thu, Oct 18, 2018 at 07:54:15PM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.78 release. > > There are 41 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Oct 20 17:53:55 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.78-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.14.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Merged, compiled, and installed onto my Raspberry Pi. > > No initial issues noticed in dmesg or general usage. Thanks for testing 3 of these and letting me know. greg k-h
Re: [PATCH] memblock: remove stale #else and the code it protects
Which tree it applies?
On Thu, Sep 27, 2018 at 08:03:45PM +0300, Mike Rapoport wrote:
>During removal of HAVE_MEMBLOCK definition, the #else clause of the
>
> #ifdef CONFIG_HAVE_MEMBLOCK
> ...
> #else
> ...
> #endif
>
>conditional was not removed.
>
>Remove it now.
>
>Signed-off-by: Mike Rapoport
>Reported-by: Alexander Duyck
>Cc: Michal Hocko
>---
> include/linux/memblock.h | 5 -
> 1 file changed, 5 deletions(-)
>
>diff --git a/include/linux/memblock.h b/include/linux/memblock.h
>index d3bc270..d4d0e01 100644
>--- a/include/linux/memblock.h
>+++ b/include/linux/memblock.h
>@@ -597,11 +597,6 @@ static inline void early_memtest(phys_addr_t start,
>phys_addr_t end)
> {
> }
> #endif
>-#else
>-static inline phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align)
>-{
>- return 0;
>-}
>
> #endif /* __KERNEL__ */
>
>--
>2.7.4
--
Wei Yang
Help you, Help me
[PATCH 1/7 linux-next] coda: remove CODA_FREE
Since commit 1d5cfdb07628
("tree wide: use kvfree() than conditional kfree()/vfree()")
size in CODA_FREE is no longer used and that macro
hides nothing more than kvfree()
Signed-off-by: Fabian Frederick
---
fs/coda/coda_linux.h | 2 --
fs/coda/psdev.c | 8
fs/coda/upcall.c | 36 ++--
3 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/fs/coda/coda_linux.h b/fs/coda/coda_linux.h
index 126155c..903f2a3 100644
--- a/fs/coda/coda_linux.h
+++ b/fs/coda/coda_linux.h
@@ -73,8 +73,6 @@ void coda_sysctl_clean(void);
} while (0)
-#define CODA_FREE(ptr, size) kvfree((ptr))
-
/* inode to cnode access functions */
static inline struct coda_inode_info *ITOC(struct inode *inode)
diff --git a/fs/coda/psdev.c b/fs/coda/psdev.c
index c5234c2..cbdddf4 100644
--- a/fs/coda/psdev.c
+++ b/fs/coda/psdev.c
@@ -126,7 +126,7 @@ static ssize_t coda_psdev_write(struct file *file, const
char __user *buf,
}
CODA_ALLOC(dcbuf, union outputArgs *, nbytes);
if (copy_from_user(dcbuf, buf, nbytes)) {
- CODA_FREE(dcbuf, nbytes);
+ kvfree(dcbuf);
retval = -EFAULT;
goto out;
}
@@ -134,7 +134,7 @@ static ssize_t coda_psdev_write(struct file *file, const
char __user *buf,
/* what downcall errors does Venus handle ? */
error = coda_downcall(vcp, hdr.opcode, dcbuf);
- CODA_FREE(dcbuf, nbytes);
+ kvfree(dcbuf);
if (error) {
pr_warn("%s: coda_downcall error: %d\n",
__func__, error);
@@ -257,7 +257,7 @@ static ssize_t coda_psdev_read(struct file * file, char
__user * buf,
goto out;
}
- CODA_FREE(req->uc_data, sizeof(struct coda_in_hdr));
+ kvfree(req->uc_data);
kfree(req);
out:
mutex_unlock(&vcp->vc_mutex);
@@ -319,7 +319,7 @@ static int coda_psdev_release(struct inode * inode, struct
file * file)
/* Async requests need to be freed here */
if (req->uc_flags & CODA_REQ_ASYNC) {
- CODA_FREE(req->uc_data, sizeof(struct coda_in_hdr));
+ kvfree(req->uc_data);
kfree(req);
continue;
}
diff --git a/fs/coda/upcall.c b/fs/coda/upcall.c
index 1175a17..d0d0fed 100644
--- a/fs/coda/upcall.c
+++ b/fs/coda/upcall.c
@@ -85,7 +85,7 @@ int venus_rootfid(struct super_block *sb, struct CodaFid
*fidp)
if (!error)
*fidp = outp->coda_root.VFid;
- CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -104,7 +104,7 @@ int venus_getattr(struct super_block *sb, struct CodaFid
*fid,
if (!error)
*attr = outp->coda_getattr.attr;
- CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -123,7 +123,7 @@ int venus_setattr(struct super_block *sb, struct CodaFid
*fid,
error = coda_upcall(coda_vcp(sb), insize, &outsize, inp);
-CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -153,7 +153,7 @@ int venus_lookup(struct super_block *sb, struct CodaFid
*fid,
*type = outp->coda_lookup.vtype;
}
- CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -173,7 +173,7 @@ int venus_close(struct super_block *sb, struct CodaFid
*fid, int flags,
error = coda_upcall(coda_vcp(sb), insize, &outsize, inp);
- CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -194,7 +194,7 @@ int venus_open(struct super_block *sb, struct CodaFid *fid,
if (!error)
*fh = outp->coda_open_by_fd.fh;
- CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -224,7 +224,7 @@ int venus_mkdir(struct super_block *sb, struct CodaFid
*dirfid,
*newfid = outp->coda_mkdir.VFid;
}
- CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -262,7 +262,7 @@ int venus_rename(struct super_block *sb, struct CodaFid
*old_fid,
error = coda_upcall(coda_vcp(sb), insize, &outsize, inp);
- CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -295,7 +295,7 @@ int venus_create(struct super_block *sb, struct CodaFid
*dirfid,
*newfid = outp->coda_create.VFid;
}
- CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -318,7 +318,7 @@ int venus_rmdir(struct super_block *sb, struct CodaFid
*dirfid,
error = coda_upcall(coda_vcp(sb), insize, &outsize, inp);
- CODA_FREE(inp, insize);
+ kvfree(inp);
return error;
}
@@ -340,7 +340,7 @@ int venus_remove(struct super_block *sb, struct CodaFid
*dirfid,
[PATCH 0/7 linux-next] coda: fs clean-up
This small patchset applies some sparse clean-up / optimizations Fabian Frederick (7): coda: remove CODA_FREE coda: destroy mutex in put_super() coda: use SIZE() for stat coda: add __init to init_coda_psdev() coda: remove sysctl object from module when unused coda: remove sb test in coda_fid_to_inode() coda: ftoc validity check integration fs/coda/Makefile | 3 ++- fs/coda/cnode.c | 15 ++- fs/coda/coda_fs_i.h | 3 +-- fs/coda/coda_int.h | 10 ++ fs/coda/coda_linux.h | 6 -- fs/coda/dir.c| 6 ++ fs/coda/file.c | 17 + fs/coda/inode.c | 1 + fs/coda/psdev.c | 10 +- fs/coda/sysctl.c | 11 --- fs/coda/upcall.c | 38 +++--- 11 files changed, 55 insertions(+), 65 deletions(-) -- 2.4.11
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
On Thu, Oct 18, 2018 at 09:29:39PM -0700, Andy Lutomirski wrote: > > Another example is __BPF_PROG_RUN_ARRAY(), which also uses > > preempt_enable_no_resched(). > > Alexei, I think this code is just wrong. Do you know why it uses > preempt_enable_no_resched()? Yes, that's a straight up bug. It looks like I need to go fix up abuse again :/ > Oleg, the code in kernel/signal.c: > > preempt_disable(); > read_unlock(&tasklist_lock); > preempt_enable_no_resched(); > freezable_schedule(); > The purpose here is to avoid back-to-back schedule() calls, and this pattern is one of the few correct uses of preempt_enable_no_resched(). Suppose we got a preemption while holding the read_lock(), then when we'd do read_unlock(), we'd drop preempt_count to 0 and reschedule, then when we get back we instantly call into schedule _again_. What this code does, is it increments preempt_count such that read_unlock() doesn't hit 0 and doesn't call schedule, then we lower it to 0 without a call to schedule() and then call schedule() explicitly.
[PATCH 4/7 linux-next] coda: add __init to init_coda_psdev()
init_coda_psdev() was only called by __init function.
Signed-off-by: Fabian Frederick
---
fs/coda/psdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/coda/psdev.c b/fs/coda/psdev.c
index cbdddf4..6d1c95f 100644
--- a/fs/coda/psdev.c
+++ b/fs/coda/psdev.c
@@ -352,7 +352,7 @@ static const struct file_operations coda_psdev_fops = {
.llseek = noop_llseek,
};
-static int init_coda_psdev(void)
+static int __init init_coda_psdev(void)
{
int i, err = 0;
if (register_chrdev(CODA_PSDEV_MAJOR, "coda", &coda_psdev_fops)) {
--
2.4.11
[PATCH 2/7 linux-next] coda: destroy mutex in put_super()
we can safely destroy vc_mutex at the end of umount process.
Signed-off-by: Fabian Frederick
---
fs/coda/inode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/coda/inode.c b/fs/coda/inode.c
index dd819c1..69bb64d 100644
--- a/fs/coda/inode.c
+++ b/fs/coda/inode.c
@@ -244,6 +244,7 @@ static void coda_put_super(struct super_block *sb)
vcp->vc_sb = NULL;
sb->s_fs_info = NULL;
mutex_unlock(&vcp->vc_mutex);
+ mutex_destroy(&vcp->vc_mutex);
pr_info("Bye bye.\n");
}
--
2.4.11
[PATCH 7/7 linux-next] coda: ftoc validity check integration
This patch moves cfi check in coda_ftoc() instead of repeating
it in the wild.
Module size
textdata bss dec hex filename
282971040 700 300377555 fs/coda/coda.ko.before
28263 980 700 2994374f7 fs/coda/coda.ko.after
Signed-off-by: Fabian Frederick
---
fs/coda/cnode.c | 10 ++
fs/coda/coda_fs_i.h | 3 +--
fs/coda/dir.c | 6 ++
fs/coda/file.c | 17 +
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/fs/coda/cnode.c b/fs/coda/cnode.c
index c42d340..36414438 100644
--- a/fs/coda/cnode.c
+++ b/fs/coda/cnode.c
@@ -148,6 +148,16 @@ struct inode *coda_fid_to_inode(struct CodaFid *fid,
struct super_block *sb)
return inode;
}
+struct coda_file_info *coda_ftoc(struct file *file)
+{
+ struct coda_file_info *cfi = file->private_data;
+
+ BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
+
+ return cfi;
+
+}
+
/* the CONTROL inode is made without asking attributes from Venus */
struct inode *coda_cnode_makectl(struct super_block *sb)
{
diff --git a/fs/coda/coda_fs_i.h b/fs/coda/coda_fs_i.h
index d702ba1a..c99d574 100644
--- a/fs/coda/coda_fs_i.h
+++ b/fs/coda/coda_fs_i.h
@@ -42,8 +42,6 @@ struct coda_file_info {
unsigned int cfi_mapcount; /* nr of times this file is mapped */
};
-#define CODA_FTOC(file) ((struct coda_file_info *)((file)->private_data))
-
/* flags */
#define C_VATTR 0x1 /* Validity of vattr in inode */
#define C_FLUSH 0x2 /* used after a flush */
@@ -54,6 +52,7 @@ struct inode *coda_cnode_make(struct CodaFid *, struct
super_block *);
struct inode *coda_iget(struct super_block *sb, struct CodaFid *fid, struct
coda_vattr *attr);
struct inode *coda_cnode_makectl(struct super_block *sb);
struct inode *coda_fid_to_inode(struct CodaFid *fid, struct super_block *sb);
+struct coda_file_info *coda_ftoc(struct file *file);
void coda_replace_fid(struct inode *, struct CodaFid *, struct CodaFid *);
#endif
diff --git a/fs/coda/dir.c b/fs/coda/dir.c
index 00876dd..3e80770 100644
--- a/fs/coda/dir.c
+++ b/fs/coda/dir.c
@@ -356,8 +356,7 @@ static int coda_venus_readdir(struct file *coda_file,
struct dir_context *ctx)
ino_t ino;
int ret;
- cfi = CODA_FTOC(coda_file);
- BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
+ cfi = coda_ftoc(coda_file);
host_file = cfi->cfi_container;
cii = ITOC(file_inode(coda_file));
@@ -426,8 +425,7 @@ static int coda_readdir(struct file *coda_file, struct
dir_context *ctx)
struct file *host_file;
int ret;
- cfi = CODA_FTOC(coda_file);
- BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
+ cfi = coda_ftoc(coda_file);
host_file = cfi->cfi_container;
if (host_file->f_op->iterate || host_file->f_op->iterate_shared) {
diff --git a/fs/coda/file.c b/fs/coda/file.c
index 1cbc1f2..55c22e2 100644
--- a/fs/coda/file.c
+++ b/fs/coda/file.c
@@ -31,9 +31,7 @@ static ssize_t
coda_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
{
struct file *coda_file = iocb->ki_filp;
- struct coda_file_info *cfi = CODA_FTOC(coda_file);
-
- BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
+ struct coda_file_info *cfi = coda_ftoc(coda_file);
return vfs_iter_read(cfi->cfi_container, to, &iocb->ki_pos, 0);
}
@@ -43,12 +41,10 @@ coda_file_write_iter(struct kiocb *iocb, struct iov_iter
*to)
{
struct file *coda_file = iocb->ki_filp;
struct inode *coda_inode = file_inode(coda_file);
- struct coda_file_info *cfi = CODA_FTOC(coda_file);
+ struct coda_file_info *cfi = coda_ftoc(coda_file);
struct file *host_file;
ssize_t ret;
- BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
-
host_file = cfi->cfi_container;
file_start_write(host_file);
inode_lock(coda_inode);
@@ -69,8 +65,7 @@ coda_file_mmap(struct file *coda_file, struct vm_area_struct
*vma)
struct file *host_file;
struct inode *coda_inode, *host_inode;
- cfi = CODA_FTOC(coda_file);
- BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
+ cfi = coda_ftoc(coda_file);
host_file = cfi->cfi_container;
if (!host_file->f_op->mmap)
@@ -142,8 +137,7 @@ int coda_release(struct inode *coda_inode, struct file
*coda_file)
struct inode *host_inode;
int err;
- cfi = CODA_FTOC(coda_file);
- BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
+ cfi = coda_ftoc(coda_file);
err = venus_close(coda_inode->i_sb, coda_i2f(coda_inode),
coda_flags, coda_file->f_cred->fsuid);
@@ -185,8 +179,7 @@ int coda_fsync(struct file *coda_file, loff_t start, loff_t
end, int datasync)
return err;
inode_lock(coda_inode);
- cfi = CODA_FTOC(coda_file);
- BUG_ON(!cfi || cfi->cfi_magic != CODA_MAGIC);
+ cfi = coda_ftoc(coda_file);
host_file = cfi->cfi_co
[PATCH 3/7 linux-next] coda: use SIZE() for stat
max_t expression was already defined in coda sources Signed-off-by: Fabian Frederick --- fs/coda/upcall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/coda/upcall.c b/fs/coda/upcall.c index d0d0fed..1323793 100644 --- a/fs/coda/upcall.c +++ b/fs/coda/upcall.c @@ -553,7 +553,7 @@ int venus_statfs(struct dentry *dentry, struct kstatfs *sfs) union outputArgs *outp; int insize, outsize, error; - insize = max_t(unsigned int, INSIZE(statfs), OUTSIZE(statfs)); + insize = SIZE(statfs); UPARG(CODA_STATFS); error = coda_upcall(coda_vcp(dentry->d_sb), insize, &outsize, inp); -- 2.4.11
[PATCH 5/7 linux-next] coda: remove sysctl object from module when unused
Inspired by NFS sysctl process
Signed-off-by: Fabian Frederick
---
fs/coda/Makefile | 3 ++-
fs/coda/coda_int.h | 10 ++
fs/coda/coda_linux.h | 4
fs/coda/sysctl.c | 11 ---
4 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/fs/coda/Makefile b/fs/coda/Makefile
index 1bab69a..30e4e1b 100644
--- a/fs/coda/Makefile
+++ b/fs/coda/Makefile
@@ -5,7 +5,8 @@
obj-$(CONFIG_CODA_FS) += coda.o
coda-objs := psdev.o cache.o cnode.o inode.o dir.o file.o upcall.o \
-coda_linux.o symlink.o pioctl.o sysctl.o
+coda_linux.o symlink.o pioctl.o
+coda-$(CONFIG_SYSCTL) += sysctl.o
# If you want debugging output, please uncomment the following line.
diff --git a/fs/coda/coda_int.h b/fs/coda/coda_int.h
index bb0b3e0..f82b59c 100644
--- a/fs/coda/coda_int.h
+++ b/fs/coda/coda_int.h
@@ -13,9 +13,19 @@ extern int coda_fake_statfs;
void coda_destroy_inodecache(void);
int __init coda_init_inodecache(void);
int coda_fsync(struct file *coda_file, loff_t start, loff_t end, int datasync);
+
+#ifdef CONFIG_SYSCTL
void coda_sysctl_init(void);
void coda_sysctl_clean(void);
+#else
+static inline void coda_sysctl_init(void)
+{
+}
+static inline void coda_sysctl_clean(void)
+{
+}
+#endif
#endif /* _CODA_INT_ */
diff --git a/fs/coda/coda_linux.h b/fs/coda/coda_linux.h
index 903f2a3..4087264 100644
--- a/fs/coda/coda_linux.h
+++ b/fs/coda/coda_linux.h
@@ -59,10 +59,6 @@ void coda_vattr_to_iattr(struct inode *, struct coda_vattr
*);
void coda_iattr_to_vattr(struct iattr *, struct coda_vattr *);
unsigned short coda_flags_to_cflags(unsigned short);
-/* sysctl.h */
-void coda_sysctl_init(void);
-void coda_sysctl_clean(void);
-
#define CODA_ALLOC(ptr, cast, size) do { \
if (size < PAGE_SIZE) \
ptr = kzalloc((unsigned long) size, GFP_KERNEL); \
diff --git a/fs/coda/sysctl.c b/fs/coda/sysctl.c
index 0301d45..fda3b70 100644
--- a/fs/coda/sysctl.c
+++ b/fs/coda/sysctl.c
@@ -12,7 +12,6 @@
#include "coda_int.h"
-#ifdef CONFIG_SYSCTL
static struct ctl_table_header *fs_table_header;
static struct ctl_table coda_table[] = {
@@ -62,13 +61,3 @@ void coda_sysctl_clean(void)
fs_table_header = NULL;
}
}
-
-#else
-void coda_sysctl_init(void)
-{
-}
-
-void coda_sysctl_clean(void)
-{
-}
-#endif
--
2.4.11
[PATCH 6/7 linux-next] coda: remove sb test in coda_fid_to_inode()
coda_fid_to_inode() is only called by coda_downcall() where
sb is already being tested.
Signed-off-by: Fabian Frederick
---
fs/coda/cnode.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/coda/cnode.c b/fs/coda/cnode.c
index 845b5a6..c42d340 100644
--- a/fs/coda/cnode.c
+++ b/fs/coda/cnode.c
@@ -137,11 +137,6 @@ struct inode *coda_fid_to_inode(struct CodaFid *fid,
struct super_block *sb)
struct inode *inode;
unsigned long hash = coda_f2i(fid);
- if ( !sb ) {
- pr_warn("%s: no sb!\n", __func__);
- return NULL;
- }
-
inode = ilookup5(sb, hash, coda_test_inode, fid);
if ( !inode )
return NULL;
--
2.4.11
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
On Thu, Oct 18, 2018 at 10:00:53PM -0700, Alexei Starovoitov wrote: > > > > > > > > Another example is __BPF_PROG_RUN_ARRAY(), which also uses > > > preempt_enable_no_resched(). > > > > Alexei, I think this code is just wrong. > > why 'just wrong' ? Because you lost a preemption point, this is a no-no. > > > Do you know why it uses > > preempt_enable_no_resched()? > > dont recall precisely. > we could be preemptable at the point where macro is called. > I think the goal of no_resched was to avoid adding scheduling points > where they didn't exist before just because a prog ran for few nsec. > May be Daniel or Roman remember. No, you did the exact opposite, where there previously was a preemption, you just ate it. The band saw didn't get stopped in time, you loose your hand etc..
Re: [PATCH 2/5] arm64: dts: mediatek: mt6797: Add pinctrl support
On Thu, Oct 18, 2018 at 10:07:52PM +0800, Sean Wang wrote:
> On Tue, Oct 9, 2018 at 3:16 AM Manivannan Sadhasivam <
> manivannan.sadhasi...@linaro.org> wrote:
>
> > Add pinctrl support for Mediatek MT6797 SoC.
> >
> > Signed-off-by: Manivannan Sadhasivam
> > ---
> > arch/arm64/boot/dts/mediatek/mt6797.dtsi | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
> > b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
> > index 4beaa71107d7..231230d32d09 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt6797.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt6797.dtsi
> > @@ -14,6 +14,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > / {
> > compatible = "mediatek,mt6797";
> > @@ -129,6 +130,19 @@
> > #clock-cells = <1>;
> > };
> >
> > + pio: pinctrl@10005000 {
> > + compatible = "mediatek,mt6797-pinctrl";
> > + reg = <0 0x10005000 0 0x1000>,
> > + <0 0x10002000 0 0x400>,
> > + <0 0x10002400 0 0x400>,
> > + <0 0x10002800 0 0x400>,
> > + <0 0x10002C00 0 0x400>;
> > + reg-names = "gpio", "iocfgl", "iocfgb",
> > + "iocfgr", "iocfgt";
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + };
> > +
> >
>
> The content looks good to me, but the dt-binding document is still being
> added the support for MT6797 SoC before the dts instance is being applied.
>
>
Okay, will add a binding doc in next revision.
Thanks,
Mani
> > scpsys: scpsys@10006000 {
> > compatible = "mediatek,mt6797-scpsys";
> > #power-domain-cells = <1>;
> > --
> > 2.17.1
> >
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> >
Re: [PATCH] mm/sparse: remove a check that compare if unsigned variable is negative
On Sat, Oct 13, 2018 at 01:04:45PM -0400, Pavel Tatashin wrote: >This is incorrect: next_present_section_nr() returns "int" and -1 no >next section, this change would lead to infinite loop. Yes, the -1 is a very special value. -- Wei Yang Help you, Help me
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On 2018/10/19 4:50, Boris Brezillon wrote:
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
+static int meson_nfc_buffer_init(struct mtd_info *mtd)
+{
+ struct nand_chip *nand = mtd_to_nand(mtd);
+ struct meson_nfc *nfc = nand_get_controller_data(nand);
+ static int max_page_bytes, max_info_bytes;
+ int page_bytes, info_bytes;
+ int nsectors;
+
+ nsectors = mtd->writesize / nand->ecc.size;
+ page_bytes = mtd->writesize + mtd->oobsize;
+ info_bytes = nsectors * PER_INFO_BYTE;
+
+ if (nfc->data_buf && nfc->info_buf) {
+ if (max_page_bytes < page_bytes)
+ meson_nfc_free_buffer(nfc);
+ else
+ return 0;
+ }
+
+ max_page_bytes = max_t(int, max_page_bytes, page_bytes);
+ max_info_bytes = max_t(int, max_info_bytes, info_bytes);
+
+ nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
Is there a good reason for not using chip->data_buf and allocating a
new buffer here?
when calling read_oob or write_oob, i need a mid-buffer which is used in
meson_nfc_prase_data_oob(). i.e. after reading a page data into
nfc->data_buf, I will format it and transfer to chip->data_buf.
+ if (!nfc->data_buf)
+ return -ENOMEM;
+
+ nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
+ if (!nfc->info_buf) {
+ kfree(nfc->data_buf);
+ return -ENOMEM;
+ }
I'd recommend moving this info_buf in the priv chip struct, otherwise
you'll have to protect nfc->info_buf with a lock to prevent an already
register chip from using this pointer while you're reallocating the
buffer. Also, I think you have a memleak here.
ok, i will move it in the chip struct .
but how memleak happens even i have called meson_nfc_free_buffer before
and free data_buf if info_buf alloc faied.
+
+ return 0;
+}
.
[PATCH] jffs2: Fix use of uninitialized delayed_work, lockdep breakage
jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
is defined then a write buffer is available and has been initialized.
However, this does is not the case when the mtd device has no
out-of-band buffer:
int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
{
if (!c->mtd->oobsize)
return 0;
...
The resulting call to cancel_delayed_work_sync passing a uninitialized
(but zeroed) delayed_work struct forces lockdep to become disabled.
[ 90.050639] overlayfs: upper fs does not support tmpfile.
[ 90.652264] INFO: trying to register non-static key.
[ 90.662171] the code is fine but needs lockdep annotation.
[ 90.673090] turning off the locking correctness validator.
[ 90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
[ 90.696672] Stack : 80d8f6a2 0038 805f 80444600
8fe364f4 805dfbe7
[ 90.713349] 80563a30 06e2 8068370c 0001 0001
8e2fdc48
[ 90.730020] 80d9 0106
6465746e 312e3420
[ 90.746690] 6b636f6c 03bf f800 20676e69 8000
8e2c2a90
[ 90.763362] 80d9 0001 8e2c2a90 0003 80260dc0
08052098 8068
[ 90.780033] ...
[ 90.784902] Call Trace:
[ 90.789793] [<8000f0d8>] show_stack+0xb8/0x148
[ 90.798659] [<8005a000>] register_lock_class+0x270/0x55c
[ 90.809247] [<8005cb64>] __lock_acquire+0x13c/0xf7c
[ 90.818964] [<8005e314>] lock_acquire+0x194/0x1dc
[ 90.828345] [<8003f27c>] flush_work+0x200/0x24c
[ 90.837374] [<80041dfc>] __cancel_work_timer+0x158/0x210
[ 90.847958] [<801a8770>] jffs2_sync_fs+0x20/0x54
[ 90.857173] [<80125cf4>] iterate_supers+0xf4/0x120
[ 90.866729] [<80158fc4>] sys_sync+0x44/0x9c
[ 90.875067] [<80014424>] syscall_common+0x34/0x58
Signed-off-by: Daniel Santos
---
fs/jffs2/super.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c
index 793ad30970ff..cae4ecda3c50 100644
--- a/fs/jffs2/super.c
+++ b/fs/jffs2/super.c
@@ -101,7 +101,8 @@ static int jffs2_sync_fs(struct super_block *sb, int wait)
struct jffs2_sb_info *c = JFFS2_SB_INFO(sb);
#ifdef CONFIG_JFFS2_FS_WRITEBUFFER
- cancel_delayed_work_sync(&c->wbuf_dwork);
+ if (jffs2_is_writebuffered(c))
+ cancel_delayed_work_sync(&c->wbuf_dwork);
#endif
mutex_lock(&c->alloc_sem);
--
2.16.4
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On 2018/10/19 16:10, Boris Brezillon wrote:
On Fri, 19 Oct 2018 15:29:05 +0800
Liang Yang wrote:
How about defining that the HW returns an array of __le64 instead and then
define the following macros which you can use after converting in the
CPU endianness
#define ECC_GET_PROTECTED_OOB_BYTE(x, y)(((x) >> (8 * (1 + y)) &
GENMASK(7, 0))
#define ECC_COMPLETEBIT(31)
#define ECC_ERR_CNT(x) (((x) >> 24) & GENMASK(5, 0))
(I'm not entirely sure the field positions are correct, but I'll let you
check that).
ok. i think it should be:
#define ECC_GET_PROTECTED_OOB_BYTE(x, y)(((x) >> (8 * y) &
GENMASK(7, 0))
if x represents the u64 and y represents the index of the u64.
Absolutely.
+
+#define PER_INFO_BYTE (sizeof(struct meson_nfc_info_format))
+
+struct meson_nfc_nand_chip {
+ struct list_head node;
+ struct nand_chip nand;
+ bool is_scramble;
I think I already mentioned the NAND_NEED_SCRAMBLING flag []. Please
drop this field and test (chip->flags & NAND_NEED_SCRAMBLING) instead.
em, i use NAND_NEED_SCRAMBLING and is_scramble is set:
static int meson_nand_attach_chip(struct nand_chip *nand)
{
..
meson_chip->is_scramble =
(nand->options & NAND_NEED_SCRAMBLING) ? 1 : 0;
..
}
Why do you need to add a new field then? Just test
nand->options & NAND_NEED_SCRAMBLING directly or provide a helper
function that does that.
ok, i will fix it.
.
Re: [PATCH v2 2/2] drm/exynos: decon: Make pixel blend mode configurable
Hi Christoph,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on v4.19-rc8 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Christoph-Manszewski/drm-exynos-decon-Make-plane-alpha-configurable/20181019-053544
base: https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
exynos-drm-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm64
All errors (new ones prefixed by >>):
drivers/gpu/drm/exynos/exynos5433_drm_decon.c: In function
'decon_win_set_pixfmt':
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c:337:3: error: 'pixel_alpha'
>> undeclared (first use in this function); did you mean 'isalpha'?
pixel_alpha = state->base.pixel_blend_mode;
^~~
isalpha
drivers/gpu/drm/exynos/exynos5433_drm_decon.c:337:3: note: each undeclared
identifier is reported only once for each function it appears in
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c:385:3: error: too few
>> arguments to function 'decon_win_set_bldmod'
decon_win_set_bldmod(ctx, win, alpha);
^~~~
drivers/gpu/drm/exynos/exynos5433_drm_decon.c:298:13: note: declared here
static void decon_win_set_bldmod(struct decon_context *ctx, unsigned int
win,
^~~~
vim +337 drivers/gpu/drm/exynos/exynos5433_drm_decon.c
326
327 static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned
int win,
328 struct drm_framebuffer *fb)
329 {
330 struct exynos_drm_plane plane = ctx->planes[win];
331 struct exynos_drm_plane_state *state =
332 to_exynos_plane_state(plane.base.state);
333 unsigned int alpha = state->base.alpha;
334 unsigned long val;
335
336 if (fb->format->has_alpha)
> 337 pixel_alpha = state->base.pixel_blend_mode;
338 else
339 pixel_alpha = DRM_MODE_BLEND_PIXEL_NONE;
340
341 val = readl(ctx->addr + DECON_WINCONx(win));
342 val &= WINCONx_ENWIN_F;
343
344 switch (fb->format->format) {
345 case DRM_FORMAT_XRGB1555:
346 val |= WINCONx_BPPMODE_16BPP_I1555;
347 val |= WINCONx_HAWSWP_F;
348 val |= WINCONx_BURSTLEN_16WORD;
349 break;
350 case DRM_FORMAT_RGB565:
351 val |= WINCONx_BPPMODE_16BPP_565;
352 val |= WINCONx_HAWSWP_F;
353 val |= WINCONx_BURSTLEN_16WORD;
354 break;
355 case DRM_FORMAT_XRGB:
356 val |= WINCONx_BPPMODE_24BPP_888;
357 val |= WINCONx_WSWP_F;
358 val |= WINCONx_BURSTLEN_16WORD;
359 break;
360 case DRM_FORMAT_ARGB:
361 default:
362 val |= WINCONx_BPPMODE_32BPP_A;
363 val |= WINCONx_WSWP_F;
364 val |= WINCONx_BURSTLEN_16WORD;
365 break;
366 }
367
368 DRM_DEBUG_KMS("cpp = %u\n", fb->format->cpp[0]);
369
370 /*
371 * In case of exynos, setting dma-burst to 16Word causes
permanent
372 * tearing for very small buffers, e.g. cursor buffer. Burst
Mode
373 * switching which is based on plane size is not recommended as
374 * plane size varies a lot towards the end of the screen and
rapid
375 * movement causes unstable DMA which results into iommu
crash/tear.
376 */
377
378 if (fb->width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
379 val &= ~WINCONx_BURSTLEN_MASK;
380 val |= WINCONx_BURSTLEN_8WORD;
381 }
382 decon_set_bits(ctx, DECON_WINCONx(win),
~WINCONx_BLEND_MODE_MASK, val);
383
384 if (win > 0) {
> 385 decon_win_set_bldmod(ctx, win, alpha);
386 decon_win_set_bldeq(ctx, win, alpha, pixel_alpha);
387 }
388 }
389
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC PATCH 1/5] x86: introduce preemption disable prefix
On Fri, Oct 19, 2018 at 01:08:23AM +, Nadav Amit wrote:
> Consider for example do_int3(), and see my inlined comments:
>
> dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
> {
> ...
> ist_enter(regs);// => preempt_disable()
> cond_local_irq_enable(regs);// => assume it enables IRQs
>
> ...
> // resched irq can be delivered here. It will not caused rescheduling
> // since preemption is disabled
>
> cond_local_irq_disable(regs); // => assume it disables IRQs
> ist_exit(regs); // => preempt_enable_no_resched()
> }
>
> At this point resched will not happen for unbounded length of time (unless
> there is another point when exiting the trap handler that checks if
> preemption should take place).
>
> Another example is __BPF_PROG_RUN_ARRAY(), which also uses
> preempt_enable_no_resched().
>
> Am I missing something?
Would not the interrupt return then check for TIF_NEED_RESCHED and call
schedule() ?
I think (and this certainly wants a comment) is that the ist_exit()
thing hard relies on the interrupt-return path doing the reschedule.
[PATCH 3/3] nvmem: zynqmp: Added zynqmp nvmem firmware driver
This patch adds zynqmp nvmem firmware driver to access the
SoC revision information from the hardware register.
Signed-off-by: Nava kishore Manne
---
Changes for v1:
-None
Changes for RFC-V3:
-Changed nvmem_register() to devm_nvmem_register()
and pr_debug() to dev_dbg() as suggested by srinivas.
Changes for RFC-V2:
-None.
drivers/nvmem/Kconfig| 15
drivers/nvmem/Makefile | 5 +--
drivers/nvmem/zynqmp_nvmem.c | 86
3 files changed, 96 insertions(+), 10 deletions(-)
create mode 100644 drivers/nvmem/zynqmp_nvmem.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 0a7a470e..2edb142 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -181,15 +181,14 @@ config RAVE_SP_EEPROM
help
Say y here to enable Rave SP EEPROM support.
-config SC27XX_EFUSE
- tristate "Spreadtrum SC27XX eFuse Support"
- depends on MFD_SC27XX_PMIC || COMPILE_TEST
- depends on HAS_IOMEM
+config NVMEM_ZYNQMP
+ bool "Xilinx ZYNQMP SoC nvmem firmware support"
+ depends on ARCH_ZYNQMP
help
- This is a simple driver to dump specified values of Spreadtrum
- SC27XX PMICs from eFuse.
+ This is a driver to access hardware related data like
+ soc revision, IDCODE... etc by using the firmware
+ interface.
- This driver can also be built as a module. If so, the module
- will be called nvmem-sc27xx-efuse.
+ If sure, say yes. If unsure, say no.
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 4e8c616..0b3abd7 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -39,5 +39,6 @@ obj-$(CONFIG_NVMEM_SNVS_LPGPR)+= nvmem_snvs_lpgpr.o
nvmem_snvs_lpgpr-y := snvs_lpgpr.o
obj-$(CONFIG_RAVE_SP_EEPROM) += nvmem-rave-sp-eeprom.o
nvmem-rave-sp-eeprom-y := rave-sp-eeprom.o
-obj-$(CONFIG_SC27XX_EFUSE) += nvmem-sc27xx-efuse.o
-nvmem-sc27xx-efuse-y := sc27xx-efuse.o
+obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
+nvmem_zynqmp_nvmem-y := zynqmp_nvmem.o
+
diff --git a/drivers/nvmem/zynqmp_nvmem.c b/drivers/nvmem/zynqmp_nvmem.c
new file mode 100644
index 000..b910864
--- /dev/null
+++ b/drivers/nvmem/zynqmp_nvmem.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define SILICON_REVISION_MASK 0xF
+
+struct zynqmp_nvmem_data {
+ struct device *dev;
+ struct nvmem_device *nvmem;
+};
+
+static int zynqmp_nvmem_read(void *context, unsigned int offset,
+void *val, size_t bytes)
+{
+ int ret;
+ int idcode, version;
+ struct zynqmp_nvmem_data *priv = context;
+
+ const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+ if (!eemi_ops || !eemi_ops->get_chipid)
+ return -ENXIO;
+
+ ret = eemi_ops->get_chipid(&idcode, &version);
+ if (ret < 0)
+ return ret;
+
+ dev_dbg(priv->dev, "Read chipid val %x %x\n", idcode, version);
+ *(int *)val = version & SILICON_REVISION_MASK;
+
+ return 0;
+}
+
+static struct nvmem_config econfig = {
+ .name = "zynqmp-nvmem",
+ .owner = THIS_MODULE,
+ .word_size = 1,
+ .size = 1,
+ .read_only = true,
+};
+
+static const struct of_device_id zynqmp_nvmem_match[] = {
+ { .compatible = "xlnx,zynqmp-nvmem-fw", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, zynqmp_nvmem_match);
+
+static int zynqmp_nvmem_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct zynqmp_nvmem_data *priv;
+
+ priv = devm_kzalloc(dev, sizeof(struct zynqmp_nvmem_data), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = dev;
+ econfig.dev = dev;
+ econfig.reg_read = zynqmp_nvmem_read;
+ econfig.priv = priv;
+
+ priv->nvmem = devm_nvmem_register(dev, &econfig);
+
+ return PTR_ERR_OR_ZERO(priv->nvmem);
+}
+
+static struct platform_driver zynqmp_nvmem_driver = {
+ .probe = zynqmp_nvmem_probe,
+ .driver = {
+ .name = "zynqmp-nvmem",
+ .of_match_table = zynqmp_nvmem_match,
+ },
+};
+
+module_platform_driver(zynqmp_nvmem_driver);
+
+MODULE_AUTHOR("Michal Simek , Nava kishore Manne
");
+MODULE_DESCRIPTION("ZynqMP NVMEM driver");
+MODULE_LICENSE("GPL");
--
2.7.4
Re: [PATCH] coresight: tmc: Fix bad register address for CLAIM
Hi Leo,
On 10/19/2018 05:56 AM, Leo Yan wrote:
Commit 4d3ebd3658d8 ("coreisght: tmc: Claim device before use") uses
CLAIM tag to validate if the device is available, it needs to pass
the device base address to access related registers.
In the function tmc_etb_disable_hw() it wrongly passes the driver data
pointer as register base address, thus it's easily to produce the kernel
warning info like below:
[ 83.579898] WARNING: CPU: 4 PID: 2970 at
drivers/hwtracing/coresight/coresight.c:207
coresight_disclaim_device_unlocked+0x44/0x80
[ 83.591448] Modules linked in:
[ 83.594485] CPU: 4 PID: 2970 Comm: uname Not tainted
4.19.0-rc6-00417-g721b509 #110
Oops! Thanks for fixing !
This patch is to fix this bug by using 'drvdata->base' as the
register base address for CLAIM related operation.
Fixes: 4d3ebd3658d8 ("coreisght: tmc: Claim device before use")
Cc: Suzuki Poulose
Cc: Mathieu Poirier
Cc: Mike Leach
Cc: Robert Walker
Signed-off-by: Leo Yan
Reviewed-by: Suzuki K Poulose
---
drivers/hwtracing/coresight/coresight-tmc-etf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c
b/drivers/hwtracing/coresight/coresight-tmc-etf.c
index 53fc83b..5864ac5 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
@@ -86,7 +86,7 @@ static void __tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
{
- coresight_disclaim_device(drvdata);
+ coresight_disclaim_device(drvdata->base);
__tmc_etb_disable_hw(drvdata);
}
[PATCH 0/3] Add nvmem driver support for ZynqMP
This series of patches are created On top of the below repo //git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git BRANCH: next/drivers Nava kishore Manne (3): firmware: xilinx: Add zynqmp_pm_get_chipid() API dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver nvmem: zynqmp: Added zynqmp nvmem firmware driver .../bindings/nvmem/xlnx,zynqmp-nvmem.txt | 37 ++ drivers/firmware/xilinx/zynqmp.c | 24 ++ drivers/nvmem/Kconfig | 15 ++-- drivers/nvmem/Makefile | 5 +- drivers/nvmem/zynqmp_nvmem.c | 86 ++ include/linux/firmware/xlnx-zynqmp.h | 2 + 6 files changed, 159 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt create mode 100644 drivers/nvmem/zynqmp_nvmem.c -- 2.7.4
[PATCH 2/3] dt-bindings: nvmem: Add bindings for ZynqMP nvmem driver
Add documentation to describe Xilinx ZynqMP nvmem driver
bindings.
Signed-off-by: Nava kishore Manne
---
Changes for v1:
Created a Seperate(New) DT binding file as
suggested by Rob.
Changes for RFC-V3:
-None.
Changes for RFC-V2:
-Moved nvmem_firmware node as a child to
firwmare node.
.../bindings/nvmem/xlnx,zynqmp-nvmem.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644
Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
diff --git a/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
new file mode 100644
index 000..0bafb9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/xlnx,zynqmp-nvmem.txt
@@ -0,0 +1,37 @@
+--
+= Zynq UltraScale+ MPSoC nvmem firmware driver binding =
+--
+The nvmem_firmware node provides access to the hardware related data
+like soc revision, IDCODE... etc, By using the firmware interface.
+
+Required properties:
+- compatible: should be "xlnx,zynqmp-nvmem-fw"
+
+= Data cells =
+Are child nodes of silicon id, bindings of which as described in
+bindings/nvmem/nvmem.txt
+
+---
+ Example
+---
+ nvmem_firmware {
+ compatible = "xlnx,zynqmp-nvmem-fw";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ /* Data cells */
+ soc_revision: soc_revision {
+ reg = <0x0 0x4>;
+ };
+ };
+
+= Data consumers =
+Are device nodes which consume nvmem data cells.
+
+For example:
+ pcap {
+ ...
+ nvmem-cells = <&soc_revision>;
+ nvmem-cell-names = "soc_revision";
+ };
+
--
2.7.4
[PATCH 1/3] firmware: xilinx: Add zynqmp_pm_get_chipid() API
This patch adds a new API to provide access to the
hardware related data like soc revision, IDCODE... etc.
Signed-off-by: Nava kishore Manne
---
Changes for v1:
-None.
Changes for RFC-V3:
-corrected typo error in commit msg.
Changes for RFC-v2:
-New Patch.
drivers/firmware/xilinx/zynqmp.c | 24
include/linux/firmware/xlnx-zynqmp.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 84b3fd2..e76c889 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -187,6 +187,29 @@ static int zynqmp_pm_get_api_version(u32 *version)
}
/**
+ * zynqmp_pm_get_chipid - Get silicon ID registers
+ * @idcode: IDCODE register
+ * @version:version register
+ *
+ * Return: Returns the status of the operation and the idcode and version
+ * registers in @idcode and @version.
+ */
+static int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!idcode || !version)
+ return -EINVAL;
+
+ ret = zynqmp_pm_invoke_fn(PM_GET_CHIPID, 0, 0, 0, 0, ret_payload);
+ *idcode = ret_payload[1];
+ *version = ret_payload[2];
+
+ return ret;
+}
+
+/**
* zynqmp_pm_get_trustzone_version() - Get secure trustzone firmware version
* @version: Returned version value
*
@@ -430,6 +453,7 @@ static int zynqmp_pm_clock_getparent(u32 clock_id, u32
*parent_id)
static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
+ .get_chipid = zynqmp_pm_get_chipid,
.query_data = zynqmp_pm_query_data,
.clock_enable = zynqmp_pm_clock_enable,
.clock_disable = zynqmp_pm_clock_disable,
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 015e130..1d3126d 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -34,6 +34,7 @@
enum pm_api_id {
PM_GET_API_VERSION = 1,
+ PM_GET_CHIPID = 22,
PM_QUERY_DATA = 35,
PM_CLOCK_ENABLE,
PM_CLOCK_DISABLE,
@@ -89,6 +90,7 @@ struct zynqmp_pm_query_data {
struct zynqmp_eemi_ops {
int (*get_api_version)(u32 *version);
+ int (*get_chipid)(u32 *idcode, u32 *version);
int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
int (*clock_enable)(u32 clock_id);
int (*clock_disable)(u32 clock_id);
--
2.7.4
[PATCH 3/3] reset: reset-zynqmp: Adding support for Xilinx zynqmp reset controller.
Add a reset controller driver for Xilinx Zynq UltraScale+ MPSoC.
The zynqmp reset-controller has the ability to reset lines
connected to different blocks and peripheral in the Soc.
Signed-off-by: Nava kishore Manne
---
Changes for v1:
-None.
Changes for RFC-V3:
-None.
Changes for RFC-V2:
-Moved eemi_ops into a priv struct as suggested
by philipp.
drivers/reset/Makefile | 1 +
drivers/reset/reset-zynqmp.c | 117 +++
2 files changed, 118 insertions(+)
create mode 100644 drivers/reset/reset-zynqmp.c
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 4243c38228e2..eb315d14a520 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -24,4 +24,5 @@ obj-$(CONFIG_RESET_TI_SYSCON) += reset-ti-syscon.o
obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
obj-$(CONFIG_RESET_UNIPHIER_USB3) += reset-uniphier-usb3.o
obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
+obj-$(CONFIG_ARCH_ZYNQMP) += reset-zynqmp.o
diff --git a/drivers/reset/reset-zynqmp.c b/drivers/reset/reset-zynqmp.c
new file mode 100644
index ..9528fa3894fc
--- /dev/null
+++ b/drivers/reset/reset-zynqmp.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Xilinx, Inc.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ZYNQMP_NR_RESETS (ZYNQMP_PM_RESET_END - ZYNQMP_PM_RESET_START - 2)
+#define ZYNQMP_RESET_ID (ZYNQMP_PM_RESET_START + 1)
+
+struct zynqmp_reset_data {
+ struct reset_controller_dev rcdev;
+ const struct zynqmp_eemi_ops *eemi_ops;
+};
+
+static inline struct zynqmp_reset_data *
+to_zynqmp_reset_data(struct reset_controller_dev *rcdev)
+{
+ return container_of(rcdev, struct zynqmp_reset_data, rcdev);
+}
+
+static int zynqmp_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
+
+ return priv->eemi_ops->reset_assert(ZYNQMP_RESET_ID + id,
+ PM_RESET_ACTION_ASSERT);
+}
+
+static int zynqmp_reset_deassert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+ struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
+
+ return priv->eemi_ops->reset_assert(ZYNQMP_RESET_ID + id,
+ PM_RESET_ACTION_RELEASE);
+}
+
+static int zynqmp_reset_status(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
+ int val, err;
+
+ err = priv->eemi_ops->reset_get_status(ZYNQMP_RESET_ID + id, &val);
+ if (!err)
+ return -EINVAL;
+
+ return val;
+}
+
+static int zynqmp_reset_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
+
+ return priv->eemi_ops->reset_assert(ZYNQMP_RESET_ID + id,
+ PM_RESET_ACTION_PULSE);
+}
+
+static struct reset_control_ops zynqmp_reset_ops = {
+ .reset = zynqmp_reset_reset,
+ .assert = zynqmp_reset_assert,
+ .deassert = zynqmp_reset_deassert,
+ .status = zynqmp_reset_status,
+};
+
+static int zynqmp_reset_probe(struct platform_device *pdev)
+{
+ struct zynqmp_reset_data *priv;
+
+ priv = devm_kzalloc(&pdev->dev,
+ sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+
+ priv->eemi_ops = zynqmp_pm_get_eemi_ops();
+ if (!priv->eemi_ops)
+ return -ENXIO;
+
+ priv->rcdev.ops = &zynqmp_reset_ops;
+ priv->rcdev.owner = THIS_MODULE;
+ priv->rcdev.of_node = pdev->dev.of_node;
+ priv->rcdev.nr_resets = ZYNQMP_NR_RESETS;
+
+ return devm_reset_controller_register(&pdev->dev, &priv->rcdev);
+}
+
+static const struct of_device_id zynqmp_reset_dt_ids[] = {
+ { .compatible = "xlnx,zynqmp-reset", },
+ { /* sentinel */ },
+};
+
+static struct platform_driver zynqmp_reset_driver = {
+ .probe = zynqmp_reset_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = zynqmp_reset_dt_ids,
+ },
+};
+
+static int __init zynqmp_reset_init(void)
+{
+ return platform_driver_register(&zynqmp_reset_driver);
+}
+
+arch_initcall(zynqmp_reset_init);
--
2.18.0
[PATCH 1/3] firmware: xilinx: Add reset API's
This Patch Adds reset API's to support release, assert
and status functionalities by using firmware interface.
Signed-off-by: Nava kishore Manne
---
Changes for v1:
-None.
Changes for RFC-V3:
-None.
Changes for RFC-V2:
-New Patch.
drivers/firmware/xilinx/zynqmp.c | 40
include/linux/firmware/xlnx-zynqmp.h | 136 +++
2 files changed, 176 insertions(+)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 84b3fd2eca8b..cd13b0686dda 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -428,6 +428,44 @@ static int zynqmp_pm_clock_getparent(u32 clock_id, u32
*parent_id)
return ret;
}
+/**
+ * zynqmp_pm_reset_assert - Request setting of reset (1 - assert, 0 - release)
+ * @reset: Reset to be configured
+ * @assert_flag: Flag stating should reset be asserted (1) or
+ * released (0)
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_reset_assert(const enum zynqmp_pm_reset reset,
+ const enum zynqmp_pm_reset_action assert_flag)
+{
+ return zynqmp_pm_invoke_fn(PM_RESET_ASSERT, reset, assert_flag,
+ 0, 0, NULL);
+}
+
+/**
+ * zynqmp_pm_reset_get_status - Get status of the reset
+ * @reset: Reset whose status should be returned
+ * @status: Returned status
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_reset_get_status(const enum zynqmp_pm_reset reset,
+ u32 *status)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!status)
+ return -EINVAL;
+
+ ret = zynqmp_pm_invoke_fn(PM_RESET_GET_STATUS, reset, 0,
+ 0, 0, ret_payload);
+ *status = ret_payload[1];
+
+ return ret;
+}
+
static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -440,6 +478,8 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_getrate = zynqmp_pm_clock_getrate,
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
+ .reset_assert = zynqmp_pm_reset_assert,
+ .reset_get_status = zynqmp_pm_reset_get_status,
};
/**
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 015e130431e6..29d83cacac6f 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -34,6 +34,8 @@
enum pm_api_id {
PM_GET_API_VERSION = 1,
+ PM_RESET_ASSERT = 17,
+ PM_RESET_GET_STATUS,
PM_QUERY_DATA = 35,
PM_CLOCK_ENABLE,
PM_CLOCK_DISABLE,
@@ -73,6 +75,137 @@ enum pm_query_id {
PM_QID_CLOCK_GET_ATTRIBUTES,
};
+enum zynqmp_pm_reset_action {
+ PM_RESET_ACTION_RELEASE,
+ PM_RESET_ACTION_ASSERT,
+ PM_RESET_ACTION_PULSE,
+};
+
+enum zynqmp_pm_reset {
+ ZYNQMP_PM_RESET_START = 999,
+ ZYNQMP_PM_RESET_PCIE_CFG,
+ ZYNQMP_PM_RESET_PCIE_BRIDGE,
+ ZYNQMP_PM_RESET_PCIE_CTRL,
+ ZYNQMP_PM_RESET_DP,
+ ZYNQMP_PM_RESET_SWDT_CRF,
+ ZYNQMP_PM_RESET_AFI_FM5,
+ ZYNQMP_PM_RESET_AFI_FM4,
+ ZYNQMP_PM_RESET_AFI_FM3,
+ ZYNQMP_PM_RESET_AFI_FM2,
+ ZYNQMP_PM_RESET_AFI_FM1,
+ ZYNQMP_PM_RESET_AFI_FM0,
+ ZYNQMP_PM_RESET_GDMA,
+ ZYNQMP_PM_RESET_GPU_PP1,
+ ZYNQMP_PM_RESET_GPU_PP0,
+ ZYNQMP_PM_RESET_GPU,
+ ZYNQMP_PM_RESET_GT,
+ ZYNQMP_PM_RESET_SATA,
+ ZYNQMP_PM_RESET_ACPU3_PWRON,
+ ZYNQMP_PM_RESET_ACPU2_PWRON,
+ ZYNQMP_PM_RESET_ACPU1_PWRON,
+ ZYNQMP_PM_RESET_ACPU0_PWRON,
+ ZYNQMP_PM_RESET_APU_L2,
+ ZYNQMP_PM_RESET_ACPU3,
+ ZYNQMP_PM_RESET_ACPU2,
+ ZYNQMP_PM_RESET_ACPU1,
+ ZYNQMP_PM_RESET_ACPU0,
+ ZYNQMP_PM_RESET_DDR,
+ ZYNQMP_PM_RESET_APM_FPD,
+ ZYNQMP_PM_RESET_SOFT,
+ ZYNQMP_PM_RESET_GEM0,
+ ZYNQMP_PM_RESET_GEM1,
+ ZYNQMP_PM_RESET_GEM2,
+ ZYNQMP_PM_RESET_GEM3,
+ ZYNQMP_PM_RESET_QSPI,
+ ZYNQMP_PM_RESET_UART0,
+ ZYNQMP_PM_RESET_UART1,
+ ZYNQMP_PM_RESET_SPI0,
+ ZYNQMP_PM_RESET_SPI1,
+ ZYNQMP_PM_RESET_SDIO0,
+ ZYNQMP_PM_RESET_SDIO1,
+ ZYNQMP_PM_RESET_CAN0,
+ ZYNQMP_PM_RESET_CAN1,
+ ZYNQMP_PM_RESET_I2C0,
+ ZYNQMP_PM_RESET_I2C1,
+ ZYNQMP_PM_RESET_TTC0,
+ ZYNQMP_PM_RESET_TTC1,
+ ZYNQMP_PM_RESET_TTC2,
+ ZYNQMP_PM_RESET_TTC3,
+ ZYNQMP_PM_RESET_SWDT_CRL,
+ ZYNQMP_PM_RESET_NAND,
+ ZYNQMP_PM_RESET_ADMA,
+ ZYNQMP_PM_RESET_GPIO,
+ ZYNQMP_PM_RESET_IOU_CC,
+ ZYNQMP_PM_RESET_TIMESTAMP,
+ ZYNQMP_PM_RESET_RPU_R50,
+ ZYNQMP_PM_RESET_RPU_R51,
+ ZYNQMP_PM_RESET_RPU_AMBA,
+ ZYNQMP_
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On Fri, 19 Oct 2018 16:29:40 +0800
Liang Yang wrote:
> On 2018/10/19 4:50, Boris Brezillon wrote:
> > On Thu, 18 Oct 2018 13:09:05 +0800
> > Jianxin Pan wrote:
> >
> >> +static int meson_nfc_buffer_init(struct mtd_info *mtd)
> >> +{
> >> + struct nand_chip *nand = mtd_to_nand(mtd);
> >> + struct meson_nfc *nfc = nand_get_controller_data(nand);
> >> + static int max_page_bytes, max_info_bytes;
> >> + int page_bytes, info_bytes;
> >> + int nsectors;
> >> +
> >> + nsectors = mtd->writesize / nand->ecc.size;
> >> + page_bytes = mtd->writesize + mtd->oobsize;
> >> + info_bytes = nsectors * PER_INFO_BYTE;
> >> +
> >> + if (nfc->data_buf && nfc->info_buf) {
> >> + if (max_page_bytes < page_bytes)
> >> + meson_nfc_free_buffer(nfc);
> >> + else
> >> + return 0;
> >> + }
> >> +
> >> + max_page_bytes = max_t(int, max_page_bytes, page_bytes);
> >> + max_info_bytes = max_t(int, max_info_bytes, info_bytes);
> >> +
> >> + nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
> >
> > Is there a good reason for not using chip->data_buf and allocating a
> > new buffer here?
> >
> when calling read_oob or write_oob, i need a mid-buffer which is used in
> meson_nfc_prase_data_oob(). i.e. after reading a page data into
> nfc->data_buf, I will format it and transfer to chip->data_buf.
>
>
> >> + if (!nfc->data_buf)
> >> + return -ENOMEM;
> >> +
> >> + nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
> >> + if (!nfc->info_buf) {
> >> + kfree(nfc->data_buf);
> >> + return -ENOMEM;
> >> + }
> >
> > I'd recommend moving this info_buf in the priv chip struct, otherwise
> > you'll have to protect nfc->info_buf with a lock to prevent an already
> > register chip from using this pointer while you're reallocating the
> > buffer. Also, I think you have a memleak here.
> >
> ok, i will move it in the chip struct .
>
> but how memleak happens even i have called meson_nfc_free_buffer before
> and free data_buf if info_buf alloc faied.
You're right, I missed the call to meson_nfc_free_buffer() when
max_page_bytes < page_bytes. Still, this part is racy, just like the
nfc->data_buf replacement is if you have several NAND chips. I'd
recommend moving those bufs to the priv chip struct.
>
> >> +
> >> + return 0;
> >> +}
> >
> > .
> >
[PATCH 2/3] dt-bindings: reset: Add bindings for ZynqMP reset driver
Add documentation to describe Xilinx ZynqMP reset driver bindings. Signed-off-by: Nava kishore Manne --- Changes for v1: -Created a Seperate(New) DT binding file as suggested by Rob. Changes for RFC-V3: -Corrected Commit Msg. Changes for RFC-V2: -Moved reset node as a child to firwmare node. .../bindings/reset/xlnx,zynqmp-reset.txt | 146 ++ 1 file changed, 146 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt diff --git a/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt new file mode 100644 index ..c42b6a274597 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt @@ -0,0 +1,146 @@ +-- + = Zynq UltraScale+ MPSoC reset driver binding = +-- +The Zynq UltraScale+ MPSoC has several different resets. + +See Chapter 36 of the Zynq UltraScale+ MPSoC TRM (UG) for more information +about zynqmp resets. + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +Required Properties: +- compatible: "xlnx,zynqmp-reset" +- #reset-cells:Specifies the number of cells needed to encode reset + line, should be 1 + +Reset outputs: + 0 :PCIE config reset. + 1 :PCIE bridge block level reset (AXI interface). + 2 :PCIE control block level,reset. + 3 :Display Port block level reset (includes DPDMA). + 4 :FPD WDT reset. + 5 :AF_FM5 block level reset. + 6 :AF_FM4 block level reset. + 7 :AF_FM3 block level reset. + 8 :AF_FM2 block level reset. + 9 :AF_FM1 block level reset. + 10 :AF_FM0 block level reset. + 11 :GDMA block level reset. + 12 :Pixel Processor (GPU_PP1) block level reset. + 13 :Pixel Processor (GPU_PP0) block level reset. + 14 :GPU block level reset. + 15 :GT block level reset. + 16 :Sata block level reset. + 17 :ACPU3 power on reset. + 18 :ACPU2 power on reset. + 19 :ACPU1 power on reset. + 20 :ACPU0 power on reset. + 21 :APU L2 reset. + 22 :ACPU3 reset. + 23 :ACPU2 reset. + 24 :ACPU1 reset. + 25 :ACPU0 reset. + 26 :DDR block level reset inside of the DDR Sub System. + 27 :APM block level reset inside of the DDR Sub System. + 28 :soft reset. + 29 :GEM 0 reset. + 30 :GEM 1 reset. + 31 :GEM 2 reset. + 32 :GEM 3 reset. + 33 :qspi reset. + 34 :uart0 reset. + 35 :uart1 reset. + 36 :spi0 reset. + 37 :spi1 reset. + 38 :sdio0 reset. + 39 :sdio1 reset. + 40 :can0 reset. + 41 :can1 reset. + 42 :i2c0 reset. + 43 :i2c1 reset. + 44 :ttc0 reset. + 45 :ttc1 reset. + 46 :ttc2 reset. + 47 :ttc3 reset. + 48 :swdt reset. + 49 :nand reset. + 50 :adma reset. + 51 :gpio reset. + 52 :iou_cc reset. + 53 :timestamp reset. + 54 :rpu_r50 reset. + 55 :rpu r51 reset. + 56 :rpu_amba reset. + 57 :ocm reset. + 58 :rpu_pge reset. + 59 :usb0_core reset. + 60 :usb1_core reset. + 61 :usb0_hiber reset. + 62 :usb1_hiber reset. + 63 :usb0_apb reset. + 64 :usb1_apb reset. + 65 :ipi reset. + 66 :apm reset. + 67 :rtc reset. + 68 :sysmon reset. + 69 :afi_fm6 reset. + 70 :lpd_swdt reset. + 71 :fpd_reset. + 72 :rpu_dbg1 reset. + 73 :rpu_dbg0 reset. + 74 :dbg_lpd reset. + 75 :dbg_fpd reset. + 76 :apll reset. + 77 :dpll reset. + 78 :vpll reset. + 79 :iopll reset. + 80 :rpll reset. + 81 :gpio_pl_0 reset. + 82 :gpio_pl_1 reset. + 83 :gpio_pl_2 reset. + 84 :gpio_pl_3 reset. + 85 :gpio_pl_4 reset. + 86 :gpio_pl_5 reset. + 87 :gpio_pl_6 reset. + 88 :gpio_pl_7 reset. + 89 :gpio_pl_8 reset. + 90 :gpio_pl_9 reset. + 91 :gpio_pl_10 reset. + 92 :gpio_pl_11 reset. + 93 :gpio_pl_12 reset. + 94 :gpio_pl_13 reset. + 95 :gpio_pl_14 reset. + 96 :gpio_pl_15 reset. + 97 :gpio_pl_16 reset. + 98 :gpio_pl_17 reset. + 99 :gpio_pl_18 reset. + 100 :gpio_pl_19 reset. + 101 :gpio_pl_20 reset. + 102 :gpio_pl_21 reset. + 103 :gpio_pl_22 reset. + 104 :gpio_pl_23 reset. + 105 :gpio_pl_24 reset. + 106 :gpio_pl_25 reset. + 107 :gpio_pl_26 reset. + 108 :gpio_pl_27 reset. + 109 :gpio_pl_28 reset. + 110 :gpio_pl_29 reset. + 111 :gpio_pl_30 reset. + 112
[PATCH 0/3] Add reset driver support for ZynqMP
This series of patches are created On top of the below repo. git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git (fetch) BRANCH: next/drivers Nava kishore Manne (3): firmware: xilinx: Add reset API's dt-bindings: reset: Add bindings for ZynqMP reset driver reset: reset-zynqmp: Adding support for Xilinx zynqmp reset controller. .../bindings/reset/xlnx,zynqmp-reset.txt | 146 ++ drivers/firmware/xilinx/zynqmp.c | 40 + drivers/reset/Makefile| 1 + drivers/reset/reset-zynqmp.c | 117 ++ include/linux/firmware/xlnx-zynqmp.h | 136 5 files changed, 440 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/xlnx,zynqmp-reset.txt create mode 100644 drivers/reset/reset-zynqmp.c -- 2.18.0
Re: [PATCH 4/6] mmc: mediatek: tune CMD/DATA together
On 13/10/2018 09:20, Chaotian Jing wrote:
> for MSDC IP which supports both data tune and async fifo, it can
> tune cmd/data together. which can save the time and make the tune
> result of CMD more stable as data line are 4bit or 8bit.
>
> Signed-off-by: Chaotian Jing
> ---
> drivers/mmc/host/mtk-sd.c | 87
> +++
> 1 file changed, 87 insertions(+)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index fe80a1d..09d7e44 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -1773,12 +1773,98 @@ static int msdc_tune_data(struct mmc_host *mmc, u32
> opcode)
> return final_delay == 0xff ? -EIO : 0;
> }
>
> +/*
> + * MSDC IP which supports data tune + async fifo can do CMD/DAT tune
> + * together, which can save the tuning time.
> + */
> +static int msdc_tune_together(struct mmc_host *mmc, u32 opcode)
> +{
> + struct msdc_host *host = mmc_priv(mmc);
> + u32 rise_delay = 0, fall_delay = 0;
> + struct msdc_delay_phase final_rise_delay, final_fall_delay = { 0,};
> + u8 final_delay, final_maxlen;
> + u32 tune_reg = host->dev_comp->pad_tune_reg;
> + int i, ret;
> +
> + sdr_set_field(host->base + MSDC_PATCH_BIT, MSDC_INT_DAT_LATCH_CK_SEL,
> + host->latch_ck);
> +
> + sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
> + sdr_clr_bits(host->base + MSDC_IOCON,
> + MSDC_IOCON_DSPL | MSDC_IOCON_W_DSPL);
> + for (i = 0 ; i < PAD_DELAY_MAX; i++) {
> + sdr_set_field(host->base + tune_reg,
> + MSDC_PAD_TUNE_CMDRDLY, i);
> + sdr_set_field(host->base + tune_reg,
> + MSDC_PAD_TUNE_DATRRDLY, i);
> + ret = mmc_send_tuning(mmc, opcode, NULL);
> + if (!ret)
> + rise_delay |= (1 << i);
> + }
> + final_rise_delay = get_best_delay(host, rise_delay);
> + /* if rising edge has enough margin, then do not scan falling edge */
> + if (final_rise_delay.maxlen >= 12 ||
> + (final_rise_delay.start == 0 && final_rise_delay.maxlen >= 4))
> + goto skip_fall;
> +
> + sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
> + sdr_set_bits(host->base + MSDC_IOCON,
> + MSDC_IOCON_DSPL | MSDC_IOCON_W_DSPL);
> + for (i = 0; i < PAD_DELAY_MAX; i++) {
> + sdr_set_field(host->base + tune_reg,
> + MSDC_PAD_TUNE_CMDRDLY, i);
> + sdr_set_field(host->base + tune_reg,
> + MSDC_PAD_TUNE_DATRRDLY, i);
> + ret = mmc_send_tuning(mmc, opcode, NULL);
> + if (!ret)
> + fall_delay |= (1 << i);
> + }
> + final_fall_delay = get_best_delay(host, fall_delay);
> +
> +skip_fall:
> + final_maxlen = max(final_rise_delay.maxlen, final_fall_delay.maxlen);
> + if (final_maxlen == final_rise_delay.maxlen) {
> + sdr_clr_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
> + sdr_clr_bits(host->base + MSDC_IOCON,
> + MSDC_IOCON_DSPL | MSDC_IOCON_W_DSPL);
> + sdr_set_field(host->base + tune_reg, MSDC_PAD_TUNE_CMDRDLY,
> + final_rise_delay.final_phase);
> + sdr_set_field(host->base + tune_reg,
> + MSDC_PAD_TUNE_DATRRDLY,
> + final_rise_delay.final_phase);
> + final_delay = final_rise_delay.final_phase;
> + } else {
> + sdr_set_bits(host->base + MSDC_IOCON, MSDC_IOCON_RSPL);
> + sdr_set_bits(host->base + MSDC_IOCON,
> + MSDC_IOCON_DSPL | MSDC_IOCON_W_DSPL);
> + sdr_set_field(host->base + tune_reg, MSDC_PAD_TUNE_CMDRDLY,
> + final_fall_delay.final_phase);
> + sdr_set_field(host->base + tune_reg,
> + MSDC_PAD_TUNE_DATRRDLY,
> + final_fall_delay.final_phase);
> + final_delay = final_fall_delay.final_phase;
> + }
> +
> + dev_dbg(host->dev, "Final pad delay: %x\n", final_delay);
> + return final_delay == 0xff ? -EIO : 0;
> +}
> +
> static int msdc_execute_tuning(struct mmc_host *mmc, u32 opcode)
> {
> struct msdc_host *host = mmc_priv(mmc);
> int ret;
> u32 tune_reg = host->dev_comp->pad_tune_reg;
>
> + if (host->dev_comp->data_tune && host->dev_comp->async_fifo) {
> + ret = msdc_tune_together(mmc, opcode);
> + if (host->hs400_mode) {
> + sdr_clr_bits(host->base + MSDC_IOCON,
> + MSDC_IOCON_DSPL | MSDC_IOCON_W_DSPL);
> + sdr_set_field(host->base + tune_reg,
> + MSDC_PAD_TUNE_DATRRDLY, 0);
> + }
> + goto tune_done;
> + }
> if (host->hs400_mode &&
Couldn't we put a els
[PATCH 0/3] Add Bitstream configuration support for ZynqMP
This series of patches are created On top of the below repo. //git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git BRANCH: next/drivers. Nava kishore Manne (3): firmware: xilinx: Add fpga API's dt-bindings: fpga: Add bindings for ZynqMP fpga driver fpga manager: Adding FPGA Manager support for Xilinx zynqmp .../bindings/fpga/xlnx,zynqmp-pcap-fpga.txt | 17 ++ drivers/firmware/xilinx/zynqmp.c | 46 + drivers/fpga/Kconfig | 9 + drivers/fpga/Makefile | 1 + drivers/fpga/zynqmp-fpga.c| 159 ++ include/linux/firmware/xlnx-zynqmp.h | 4 + 6 files changed, 236 insertions(+) create mode 100644 Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt create mode 100644 drivers/fpga/zynqmp-fpga.c -- 2.18.0
[PATCH 3/3] fpga manager: Adding FPGA Manager support for Xilinx zynqmp
This patch adds FPGA Manager support for the Xilinx
ZynqMp chip.
Signed-off-by: Nava kishore Manne
---
Changes for v1:
-None.
Changes for RFC-V2:
-Updated the Fpga Mgr registrations call's
to 4.18
drivers/fpga/Kconfig | 9 +++
drivers/fpga/Makefile | 1 +
drivers/fpga/zynqmp-fpga.c | 159 +
3 files changed, 169 insertions(+)
create mode 100644 drivers/fpga/zynqmp-fpga.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 1ebcef4bab5b..26ebbcf3d3a3 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -56,6 +56,15 @@ config FPGA_MGR_ZYNQ_FPGA
help
FPGA manager driver support for Xilinx Zynq FPGAs.
+config FPGA_MGR_ZYNQMP_FPGA
+ tristate "Xilinx Zynqmp FPGA"
+ depends on ARCH_ZYNQMP || COMPILE_TEST
+ help
+ FPGA manager driver support for Xilinx ZynqMP FPGAs.
+ This driver uses processor configuration port(PCAP)
+ to configure the programmable logic(PL) through PS
+ on ZynqMP SoC.
+
config FPGA_MGR_XILINX_SPI
tristate "Xilinx Configuration over Slave Serial (SPI)"
depends on SPI
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 7a2d73ba7122..3488ebbaee46 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)+= socfpga-a10.o
obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
obj-$(CONFIG_FPGA_MGR_XILINX_SPI) += xilinx-spi.o
obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
+obj-$(CONFIG_FPGA_MGR_ZYNQMP_FPGA) += zynqmp-fpga.o
obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT)+= altera-pr-ip-core-plat.o
diff --git a/drivers/fpga/zynqmp-fpga.c b/drivers/fpga/zynqmp-fpga.c
new file mode 100644
index ..2760d7e3872a
--- /dev/null
+++ b/drivers/fpga/zynqmp-fpga.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Xilinx, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Constant Definitions */
+#define IXR_FPGA_DONE_MASK 0X0008U
+
+/**
+ * struct zynqmp_fpga_priv - Private data structure
+ * @dev: Device data structure
+ * @flags: flags which is used to identify the bitfile type
+ */
+struct zynqmp_fpga_priv {
+ struct device *dev;
+ u32 flags;
+};
+
+static int zynqmp_fpga_ops_write_init(struct fpga_manager *mgr,
+ struct fpga_image_info *info,
+ const char *buf, size_t size)
+{
+ struct zynqmp_fpga_priv *priv;
+
+ priv = mgr->priv;
+ priv->flags = info->flags;
+
+ return 0;
+}
+
+static int zynqmp_fpga_ops_write(struct fpga_manager *mgr,
+const char *buf, size_t size)
+{
+ struct zynqmp_fpga_priv *priv;
+ char *kbuf;
+ dma_addr_t dma_addr;
+ int ret;
+ const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+ if (!eemi_ops || !eemi_ops->fpga_load)
+ return -ENXIO;
+
+ priv = mgr->priv;
+
+ kbuf = dma_alloc_coherent(priv->dev, size, &dma_addr, GFP_KERNEL);
+ if (!kbuf)
+ return -ENOMEM;
+
+ memcpy(kbuf, buf, size);
+
+ wmb(); /* ensure all writes are done before initiate FW call */
+
+ ret = eemi_ops->fpga_load(dma_addr, size, priv->flags);
+
+ dma_free_coherent(priv->dev, size, kbuf, dma_addr);
+
+ return ret;
+}
+
+static int zynqmp_fpga_ops_write_complete(struct fpga_manager *mgr,
+ struct fpga_image_info *info)
+{
+ return 0;
+}
+
+static enum fpga_mgr_states zynqmp_fpga_ops_state(struct fpga_manager *mgr)
+{
+ u32 status;
+ const struct zynqmp_eemi_ops *eemi_ops = zynqmp_pm_get_eemi_ops();
+
+ if (!eemi_ops || !eemi_ops->fpga_get_status)
+ return FPGA_MGR_STATE_UNKNOWN;
+
+ eemi_ops->fpga_get_status(&status);
+ if (status & IXR_FPGA_DONE_MASK)
+ return FPGA_MGR_STATE_OPERATING;
+
+ return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static const struct fpga_manager_ops zynqmp_fpga_ops = {
+ .state = zynqmp_fpga_ops_state,
+ .write_init = zynqmp_fpga_ops_write_init,
+ .write = zynqmp_fpga_ops_write,
+ .write_complete = zynqmp_fpga_ops_write_complete,
+};
+
+static int zynqmp_fpga_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct zynqmp_fpga_priv *priv;
+ struct fpga_manager *mgr;
+ int err, ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = dev;
+ ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(44));
+ if (ret < 0)
+ dev_err(dev, "no usable DMA configuration");
+
+ mgr
[PATCH 1/3] firmware: xilinx: Add fpga API's
This Patch Adds fpga API's to support the Bitstream loading
by using firmware interface.
Signed-off-by: Nava kishore Manne
---
Changes for v1:
-None.
Changes for RFC-V2:
-New Patch.
drivers/firmware/xilinx/zynqmp.c | 46
include/linux/firmware/xlnx-zynqmp.h | 4 +++
2 files changed, 50 insertions(+)
diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
index 84b3fd2eca8b..38a1ab1be03b 100644
--- a/drivers/firmware/xilinx/zynqmp.c
+++ b/drivers/firmware/xilinx/zynqmp.c
@@ -428,6 +428,50 @@ static int zynqmp_pm_clock_getparent(u32 clock_id, u32
*parent_id)
return ret;
}
+/**
+ * zynqmp_pm_fpga_load - Perform the fpga load
+ * @address: Address to write to
+ * @size: pl bitstream size
+ * @flags:
+ * BIT(0) - Bit-stream type.
+ * 0 - Full Bit-stream.
+ * 1 - Partial Bit-stream.
+ *
+ * This function provides access to pmufw. To transfer
+ * the required bitstream into PL.
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_fpga_load(const u64 address, const u32 size,
+ const u32 flags)
+{
+ return zynqmp_pm_invoke_fn(PM_FPGA_LOAD, lower_32_bits(address),
+ upper_32_bits(address), size, flags, NULL);
+}
+
+/**
+ * zynqmp_pm_fpga_get_status - Read value from PCAP status register
+ * @value: Value to read
+ *
+ * This function provides access to the xilfpga library to get
+ * the PCAP status
+ *
+ * Return: Returns status, either success or error+reason
+ */
+static int zynqmp_pm_fpga_get_status(u32 *value)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!value)
+ return -EINVAL;
+
+ ret = zynqmp_pm_invoke_fn(PM_FPGA_GET_STATUS, 0, 0, 0, 0, ret_payload);
+ *value = ret_payload[1];
+
+ return ret;
+}
+
static const struct zynqmp_eemi_ops eemi_ops = {
.get_api_version = zynqmp_pm_get_api_version,
.query_data = zynqmp_pm_query_data,
@@ -440,6 +484,8 @@ static const struct zynqmp_eemi_ops eemi_ops = {
.clock_getrate = zynqmp_pm_clock_getrate,
.clock_setparent = zynqmp_pm_clock_setparent,
.clock_getparent = zynqmp_pm_clock_getparent,
+ .fpga_load = zynqmp_pm_fpga_load,
+ .fpga_get_status = zynqmp_pm_fpga_get_status,
};
/**
diff --git a/include/linux/firmware/xlnx-zynqmp.h
b/include/linux/firmware/xlnx-zynqmp.h
index 015e130431e6..b24400ee630a 100644
--- a/include/linux/firmware/xlnx-zynqmp.h
+++ b/include/linux/firmware/xlnx-zynqmp.h
@@ -34,6 +34,8 @@
enum pm_api_id {
PM_GET_API_VERSION = 1,
+ PM_FPGA_LOAD = 22,
+ PM_FPGA_GET_STATUS,
PM_QUERY_DATA = 35,
PM_CLOCK_ENABLE,
PM_CLOCK_DISABLE,
@@ -89,6 +91,8 @@ struct zynqmp_pm_query_data {
struct zynqmp_eemi_ops {
int (*get_api_version)(u32 *version);
+ int (*fpga_load)(const u64 address, const u32 size, const u32 flags);
+ int (*fpga_get_status)(u32 *value);
int (*query_data)(struct zynqmp_pm_query_data qdata, u32 *out);
int (*clock_enable)(u32 clock_id);
int (*clock_disable)(u32 clock_id);
--
2.18.0
[PATCH 2/3] dt-bindings: fpga: Add bindings for ZynqMP fpga driver
Add documentation to describe Xilinx ZynqMP fpga driver
bindings.
Signed-off-by: Nava kishore Manne
---
Changes for v1:
Created a Seperate(New) DT binding file as
suggested by Rob.
Changes for RFC-V2:
-Moved pcap node as a child to firwmare
node as suggested by Rob.
.../bindings/fpga/xlnx,zynqmp-pcap-fpga.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
diff --git a/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
new file mode 100644
index ..248ff0ee60a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xlnx,zynqmp-pcap-fpga.txt
@@ -0,0 +1,17 @@
+--
+Device Tree zynqmp-fpga bindings for the Zynq Ultrascale+ MPSoC controlled
+using ZynqMP SoC firmware interface
+--
+For Bitstream configuration on ZynqMp Soc uses processor configuration
+port(PCAP) to configure the programmable logic(PL) through PS by using
+FW interface.
+
+Required properties:
+- compatible: should contain "xlnx,zynqmp-pcap-fpga"
+
+---
+Example
+---
+ zynqmp_pcap: pcap {
+ compatible = "xlnx,zynqmp-pcap-fpga";
+ };
--
2.18.0
Re: [PATCH 6/6] mmc: mediatek: drop too much code of tuning method
On 13/10/2018 09:20, Chaotian Jing wrote:
> the tuning code is becoming more and more bloated, let's make the
> set cmd/data delay to inline function to avoid too much redundant code.
>
> Signed-off-by: Chaotian Jing
> ---
> drivers/mmc/host/mtk-sd.c | 133
> +-
> 1 file changed, 38 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
[...]> @@ -1923,17 +1898,8 @@ static int msdc_tune_together(struct mmc_host
*mmc, u32 opcode)
> sdr_clr_bits(host->base + MSDC_IOCON,
>MSDC_IOCON_DSPL | MSDC_IOCON_W_DSPL);
> for (i = 0 ; i < PAD_DELAY_MAX; i++) {
> - if (host->top_base) {
> - sdr_set_field(host->top_base + EMMC_TOP_CMD,
> - PAD_CMD_RXDLY, i);
> - sdr_set_field(host->top_base + EMMC_TOP_CONTROL,
> - PAD_DAT_RD_RXDLY, i);
> - } else {
> - sdr_set_field(host->base + tune_reg,
> - MSDC_PAD_TUNE_CMDRDLY, i);
> - sdr_set_field(host->base + tune_reg,
> - MSDC_PAD_TUNE_DATRRDLY, i);
> - }
> + msdc_set_cmd_delay(host, i);
> + msdc_set_data_delay(host, i);
Put the clean-up before introducing msdc_tune_together, that makes the series
much easier to read.
Thanks,
Matthias
Re: [RFC v4 PATCH 2/5] mm/__free_one_page: skip merge for order-0 page unless compaction failed
On Fri, Oct 19, 2018 at 01:57:03PM +0800, Aaron Lu wrote: > > > > I don't think this is the right way of thinking about it because it's > > possible to have the system split in such a way so that the migration > > scanner only encounters unmovable pages before it meets the free scanner > > where unmerged buddies were in the higher portion of the address space. > > Yes it is possible unmerged pages are in the higher portion. > > My understanding is, when the two scanners meet, all unmerged pages will > be either used by the free scanner as migrate targets or sent to merge > by the migration scanner. > It's not guaranteed if the lower portion of the address space consisted entirely of pages that cannot migrate (because they are unmovable or because migration failed due to pins). It's actually a fundamental limitation of compaction that it can miss migration and compaction opportunities due to how the scanners are implemented. It was designed that way to avoid pageblocks being migrated unnecessarily back and forth but the downside is missed opportunities. > > You either need to keep unmerged buddies on a separate list or search > > the order-0 free list for merge candidates prior to compaction. > > > > > > It's needed to form them efficiently but excessive reclaim or writing 3 > > > > to drop_caches can also do it. Be careful of tying lazy buddy too > > > > closely to compaction. > > > > > > That's the current design of this patchset, do you see any immediate > > > problem of this? Is it that you are worried about high-order allocation > > > success rate using this design? > > > > I've pointed out what I see are the design flaws but yes, in general, I'm > > worried about the high order allocation success rate using this design, > > the reliance on compaction and the fact that the primary motivation is > > when THP is disabled. > > When THP is in use, zone lock contention is pretty much nowhere :-) > > I'll see what I can get with 'address space range' lock first and will > come back to 'lazy buddy' if it doesn't work out. Thank you and > Vlastimil for all the suggestions. My pleasure. -- Mel Gorman SUSE Labs
[PATCH 1/2] i2c: Remove unnecessary call to irq_find_mapping
irq_create_mapping calls irq_find_mapping internally and will use the found mapping if one exists, so there is no need to manually call this from i2c_smbus_host_notify_to_irq. Signed-off-by: Charles Keepax --- drivers/i2c/i2c-core-base.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index dc78aa7369def..656f0a6fe3adf 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -306,10 +306,7 @@ static int i2c_smbus_host_notify_to_irq(const struct i2c_client *client) if (client->flags & I2C_CLIENT_TEN) return -EINVAL; - irq = irq_find_mapping(adap->host_notify_domain, client->addr); - if (!irq) - irq = irq_create_mapping(adap->host_notify_domain, -client->addr); + irq = irq_create_mapping(adap->host_notify_domain, client->addr); return irq > 0 ? irq : -ENXIO; } -- 2.11.0
[PATCH 2/2] i2c: Clear client->irq in i2c_device_remove
The IRQ will be mapped in i2c_device_probe only if client->irq is zero and i2c_device_remove does not clear this. When rebinding an I2C device, whos IRQ provider has also been rebound this means that an IRQ mapping will never be created, causing the I2C device to fail to acquire its IRQ. Fix this issue by clearing client->irq in i2c_device_remove, forcing i2c_device_probe to lookup the mapping again. Signed-off-by: Charles Keepax --- drivers/i2c/i2c-core-base.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index 656f0a6fe3adf..28460f6a60cc1 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -430,6 +430,8 @@ static int i2c_device_remove(struct device *dev) dev_pm_clear_wake_irq(&client->dev); device_init_wakeup(&client->dev, false); + client->irq = 0; + return status; } -- 2.11.0
Re: [PATCH 4.4 00/48] 4.4.162-stable review
4.4, 4.9 and 4.14 contain a new file named arch/riscv/include/asm/asm-prototypes.h this doesnt seem to belong to these kernels since arch/riscv was not even present before Sebastian Am 18.10.2018 um 19:54 schrieb Greg Kroah-Hartman: This is the start of the stable review cycle for the 4.4.162 release. There are 48 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Oct 20 17:54:03 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.162-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y and the diffstat can be found below. thanks, greg k-h - Pseudo-Shortlog of commits: Greg Kroah-Hartman Linux 4.4.162-rc1 Long Li HV: properly delay KVP packets when negotiation is in progress Vitaly Kuznetsov Drivers: hv: kvp: fix IP Failover K. Y. Srinivasan Drivers: hv: util: Pass the channel information during the init call K. Y. Srinivasan Drivers: hv: utils: Invoke the poll function after handshake Stephen Warren usb: gadget: serial: fix oops when data rx'd after close Alexey Brodkin ARC: build: Get rid of toolchain check Michael Neuling powerpc/tm: Avoid possible userspace r1 corruption on reclaim Michael Neuling powerpc/tm: Fix userspace r13 corruption James Cowgill RISC-V: include linux/ftrace.h in asm-prototypes.h Nathan Chancellor net/mlx4: Use cpumask_available for eq->affinity_mask Michael Schmitz Input: atakbd - fix Atari CapsLock behaviour Andreas Schwab Input: atakbd - fix Atari keymap Keerthy clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for non-am43 SoCs Jozef Balga media: af9035: prevent buffer overflow on write Andy Lutomirski x86/fpu: Finish excising 'eagerfpu' Rik van Riel x86/fpu: Remove struct fpu::counter Andy Lutomirski x86/fpu: Remove use_eager_fpu() Paolo Bonzini KVM: x86: remove eager_fpu field of struct kvm_vcpu_arch Eric Dumazet rtnl: limit IFLA_NUM_TX_QUEUES and IFLA_NUM_RX_QUEUES to 4096 Florian Fainelli net: systemport: Fix wake-up interrupt race during resume Maxime Chevallier net: mvpp2: Extract the correct ethtype from the skb for tx csum offload Ido Schimmel team: Forbid enslaving team device to itself Shahed Shaikh qlcnic: fix Tx descriptor corruption on 82xx devices Yu Zhao net/usb: cancel pending work when unbinding smsc75xx Sean Tranchetti netlabel: check for IPV4MASK in addrinfo_get Jeff Barnhill <0xeff...@gmail.com> net/ipv6: Display all addresses in output of /proc/net/if_inet6 Sabrina Dubroca net: ipv4: update fnhe_pmtu when first hop's MTU changes Eric Dumazet ipv4: fix use-after-free in ip_cmsg_recv_dstaddr() Paolo Abeni ip_tunnel: be careful when accessing the inner header Paolo Abeni ip6_tunnel: be careful when accessing the inner header Mahesh Bandewar bonding: avoid possible dead-lock Michael Chan bnxt_en: Fix TX timeout during netpoll. Hou Tao jffs2: return -ERANGE when xattr buffer is too small Mathias Nyman xhci: Don't print a warning when setting link state for disabled ports Edgar Cherkasov i2c: i2c-scmi: fix for i2c_smbus_write_block_data Adrian Hunter perf script python: Fix export-to-postgresql.py occasional failure Mikulas Patocka mach64: detect the dot clock divider correctly on sparc Jann Horn mm/vmstat.c: fix outdated vmstat_text Theodore Ts'o ext4: add corruption check in ext4_xattr_set_entry() Amber Lin drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7 Nicolas Ferre ARM: dts: at91: add new compatibility string for macb on sama5d3 Nicolas Ferre net: macb: disable scatter-gather for macb on sama5d3 Jongsung Kim stmmac: fix valid numbers of unicast filter entries Yu Zhao sound: enable interrupt after dma buffer initialization Tony Lindgren mfd: omap-usb-host: Fix dts probe of children Lei Yang selftests/efivarfs: add required kernel configs Danny Smith ASoC: sigmadsp: safeload should not have lower byte limit Pierre-Louis Bossart ASoC: wm8804: Add ACPI support - Diffstat: Documentation/devicetree/bindings/net/macb.txt | 1 + Documentation/kernel-parameters.txt| 5 -- Makefile | 4 +- arch/arc/Makefile | 14 arch/arm/boot/dts/sama5d3_emac.dtsi| 2 +- arch/powerpc/kernel/tm.S | 20 +- arch/riscv/include/asm/asm-prototypes.h| 7 ++ arch/x86/crypto/crc32c-intel
Re: [PATCH v5 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
On 2018/10/19 16:42, Boris Brezillon wrote:
On Fri, 19 Oct 2018 16:29:40 +0800
Liang Yang wrote:
On 2018/10/19 4:50, Boris Brezillon wrote:
On Thu, 18 Oct 2018 13:09:05 +0800
Jianxin Pan wrote:
+static int meson_nfc_buffer_init(struct mtd_info *mtd)
+{
+ struct nand_chip *nand = mtd_to_nand(mtd);
+ struct meson_nfc *nfc = nand_get_controller_data(nand);
+ static int max_page_bytes, max_info_bytes;
+ int page_bytes, info_bytes;
+ int nsectors;
+
+ nsectors = mtd->writesize / nand->ecc.size;
+ page_bytes = mtd->writesize + mtd->oobsize;
+ info_bytes = nsectors * PER_INFO_BYTE;
+
+ if (nfc->data_buf && nfc->info_buf) {
+ if (max_page_bytes < page_bytes)
+ meson_nfc_free_buffer(nfc);
+ else
+ return 0;
+ }
+
+ max_page_bytes = max_t(int, max_page_bytes, page_bytes);
+ max_info_bytes = max_t(int, max_info_bytes, info_bytes);
+
+ nfc->data_buf = kmalloc(max_page_bytes, GFP_KERNEL);
Is there a good reason for not using chip->data_buf and allocating a
new buffer here?
when calling read_oob or write_oob, i need a mid-buffer which is used in
meson_nfc_prase_data_oob(). i.e. after reading a page data into
nfc->data_buf, I will format it and transfer to chip->data_buf.
+ if (!nfc->data_buf)
+ return -ENOMEM;
+
+ nfc->info_buf = kmalloc(max_info_bytes, GFP_KERNEL);
+ if (!nfc->info_buf) {
+ kfree(nfc->data_buf);
+ return -ENOMEM;
+ }
I'd recommend moving this info_buf in the priv chip struct, otherwise
you'll have to protect nfc->info_buf with a lock to prevent an already
register chip from using this pointer while you're reallocating the
buffer. Also, I think you have a memleak here.
ok, i will move it in the chip struct .
but how memleak happens even i have called meson_nfc_free_buffer before
and free data_buf if info_buf alloc faied.
You're right, I missed the call to meson_nfc_free_buffer() when
max_page_bytes < page_bytes. Still, this part is racy, just like the
nfc->data_buf replacement is if you have several NAND chips. I'd
recommend moving those bufs to the priv chip struct.
ok. i will move data_duf and info_buf to priv chip struct.
+
+ return 0;
+}
.
.
Re: [PATCH 3/3] reset: reset-zynqmp: Adding support for Xilinx zynqmp reset controller.
Hi Nava,
On Sat, 2018-10-20 at 14:11 +0530, Nava kishore Manne wrote:
> Add a reset controller driver for Xilinx Zynq UltraScale+ MPSoC.
> The zynqmp reset-controller has the ability to reset lines
> connected to different blocks and peripheral in the Soc.
>
> Signed-off-by: Nava kishore Manne
> ---
> Changes for v1:
> -None.
I had comments on RFC v3 that are not addressed yet, see below.
> --- /dev/null
> +++ b/drivers/reset/reset-zynqmp.c
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Xilinx, Inc.
> + *
> + */
> +
> +#include
Unnecessary.
[...]
> +static int zynqmp_reset_status(struct reset_controller_dev *rcdev,
> +unsigned long id)
> +{
> + struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
> + int val, err;
> +
> + err = priv->eemi_ops->reset_get_status(ZYNQMP_RESET_ID + id, &val);
> + if (!err)
> + return -EINVAL;
Should return error code, and only if there is an error:
if (err)
return err;
> + return val;
> +}
> +
> +static int zynqmp_reset_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct zynqmp_reset_data *priv = to_zynqmp_reset_data(rcdev);
> +
> + return priv->eemi_ops->reset_assert(ZYNQMP_RESET_ID + id,
> + PM_RESET_ACTION_PULSE);
> +}
> +
> +static struct reset_control_ops zynqmp_reset_ops = {
Should be const:
static const struct reset_control_ops zynqmp_reset_ops = {
> + .reset = zynqmp_reset_reset,
> + .assert = zynqmp_reset_assert,
> + .deassert = zynqmp_reset_deassert,
> + .status = zynqmp_reset_status,
> +};
> +
> +static int zynqmp_reset_probe(struct platform_device *pdev)
> +{
> + struct zynqmp_reset_data *priv;
> +
> + priv = devm_kzalloc(&pdev->dev,
> + sizeof(*priv), GFP_KERNEL);
Fits on one line:
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
regards
Philipp
Re: [PATCH 5/6] mmc: mediatek: add MT8183 MMC driver support
On 13/10/2018 09:20, Chaotian Jing wrote:
> MT8183 puts the tune register at top layer, so need add new code
> to support it.
>
> Signed-off-by: Chaotian Jing
> ---
> drivers/mmc/host/mtk-sd.c | 283
> ++
> 1 file changed, 233 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 09d7e44..5b26f2f 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -87,6 +87,13 @@
> #define SDC_FIFO_CFG 0x228
>
>
> /*--*/
> +/* Top Pad Register Offset
> */
> +/*--*/
> +#define EMMC_TOP_CONTROL 0x00
> +#define EMMC_TOP_CMD 0x04
> +#define EMMC50_PAD_DS_TUNE 0x0c
> +
> +/*--*/
> /* Register Mask
> */
>
> /*--*/
>
> @@ -261,6 +268,23 @@
> #define SDC_FIFO_CFG_WRVALIDSEL (0x1 << 24) /* RW */
> #define SDC_FIFO_CFG_RDVALIDSEL (0x1 << 25) /* RW */
>
> +/* EMMC_TOP_CONTROL mask */
> +#define PAD_RXDLY_SEL (0x1 << 0) /* RW */
> +#define DELAY_EN(0x1 << 1) /* RW */
> +#define PAD_DAT_RD_RXDLY2 (0x1f << 2) /* RW */
> +#define PAD_DAT_RD_RXDLY(0x1f << 7) /* RW */
> +#define PAD_DAT_RD_RXDLY2_SEL (0x1 << 12) /* RW */
> +#define PAD_DAT_RD_RXDLY_SEL(0x1 << 13) /* RW */
> +#define DATA_K_VALUE_SEL(0x1 << 14) /* RW */
> +#define SDC_RX_ENH_EN (0x1 << 15) /* TW */
> +
> +/* EMMC_TOP_CMD mask */
> +#define PAD_CMD_RXDLY2 (0x1f << 0) /* RW */
> +#define PAD_CMD_RXDLY (0x1f << 5) /* RW */
> +#define PAD_CMD_RD_RXDLY2_SEL (0x1 << 10) /* RW */
> +#define PAD_CMD_RD_RXDLY_SEL(0x1 << 11) /* RW */
> +#define PAD_CMD_TX_DLY (0x1f << 12)/* RW */
> +
> #define REQ_CMD_EIO (0x1 << 0)
> #define REQ_CMD_TMO (0x1 << 1)
> #define REQ_DAT_ERR (0x1 << 2)
> @@ -333,6 +357,9 @@ struct msdc_save_para {
> u32 emmc50_cfg0;
> u32 emmc50_cfg3;
> u32 sdc_fifo_cfg;
> + u32 emmc_top_control;
> + u32 emmc_top_cmd;
> + u32 emmc50_pad_ds_tune;
> };
>
> struct mtk_mmc_compatible {
> @@ -351,6 +378,8 @@ struct msdc_tune_para {
> u32 iocon;
> u32 pad_tune;
> u32 pad_cmd_tune;
> + u32 emmc_top_control;
> + u32 emmc_top_cmd;
> };
>
> struct msdc_delay_phase {
> @@ -372,6 +401,7 @@ struct msdc_host {
> int error;
>
> void __iomem *base; /* host base address */
> + void __iomem *top_base; /* host top register base address */
Where do you assign a value to top_base?
I'm not familiar with the driver, but couldn't we reuse base and a flag for
example in mtk_mmc_compatible to check which tune register we need to use?
Regards,
Matthias
>
> struct msdc_dma dma;/* dma channel */
> u64 dma_mask;
> @@ -429,6 +459,18 @@ struct msdc_host {
> .support_64g = false,
> };
>
> +static const struct mtk_mmc_compatible mt8183_compat = {
> + .clk_div_bits = 12,
> + .hs400_tune = false,
> + .pad_tune_reg = MSDC_PAD_TUNE0,
> + .async_fifo = true,
> + .data_tune = true,
> + .busy_check = true,
> + .stop_clk_fix = true,
> + .enhance_rx = true,
> + .support_64g = true,
> +};
> +
> static const struct mtk_mmc_compatible mt2701_compat = {
> .clk_div_bits = 12,
> .hs400_tune = false,
> @@ -468,6 +510,7 @@ struct msdc_host {
> static const struct of_device_id msdc_of_ids[] = {
> { .compatible = "mediatek,mt8135-mmc", .data = &mt8135_compat},
> { .compatible = "mediatek,mt8173-mmc", .data = &mt8173_compat},
> + { .compatible = "mediatek,mt8183-mmc", .data = &mt8183_compat},
> { .compatible = "mediatek,mt2701-mmc", .data = &mt2701_compat},
> { .compatible = "mediatek,mt2712-mmc", .data = &mt2712_compat},
> { .compatible = "mediatek,mt7622-mmc", .data = &mt7622_compat},
> @@ -777,12 +820,28 @@ static void msdc_set_mclk(struct msdc_host *host,
> unsigned char timing, u32 hz)
>*/
> if (host->mmc->actual_clock <= 5200) {
> writel(host->def_tune_para.iocon, host->base + MSDC_IOCON);
> - writel(host->def_tune_para.pad_tune, host->base + tune_reg);
> + if (host->top_base) {
> + writel(host->def_tune_para.emmc_top_control,
> +host->top_base + EMMC_TOP_CONTROL);
> + writel(host->def_tune_para.emmc_top_cmd,
> +host->top_base + EMMC_TOP_CMD);
> + } else {
> + writel(host->def_tune_para.pad_tune,
> +
Re: [PATCH] Input: pm8941-pwrkey - Add pms405 pwrkey support
On 18-10-18, 17:01, Dmitry Torokhov wrote:
> On Thu, Oct 18, 2018 at 10:54:37AM +0530, Vinod wrote:
> > On 19-09-18, 18:49, Bjorn Andersson wrote:
> > > From: Vinod Koul
> > >
> > > Update the binding and driver for pms405 pwrkey.
> >
> > Rob, Dmitry
> >
> > Gentle reminder for this patch...
> >
> > > Signed-off-by: Vinod Koul
> > > Signed-off-by: Bjorn Andersson
> > > ---
> > > Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt | 1 +
> > > drivers/input/misc/pm8941-pwrkey.c | 1 +
> > > 2 files changed, 2 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> > > b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> > > index 34ab5763f494..736fba3bad54 100644
> > > --- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> > > +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
> > > @@ -8,6 +8,7 @@ PROPERTIES
> > > Definition: must be one of:
> > > "qcom,pm8941-pwrkey"
> > > "qcom,pm8941-resin"
> > > + "qcom,pms405-pwrkey"
> > >
> > > - reg:
> > > Usage: required
> > > diff --git a/drivers/input/misc/pm8941-pwrkey.c
> > > b/drivers/input/misc/pm8941-pwrkey.c
> > > index 48153e0ca19a..fccf63263c1c 100644
> > > --- a/drivers/input/misc/pm8941-pwrkey.c
> > > +++ b/drivers/input/misc/pm8941-pwrkey.c
> > > @@ -317,6 +317,7 @@ static const struct pm8941_data resin_data = {
> > > static const struct of_device_id pm8941_pwr_key_id_table[] = {
> > > { .compatible = "qcom,pm8941-pwrkey", .data = &pwrkey_data },
> > > { .compatible = "qcom,pm8941-resin", .data = &resin_data },
> > > + { .compatible = "qcom,pms405-pwrkey", .data = &pwrkey_data },
>
> I am sure I asked this question before (in context of a different
> driver), but why do we need this compatible if we already have
> pm8941-pwrkey compatible? Isn't pms405-pwrkey compatible with
> pm8941-pwrkey as far as power key block goes? In which cases do we need
> new compatibles and when can we reuse existing ones? Rob?
Relooking I do think that reuse of pm8941-pwrkey is entirely feasible,
thanks for the suggestion. We can drop this and I will update DTS
--
~Vinod
Re: [PATCH v2 2/4] nfc: pn532_uart: Add NXP PN532 to devicetree docs
On Thu, Oct 18, 2018 at 03:41:29PM -0500, Rob Herring wrote: > On Thu, Oct 18, 2018 at 05:03:13PM +0200, Marcel Holtmann wrote: > > Hi Lars, > > > > > Add pn532 to the trivial-devices.txt binding doc. > > > > > > Signed-off-by: Lars Poeschel > > > --- > > > Documentation/devicetree/bindings/trivial-devices.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/Documentation/devicetree/bindings/trivial-devices.txt > > > b/Documentation/devicetree/bindings/trivial-devices.txt > > > index 763a2808a95c..c580be08a380 100644 > > > --- a/Documentation/devicetree/bindings/trivial-devices.txt > > > +++ b/Documentation/devicetree/bindings/trivial-devices.txt > > > @@ -172,6 +172,7 @@ nxp,pcf2129 Real-time clock > > > nxp,pcf8523 Real-time Clock > > > nxp,pcf8563 Real-time clock/calendar > > > nxp,pcf85063 Tiny Real-Time Clock > > > +nxp,pn532-uart NXP PN532 NFC-/RFID-Chip, using UART interface > > > > is this really such a trivial device? It doesn’t require any GPIO to enable > > / reset the NFC chip? It does not require any additional things like GPIO or Interrupts. These are optional and at the moment not supported by the driver. > Considering it supports multiple interfaces, it is not. > > The '-uart' can be dropped and the same compatible used for any > of the bus connections because the device is bound based on the bus > type. Ok. I drop the '-uart' part from the compatible string and provide a seperate, little binding doc, documenting the compatible string used. But does this also have consequences for the already existing -i2c driver? This one uses 'nxp,pn532-i2c' as compatible string. Thanks, Lars
Re: [PATCH] mmc: sdhci-pci: Try "cd" for card-detect lookup before using NULL
On Fri, Oct 19, 2018 at 12:53 AM Rajat Jain wrote:
>
> Problem:
>
> The card detect IRQ does not work with modern BIOS (that want
> to use DSD to provide the card detect GPIO to the driver).
>
> Details:
>
> (Discussion: https://lkml.org/lkml/2018/9/25/1113)
We have a Link tag for such references.
> The mmc core provides the mmc_gpiod_request_cd() API to let host drivers
> request the gpio descriptor for the "card detect" (or carrier detect?) pin.
card detect is a right term.
> This pin is specified in the ACPI for the SDHC device:
>
> * Either as a resource using _CRS. This is a method used by legacy BIOS.
>(The driver needs to tell which resource index).
>
> * Or as a named property ("cd-gpio") in DSD (which may internally point
cd-gpios (gpio suffix is a legacy).
>to an entry in _CRS). This way, the driver can lookup using a string.
>This is what modern BIOS prefer to use.
>
> This API finally results in a call to the following code:
>
> struct gpio_desc *acpi_find_gpio(..., const char *con_id,...)
> {
> ...
>/* Lookup gpio (using "-gpio") in the _DSD */
> ...
>if (!acpi_can_fallback_to_crs(adev, con_id))
> return ERR_PTR(-ENOENT);
> ...
>/* Falling back to _CRS is allowed, Lookup gpio in the _CRS */
> ...
> }
>
> Note that this means that if the ACPI has _DSD properties, the kernel
> will never use _CRS for the lookup (Because acpi_can_fallback_to_crs()
> will always be false for any device hat has _DSD entries).
>
> The SDHCI driver is thus currently broken on a modern BIOS
> (even if
> BIOS provides both _CRS and DSD entries, either of which could be used for
_DSD
> a successful lookup).
This is incorrect. _DSD for GPIOs without any accompanying _CRS
doesn't make any sense.
> Ironically, none of these will be used for the
> lookup currently because:
>
> * Since the con_id is NULL, acpi_find_gpio() does not find a matching
> entry in DSDT. (The DSDT entry has the property name = "cd-gpio")
cd-gpios
>
> * Because ACPI contains DSDT entries, thus acpi_can_fallback_to_crs()
> returns false (because device properties have been populated from
> DSD), thus the _CRS is never used for the lookup.
_DSD
>
> Fix:
>
> Try "cd" for lookup in the _DSD before falling back to using NULL so
> as to try looking up in the _CRS.
>
> I've tested this patch successfully with both Legacy BIOS (that
> provide only _CRS method) as well as modern BIOS (that provide both
> _CRS and DSD). Also the use of "cd" also appears to be farly consistent
_DSD
fairly
> across other users of this API (other MMC host controller drivers).
> if (slot->cd_idx >= 0) {
> - ret = mmc_gpiod_request_cd(host->mmc, NULL, slot->cd_idx,
> + ret = mmc_gpiod_request_cd(host->mmc, "cd", slot->cd_idx,
>slot->cd_override_level, 0, NULL);
Yes.
> + if (ret && ret != -EPROBE_DEFER)
> + ret = mmc_gpiod_request_cd(host->mmc, NULL,
> + slot->cd_idx,
> + slot->cd_override_level,
> + 0, NULL);
And no. Instead of this part you need to provide an ACPI GPIO mapping table.
See examples, like
net/rfkill/rfkill-gpio.c
(look for acpi_rfkill_default_gpios)
> if (ret == -EPROBE_DEFER)
> goto remove;
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 4.4 00/48] 4.4.162-stable review
On Fri, Oct 19, 2018 at 10:40:48AM +0200, Sebastian Gottschall wrote: > 4.4, 4.9 and 4.14 contain a new file named > arch/riscv/include/asm/asm-prototypes.h > > this doesnt seem to belong to these kernels since arch/riscv was not even > present before Good catch, patch now dropped from all of those trees. thanks, greg k-h
Re: [PATCH] cacheinfo: Keep the old value if of_property_read_u32fails
Hi,
On Fri, Oct 19, 2018 at 02:23:27PM +0800, 陈华才 wrote:
> Hi, Sudeep,
>
> I use MIPS, and there is no "size" in
> /sys/devices/system/cpu/cpuX/cache/indexX/ file after your patch. Because
> the DT node only has "next-level-cache = <&L2>;" but has no "size"
> information.
>
Thanks for the confirmation and your time. I was worried if this was ARM64
with local patches.
You can add:
Reviewed-by: Sudeep Holla
Also please add:
Fixes: 448a5a552f33 ("drivers: base: cacheinfo: use OF property_read_u32
instead of get_property,read_number")
--
Regards,
Sudeep
RE: [PATCH 3/3] reset: reset-zynqmp: Adding support for Xilinx zynqmp reset controller.
Hi Philipp Thanks for the quicks response > -Original Message- > From: Philipp Zabel [mailto:p.za...@pengutronix.de] > Sent: Friday, October 19, 2018 2:33 PM > To: Nava kishore Manne ; robh...@kernel.org; > mark.rutl...@arm.com; Michal Simek ; Rajan Vaja > ; Jolly Shah ; > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; chinnikishore...@gmail.com > Subject: Re: [PATCH 3/3] reset: reset-zynqmp: Adding support for Xilinx > zynqmp reset controller. > > Hi Nava, > > On Sat, 2018-10-20 at 14:11 +0530, Nava kishore Manne wrote: > > Add a reset controller driver for Xilinx Zynq UltraScale+ MPSoC. > > The zynqmp reset-controller has the ability to reset lines connected > > to different blocks and peripheral in the Soc. > > > > Signed-off-by: Nava kishore Manne > > --- > > Changes for v1: > > -None. > > I had comments on RFC v3 that are not addressed yet, see below. > Sorry, I have missed your comments . Will fix in the next version. Regards, Navakishore.
Re: [PATCH v3 4/7] dmaengine: stm32-dma: Add DMA/MDMA chaining support
On 10/16/18 4:44 PM, Vinod wrote: > On 16-10-18, 11:19, Pierre Yves MORDRET wrote: >> >> >> On 10/15/18 7:14 PM, Vinod wrote: >>> On 10-10-18, 09:02, Pierre Yves MORDRET wrote: On 10/10/2018 06:03 AM, Vinod wrote: > On 09-10-18, 10:40, Pierre Yves MORDRET wrote: >> >> >> On 10/07/2018 06:00 PM, Vinod wrote: >>> On 28-09-18, 15:01, Pierre-Yves MORDRET wrote: This patch adds support of DMA/MDMA chaining support. It introduces an intermediate transfer between peripherals and STM32 DMA. This intermediate transfer is triggered by SW for single M2D transfer and by STM32 DMA IP for all other modes (sg, cyclic) and direction (D2M). A generic SRAM allocator is used for this intermediate buffer Each DMA channel will be able to define its SRAM needs to achieve chaining feature : (2 ^ order) * PAGE_SIZE. For cyclic, SRAM buffer is derived from period length (rounded on PAGE_SIZE). >>> >>> So IIUC, you chain two dma txns together and transfer data via an SRAM? >> >> Correct. one DMA is DMAv2 (stm32-dma) and the other is MDMA(stm32-mdma). >> Intermediate transfer is between device and memory. >> This intermediate transfer is using SDRAM. > > Ah so you use dma calls to setup mdma xtfers? I dont think that is a > good idea. How do you know you should use mdma for subsequent transfer? > When user bindings told to setup chaining intermediate MDMA transfers are always triggers. For instance if a user requests a Dev2Mem transfer with chaining. From client pov this is still a prep_slave_sg. Internally DMAv2 is setup in cyclic mode (in double buffer mode indeed => 2 buffer of PAGE_SIZE/2) and destination is SDRAM. DMAv2 will flip/flop on those 2 buffers. At the same time DMAv2 driver prepares a MDMA SG that will fetch data from those 2 buffers in SDRAM and fills final destination memory. >>> >>> I am not able to follow is why does it need to be internal, why should >>> the client not set the two transfers and trigger them? >>> >> >> Client may use or not chaining: defined within DT. API and dynamic are same >> at > > That should be upto client... As a dmaengine driver you should enable > data transfer from src to dstn. > >> driver client level. Moreover driver exposes only DMAv2 and not both DMAv2 >> and >> MDMA. This is totally hidden for client. If client sets both this would imply > > Why should a controller be hidden from user, I dont see why that would > be a good thing > >> changing all drivers that may want use chaining. Even more to deal with DMAv2 >> and MDMA at its level. >> Since DMAv2 deals with MDMA, all drivers are same as before. no changes >> required. > > It is not about changes, it is about the SW model you want to have. > > The intermediate SRAM transfers should not be made within DMAengine > driver, client can chose to have two transfers and couple or not, it is > upto them to choose. Sorry I do not like this abstraction and would like > to see a cleaner approach > What we have done it to hide all the complexity related to DMA engine: synchronization, residue and many other topics solved by this approach. If this is up to client to perform intermediate transfer, each client drivers using chaining will need to duplicate the required sw. This approach is present as a feature from driver pov. Regards
Re: [PATCH 1/1] nds32: Fix gcc 8.0 compiler option incompatible.
Nickhu 於 2018年10月18日 週四 下午4:38寫道： > > When the kernel configs of ftrace and frame pointer options are > choosed, the compiler option of kernel will incompatible. > Error message: > nds32le-linux-gcc: error: -pg and -fomit-frame-pointer are > incompatible > > Signed-off-by: Nickhu > Signed-off-by: Zong Li > --- > arch/nds32/mm/Makefile | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/nds32/mm/Makefile b/arch/nds32/mm/Makefile > index 6b6855852223..7c5c15ad854a 100644 > --- a/arch/nds32/mm/Makefile > +++ b/arch/nds32/mm/Makefile > @@ -4,4 +4,8 @@ obj-y := extable.o tlb.o \ > > obj-$(CONFIG_ALIGNMENT_TRAP) += alignment.o > obj-$(CONFIG_HIGHMEM) += highmem.o > -CFLAGS_proc-n13.o += -fomit-frame-pointer > + > +ifdef CONFIG_FUNCTION_TRACER > +CFLAGS_REMOVE_proc.o = $(CC_FLAGS_FTRACE) > +endif > +CFLAGS_proc.o += -fomit-frame-pointer Hi Nick, Thanks. Acked-by: Greentime Hu
Re: [PATCH 0/3] nds32: Unaligned access handler fix
Nickhu 於 2018年10月18日 週四 下午4:34寫道： > > The patches are about unaligned access handler. We fix some > bugs in unaligned access handler and add some kernel configs > for unaligned access handler. Then we add the kernel unaligned > access handled by software in handler. > > Nickhu (3): > nds32: Fix instruction simulator bug for unaligned access handler. > nds32: Add 'HAVE_EFFICIENT_UNALIGNED_ACCESS' config > nds32: Add unaligned access in kernel space. > > arch/nds32/Kconfig.cpu| 3 ++- > arch/nds32/kernel/traps.c | 4 +++- > arch/nds32/mm/alignment.c | 43 +++ > 3 files changed, 30 insertions(+), 20 deletions(-) > Hi Nick, Thanks Acked-by: Greentime Hu
[tip:locking/core] locking/lockdep: Fix debug_locks off performance problem
Commit-ID: 9506a7425b094d2f1d9c877ed5a78f416669269b
Gitweb: https://git.kernel.org/tip/9506a7425b094d2f1d9c877ed5a78f416669269b
Author: Waiman Long
AuthorDate: Thu, 18 Oct 2018 21:45:17 -0400
Committer: Ingo Molnar
CommitDate: Fri, 19 Oct 2018 07:53:17 +0200
locking/lockdep: Fix debug_locks off performance problem
It was found that when debug_locks was turned off because of a problem
found by the lockdep code, the system performance could drop quite
significantly when the lock_stat code was also configured into the
kernel. For instance, parallel kernel build time on a 4-socket x86-64
server nearly doubled.
Further analysis into the cause of the slowdown traced back to the
frequent call to debug_locks_off() from the __lock_acquired() function
probably due to some inconsistent lockdep states with debug_locks
off. The debug_locks_off() function did an unconditional atomic xchg
to write a 0 value into debug_locks which had already been set to 0.
This led to severe cacheline contention in the cacheline that held
debug_locks. As debug_locks is being referenced in quite a few different
places in the kernel, this greatly slow down the system performance.
To prevent that trashing of debug_locks cacheline, lock_acquired()
and lock_contended() now checks the state of debug_locks before
proceeding. The debug_locks_off() function is also modified to check
debug_locks before calling __debug_locks_off().
Signed-off-by: Waiman Long
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Link:
http://lkml.kernel.org/r/1539913518-15598-1-git-send-email-long...@redhat.com
Signed-off-by: Ingo Molnar
---
kernel/locking/lockdep.c | 4 ++--
lib/debug_locks.c| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index be76f476c63f..1efada2dd9dd 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -4066,7 +4066,7 @@ void lock_contended(struct lockdep_map *lock, unsigned
long ip)
{
unsigned long flags;
- if (unlikely(!lock_stat))
+ if (unlikely(!lock_stat || !debug_locks))
return;
if (unlikely(current->lockdep_recursion))
@@ -4086,7 +4086,7 @@ void lock_acquired(struct lockdep_map *lock, unsigned
long ip)
{
unsigned long flags;
- if (unlikely(!lock_stat))
+ if (unlikely(!lock_stat || !debug_locks))
return;
if (unlikely(current->lockdep_recursion))
diff --git a/lib/debug_locks.c b/lib/debug_locks.c
index 96c4c633d95e..124fdf238b3d 100644
--- a/lib/debug_locks.c
+++ b/lib/debug_locks.c
@@ -37,7 +37,7 @@ EXPORT_SYMBOL_GPL(debug_locks_silent);
*/
int debug_locks_off(void)
{
- if (__debug_locks_off()) {
+ if (debug_locks && __debug_locks_off()) {
if (!debug_locks_silent) {
console_verbose();
return 1;
[tip:locking/core] locking/lockdep: Make global debug_locks* variables read-mostly
Commit-ID: 01a14bda11add9dcd4a59200f13834d634559935 Gitweb: https://git.kernel.org/tip/01a14bda11add9dcd4a59200f13834d634559935 Author: Waiman Long AuthorDate: Thu, 18 Oct 2018 21:45:18 -0400 Committer: Ingo Molnar CommitDate: Fri, 19 Oct 2018 07:53:18 +0200 locking/lockdep: Make global debug_locks* variables read-mostly Make the frequently used lockdep global variable debug_locks read-mostly. As debug_locks_silent is sometime used together with debug_locks, it is also made read-mostly so that they can be close together. With false cacheline sharing, cacheline contention problem can happen depending on what get put into the same cacheline as debug_locks. Signed-off-by: Waiman Long Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Link: http://lkml.kernel.org/r/1539913518-15598-2-git-send-email-long...@redhat.com Signed-off-by: Ingo Molnar --- include/linux/debug_locks.h | 4 ++-- lib/debug_locks.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h index 120225e9a366..257ab3c92cb8 100644 --- a/include/linux/debug_locks.h +++ b/include/linux/debug_locks.h @@ -8,8 +8,8 @@ struct task_struct; -extern int debug_locks; -extern int debug_locks_silent; +extern int debug_locks __read_mostly; +extern int debug_locks_silent __read_mostly; static inline int __debug_locks_off(void) diff --git a/lib/debug_locks.c b/lib/debug_locks.c index 124fdf238b3d..ce51749cc145 100644 --- a/lib/debug_locks.c +++ b/lib/debug_locks.c @@ -21,7 +21,7 @@ * that would just muddy the log. So we report the first one and * shut up after that. */ -int debug_locks = 1; +int debug_locks __read_mostly = 1; EXPORT_SYMBOL_GPL(debug_locks); /* @@ -29,7 +29,7 @@ EXPORT_SYMBOL_GPL(debug_locks); * 'silent failure': nothing is printed to the console when * a locking bug is detected. */ -int debug_locks_silent; +int debug_locks_silent __read_mostly; EXPORT_SYMBOL_GPL(debug_locks_silent); /*
[PATCH v3 RESEND] regmap: Add regmap_noinc_write API
The regmap API had a noinc_read function added for instances where devices
supported returning data from an internal FIFO in a single read.
This commit adds the noinc_write variant to allow writing to a non
incrementing register, this is used in devices such as the sx1301 for
loading firmware.
Signed-off-by: Ben Whitten
---
drivers/base/regmap/internal.h | 3 ++
drivers/base/regmap/regmap.c | 77 ++
include/linux/regmap.h | 19 +++
3 files changed, 99 insertions(+)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index a6bf34d63..404f123 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -94,11 +94,13 @@ struct regmap {
bool (*readable_reg)(struct device *dev, unsigned int reg);
bool (*volatile_reg)(struct device *dev, unsigned int reg);
bool (*precious_reg)(struct device *dev, unsigned int reg);
+ bool (*writeable_noinc_reg)(struct device *dev, unsigned int reg);
bool (*readable_noinc_reg)(struct device *dev, unsigned int reg);
const struct regmap_access_table *wr_table;
const struct regmap_access_table *rd_table;
const struct regmap_access_table *volatile_table;
const struct regmap_access_table *precious_table;
+ const struct regmap_access_table *wr_noinc_table;
const struct regmap_access_table *rd_noinc_table;
int (*reg_read)(void *context, unsigned int reg, unsigned int *val);
@@ -183,6 +185,7 @@ bool regmap_writeable(struct regmap *map, unsigned int reg);
bool regmap_readable(struct regmap *map, unsigned int reg);
bool regmap_volatile(struct regmap *map, unsigned int reg);
bool regmap_precious(struct regmap *map, unsigned int reg);
+bool regmap_writeable_noinc(struct regmap *map, unsigned int reg);
bool regmap_readable_noinc(struct regmap *map, unsigned int reg);
int _regmap_write(struct regmap *map, unsigned int reg,
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 0360a90..d4f1fc6 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -168,6 +168,17 @@ bool regmap_precious(struct regmap *map, unsigned int reg)
return false;
}
+bool regmap_writeable_noinc(struct regmap *map, unsigned int reg)
+{
+ if (map->writeable_noinc_reg)
+ return map->writeable_noinc_reg(map->dev, reg);
+
+ if (map->wr_noinc_table)
+ return regmap_check_range_table(map, reg, map->wr_noinc_table);
+
+ return true;
+}
+
bool regmap_readable_noinc(struct regmap *map, unsigned int reg)
{
if (map->readable_noinc_reg)
@@ -777,11 +788,13 @@ struct regmap *__regmap_init(struct device *dev,
map->rd_table = config->rd_table;
map->volatile_table = config->volatile_table;
map->precious_table = config->precious_table;
+ map->wr_noinc_table = config->wr_noinc_table;
map->rd_noinc_table = config->rd_noinc_table;
map->writeable_reg = config->writeable_reg;
map->readable_reg = config->readable_reg;
map->volatile_reg = config->volatile_reg;
map->precious_reg = config->precious_reg;
+ map->writeable_noinc_reg = config->writeable_noinc_reg;
map->readable_noinc_reg = config->readable_noinc_reg;
map->cache_type = config->cache_type;
@@ -1298,6 +1311,7 @@ int regmap_reinit_cache(struct regmap *map, const struct
regmap_config *config)
map->readable_reg = config->readable_reg;
map->volatile_reg = config->volatile_reg;
map->precious_reg = config->precious_reg;
+ map->writeable_noinc_reg = config->writeable_noinc_reg;
map->readable_noinc_reg = config->readable_noinc_reg;
map->cache_type = config->cache_type;
@@ -1898,6 +1912,69 @@ int regmap_raw_write(struct regmap *map, unsigned int
reg,
EXPORT_SYMBOL_GPL(regmap_raw_write);
/**
+ * regmap_noinc_write(): Write data from a register without incrementing the
+ * register number
+ *
+ * @map: Register map to write to
+ * @reg: Register to write to
+ * @val: Pointer to data buffer
+ * @val_len: Length of output buffer in bytes.
+ *
+ * The regmap API usually assumes that bulk bus write operations will write a
+ * range of registers. Some devices have certain registers for which a write
+ * operation can write to an internal FIFO.
+ *
+ * The target register must be volatile but registers after it can be
+ * completely unrelated cacheable registers.
+ *
+ * This will attempt multiple writes as required to write val_len bytes.
+ *
+ * A value of zero will be returned on success, a negative errno will be
+ * returned in error cases.
+ */
+int regmap_noinc_write(struct regmap *map, unsigned int reg,
+ const void *val, size_t val_len)
+{
+ size_t write_len;
+ int ret;
+
+ if (!map->bus)
+ return -EINVAL;
+ if (!map->bus->write)
+ return
[PATCH] ARM: dts: imx6sx-sdb: Add flexcan support
From: Dong Aisheng
CAN transceiver is different on RevA and RevB board.
It's active high on RevA while active low on Rev B.
Signed-off-by: Dong Aisheng
Signed-off-by: Joakim Zhang
---
arch/arm/boot/dts/imx6sx-sdb.dts | 5
arch/arm/boot/dts/imx6sx-sdb.dtsi | 42 +++
2 files changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 6dd9bebfe027..092b8de142a8 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -10,6 +10,11 @@
/ {
model = "Freescale i.MX6 SoloX SDB RevB Board";
+
+ /* Transceiver EN/STBY is active low on RevB board */
+ reg_can_stby: regulator-can-stby {
+ gpio = <&gpio4 27 GPIO_ACTIVE_LOW>;
+ };
};
&i2c1 {
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi
b/arch/arm/boot/dts/imx6sx-sdb.dtsi
index f8f31872fa14..e37ec4b396a2 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dtsi
+++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi
@@ -136,6 +136,20 @@
regulator-max-microvolt = <500>;
};
+ reg_can_en: regulator-can-en {
+ compatible = "regulator-fixed";
+ regulator-name = "can-en";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
+ reg_can_stby: regulator-can-stby {
+ compatible = "regulator-fixed";
+ regulator-name = "can-stby";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+
sound {
compatible = "fsl,imx6sx-sdb-wm8962", "fsl,imx-audio-wm8962";
model = "wm8962-audio";
@@ -202,6 +216,20 @@
status = "okay";
};
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ xceiver-supply = <®_can_stby>;
+ status = "okay";
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ xceiver-supply = <®_can_stby>;
+ status = "okay";
+};
+
&i2c3 {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -397,6 +425,20 @@
>;
};
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6SX_PAD_QSPI1B_DQS__CAN1_TX 0x1b020
+ MX6SX_PAD_QSPI1A_SS1_B__CAN1_RX 0x1b020
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX6SX_PAD_QSPI1B_SS1_B__CAN2_RX 0x1b020
+ MX6SX_PAD_QSPI1A_DQS__CAN2_TX 0x1b020
+ >;
+ };
+
pinctrl_gpio_keys: gpio_keysgrp {
fsl,pins = <
MX6SX_PAD_CSI_DATA04__GPIO1_IO_18 0x17059
--
2.17.1
RE: [LINUX PATCH v11 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller
Hi Boris,
Sorry for the late reply.
I am busy with some other work.
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Thursday, October 4, 2018 1:09 AM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; Michal Simek
> ; linux-...@lists.infradead.org;
> linux-kernel@vger.kernel.org;
> nagasures...@gmail.com
> Subject: Re: [LINUX PATCH v11 3/3] mtd: rawnand: arasan: Add support for
> Arasan
> NAND Flash Controller
>
> Hi Naga,
>
> On Tue, 25 Sep 2018 17:50:31 +0530
> Naga Sureshkumar Relli wrote:
>
> > +static int anfc_read_param_get_feature_sp_read_type_exec(struct nand_chip
> > *chip,
> > +const struct nand_subop
> > +*subop)
> > +{
> > + const struct nand_op_instr *instr;
> > + struct anfc_nand_controller *nfc = to_anfc(chip->controller);
> > + unsigned int op_id, len;
> > + struct anfc_op nfc_op = {};
> > + struct mtd_info *mtd = nand_to_mtd(chip);
> > + struct anfc_nand_chip *achip = to_anfc_nand(chip);
> > + u32 dma_mode, addrcycles, write_size;
> > +
> > + anfc_parse_instructions(chip, subop, &nfc_op);
> > + instr = nfc_op.data_instr;
> > + op_id = nfc_op.data_instr_idx;
> > +
> > + if (nfc_op.cmds[0] == NAND_CMD_PARAM) {
> > + nfc->prog = PROG_RDPARAM;
> > + dma_mode = 0;
> > + addrcycles = 1;
> > + write_size = 0;
> > + }
> > + if (nfc_op.cmds[0] == NAND_CMD_GET_FEATURES) {
> > + nfc->prog = PROG_GET_FEATURE;
> > + dma_mode = 0;
> > + addrcycles = 1;
> > + write_size = 0;
> > + }
> > + if (nfc_op.cmds[0] == NAND_CMD_READ0) {
> > + nfc->prog = PROG_PGRD;
> > + addrcycles = achip->raddr_cycles + achip->caddr_cycles;
> > + write_size = mtd->writesize;
> > + dma_mode = 1;
> > + }
> > +
>
> Sorry, but I still don't understand why nfc->prog is different. Did you try
> using
> PROG_PGRD for all these ops? I mean, the sequence is the same, and you keep
> passing the
> opcode and the number of address cycles to the engine using other reg fields.
Yes, I tried it now with PROG_PGRD and I don't see any issues.
I will update the same in next version of patch.
Thanks for your suggestion.
>
> Also, you're not using the addrcycles info provided by the the address
> instruction and instead
> deduce it based on the opcode, which is wrong.
> To make it clearer, I'd like to avoid those nfc_op.cmds[0] == NAND_OPCODE
> tests,
> because it's exactly the kind of things we were trying to get rid off by
> introducing the -
> >exec_op() interface.
Ok. I understand, I will remove hardcoding the commands in the driver.
And I will change the driver to read addrcycles info from address instruction.
Thanks,
Naga Sureshkumar Relli
>
> > + anfc_prepare_cmd(nfc, nfc_op.cmds[0], 0, dma_mode, write_size,
> > +addrcycles);
> > + anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +
> > + if (!nfc_op.data_instr)
> > + return 0;
> > +
> > + len = nand_subop_get_data_len(subop, op_id);
> > + anfc_rw_pio_op(mtd, nfc->buf, roundup(len, 4), 1, nfc->prog, 1, 0);
> > + memcpy(instr->ctx.data.buf.in, nfc->buf, len);
> > +
> > + return 0;
> > +}
RE: [LINUX PATCH v11 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller
Hi Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Thursday, October 4, 2018 1:17 AM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; Michal Simek
> ; linux-...@lists.infradead.org;
> linux-kernel@vger.kernel.org;
> nagasures...@gmail.com
> Subject: Re: [LINUX PATCH v11 3/3] mtd: rawnand: arasan: Add support for
> Arasan
> NAND Flash Controller
>
> On Tue, 25 Sep 2018 17:50:31 +0530
> Naga Sureshkumar Relli wrote:
>
> > +static int anfc_zero_len_page_write_type_exec(struct nand_chip *chip,
> > + const struct nand_subop *subop) {
> > + const struct nand_op_instr *instr;
> > + struct anfc_nand_chip *achip = to_anfc_nand(chip);
> > + struct anfc_nand_controller *nfc = to_anfc(chip->controller);
> > + unsigned int op_id;
> > + struct anfc_op nfc_op = {};
> > + struct mtd_info *mtd = nand_to_mtd(chip);
> > + u32 addrcycles;
> > +
> > + anfc_parse_instructions(chip, subop, &nfc_op);
> > + nfc->prog = PROG_PGRD;
> > + instr = nfc_op.data_instr;
> > + op_id = nfc_op.data_instr_idx;
> > +
> > + addrcycles = achip->raddr_cycles + achip->caddr_cycles;
> > +
> > + anfc_prepare_cmd(nfc, nfc_op.cmds[0], NAND_CMD_PAGEPROG, 1,
>
> Why are the second opcode and the number of address cycles hardcoded.
> That's simply not future-proof, and I don't want that. Also, I don't
> understand why you do
> that, you have all the information you need in subop and you keep guessing
> some parameters.
Ok, I will remove all these hard coding commands from the driver, instead I
will use nfc_op.cmds[0], nfc_op.cmds[1].
Thanks,
Naga Sureshkumar Relli
>
> > +mtd->writesize, addrcycles);
> > + anfc_setpagecoladdr(nfc, nfc_op.row, nfc_op.col);
> > +
> > + return 0;
> > +}
[PATCH v3 2/5] mfd: lochnagar: Add support for the Cirrus Logic Lochnagar
Lochnagar is an evaluation and development board for Cirrus
Logic Smart CODEC and Amp devices. It allows the connection of
most Cirrus Logic devices on mini-cards, as well as allowing
connection of various application processor systems to provide a
full evaluation platform. This driver supports the board
controller chip on the Lochnagar board. Audio system topology,
clocking and power can all be controlled through the Lochnagar
controller chip, allowing the device under test to be used in
a variety of possible use cases.
As the Lochnagar is a fairly complex device this MFD driver
allows the drivers for the various features to be bound
in. Initially clocking, regulator and pinctrl will be added as
these are necessary to configure the system. But in time at least
audio and voltage/current monitoring will also be added.
Signed-off-by: Charles Keepax
---
Changes since v2:
- Minor updates to the device names bound in for the clock driver
Thanks,
Charles
MAINTAINERS | 13 +
drivers/mfd/Kconfig | 8 +
drivers/mfd/Makefile| 2 +
drivers/mfd/lochnagar-i2c.c | 732
include/linux/mfd/lochnagar.h | 48 +++
include/linux/mfd/lochnagar1_regs.h | 157
include/linux/mfd/lochnagar2_regs.h | 253 +
7 files changed, 1213 insertions(+)
create mode 100644 drivers/mfd/lochnagar-i2c.c
create mode 100644 include/linux/mfd/lochnagar.h
create mode 100644 include/linux/mfd/lochnagar1_regs.h
create mode 100644 include/linux/mfd/lochnagar2_regs.h
diff --git a/MAINTAINERS b/MAINTAINERS
index d9e6d86488df4..f1f3494ac5cd8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3557,6 +3557,19 @@ L: net...@vger.kernel.org
S: Maintained
F: drivers/net/ethernet/cirrus/ep93xx_eth.c
+CIRRUS LOGIC LOCHNAGAR DRIVER
+M: Charles Keepax
+M: Richard Fitzgerald
+L: patc...@opensource.cirrus.com
+S: Supported
+F: drivers/clk/clk-lochnagar.c
+F: drivers/mfd/lochnagar-i2c.c
+F: drivers/pinctrl/cirrus/pinctrl-lochnagar.c
+F: drivers/regulator/lochnagar-regulator.c
+F: include/dt-bindings/clk/lochnagar.h
+F: include/dt-bindings/pinctrl/lochnagar.h
+F: include/linux/mfd/lochnagar*
+
CISCO FCOE HBA DRIVER
M: Satish Kharat
M: Sesidhar Baddela
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f3a5f8d027906..dc64151373714 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1676,6 +1676,14 @@ config MFD_VX855
VIA VX855/VX875 south bridge. You will need to enable the vx855_spi
and/or vx855_gpio drivers for this to do anything useful.
+config MFD_LOCHNAGAR
+ bool "Cirrus Logic Lochnagar Audio Development Board"
+ select MFD_CORE
+ select REGMAP_I2C
+ depends on I2C=y && OF
+ help
+ Support for Cirrus Logic Lochnagar audio development board.
+
config MFD_ARIZONA
select REGMAP
select REGMAP_IRQ
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5856a9489cbd8..f16773cb887ff 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -37,6 +37,8 @@ obj-$(CONFIG_MFD_T7L66XB) += t7l66xb.o tmio_core.o
obj-$(CONFIG_MFD_TC6387XB) += tc6387xb.o tmio_core.o
obj-$(CONFIG_MFD_TC6393XB) += tc6393xb.o tmio_core.o
+obj-$(CONFIG_MFD_LOCHNAGAR)+= lochnagar-i2c.o
+
obj-$(CONFIG_MFD_ARIZONA) += arizona-core.o
obj-$(CONFIG_MFD_ARIZONA) += arizona-irq.o
obj-$(CONFIG_MFD_ARIZONA_I2C) += arizona-i2c.o
diff --git a/drivers/mfd/lochnagar-i2c.c b/drivers/mfd/lochnagar-i2c.c
new file mode 100644
index 0..b878a79a49066
--- /dev/null
+++ b/drivers/mfd/lochnagar-i2c.c
@@ -0,0 +1,732 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Lochnagar I2C bus interface
+ *
+ * Copyright (c) 2012-2018 Cirrus Logic, Inc. and
+ * Cirrus Logic International Semiconductor Ltd.
+ *
+ * Author: Charles Keepax
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define LOCHNAGAR_BOOT_RETRIES 10
+#define LOCHNAGAR_BOOT_DELAY_MS350
+
+#define LOCHNAGAR_CONFIG_POLL_US 1
+
+static bool lochnagar1_readable_register(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case LOCHNAGAR_SOFTWARE_RESET:
+ case LOCHNAGAR_FIRMWARE_ID1:
+ case LOCHNAGAR_FIRMWARE_ID2:
+ case LOCHNAGAR1_CDC_AIF1_SEL:
+ case LOCHNAGAR1_CDC_AIF2_SEL:
+ case LOCHNAGAR1_CDC_AIF3_SEL:
+ case LOCHNAGAR1_CDC_MCLK1_SEL:
+ case LOCHNAGAR1_CDC_MCLK2_SEL:
+ case LOCHNAGAR1_CDC_AIF_CTRL1:
+ case LOCHNAGAR1_CDC_AIF_CTRL2:
+ case LOCHNAGAR1_EXT_AIF_CTRL:
+ case LOCHNAGAR1_DSP_AIF1_SEL:
+ case LOCHNAGAR1_DSP_AIF2_SEL:
+ case LOCHNAGAR1_DSP_CLKIN_SEL:
+ case LOCHNAGAR1_DSP_AIF:
+ case LOCHNAGAR1_GF_AIF1:
+ case LOCHNAGAR1_GF_AIF2:
+ ca
[PATCH v3 3/5] clk: lochnagar: Add support for the Cirrus Logic Lochnagar
Lochnagar is an evaluation and development board for Cirrus
Logic Smart CODEC and Amp devices. It allows the connection of
most Cirrus Logic devices on mini-cards, as well as allowing
connection of various application processor systems to provide a
full evaluation platform. This driver supports the board
controller chip on the Lochnagar board.
The Lochnagar can take several input clocks from the host system,
provides several of its own clock sources, and provides extensive
routing options for those clocks to be supplied to the attached
CODEC/Amp device.
Signed-off-by: Charles Keepax
---
Changes since v2:
- Remove some unused headers
- Remove an unused check on ena_mask
- Return an out of range value if get_parent fails
- Move to the hw based clock APIs
- Use u16s for register definitions
- Move fixed clocks into DT completely
- Don't use the Lochnagar struct directly
Note that the patch will still need to go through with the MFD stuff
to build correctly.
Thanks,
Charles
drivers/clk/Kconfig | 7 +
drivers/clk/Makefile| 1 +
drivers/clk/clk-lochnagar.c | 368
3 files changed, 376 insertions(+)
create mode 100644 drivers/clk/clk-lochnagar.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 292056bbb30e9..9247c97f85d79 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -219,6 +219,13 @@ config COMMON_CLK_XGENE
---help---
Sypport for the APM X-Gene SoC reference, PLL, and device clocks.
+config COMMON_CLK_LOCHNAGAR
+ tristate "Cirrus Logic Lochnagar clock driver"
+ depends on MFD_LOCHNAGAR
+ help
+ This driver supports the clocking features of the Cirrus Logic
+ Lochnagar audio development board.
+
config COMMON_CLK_NXP
def_bool COMMON_CLK && (ARCH_LPC18XX || ARCH_LPC32XX)
select REGMAP_MMIO if ARCH_LPC32XX
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index a84c5573cabea..0443a7219bdf4 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_COMMON_CLK_GEMINI) += clk-gemini.o
obj-$(CONFIG_COMMON_CLK_ASPEED)+= clk-aspeed.o
obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
obj-$(CONFIG_CLK_HSDK) += clk-hsdk-pll.o
+obj-$(CONFIG_COMMON_CLK_LOCHNAGAR) += clk-lochnagar.o
obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
obj-$(CONFIG_COMMON_CLK_MAX9485) += clk-max9485.o
obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
diff --git a/drivers/clk/clk-lochnagar.c b/drivers/clk/clk-lochnagar.c
new file mode 100644
index 0..764ee326957a5
--- /dev/null
+++ b/drivers/clk/clk-lochnagar.c
@@ -0,0 +1,368 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Lochnagar clock control
+ *
+ * Copyright (c) 2017-2018 Cirrus Logic, Inc. and
+ * Cirrus Logic International Semiconductor Ltd.
+ *
+ * Author: Charles Keepax
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define LOCHNAGAR_NUM_CLOCKS (LOCHNAGAR_SPDIF_CLKOUT + 1)
+
+struct lochnagar_clk {
+ const char * const name;
+ struct clk_hw hw;
+
+ struct lochnagar_clk_priv *priv;
+
+ u16 cfg_reg;
+ u16 ena_mask;
+ u16 dir_mask; /* Control bit to set clock as a source or sink */
+
+ u16 src_reg;
+ u16 src_mask;
+};
+
+struct lochnagar_clk_priv {
+ struct device *dev;
+ struct regmap *regmap;
+ enum lochnagar_type type;
+
+ const char **parents;
+ unsigned int nparents;
+
+ struct lochnagar_clk lclks[LOCHNAGAR_NUM_CLOCKS];
+
+ struct clk_hw_onecell_data *clk_data;
+};
+
+static const char * const lochnagar1_clk_parents[] = {
+ "ln-none",
+ "ln-spdif-mclk",
+ "ln-psia1-mclk",
+ "ln-psia2-mclk",
+ "ln-cdc-clkout",
+ "ln-dsp-clkout",
+ "ln-pmic-32k",
+ "ln-gf-mclk1",
+ "ln-gf-mclk3",
+ "ln-gf-mclk2",
+ "ln-gf-mclk4",
+};
+
+static const char * const lochnagar2_clk_parents[] = {
+ "ln-none",
+ "ln-cdc-clkout",
+ "ln-dsp-clkout",
+ "ln-pmic-32k",
+ "ln-spdif-mclk",
+ "ln-clk-12m",
+ "ln-clk-11m",
+ "ln-clk-24m",
+ "ln-clk-22m",
+ "ln-reserved",
+ "ln-usb-clk-24m",
+ "ln-gf-mclk1",
+ "ln-gf-mclk3",
+ "ln-gf-mclk2",
+ "ln-psia1-mclk",
+ "ln-psia2-mclk",
+ "ln-spdif-clkout",
+ "ln-adat-clkout",
+ "ln-usb-clk-12m",
+};
+
+#define LN1_CLK(ID, NAME, REG) \
+ [LOCHNAGAR_##ID] = { \
+ .name = NAME, \
+ .cfg_reg = LOCHNAGAR1_##REG, \
+ .ena_mask = LOCHNAGAR1_##ID##_ENA_MASK, \
+ .src_reg = LOCHNAGAR1_##ID##_SEL, \
+ .src_mask = LOCHNAGAR1_SRC_MASK, \
+ }
+
+#define LN2_CLK(ID, NAME) \
+ [LOCHNAGAR_##ID] = { \
+ .name = NAME, \
+ .cfg_reg = LOCHNAGAR2
[PATCH v3 5/5] pinctrl: lochnagar: Add support for the Cirrus Logic Lochnagar
Lochnagar is an evaluation and development board for Cirrus
Logic Smart CODEC and Amp devices. It allows the connection of
most Cirrus Logic devices on mini-cards, as well as allowing
connection of various application processor systems to provide a
full evaluation platform. This driver supports the board
controller chip on the Lochnagar board.
Lochnagar provides many pins which can generally be used for an
audio function such as an AIF or a PDM interface, but also as
GPIOs.
Signed-off-by: Charles Keepax
---
Changes since v2:
- Updated aif-master/aif-slave to use a vendor prefix
- Correctly get and put of_node pointer in probe/remove
Thanks,
Charles
drivers/pinctrl/cirrus/Kconfig | 10 +
drivers/pinctrl/cirrus/Makefile|2 +
drivers/pinctrl/cirrus/pinctrl-lochnagar.c | 1167
drivers/pinctrl/cirrus/pinctrl-lochnagar.h | 112 +++
4 files changed, 1291 insertions(+)
create mode 100644 drivers/pinctrl/cirrus/pinctrl-lochnagar.c
create mode 100644 drivers/pinctrl/cirrus/pinctrl-lochnagar.h
diff --git a/drivers/pinctrl/cirrus/Kconfig b/drivers/pinctrl/cirrus/Kconfig
index 27013e5949bc1..74af07e251741 100644
--- a/drivers/pinctrl/cirrus/Kconfig
+++ b/drivers/pinctrl/cirrus/Kconfig
@@ -1,3 +1,13 @@
+config PINCTRL_LOCHNAGAR
+ tristate "Cirrus Logic Lochnagar pinctrl driver"
+ depends on MFD_LOCHNAGAR
+ select PINMUX
+ select PINCONF
+ select GENERIC_PINCONF
+ help
+ This driver supports configuring the GPIO and other pin configuration
+ of the Cirrus Logic Lochnagar audio development board.
+
# This is all selected by the Madera MFD driver Kconfig options
config PINCTRL_MADERA
tristate
diff --git a/drivers/pinctrl/cirrus/Makefile b/drivers/pinctrl/cirrus/Makefile
index 6e4938cde9e30..20baebf438f62 100644
--- a/drivers/pinctrl/cirrus/Makefile
+++ b/drivers/pinctrl/cirrus/Makefile
@@ -1,4 +1,6 @@
# Cirrus Logic pinctrl drivers
+obj-$(CONFIG_PINCTRL_LOCHNAGAR)+= pinctrl-lochnagar.o
+
pinctrl-madera-objs:= pinctrl-madera-core.o
ifeq ($(CONFIG_PINCTRL_CS47L35),y)
pinctrl-madera-objs+= pinctrl-cs47l35.o
diff --git a/drivers/pinctrl/cirrus/pinctrl-lochnagar.c
b/drivers/pinctrl/cirrus/pinctrl-lochnagar.c
new file mode 100644
index 0..d5dc8362cc48d
--- /dev/null
+++ b/drivers/pinctrl/cirrus/pinctrl-lochnagar.c
@@ -0,0 +1,1167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Lochnagar pin and GPIO control
+ *
+ * Copyright (c) 2017-2018 Cirrus Logic, Inc. and
+ * Cirrus Logic International Semiconductor Ltd.
+ *
+ * Author: Charles Keepax
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include "../pinctrl-utils.h"
+#include "pinctrl-lochnagar.h"
+
+#define LN_PIN_GPIO(REV, ID, NAME, REG, SHIFT, INVERT) \
+static const struct lochnagar_pin lochnagar##REV##_##ID##_pin = { \
+ .name = NAME, .type = LN_PTYPE_GPIO, .reg = LOCHNAGAR##REV##_##REG, \
+ .shift = LOCHNAGAR##REV##_##SHIFT##_SHIFT, .invert = INVERT, \
+}
+
+#define LN_PIN_SAIF(REV, ID, NAME) \
+static const struct lochnagar_pin lochnagar##REV##_##ID##_pin = \
+ { .name = NAME, .type = LN_PTYPE_AIF, }
+
+#define LN_PIN_AIF(REV, ID) \
+ LN_PIN_SAIF(REV, ID##_BCLK, LN_##ID##_STR"-bclk"); \
+ LN_PIN_SAIF(REV, ID##_LRCLK, LN_##ID##_STR"-lrclk"); \
+ LN_PIN_SAIF(REV, ID##_RXDAT, LN_##ID##_STR"-rxdat"); \
+ LN_PIN_SAIF(REV, ID##_TXDAT, LN_##ID##_STR"-txdat")
+
+#define LN1_PIN_GPIO(ID, NAME, REG, SHIFT, INVERT) \
+ LN_PIN_GPIO(1, ID, NAME, REG, SHIFT, INVERT)
+
+#define LN1_PIN_MUX(ID, NAME) \
+static const struct lochnagar_pin lochnagar1_##ID##_pin = \
+ { .name = NAME, .type = LN_PTYPE_MUX, .reg = LOCHNAGAR1_##ID, }
+
+#define LN1_PIN_AIF(ID) LN_PIN_AIF(1, ID)
+
+#define LN2_PIN_GPIO(ID, NAME, REG, SHIFT, INVERT) \
+ LN_PIN_GPIO(2, ID, NAME, REG, SHIFT, INVERT)
+
+#define LN2_PIN_MUX(ID, NAME) \
+static const struct lochnagar_pin lochnagar2_##ID##_pin = \
+ { .name = NAME, .type = LN_PTYPE_MUX, .reg = LOCHNAGAR2_GPIO_##ID, }
+
+#define LN2_PIN_AIF(ID) LN_PIN_AIF(2, ID)
+
+#define LN2_PIN_GAI(ID) \
+ LN2_PIN_MUX(ID##_BCLK, LN_##ID##_STR"-bclk"); \
+ LN2_PIN_MUX(ID##_LRCLK, LN_##ID##_STR"-lrclk"); \
+ LN2_PIN_MUX(ID##_RXDAT, LN_##ID##_STR"-rxdat"); \
+ LN2_PIN_MUX(ID##_TXDAT, LN_##ID##_STR"-txdat")
+
+#define LN_PIN(REV, ID) [LOCHNAGAR##REV##_PIN_##ID] = { \
+ .number = LOCHNAGAR##REV##_PIN_##ID, \
+ .name = lochnagar##REV##_##ID##_pin.name, \
+ .drv_data = (void *)&lochnagar##REV##_##ID##_pin, \
+}
+
+#define LN1_PIN(ID) LN_PIN(1, ID)
+#define LN2_PIN(ID) LN_PIN(2, ID)
+
+#define LN_PINS(REV, ID) \
+ LN_PIN(REV, ID##_BCLK), LN_PIN(REV, ID##_LRCLK), \
+ LN_PIN(REV, ID##_RXDAT), LN_PIN(REV, ID##_TXDAT)
+
+#define LN1_PINS(ID) LN_PINS(1, ID)
+#define LN2_PINS(ID) LN_PINS(2
[PATCH v3 4/5] regulator: lochnagar: Add support for the Cirrus Logic Lochnagar
Lochnagar is an evaluation and development board for Cirrus
Logic Smart CODEC and Amp devices. It allows the connection of
most Cirrus Logic devices on mini-cards, as well as allowing
connection of various application processor systems to provide a
full evaluation platform. This driver supports the board
controller chip on the Lochnagar board.
The Lochnagar board provides power supplies for the attached
CODEC/Amp device. Currently this driver supports the microphone
supplies and the digital core voltage for the attached
device. There are some additional supplies that will be
added in time but these supplies are sufficient for most
systems/use-cases.
Signed-off-by: Charles Keepax
---
No changes since v2.
Thanks,
Charles
drivers/regulator/Kconfig | 7 +
drivers/regulator/Makefile | 1 +
drivers/regulator/lochnagar-regulator.c | 255
3 files changed, 263 insertions(+)
create mode 100644 drivers/regulator/lochnagar-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 329cdd33ed624..3eda02afdcdeb 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -356,6 +356,13 @@ config REGULATOR_LM363X
One boost output voltage is configurable and always on.
Other LDOs are used for the display module.
+config REGULATOR_LOCHNAGAR
+ tristate "Cirrus Logic Lochnagar regulator driver"
+ depends on MFD_LOCHNAGAR
+ help
+ This enables regulator support on the Cirrus Logic Lochnagar audio
+ development board.
+
config REGULATOR_LP3971
tristate "National Semiconductors LP3971 PMIC regulator driver"
depends on I2C
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 801d9a34a2037..0c715fa77bd62 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_REGULATOR_HI655X) += hi655x-regulator.o
obj-$(CONFIG_REGULATOR_ISL6271A) += isl6271a-regulator.o
obj-$(CONFIG_REGULATOR_ISL9305) += isl9305.o
obj-$(CONFIG_REGULATOR_LM363X) += lm363x-regulator.o
+obj-$(CONFIG_REGULATOR_LOCHNAGAR) += lochnagar-regulator.o
obj-$(CONFIG_REGULATOR_LP3971) += lp3971.o
obj-$(CONFIG_REGULATOR_LP3972) += lp3972.o
obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
diff --git a/drivers/regulator/lochnagar-regulator.c
b/drivers/regulator/lochnagar-regulator.c
new file mode 100644
index 0..54d791d204080
--- /dev/null
+++ b/drivers/regulator/lochnagar-regulator.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Lochnagar regulator driver
+ *
+ * Copyright (c) 2017-2018 Cirrus Logic, Inc. and
+ * Cirrus Logic International Semiconductor Ltd.
+ *
+ * Author: Charles Keepax
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static const struct regulator_ops lochnagar_micvdd_ops = {
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+
+ .get_voltage_sel = regulator_get_voltage_sel_regmap,
+ .set_voltage_sel = regulator_set_voltage_sel_regmap,
+};
+
+static const struct regulator_linear_range lochnagar_micvdd_ranges[] = {
+ REGULATOR_LINEAR_RANGE(100, 0,0xC, 5),
+ REGULATOR_LINEAR_RANGE(170, 0xD, 0x1F, 10),
+};
+
+static int lochnagar_micbias_enable(struct regulator_dev *rdev)
+{
+ struct lochnagar *lochnagar = rdev_get_drvdata(rdev);
+ int ret;
+
+ mutex_lock(&lochnagar->analogue_config_lock);
+
+ ret = regulator_enable_regmap(rdev);
+ if (ret < 0)
+ goto err;
+
+ ret = lochnagar_update_config(lochnagar);
+
+err:
+ mutex_unlock(&lochnagar->analogue_config_lock);
+
+ return ret;
+}
+
+static int lochnagar_micbias_disable(struct regulator_dev *rdev)
+{
+ struct lochnagar *lochnagar = rdev_get_drvdata(rdev);
+ int ret;
+
+ mutex_lock(&lochnagar->analogue_config_lock);
+
+ ret = regulator_disable_regmap(rdev);
+ if (ret < 0)
+ goto err;
+
+ ret = lochnagar_update_config(lochnagar);
+
+err:
+ mutex_unlock(&lochnagar->analogue_config_lock);
+
+ return ret;
+}
+
+static const struct regulator_ops lochnagar_micbias_ops = {
+ .enable = lochnagar_micbias_enable,
+ .disable = lochnagar_micbias_disable,
+ .is_enabled = regulator_is_enabled_regmap,
+};
+
+static const struct regulator_ops lochnagar_vddcore_ops = {
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage = regulator_map_voltage_linear_range,
+
+ .get_voltage
[PATCH v3 1/5] mfd: lochnagar: Add initial binding documentation
Lochnagar is an evaluation and development board for Cirrus Logic Smart CODEC and Amp devices. It allows the connection of most Cirrus Logic devices on mini-cards, as well as allowing connection of various application processor systems to provide a full evaluation platform. This driver supports the board controller chip on the Lochnagar board. Signed-off-by: Charles Keepax Acked-by: Rob Herring --- Changes since v2: - Used vendor prefix on aif-master and aif-slave - Used -gpios instead of -gpio in example DT - Used - rather than _ on node names in example DT - Removed some clocks from the clock DT binding doc since they are now being registered purely through DT as fixed clocks Thanks, Charles .../devicetree/bindings/mfd/cirrus,lochnagar.txt | 230 + include/dt-bindings/clk/lochnagar.h| 26 +++ include/dt-bindings/pinctrl/lochnagar.h| 132 3 files changed, 388 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt create mode 100644 include/dt-bindings/clk/lochnagar.h create mode 100644 include/dt-bindings/pinctrl/lochnagar.h diff --git a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt new file mode 100644 index 0..4bed850aa7101 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.txt @@ -0,0 +1,230 @@ +Cirrus Logic Lochnagar Audio Development Board + +Lochnagar is an evaluation and development board for Cirrus Logic +Smart CODEC and Amp devices. It allows the connection of most Cirrus +Logic devices on mini-cards, as well as allowing connection of +various application processor systems to provide a full evaluation +platform. Audio system topology, clocking and power can all be +controlled through the Lochnagar, allowing the device under test +to be used in a variety of possible use cases. + +Also see these documents for generic binding information: + [1] GPIO : ../gpio/gpio.txt + [2] Pinctrl: ../pinctrl/pinctrl-bindings.txt + [3] Clock : ../clock/clock-bindings.txt + [4] Regulator: ../regulator/regulator.txt + +And these for relevant defines: + [5] include/dt-bindings/pinctrl/lochnagar.h + [6] include/dt-bindings/clock/lochnagar.h + +Required properties: + + - compatible : One of the following strings: + "cirrus,lochnagar1" + "cirrus,lochnagar2" + + - reg : I2C slave address + + - gpio-controller : Indicates this device is a GPIO controller. + - #gpio-cells : Must be 2. The first cell is the pin number, see +[5] for available pins and the second cell is used to specify +optional parameters, see [1]. + - gpio-ranges : Range of pins managed by the GPIO controller, see +[1]. Both the GPIO and Pinctrl base should be set to zero and the +count to the appropriate of the LOCHNAGARx_PIN_NUM_GPIOS define, +see [5]. + + - reset-gpios : Reset line to the Lochnagar, see [1]. + + - #clock-cells : Must be 1. The first cell indicates the clock +number, see [6] for available clocks and [3]. + + - pinctrl-names : A pinctrl state named "default" must be defined. + - pinctrl-0 : A phandle to the default pinctrl state. + + - SYSVDD-supply: Primary power supply for the Lochnagar. + +Optional properties: + + - present-gpios : Host present line, indicating the presence of a +host system, see [1]. This can be omitted if the present line is +tied in hardware. + + - clocks : Must contain an entry for each clock in clock-names. + - clock-names : May contain entries for each of the following +clocks: + - ln-cdc-clkout : Output clock from CODEC card. + - ln-dsp-clkout : Output clock from DSP card. + - ln-gf-mclk1,ln-gf-mclk2,ln-gf-mclk3,ln-gf-mclk4 : Optional + input audio clocks from host system. + - ln-psia1-mclk, ln-psia2-mclk : Optional input audio clocks from + external connector. + - ln-spdif-clkout : Optional input audio clock from SPDIF. + - ln-adat-clkout : Optional input audio clock from ADAT. + + - assigned-clocks : A list of Lochnagar clocks to be reparented, see +[6] for available clocks. + - assigned-clock-parents : Parents to be assigned to the clocks +listed in "assigned-clocks". + + - MICBIAS1-supply, MICBIAS2-supply: Regulator supplies for the +MICxVDD outputs, supplying the digital microphones, normally +supplied from the attached CODEC. + +Required sub-nodes: + +The pin configurations are defined as a child of the pinctrl states +node, see [2]. Each sub-node can have the following properties: + - groups : A list of groups to select (either this or "pins" must be +specified), available groups: + codec-aif1, codec-aif2, codec-aif3, dsp-aif1, dsp-aif2, psia1, + psia2, gf-aif1, gf-aif2, gf-aif3, gf-aif4, spdif-aif, usb-aif1, + usb-aif2, adat-aif, soundcard-aif + - pins : A list of pin names to select (either this or "groups" must +
Re: [PATCH 2/2] tty: serial: add driver for the SiFive UART
Hi Paul,
I love your patch! Yet something to improve:
[auto build test ERROR on tty/tty-testing]
[also build test ERROR on v4.19-rc8 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Paul-Walmsley/dt-bindings-serial-add-documentation-for-the-SiFive-UART-driver/20181019-165529
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
tty-testing
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> drivers/tty/serial/sifive.c:891:20: error: 'sifive_serial_poll_put_char'
>> undeclared here (not in a function); did you mean
>> 'sifive_serial_clk_notifier'?
.poll_put_char = sifive_serial_poll_put_char,
^~~
sifive_serial_clk_notifier
>> drivers/tty/serial/sifive.c:892:20: error: 'sifive_serial_poll_get_char'
>> undeclared here (not in a function); did you mean
>> 'sifive_serial_poll_put_char'?
.poll_get_char = sifive_serial_poll_get_char,
^~~
sifive_serial_poll_put_char
In file included from drivers/tty/serial/sifive.c:47:0:
drivers/tty/serial/sifive.c:1028:25: error: 'sifive_serial_match' undeclared
here (not in a function); did you mean 'sifive_serial_of_match'?
MODULE_DEVICE_TABLE(of, sifive_serial_match);
^
include/linux/module.h:213:15: note: in definition of macro
'MODULE_DEVICE_TABLE'
extern typeof(name) __mod_##type##__##name##_device_table \
^~~~
include/linux/module.h:213:21: error:
'__mod_of__sifive_serial_match_device_table' aliased to undefined symbol
'sifive_serial_match'
extern typeof(name) __mod_##type##__##name##_device_table \
^
drivers/tty/serial/sifive.c:1028:1: note: in expansion of macro
'MODULE_DEVICE_TABLE'
MODULE_DEVICE_TABLE(of, sifive_serial_match);
^~~
drivers/tty/serial/sifive.c:522:13: warning: '__ssp_wait_for_xmitr' defined
but not used [-Wunused-function]
static void __ssp_wait_for_xmitr(struct sifive_serial_port *ssp)
^~~~
vim +891 drivers/tty/serial/sifive.c
873
874 static const struct uart_ops sifive_serial_uops = {
875 .tx_empty = sifive_serial_tx_empty,
876 .set_mctrl = sifive_serial_set_mctrl,
877 .get_mctrl = sifive_serial_get_mctrl,
878 .stop_tx= sifive_serial_stop_tx,
879 .start_tx = sifive_serial_start_tx,
880 .stop_rx= sifive_serial_stop_rx,
881 .break_ctl = sifive_serial_break_ctl,
882 .startup= sifive_serial_startup,
883 .shutdown = sifive_serial_shutdown,
884 .set_termios= sifive_serial_set_termios,
885 .type = sifive_serial_type,
886 .release_port = sifive_serial_release_port,
887 .request_port = sifive_serial_request_port,
888 .config_port= sifive_serial_config_port,
889 .verify_port= sifive_serial_verify_port,
890 #ifdef CONFIG_CONSOLE_POLL
> 891 .poll_put_char = sifive_serial_poll_put_char,
> 892 .poll_get_char = sifive_serial_poll_get_char,
893 #endif
894 };
895
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH] docs: Extend trusted keys documentation for TPM 2.0
Extend the documentation for trusted keys with documentation for how to set up a key for a TPM 2.0 so it can be used with a TPM 2.0 as well. Signed-off-by: Stefan Berger Reviewed-by: Mimi Zohar --- .../security/keys/trusted-encrypted.rst | 31 ++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst index 3bb24e09a332..6ec6bb2ac497 100644 --- a/Documentation/security/keys/trusted-encrypted.rst +++ b/Documentation/security/keys/trusted-encrypted.rst @@ -18,10 +18,33 @@ integrity verifications match. A loaded Trusted Key can be updated with new when the kernel and initramfs are updated. The same key can have many saved blobs under different PCR values, so multiple boots are easily supported. +TPM 1.2 +--- + By default, trusted keys are sealed under the SRK, which has the default authorization value (20 zeros). This can be set at takeownership time with the trouser's utility: "tpm_takeownership -u -z". +TPM 2.0 +--- + +The user must first create a storage key and make it persistent, so the key is +available after reboot. This can be done using the following commands. + +With the IBM TSS 2 stack:: + + #> tsscreateprimary -hi o -st + Handle 8000 + #> tssevictcontrol -hi o -ho 8000 -hp 8101 + +Or with the Intel TSS 2 stack:: + + #> tpm2_createprimary --hierarchy o -G rsa2048 -o key.ctxt + [...] + handle: 0x80FF + #> tpm2_evictcontrol -c key.ctxt -p 0x8101 + persistentHandle: 0x8101 + Usage:: keyctl add trusted name "new keylen [options]" ring @@ -30,7 +53,9 @@ Usage:: keyctl print keyid options: - keyhandle=ascii hex value of sealing key default 0x4000 (SRK) + keyhandle=ascii hex value of sealing key + TPM 1.2: default 0x4000 (SRK) + TPM 2.0: no default; must be passed every time keyauth= ascii hex auth for sealing key default 0x00...i (40 ascii zeros) blobauth= ascii hex auth for sealed data default 0x00... @@ -84,6 +109,10 @@ Examples of trusted and encrypted key usage: Create and save a trusted key named "kmk" of length 32 bytes:: +Note: When using a TPM 2.0 with a persistent key with handle 0x8101, +append 'keyhandle=0x8101' to statements between quotes, such as +"new 32 keyhandle=0x8101". + $ keyctl add trusted kmk "new 32" @u 440502848 -- 2.17.2
Re: [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement
On 18/10/2018 12:18, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> This fixes the following error as seen post commit daecf46ee0e5
> ("ASoC: soc-core: use snd_soc_dai_link_component for platform") on
> Apalis TK1 after initial probe deferral:
>
> tegra-snd-sgtl5000 sound: ASoC: Both platform name/of_node are set for
> sgtl5000
> tegra-snd-sgtl5000 sound: ASoC: failed to init link sgtl5000
> tegra-snd-sgtl5000 sound: snd_soc_register_card failed (-22)
> tegra-snd-sgtl5000: probe of sound failed with error -22
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> Changes in v1:
> - Split from the Tegra series as suggested by Mark.
> - Fix issue in soc-core rather than working around it in tegra_sgtl5000.
>
> sound/soc/soc-core.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index 6ddcf12bc030..b97624005976 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -2733,7 +2733,7 @@ static int snd_soc_bind_card(struct snd_soc_card *card)
> int snd_soc_register_card(struct snd_soc_card *card)
> {
> int i, ret;
> - struct snd_soc_dai_link *link;
> + struct snd_soc_dai_link *link = NULL;
>
> if (!card->name || !card->dev)
> return -EINVAL;
> @@ -2744,7 +2744,7 @@ int snd_soc_register_card(struct snd_soc_card *card)
> if (ret) {
> dev_err(card->dev, "ASoC: failed to init link %s\n",
> link->name);
> - return ret;
> + goto err;
> }
> }
>
> @@ -2763,7 +2763,17 @@ int snd_soc_register_card(struct snd_soc_card *card)
> mutex_init(&card->mutex);
> mutex_init(&card->dapm_mutex);
>
> - return snd_soc_bind_card(card);
> + ret = snd_soc_bind_card(card);
> + if (ret)
> + goto err;
> +
> + return 0;
> +
> +err:
> + if (link && link->platform)
> + link->platform = NULL;
Looking at snd_soc_init_platform(), it seems that the platform pointer
can be allocated by the machine driver and so if it is not allocated by
the core, then I don't think we should clear it here. Seems we need a
way to determine if this was allocated by the core.
Furthermore, it seems that it is possible that there is more than one
link that might be to be cleared.
Cheers
Jon
--
nvpublic
Re: [PATCHv3 0/6] atomics: generate atomic headers / instrument arm64
Hi Ingo, On Mon, Oct 08, 2018 at 06:15:24PM +0100, Mark Rutland wrote: > On Tue, Sep 04, 2018 at 11:48:24AM +0100, Mark Rutland wrote: > > As previously requested, this is a (trivial) rebase of the remaining > > generated > > atomic patches atop of v4.19-rc2, avoiding any potential conflict with > > Peter's > > ldsem atomic cleanup patch that got taken through the tty tree. > > > > Are you still happy to pick this up? Full blurb below. > > Ping! > > Do you have any comments, or would you be happy to queue this? > > I'm happy to resend come rc1, if you'd prefer? It would be really nice to see this merged. Any chance we could get this queued at -rc1 for 4.21, please? If not, what more needs to be done? Cheers, Will
Re: [PATCH 0/1] ACPI / scan: Create platform device for INT33FE ACPI nodes
On Wednesday, October 17, 2018 1:39:54 PM CEST Andy Shevchenko wrote: > On Wed, Oct 17, 2018 at 11:59 AM Hans de Goede wrote: > > > > Hi Rafael, Andy, > > > > For the why and what of this patch see the (somewhat long) commit message. > > > > The single patch in this set both touches drivers/acpi/scan.c and > > drivers/platform/x86/intel_cht_int33fe.c, this is done this way to avoid > > regressions when bisecting. > > > > The main change here really is to ACPI change and intel_cht_int33fe.c is > > modified to follow suit. Also I do not expect intel_cht_int33fe.c to see > > much changes this cycle. As such I believe it would be best to merge this > > patch through Rafael's tree (after review). > > > > Andy is that ok with you and we have your ack for this? > > I love this patch! > > Definitely, > Acked-by: Andy Shevchenko Patch applied, thanks!
Re: [PATCH] power: reset: at91-reset: enable I-cache for at91sam9260_reset
On Wed, Oct 17, 2018 at 3:10 PM wrote: > > > > > We take the normal path of sys_reboot => kernel_restart => machine_restart > > ... > > > > I added code to print the c1 register in different paths. And I-cache > > is enabled. > > So now I am really confused about why the patch worked. > > Just saying... maybe your instructions add some delay on the execution path > and this is why it helps... try to access cp15 co-processor for read and > write back the value you read without actually to modify it, to see if this > could be the reason: e.g.: > > mrc p15, 0, r0, c1, c0, 0 > orr r1, r1, #4096 // whatever is in r1, doesn't matter > mcr p15, 0, r0, c1, c0, 0 > Yes, this also seems to work. I have over 100 reboots completed with this code. So what could be the issue here? It seem related to the powering down of the sdram at least. This thread on the AT91SAM community deals with the same issue: http://www.at91.com/viewtopic.php?t=25830 There the solution people chose was removing the SDRAM powering down. But that leaves one open to the cause of the errata. Do you have any thought on how to approach this? > Thank you, > Claudiu Beznea > Regards Jonas > > > >> Best regards, > >> Alexander > > > > Jonas > > > >> > >> > >> > > > > -- JONAS DANIELSSON Software Developer +46 72 361 5022 Malmö - Sweden ORBITAL SYSTEMS orbital-systems.com The information contained in this message is intended for the personal and confidential use of the designated recipients named above and may contain confidential and/or privileged material. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error, and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender immediately and delete this e-mail from your system. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by ORBITAL SYSTEMS AB, its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way.
Re: [PATCH v1 1/2] clk: qcom: rcg2: Add support for display port clock ops
Hello Stephen,
On 10/10/2018 2:16 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-10-09 06:57:46)
diff --git a/drivers/clk/qcom/clk-rcg2.c b/drivers/clk/qcom/clk-rcg2.c
index 6e3bd19..ca6142f 100644
--- a/drivers/clk/qcom/clk-rcg2.c
+++ b/drivers/clk/qcom/clk-rcg2.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
Can you also select RATIONAL in the Kconfig language? Yes the clk
subsystem is already selecting it, but it's nice to be explicit in the
subdrivers.
Sure, would take care of adding it in KCONFIG.
#include
#include
#include
@@ -1124,3 +1125,88 @@ int qcom_cc_register_rcg_dfs(struct regmap *regmap,
return 0;
}
EXPORT_SYMBOL_GPL(qcom_cc_register_rcg_dfs);
+
+static int clk_rcg2_dp_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_rcg2 *rcg = to_clk_rcg2(hw);
+ struct freq_tbl f = { 0 };
+ unsigned long src_rate;
+ unsigned long num, den;
+ u32 mask = BIT(rcg->hid_width) - 1;
+ u32 hid_div, cfg;
+ int i, num_parents = clk_hw_get_num_parents(hw);
+
+ src_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
What is this doing? We shouldn't need to check the parent clk for any
rate here when we're setting the rate.
Hmmm, let me get back on this.
+ if (src_rate <= 0) {
+ pr_err("Invalid RCG parent rate\n");
+ return -EINVAL;
+ }
+
+ rational_best_approximation(src_rate, rate,
+ (unsigned long)(1 << 16) - 1,
Use GENMASK?
+ (unsigned long)(1 << 16) - 1, &den, &num);
Same? >
Sure, would use GENMASK.
+
+ if (!num || !den) {
+ pr_err("Invalid MN values derived for requested rate %lu\n",
+ rate);
+ return -EINVAL;
+ }
+
+ regmap_read(rcg->clkr.regmap, rcg->cmd_rcgr + CFG_REG, &cfg);
+ hid_div = cfg;
+ cfg &= CFG_SRC_SEL_MASK;
+ cfg >>= CFG_SRC_SEL_SHIFT;
+
+ for (i = 0; i < num_parents; i++)
+ if (cfg == rcg->parent_map[i].cfg) {
+ f.src = rcg->parent_map[i].src;
+ break;
+ }
+
+ f.pre_div = hid_div;
+ f.pre_div >>= CFG_SRC_DIV_SHIFT;
+ f.pre_div &= mask;
+
+ if (num == den) {
+ f.m = 0;
+ f.n = 0;
+ } else {
+ f.m = num;
+ f.n = den;
+ }
+
+ return clk_rcg2_configure(rcg, &f);
+}
+
+static int clk_rcg2_dp_set_rate_and_parent(struct clk_hw *hw,
+ unsigned long rate, unsigned long parent_rate, u8 index)
+{
+ return clk_rcg2_dp_set_rate(hw, rate, parent_rate);
+}
+
+static int clk_rcg2_dp_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ if (!hw)
+ return -EINVAL;
+
+ if (!clk_hw_get_parent(hw)) {
+ pr_err("Missing the parent for the DP RCG\n");
+ return -EINVAL;
+ }
Let me Harry Potter this stuff. Expelliarmus!
+
+ req->best_parent_rate = clk_hw_get_rate(clk_hw_get_parent(hw));
Presumably we should ask the parent clk for the rate that is requested
here by calling determine rate up and see if the parent can do it. Sure,
this clk does nothing, so we don't really need any sort of op here then
and we can just flag the clk as CLK_SET_RATE_PARENT and let the core do
the rest.
+ return 0;
+}
+
Would remove this.
+const struct clk_ops clk_dp_ops = {
+ .is_enabled = clk_rcg2_is_enabled,
+ .get_parent = clk_rcg2_get_parent,
+ .set_parent = clk_rcg2_set_parent,
+ .recalc_rate = clk_rcg2_recalc_rate,
+ .set_rate = clk_rcg2_dp_set_rate,
+ .set_rate_and_parent = clk_rcg2_dp_set_rate_and_parent,
+ .determine_rate = clk_rcg2_dp_determine_rate,
+};
+EXPORT_SYMBOL_GPL(clk_dp_ops);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
[PATCH v3 0/2] dt-bindings: uniphier: two trivial DT bindings patches
Arnd, Olof,
I know it is very late in this development cycle.
If possible, could you directly apply these two patches
to your ARM-SoC, aiming for the upcoming v4.20-rc1 MW?
If not, I can wait for v4.21-rc1.
Thanks,
Masahiro
Changes in v3:
- Capitalize 'Board' consistently
- Add Rob's Reviewed-by
Changes in v2:
Changes suggested by Rob.
- Move the file to
Documentation/devicetree/bindings/arm/socionext/uniphier.txt
- Group boards by each SoC
Previous post:
v1: https://patchwork.ozlabs.org/patch/842010/
- New patch
Masahiro Yamada (2):
dt-bindings: uniphier: add bindings for UniPhier SoC family
dt-bindings: uniphier: move cache-uniphier.txt to vendor directory
.../arm/{uniphier => socionext}/cache-uniphier.txt | 0
.../devicetree/bindings/arm/socionext/uniphier.txt | 47 ++
MAINTAINERS| 1 +
3 files changed, 48 insertions(+)
rename Documentation/devicetree/bindings/arm/{uniphier =>
socionext}/cache-uniphier.txt (100%)
create mode 100644 Documentation/devicetree/bindings/arm/socionext/uniphier.txt
--
2.7.4
[PATCH v3 2/2] dt-bindings: uniphier: move cache-uniphier.txt to vendor directory
Now, the Socionext vendor directory is available at
Documentation/devicetree/bindings/arm/socionext/
Move cache-uniphier.txt over to it.
Signed-off-by: Masahiro Yamada
Reviewed-by: Rob Herring
---
Changes in v3: None
Changes in v2:
- New patch
.../devicetree/bindings/arm/{uniphier => socionext}/cache-uniphier.txt| 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/arm/{uniphier =>
socionext}/cache-uniphier.txt (100%)
diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
b/Documentation/devicetree/bindings/arm/socionext/cache-uniphier.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
rename to Documentation/devicetree/bindings/arm/socionext/cache-uniphier.txt
--
2.7.4
[PATCH v3 1/2] dt-bindings: uniphier: add bindings for UniPhier SoC family
Document the list of SoCs and boards of UniPhier platform.
Signed-off-by: Masahiro Yamada
Reviewed-by: Rob Herring
---
Changes in v3:
- Capitalize 'Board' consistently
- Add Rob's Reviewed-by
Changes in v2:
Changes suggested by Rob.
- Move the file to
Documentation/devicetree/bindings/arm/socionext/uniphier.txt
- Group boards by each SoC
Previous post:
v1: https://patchwork.ozlabs.org/patch/842010/
.../devicetree/bindings/arm/socionext/uniphier.txt | 47 ++
MAINTAINERS| 1 +
2 files changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/socionext/uniphier.txt
diff --git a/Documentation/devicetree/bindings/arm/socionext/uniphier.txt
b/Documentation/devicetree/bindings/arm/socionext/uniphier.txt
new file mode 100644
index 000..b3ed103
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/socionext/uniphier.txt
@@ -0,0 +1,47 @@
+Socionext UniPhier SoC family
+-
+
+Required properties in the root node:
+ - compatible: should contain board and SoC compatible strings
+
+SoC and board compatible strings:
+ (sorted chronologically)
+
+ - LD4 SoC: "socionext,uniphier-ld4"
+ - Reference Board: "socionext,uniphier-ld4-ref"
+
+ - Pro4 SoC: "socionext,uniphier-pro4"
+ - Reference Board: "socionext,uniphier-pro4-ref"
+ - Ace Board: "socionext,uniphier-pro4-ace"
+ - Sanji Board: "socionext,uniphier-pro4-sanji"
+
+ - sLD8 SoC: "socionext,uniphier-sld8"
+ - Reference Board: "socionext,uniphier-sld8-ref"
+
+ - PXs2 SoC: "socionext,uniphier-pxs2"
+ - Gentil Board:"socionext,uniphier-pxs2-gentil"
+ - Vodka Board: "socionext,uniphier-pxs2-vodka"
+
+ - LD6b SoC: "socionext,uniphier-ld6b"
+ - Reference Board: "socionext,uniphier-ld6b-ref"
+
+ - LD11 SoC: "socionext,uniphier-ld11"
+ - Reference Board: "socionext,uniphier-ld11-ref"
+ - Global Board:"socionext,uniphier-ld11-global"
+
+ - LD20 SoC: "socionext,uniphier-ld20"
+ - Reference Board: "socionext,uniphier-ld20-ref"
+ - Global Board:"socionext,uniphier-ld20-global"
+
+ - PXs3 SoC: "socionext,uniphier-pxs3"
+ - Reference Board: "socionext,uniphier-pxs3-ref"
+
+Example:
+
+/dts-v1/;
+
+/ {
+ compatible = "socionext,uniphier-ld20-ref", "socionext,uniphier-ld20";
+
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 5e6a1da..87b2c2c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2183,6 +2183,7 @@ M:Masahiro Yamada
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
T: git
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-uniphier.git
S: Maintained
+F: Documentation/devicetree/bindings/arm/socionext/uniphier.txt
F: Documentation/devicetree/bindings/gpio/gpio-uniphier.txt
F: Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.txt
F: arch/arm/boot/dts/uniphier*
--
2.7.4
Re: [PATCH v1 2/2] clk: qcom : dispcc: Add support for display port clocks
Hello Stephen,
On 10/10/2018 2:04 AM, Stephen Boyd wrote:
Quoting Taniya Das (2018-10-09 06:57:47)
diff --git a/drivers/clk/qcom/dispcc-sdm845.c b/drivers/clk/qcom/dispcc-sdm845.c
index 0cc4909..6d3136a 100644
--- a/drivers/clk/qcom/dispcc-sdm845.c
+++ b/drivers/clk/qcom/dispcc-sdm845.c
@@ -128,6 +144,100 @@ enum {
},
};
+static const struct freq_tbl ftbl_disp_cc_mdss_dp_aux_clk_src[] = {
+ F(1920, P_BI_TCXO, 1, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 disp_cc_mdss_dp_aux_clk_src = {
+ .cmd_rcgr = 0x219c,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_2,
+ .freq_tbl = ftbl_disp_cc_mdss_dp_aux_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_dp_aux_clk_src",
+ .parent_names = disp_cc_parent_names_2,
+ .num_parents = 2,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static const struct freq_tbl ftbl_disp_cc_mdss_dp_crypto_clk_src[] = {
+ F(108000, P_DP_PHY_PLL_LINK_CLK, 3, 0, 0),
+ F(18, P_DP_PHY_PLL_LINK_CLK, 3, 0, 0),
+ F(36, P_DP_PHY_PLL_LINK_CLK, 3, 0, 0),
+ F(54, P_DP_PHY_PLL_LINK_CLK, 3, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 disp_cc_mdss_dp_crypto_clk_src = {
+ .cmd_rcgr = 0x2154,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_1,
+ .freq_tbl = ftbl_disp_cc_mdss_dp_crypto_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_dp_crypto_clk_src",
+ .parent_names = disp_cc_parent_names_1,
+ .num_parents = 4,
+ .flags = CLK_GET_RATE_NOCACHE,
Why?
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static const struct freq_tbl ftbl_disp_cc_mdss_dp_link_clk_src[] = {
+ F(162000, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
+ F(27, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
+ F(54, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
+ F(81, P_DP_PHY_PLL_LINK_CLK, 1, 0, 0),
Are these in kHz? They really look like it and that's bad. Why do we
need them at all? Just to make sure the display driver picks these exact
frequencies? It seems like we could just pass whatever number comes in
up to the parent and see what it can do.
Let me check back the reason we had to make this change.
+ { }
+};
+
+static struct clk_rcg2 disp_cc_mdss_dp_link_clk_src = {
+ .cmd_rcgr = 0x2138,
+ .mnd_width = 0,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_1,
+ .freq_tbl = ftbl_disp_cc_mdss_dp_link_clk_src,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_dp_link_clk_src",
+ .parent_names = disp_cc_parent_names_1,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_rcg2_ops,
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_dp_pixel1_clk_src = {
+ .cmd_rcgr = 0x2184,
+ .mnd_width = 16,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_1,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_dp_pixel1_clk_src",
+ .parent_names = disp_cc_parent_names_1,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_dp_ops,
+ },
+};
+
+static struct clk_rcg2 disp_cc_mdss_dp_pixel_clk_src = {
+ .cmd_rcgr = 0x216c,
+ .mnd_width = 16,
+ .hid_width = 5,
+ .parent_map = disp_cc_parent_map_1,
+ .clkr.hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_dp_pixel_clk_src",
+ .parent_names = disp_cc_parent_names_1,
+ .num_parents = 4,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_dp_ops,
+ },
+};
+
static const struct freq_tbl ftbl_disp_cc_mdss_esc0_clk_src[] = {
F(1920, P_BI_TCXO, 1, 0, 0),
{ }
@@ -391,6 +501,115 @@ enum {
},
};
+static struct clk_branch disp_cc_mdss_dp_aux_clk = {
+ .halt_reg = 0x2054,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2054,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "disp_cc_mdss_dp_aux_clk",
+ .parent_names = (const char *[]){
+ "disp_cc_mdss_dp_aux_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch disp_cc_mdss_dp_crypto_clk = {
+ .halt_reg = 0x2048,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x2048,
+ .enable_mask = BIT(
Re: [PATCH v3] mm: memcontrol: Don't flood OOM messages with no eligible task.
On 2018/10/19 8:54, Sergey Senozhatsky wrote:
> On (10/18/18 20:58), Tetsuo Handa wrote:
>>>
>>> A knob might do.
>>> As well as /proc/sys/kernel/printk tweaks, probably. One can even add
>>> echo "a b c d" > /proc/sys/kernel/printk to .bashrc and adjust printk
>>> console levels on login and rollback to old values in .bash_logout
>>> May be.
>>
>> That can work for only single login with root user case.
>> Not everyone logs into console as root user.
>
> Add sudo ;)
That will not work. ;-) As long as the console loglevel setting is
system wide, we can't allow multiple login sessions.
>
>> It is pity that we can't send kernel messages to only selected consoles
>> (e.g. all messages are sent to netconsole, but only critical messages are
>> sent to local consoles).
>
> OK, that's a fair point. There was a patch from FB, which would allow us
> to set a log_level on per-console basis. So the noise goes to heav^W net
> console; only critical stuff goes to the serial console (if I recall it
> correctly). I'm not sure what happened to that patch, it was a while ago.
> I'll try to find that out.
Per a console loglevel setting would help for several environments.
But syzbot environment cannot count on netconsole. We can't expect that
unlimited printk() will become safe.
>
> [..]
>> That boils down to a "user interaction" problem.
>> Not limiting
>>
>> "%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl, order=%d,
>> oom_score_adj=%hd\n"
>> "Out of memory and no killable processes...\n"
>>
>> is very annoying.
>>
>> And I really can't understand why Michal thinks "handling this requirement"
>> as
>> "make the code more complex than necessary and squash different things
>> together".
>
> Michal is trying very hard to address the problem in a reasonable way.
OK. But Michal, do we have a reasonable way which can be applied now instead of
my patch or one of below patches? Just enumerating words like "hackish" or "a
mess"
without YOU ACTUALLY PROPOSE PATCHES will bounce back to YOU.
> The problem you are talking about is not MM specific. You can have a
> faulty SCSI device, corrupted FS, and so and on.
"a faulty SCSI device, corrupted FS, and so and on" are reporting problems
which will complete a request. They can use (and are using) ratelimit,
aren't they?
"a memcg OOM with no eligible task" is reporting a problem which cannot
complete a request. But it can use ratelimit as well.
But we have an immediately applicable mitigation for a problem that
already OOM-killed threads are triggering "a memcg OOM with no eligible
task" using one of below patches.
>From 0a533d15949eac25f5ce7ce6e53f5830608f08e7 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 19 Oct 2018 15:52:56 +0900
Subject: [PATCH v2] mm, oom: OOM victims do not need to select next OOM victim
unless __GFP_NOFAIL.
Since commit 696453e66630ad45 ("mm, oom: task_will_free_mem should skip
oom_reaped tasks") changed to select next OOM victim as soon as
MMF_OOM_SKIP is set, a memcg OOM event from a user process can generate
220+ times (12400+ lines / 730+ KB) of OOM-killer messages with
"Out of memory and no killable processes..." (i.e. no progress) due to
a race window.
This patch completely eliminates such race window by making
out_of_memory() from OOM victims no-op, for OOM victims do not
forever retry (unless __GFP_NOFAIL).
Signed-off-by: Tetsuo Handa
---
mm/oom_kill.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index f10aa53..0e8d20b 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -1058,6 +1058,9 @@ bool out_of_memory(struct oom_control *oc)
if (oom_killer_disabled)
return false;
+ if (tsk_is_oom_victim(current) && !(oc->gfp_mask & __GFP_NOFAIL))
+ return true;
+
if (!is_memcg_oom(oc)) {
blocking_notifier_call_chain(&oom_notify_list, 0, &freed);
if (freed > 0)
--
1.8.3.1
>From 4a0e9c9514e1c9c5f90f6247a2c142f622558129 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 19 Oct 2018 16:31:48 +0900
Subject: [PATCH] mm, oom: task_will_free_mem() should ignore MMF_OOM_SKIP.
Since commit 696453e66630ad45 ("mm, oom: task_will_free_mem should skip
oom_reaped tasks") changed to select next OOM victim as soon as
MMF_OOM_SKIP is set, a memcg OOM event from a user process can generate
220+ times (12400+ lines / 730+ KB) of OOM-killer messages with
"Out of memory and no killable processes..." (i.e. no progress) due to
a race window.
But since we added fatal_signal_pending() check to iterations which
can result in a behavior observed in the commit above
(e.g. commit 5abf186a30a89d5b "mm, fs: check for fatal signals in
do_generic_file_read()"), we won't observe such behavior any more.
This patch completely eliminates such race window by removing the
MMF_OOM_SKIP test from task_will_free_mem(), at the risk of falling
into infinite loop when we have to select next OOM victim due to
doing __GFP_NOFAIL
RE: [PATCH v2 3/4] dmaengine: xilinx_dma: Introduce helper macro for preparing dma address
Hi, Thanks for the patch... > > This patch introduces the xilinx_prep_dma_addr_t macro which prepares > dma_addr_t from hardware buffer descriptor LSB and MSB fields. It will be > used in simple dma 64-bit programming sequence. > > Signed-off-by: Radhey Shyam Pandey Reviewed-by: Appana Durga Kedareswara Rao Regards, Kedar. > --- > Changes for v2: > New patch- Preparatory change for 4/4 fix. > --- > drivers/dma/xilinx/xilinx_dma.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c > index a37871e..c27ab64 100644 > --- a/drivers/dma/xilinx/xilinx_dma.c > +++ b/drivers/dma/xilinx/xilinx_dma.c > @@ -190,6 +190,8 @@ > /* AXI CDMA Specific Masks */ > #define XILINX_CDMA_CR_SGMODE BIT(3) > > +#define xilinx_prep_dma_addr_t(addr) \ > + ((dma_addr_t)((u64)addr##_##msb << 32 | (addr))) > /** > * struct xilinx_vdma_desc_hw - Hardware Descriptor > * @next_desc: Next Descriptor Pointer @0x00 > -- > 1.7.1
