* master - lvconvert: improve text about splitmirrors
From: David Teigland @ 2018-07-23 17:29 UTC (permalink / raw)
To: lvm-devel
Gitweb: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=778ce8d80830a60d258b419720be3e45a7ee9f0b
Commit: 778ce8d80830a60d258b419720be3e45a7ee9f0b
Parent: 8a66c81b9beb87f2f381e7e2aa76e4e54fd19934
Author: David Teigland <teigland@redhat.com>
AuthorDate: Mon Jul 23 12:28:48 2018 -0500
Committer: David Teigland <teigland@redhat.com>
CommitterDate: Mon Jul 23 12:28:48 2018 -0500
lvconvert: improve text about splitmirrors
in messages and man page.
---
lib/metadata/raid_manip.c | 4 ++--
tools/args.h | 14 +++++++++-----
tools/command-lines.in | 2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/lib/metadata/raid_manip.c b/lib/metadata/raid_manip.c
index 92e01a2..931b411 100644
--- a/lib/metadata/raid_manip.c
+++ b/lib/metadata/raid_manip.c
@@ -3553,7 +3553,7 @@ int lv_raid_merge(struct logical_volume *image_lv)
struct volume_group *vg = image_lv->vg;
if (image_lv->status & LVM_WRITE) {
- log_error("%s is not read-only - refusing to merge.",
+ log_error("%s cannot be merged because --trackchanges was not used.",
display_lvname(image_lv));
return 0;
}
@@ -3562,7 +3562,7 @@ int lv_raid_merge(struct logical_volume *image_lv)
return_0;
if (!(p = strstr(lv_name, "_rimage_"))) {
- log_error("Unable to merge non-mirror image %s.",
+ log_error("Unable to merge non-raid image %s.",
display_lvname(image_lv));
return 0;
}
diff --git a/tools/args.h b/tools/args.h
index 9e83b12..adca84b 100644
--- a/tools/args.h
+++ b/tools/args.h
@@ -618,7 +618,9 @@ arg(splitcache_ARG, '\0', "splitcache", 0, 0, 0,
arg(splitmirrors_ARG, '\0', "splitmirrors", number_VAL, 0, 0,
"Splits the specified number of images from a raid1 or mirror LV\n"
"and uses them to create a new LV. If --trackchanges is also specified,\n"
- "changes to the raid1 LV are tracked while the split LV remains detached.\n")
+ "changes to the raid1 LV are tracked while the split LV remains detached.\n"
+ "If --name is specified, then the images are permanently split from the\n"
+ "original LV and changes are not tracked.\n")
arg(splitsnapshot_ARG, '\0', "splitsnapshot", 0, 0, 0,
"Separates a COW snapshot from its origin LV. The LV that is split off\n"
@@ -697,10 +699,12 @@ arg(thinpool_ARG, '\0', "thinpool", lv_VAL, 0, 0,
arg(trackchanges_ARG, '\0', "trackchanges", 0, 0, 0,
"Can be used with --splitmirrors on a raid1 LV. This causes\n"
"changes to the original raid1 LV to be tracked while the split images\n"
- "remain detached. This allows the read-only detached image(s) to be\n"
- "merged efficiently back into the raid1 LV later. Only the regions with\n"
- "changed data are resynchronized during merge. (This option only applies\n"
- "when using the raid1 LV type.)\n")
+ "remain detached. This is a temporary state that allows the read-only\n"
+ "detached image to be merged efficiently back into the raid1 LV later.\n"
+ "Only the regions with changed data are resynchronized during merge.\n"
+ "While a raid1 LV is tracking changes, operations on it are limited to\n"
+ "merging the split image (see --mergemirrors) or permanently splitting\n"
+ "the image (see --splitmirrors with --name.\n")
/* TODO: hide this? */
arg(trustcache_ARG, '\0', "trustcache", 0, 0, 0,
diff --git a/tools/command-lines.in b/tools/command-lines.in
index d6cd04e..1511098 100644
--- a/tools/command-lines.in
+++ b/tools/command-lines.in
@@ -408,7 +408,7 @@ lvconvert --splitmirrors Number --trackchanges LV_raid1_cache
OO: OO_LVCONVERT
OP: PV ...
ID: lvconvert_split_mirror_images
-DESC: Split images from a raid1 LV and track changes to origin.
+DESC: Split images from a raid1 LV and track changes to origin for later merge.
RULE: all not lv_is_locked lv_is_pvmove
lvconvert --mergemirrors LV_linear_raid|VG|Tag ...
^ permalink raw reply related
* Re: [PATCH net] ip: hash fragments consistently
From: Eric Dumazet @ 2018-07-23 16:26 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: David S. Miller, Tom Herbert
In-Reply-To: <9b22fd3a35416b3145f1245466167b001925ce1a.1532357173.git.pabeni@redhat.com>
On 07/23/2018 07:50 AM, Paolo Abeni wrote:
> The skb hash for locally generated ip[v6] fragments belonging
> to the same datagram can vary in several circumstances:
> * for connected UDP[v6] sockets, the first fragment get its hash
> via set_owner_w()/skb_set_hash_from_sk()
> * for unconnected IPv6 UDPv6 sockets, the first fragment can get
> its hash via ip6_make_flowlabel()/skb_get_hash_flowi6(), if
> auto_flowlabel is enabled
>
> For the following frags the hash is usually computed via
> skb_get_hash().
> The above can cause OoO for unconnected IPv6 UDPv6 socket: in that
> scenario the egress tx queue can be selected on a per packet basis
> via the skb hash.
> It may also fool flow-oriented schedulers to place fragments belonging
> to the same datagram in different flows.
>
It also fools bond_xmit_hash(), packets of the same datagram can be sent on
two bonding slaves instead of one, meaning adding pressure on the defrag unit
in receiver.
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y
From: Srivatsa S. Bhat @ 2018-07-23 17:27 UTC (permalink / raw)
To: Greg KH
Cc: Dave Hansen, Wanpeng Li, ak, linux-tip-commits, Piotr Luc,
Mel Gorman, arjan.van.de.ven, xen-devel, Alexander Sergeyev,
Brian Gerst, Andy Lutomirski, MickaëlSalaün,
Thomas Gleixner, Joe Konno, Laura Abbott, Will Drewry,
Jiri Kosina, linux-kernel, Jia Zhang, Andrew Morton, torvalds,
dwmw, karahmed, dave.hansen, linux, Bo Gan
In-Reply-To: <20180723112624.GA29710@kroah.com>
On 7/23/18 4:26 AM, Greg KH wrote:
> On Sat, Jul 14, 2018 at 02:25:43AM -0700, Srivatsa S. Bhat wrote:
>> Hi Greg,
>>
>> This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS)
>> and patches for the Speculative Store Bypass vulnerability to 4.4.y
>> (they apply cleanly on top of 4.4.140).
>>
>> I used 4.9.y as my reference when backporting to 4.4.y (as I thought
>> that would minimize the amount of fixing up necessary). Unfortunately
>> I had to skip the KVM fixes for these vulnerabilities, as the KVM
>> codebase is drastically different in 4.4 as compared to 4.9. (I tried
>> my best to backport them initially, but wasn't confident that they
>> were correct, so I decided to drop them from this series).
>>
>> You'll notice that the initial few patches in this series include
>> cleanups etc., that are non-critical to IBPB/IBRS/SSBD. Most of these
>> patches are aimed at getting the cpufeature.h vs cpufeatures.h split
>> into 4.4, since a lot of the subsequent patches update these headers.
>> On my first attempt to backport these patches to 4.4.y, I had actually
>> tried to do all the updates on the cpufeature.h file itself, but it
>> started getting very cumbersome, so I resorted to backporting the
>> cpufeature.h vs cpufeatures.h split and their dependencies as well. I
>> think apart from these initial patches, the rest of the patchset
>> doesn't have all that much noise.
>>
>> This patchset has been tested on both Intel and AMD machines (Intel
>> Xeon CPU E5-2660 v4 and AMD EPYC 7281 16-Core Processor, respectively)
>> with updated microcode. All the patch backports have been
>> independently reviewed by Matt Helsley, Alexey Makhalov and Bo Gan.
>>
>> I would appreciate if you could kindly consider these patches for
>> review and inclusion in a future 4.4.y release.
>
> Given no one has complained about these yet, I've queued them all up,
> including the 2 extra ones you sent afterward.
>
Great! Thank you very much!
> Let's see what breaks :)
>
Hehe :)
Regards,
Srivatsa
VMware Photon OS
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [RESEND] Spectre-v2 (IBPB/IBRS) and SSBD fixes for 4.4.y
From: Srivatsa S. Bhat @ 2018-07-23 17:27 UTC (permalink / raw)
To: Greg KH
Cc: stable, Denys Vlasenko, Bo Gan, Konrad Rzeszutek Wilk,
Borislav Petkov, Thomas Gleixner, Ricardo Neri, Tom Lendacky, ak,
linux-tip-commits, Jia Zhang, Josh Poimboeuf, xen-devel,
Krčmář, Peter Zijlstra, Andy Lutomirski,
Arnaldo Carvalho de Melo, Sherry Hurwitz, Kees Cook, linux-kernel,
Shuah Khan, Oleg Nesterov, torvalds, dwmw, karahmed,
Borislav Petkov, dave.hansen, linux, Quentin Casasnovas,
Joerg Roedel, Alexander Shishkin, Kyle Huey, Will Drewry,
Andrey Ryabinin, H. Peter Anvin, Brian Gerst,
Kristen Carlson Accardi, Thomas Garnier, Andrew Morton, Joe Konno,
kvm, Piotr Luc, boris.ostrovsky, Jan Beulich, arjan,
Alexander Kuleshov, Juergen Gross, Ross Zwisler, Jörg Otte,
tim.c.chen, Alexander Sergeyev, Josh Triplett, gnomes, Tony Luck,
Laura Abbott, dave.hansen, Ingo Molnar, Mike Galbraith,
Rik van Riel, Kirill A. Shutemov, Alexey Makhalov, Dave Hansen,
ashok.raj, Mel Gorman, MickaëlSalaün, Fenghua Yu,
Matt Helsley (VMware), Vince Weaver, Prarit Bhargava, rostedt,
Dan Williams, Jim Mattson, Dave Young, linux-edac, Jon Masters,
Jiri Kosina, Andy Lutomirski, Paolo Bonzini, Arnd Bergmann,
linux-mm, Jiri Olsa, arjan.van.de.ven, sironi,
Frederic Weisbecker, Kyle Huey, Alexander Popov, Andy Shevchenko,
Nadav Amit, Yazen Ghannam, Wanpeng Li, Stephane Eranian,
David Woodhouse, srivatsab
In-Reply-To: <20180723112624.GA29710@kroah.com>
On 7/23/18 4:26 AM, Greg KH wrote:
> On Sat, Jul 14, 2018 at 02:25:43AM -0700, Srivatsa S. Bhat wrote:
>> Hi Greg,
>>
>> This patch series is a backport of the Spectre-v2 fixes (IBPB/IBRS)
>> and patches for the Speculative Store Bypass vulnerability to 4.4.y
>> (they apply cleanly on top of 4.4.140).
>>
>> I used 4.9.y as my reference when backporting to 4.4.y (as I thought
>> that would minimize the amount of fixing up necessary). Unfortunately
>> I had to skip the KVM fixes for these vulnerabilities, as the KVM
>> codebase is drastically different in 4.4 as compared to 4.9. (I tried
>> my best to backport them initially, but wasn't confident that they
>> were correct, so I decided to drop them from this series).
>>
>> You'll notice that the initial few patches in this series include
>> cleanups etc., that are non-critical to IBPB/IBRS/SSBD. Most of these
>> patches are aimed at getting the cpufeature.h vs cpufeatures.h split
>> into 4.4, since a lot of the subsequent patches update these headers.
>> On my first attempt to backport these patches to 4.4.y, I had actually
>> tried to do all the updates on the cpufeature.h file itself, but it
>> started getting very cumbersome, so I resorted to backporting the
>> cpufeature.h vs cpufeatures.h split and their dependencies as well. I
>> think apart from these initial patches, the rest of the patchset
>> doesn't have all that much noise.
>>
>> This patchset has been tested on both Intel and AMD machines (Intel
>> Xeon CPU E5-2660 v4 and AMD EPYC 7281 16-Core Processor, respectively)
>> with updated microcode. All the patch backports have been
>> independently reviewed by Matt Helsley, Alexey Makhalov and Bo Gan.
>>
>> I would appreciate if you could kindly consider these patches for
>> review and inclusion in a future 4.4.y release.
>
> Given no one has complained about these yet, I've queued them all up,
> including the 2 extra ones you sent afterward.
>
Great! Thank you very much!
> Let's see what breaks :)
>
Hehe :)
Regards,
Srivatsa
VMware Photon OS
^ permalink raw reply
* pull-request: wireless-drivers-next 2018-07-23
From: Kalle Valo @ 2018-07-23 17:27 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
this first pull request for 4.19 got delayed as I was on vacation for
two weeks. I was supposed to send this before my vacation but didn't
manage to do it due to other urgent stuff, but I'll try to catch up with
everything this week so that we get everything ready on time for 4.19.
More info in the signed tag below and please let me know if there are
any problems.
Kalle
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2018-07-23
for you to fetch changes up to 4a07ed51cae18765c76d9aede5b9830d42db1546:
mt76x2: debugfs: add sw pulse statistics to dfs debugfs (2018-07-04 18:16:01 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.19
The first set of patches for 4.19. Only smaller features and bug
fixes, not really anything major. Also included are changes to
include/linux/bitfield.h, we agreed with Johannes that it makes sense
to apply them via wireless-drivers-next.
Major changes:
ath10k
* support channel 173
* fix spectral scan for QCA9984 and QCA9888 chipsets
ath6kl
* add support for Dell Wireless 1537
ti wlcore
* add support for runtime PM
* enable runtime PM autosuspend support
qtnfmac
* support changing MAC address
* enable source MAC address randomization support
libertas
* fix suspend and resume for SDIO cards
mt76
* add software DFS radar pattern detector for mt76x2 based devices
----------------------------------------------------------------
Andrey Shevchenko (1):
qtnfmac: enable source MAC address randomization support
Arnd Bergmann (2):
zd1211rw: stop using deprecated get_seconds()
ipw2x00: track time using boottime
Ben Greear (1):
ath10k: support use of channel 173
Brian Norris (6):
ath10k: use crash_dump enum instead of magic numbers
ath10k: snoc: use module_platform_driver() macro
ath10k: snoc: use correct bus-specific pointer in RX retry
ath10k: snoc: stop including pci.h
ath10k: snoc: drop unused WCN3990_CE_ATTR_FLAGS
ath10k: snoc: sort include files
Colin Ian King (3):
ath10k: fix memory leak of tpc_stats
ath9k: debug: fix spelling mistake "WATHDOG" -> "WATCHDOG"
brcmsmac: make function wlc_phy_workarounds_nphy_rev1 static
Dan Carpenter (1):
rndis_wlan: potential buffer overflow in rndis_wlan_auth_indication()
Daniel Mack (1):
libertas: fix suspend and resume for SDIO connected cards
Eyal Reizer (1):
wlcore: Use generic runtime pm calls for wowlan elp configuration
Felix Fietkau (9):
mt76: fix beacon timer drift
mt76: fix threshold for gain adjustment
mt76: fix swapped values for RXO-18 in gain control
mt76: adjust AGC control register 26 based on gain for VHT80
mt76: clear false CCA counters after changing gain settings
mt76: fix variable gain adjustment range
mt76: add a debugfs file to dump agc calibration information
mt76: track ewma rssi for gain adjustment per station
mt76: improve gain adjustment in noisy environments
Govind Singh (1):
ath10k: handle resource init failure case
Gustavo A. R. Silva (5):
ath10k: htt_tx: mark expected switch fall-throughs
ath5k: mark expected switch fall-through
ath6kl: mark expected switch fall-throughs
ath9k: mark expected switch fall-throughs
wlcore: Fix memory leak in wlcore_cmd_wait_for_event_or_timeout
Guy Chronister (1):
ath6kl: add support for Dell Wireless 1537
Igor Mitsyanko (1):
qtnfmac: implement net_device_ops callback to set MAC address
Johannes Berg (3):
bitfield: fix *_encode_bits()
bitfield: add u8 helpers
bitfield: add tests
Kalle Valo (1):
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthikeyan Periyasamy (1):
ath10k: fix spectral scan for QCA9984 and QCA9888 chipsets
Lorenzo Bianconi (5):
mt76x2: fix mrr idx/count estimation in mt76x2_mac_fill_tx_status()
mt76: introduce mt76_{incr,decr} utility routines
mt76x2: dfs: add sw event ring buffer
mt76x2: dfs: add sw pattern detector
mt76x2: debugfs: add sw pulse statistics to dfs debugfs
Niklas Cassel (1):
ath10k: do not mix spaces and tabs in Kconfig
Omer Efrat (1):
wireless-drivers: use BIT_ULL for NL80211_STA_INFO_ attribute types
Rafał Miłecki (5):
brcmfmac: detect firmware support for monitor interface
brcmfmac: detect firmware support for radiotap monitor frames
brcmfmac: handle msgbuf packets marked with monitor mode flag
brcmfmac: define more bits for the flags of struct brcmf_sta_info_le
brcmfmac: update STA info struct to the v5
Sebastian Andrzej Siewior (3):
libertas_tf: use irqsave() in USB's complete callback
libertas: use irqsave() in USB's complete callback
zd1211rw: use irqsave() in USB's complete callback
Stefan Agner (1):
brcmsmac: fix wrap around in conversion from constant to s16
Surabhi Vishnoi (1):
ath10k: skip data calibration for non-bmi target
Tony Lindgren (7):
wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()
wlcore: Make sure PM calls are paired
wlcore: Add support for runtime PM
wlcore: Fix misplaced PM call for scan_complete_work()
wlcore: Fix timout errors after recovery
wlcore: Make sure firmware is initialized in wl1271_op_add_interface()
wlcore: Enable runtime PM autosuspend support
Varsha Rao (2):
brcmsmac: Remove unnecessary parentheses
net: ipw2x00: Replace NULL comparison with !priv
Wei Yongjun (1):
ath10k: make some functions static
Xinming Hu (1):
mwifiex: uap: do not chok ethernet header in bridge path
YueHaibing (4):
ath10k: fix incorrect size of dma_free_coherent in ath10k_ce_alloc_src_ring_64
ath10k: use dma_zalloc_coherent instead of allocator/memset
atmel: use memdup_user to simplify the code
atmel: using strlcpy() to avoid possible buffer overflows
drivers/net/wireless/ath/ath10k/Kconfig | 24 +-
drivers/net/wireless/ath/ath10k/ce.c | 2 +-
drivers/net/wireless/ath/ath10k/ce.h | 42 ++
drivers/net/wireless/ath/ath10k/core.c | 19 +-
drivers/net/wireless/ath/ath10k/core.h | 3 +-
drivers/net/wireless/ath/ath10k/debug.c | 21 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 4 +-
drivers/net/wireless/ath/ath10k/hw.h | 3 +
drivers/net/wireless/ath/ath10k/mac.c | 7 +-
drivers/net/wireless/ath/ath10k/pci.h | 42 --
drivers/net/wireless/ath/ath10k/snoc.c | 47 +-
drivers/net/wireless/ath/ath10k/snoc.h | 1 -
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 14 +-
drivers/net/wireless/ath/ath5k/pcu.c | 1 +
drivers/net/wireless/ath/ath6kl/cfg80211.c | 17 +-
drivers/net/wireless/ath/ath6kl/sdio.c | 1 +
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 +
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 1 +
drivers/net/wireless/ath/ath9k/debug.c | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 1 +
drivers/net/wireless/ath/wil6210/cfg80211.c | 18 +-
drivers/net/wireless/atmel/atmel.c | 14 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 40 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 25 +
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 2 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.h | 6 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 43 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 18 +
.../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c | 2 +-
.../broadcom/brcm80211/brcmsmac/phy/phy_qmath.c | 2 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 18 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.h | 12 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 6 +-
drivers/net/wireless/intel/ipw2x00/ipw2200.h | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 6 +-
drivers/net/wireless/marvell/libertas/cfg.c | 12 +-
drivers/net/wireless/marvell/libertas/dev.h | 1 +
drivers/net/wireless/marvell/libertas/if_sdio.c | 30 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 7 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 8 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 14 +-
drivers/net/wireless/marvell/mwifiex/uap_txrx.c | 52 +-
drivers/net/wireless/mediatek/mt76/mt76.h | 12 +
drivers/net/wireless/mediatek/mt76/mt76x2.h | 16 +-
.../net/wireless/mediatek/mt76/mt76x2_debugfs.c | 22 +
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.c | 377 ++++++++++++++-
drivers/net/wireless/mediatek/mt76/mt76x2_dfs.h | 64 +++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 39 +-
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 7 +-
drivers/net/wireless/mediatek/mt76/mt76x2_phy.c | 107 ++++-
drivers/net/wireless/mediatek/mt76/mt76x2_tx.c | 33 ++
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c | 3 +
drivers/net/wireless/quantenna/qtnfmac/commands.c | 57 ++-
drivers/net/wireless/quantenna/qtnfmac/core.c | 25 +
drivers/net/wireless/quantenna/qtnfmac/qlink.h | 20 +
drivers/net/wireless/rndis_wlan.c | 6 +-
drivers/net/wireless/ti/wl18xx/debugfs.c | 29 +-
drivers/net/wireless/ti/wlcore/acx.c | 1 -
drivers/net/wireless/ti/wlcore/cmd.c | 10 +
drivers/net/wireless/ti/wlcore/debugfs.c | 90 ++--
drivers/net/wireless/ti/wlcore/main.c | 528 ++++++++++++++-------
drivers/net/wireless/ti/wlcore/ps.c | 146 ------
drivers/net/wireless/ti/wlcore/ps.h | 3 -
drivers/net/wireless/ti/wlcore/scan.c | 13 +-
drivers/net/wireless/ti/wlcore/sysfs.c | 13 +-
drivers/net/wireless/ti/wlcore/testmode.c | 20 +-
drivers/net/wireless/ti/wlcore/tx.c | 10 +-
drivers/net/wireless/ti/wlcore/vendor_cmd.c | 30 +-
drivers/net/wireless/ti/wlcore/wlcore.h | 1 -
drivers/net/wireless/ti/wlcore/wlcore_i.h | 1 -
drivers/net/wireless/zydas/zd1211rw/zd_chip.c | 2 +-
drivers/net/wireless/zydas/zd1211rw/zd_usb.c | 21 +-
include/linux/bitfield.h | 7 +-
lib/Kconfig.debug | 7 +
lib/Makefile | 1 +
lib/test_bitfield.c | 168 +++++++
79 files changed, 1787 insertions(+), 704 deletions(-)
create mode 100644 lib/test_bitfield.c
^ permalink raw reply
* Re: [PATCH 05/11] touchscreen: elants: Use octal permissions
From: Joe Perches @ 2018-07-23 17:25 UTC (permalink / raw)
To: Dmitry Torokhov, Greg Kroah-Hartman
Cc: dev-harsh1998, trivial, Simon Budig, Andi Shyti, Luca Ceresoli,
Guenter Roeck, linux-input, linux-kernel
In-Reply-To: <20180723171831.GC100814@dtor-ws>
On Mon, 2018-07-23 at 10:18 -0700, Dmitry Torokhov wrote:
> On Mon, Jul 23, 2018 at 03:32:00PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Jul 23, 2018 at 06:49:20PM +0530, dev-harsh1998 wrote:
> > > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> > > +static DEVICE_ATTR(iap_mode, S_IRUGO, show_iap_mode, NULL);
> > >
> > > WARNING: Symbolic permissions 'S_IWUSR' are not preferred. Consider using octal permissions '0200'.
> > > +static DEVICE_ATTR(update_fw, S_IWUSR, NULL, write_update_fw)
> > >
> > > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> > > + .dattr = __ATTR(_field, S_IRUGO, \
> > >
> > > Signed-off-by: Harshit Jain <harshitjain6751@gmail.com>
> >
> > This name doesn't match up with the From: line above :(
> >
> > Please fix up and try again.
>
> dtor@dtor-ws:~/kernel/linux-next$ git grep S_IRU | wc -l
> 7605
>
> We either need to run a tree-wide script or leave this alone. FWIW I am
> perfectly fine with either octals or symbolic names so I do not see
> benefit of doing conversion for code that is not known to be broken.
About half of those are in one subsystem (drivers/hwmon)
$ git grep -w S_IRUGO | cut -f1,2 -d'/' | \
sort | uniq -c | sort -rn | head -10 | cat -n
1 3846 drivers/hwmon
2 748 drivers/scsi
3 215 drivers/infiniband
4 168 drivers/usb
5 109 drivers/media
6 106 drivers/input
7 102 drivers/platform
8 101 drivers/misc
9 101 drivers/gpu
10 91 drivers/edac
The generic reason is octal is readable and S_<FOO> is unintelligible.
https://lkml.org/lkml/2016/8/2/1945
^ permalink raw reply
* Re: [PATCHv5 10/19] x86/mm: Implement page_keyid() using page_ext
From: Alison Schofield @ 2018-07-23 17:22 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Dave Hansen, Kirill A. Shutemov, Ingo Molnar, x86,
Thomas Gleixner, H. Peter Anvin, Tom Lendacky, Kai Huang,
Jacob Pan, linux-kernel, linux-mm
In-Reply-To: <20180723094517.7sxt62p3h75htppw@kshutemo-mobl1>
On Mon, Jul 23, 2018 at 12:45:17PM +0300, Kirill A. Shutemov wrote:
> On Wed, Jul 18, 2018 at 04:38:02PM -0700, Dave Hansen wrote:
> > On 07/17/2018 04:20 AM, Kirill A. Shutemov wrote:
> > > Store KeyID in bits 31:16 of extended page flags. These bits are unused.
> >
> > I'd love a two sentence remind of what page_ext is and why you chose to
> > use it. Yes, you need this. No, not everybody that you want to review
> > this patch set knows what it is or why you chose it.
>
> Okay.
>
> > > page_keyid() returns zero until page_ext is ready.
> >
> > Is there any implication of this? Or does it not matter because we
> > don't run userspace until after page_ext initialization is done?
>
> It matters in sense that we shouldn't reference page_ext before it's
> initialized otherwise we will get garbage and crash.
>
> > > page_ext initializer enables static branch to indicate that
> >
> > "enables a static branch"
> >
> > > page_keyid() can use page_ext. The same static branch will gate MKTME
> > > readiness in general.
> >
> > Can you elaborate on this a bit? It would also be a nice place to hint
> > to the folks working hard on the APIs to ensure she checks this.
>
> Okay.
At API init time we can check if (MKTME_ENABLED && mktme_nr_keyids > 0)
Sounds like this is another dependency we need to check and 'wait' on?
It happens after MKTME_ENABLED is set? Let me know.
>
> > > We don't yet set KeyID for the page. It will come in the following
> > > patch that implements prep_encrypted_page(). All pages have KeyID-0 for
> > > now.
> >
> > It also wouldn't hurt to mention why you don't use an X86_FEATURE_* for
> > this rather than an explicit static branch. I'm sure the x86
> > maintainers will be curious.
>
> Sure.
>
> --
> Kirill A. Shutemov
^ permalink raw reply
* Re: [GIT PULL] Renesas ARM Based SoC Defconfig Updates for v4.19
From: Olof Johansson @ 2018-07-23 16:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, ARM-SoC Maintainers, Linux-Renesas, Kevin Hilman,
Arnd Bergmann, Linux ARM, Magnus Damm
In-Reply-To: <CAMuHMdVbyUa5PtQf4LZQDv-=aqToahX5Eb4TEDvsJniYm-trNQ@mail.gmail.com>
On Mon, Jul 23, 2018 at 2:11 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Olof,
>
> On Sun, Jul 22, 2018 at 12:27 AM Olof Johansson <olof@lixom.net> wrote:
>> On Fri, Jul 20, 2018 at 02:03:54PM +0200, Simon Horman wrote:
>> > Please consider these Renesas ARM based SoC defconfig updates for v4.19.
>
>> > * Set CONFIG_LOCALVERSION to shmobile_defconfig
>> >
>> > This follows what appears to be common practice in defconfigs
>> > and allows easier management of the kernel flavour at run-time.
>>
>> I replied to the multi-versions of defconfig for this patch -- it's not a good
>> way to solve the problem of detecting config at runtime. Please drop this
>> patch. See:
>>
>> https://lore.kernel.org/lkml/CAOesGMgkU6yBRpAsED2fPyuAo9Tc=YprndGdkmBVrc+0783VwQ@mail.gmail.com/
>
> One more comment to the rescue: it does complicate regression testing,
> as the test software running on the DUT has no easy way to distinguish
> between e.g. shmobile_defconfig and multi_v7_defconfig (and whatever
> other board-specific configs I use for testing).
> Yes, I can have these as local patches in my tree (of course I already have ;-),
> but when bisecting, I have to remember to (un)apply them in every step.
Hi,
It looks like scripts/setlocalversion will look for files named
localversion* in the directory you build in, git won't touch the file
so you don't have to re-apply it every time.
I do see the usefulness for bisect and so on, but there's such a high
chance that people will start changing configs without changing
localversion that the value of it will diminish immediately for
downstream trees. Also, the "local" in localversion sort of indicates
that it shouldn't be set in a central place. :)
-Olof
^ permalink raw reply
* Re: [PATCH/RFT 0/7] rsnd: add support for r8a77965
From: Simon Horman @ 2018-07-23 16:21 UTC (permalink / raw)
To: Yoshihiro Kaneko; +Cc: linux-renesas-soc, Magnus Damm, linux-arm-kernel
In-Reply-To: <1531856883-19645-1-git-send-email-ykaneko0929@gmail.com>
On Wed, Jul 18, 2018 at 04:47:56AM +0900, Yoshihiro Kaneko wrote:
> This series adds sound support for r8a77965 (R-Car M3-N).
> This series is based on the devel branch of Simon Horman's renesas tree.
>
> Hiroyuki Yokoyama (1):
> ASoC: rsnd: Document R-Car M3-N support
>
> Takeshi Kihara (6):
> arm64: dts: renesas: r8a77965: Add Audio-DMAC device nodes
> arm64: dts: renesas: r8a77965: Add Sound device node and SSI support
> arm64: dts: renesas: r8a77965: Add Sound SRC support
> arm64: dts: renesas: r8a77965: Add Sound DVC device nodes
> arm64: dts: renesas: r8a77965: Add Sound CTU support
> arm64: dts: renesas: r8a77965: Add Sound MIX support
>
> .../devicetree/bindings/sound/renesas,rsnd.txt | 1 +
> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 245 ++++++++++++++++++++-
Thanks Kaneko-san,
in general this series looks good, however, I would like to ask you to
squash all the dts patches (the patches by Kihara-san) into a single patch.
For many years now we have split patches up as this series does.
And no doubt that is why BPS team chose to split up the patches
that you have based this patchset on. However, we were recently
asked by the Olof Johansson to squash patches together to make
the high-level intent of patches clearer to him in his position
of ARM-SoC co-maintainer.
So while what you have done is correct, it is now the "old way".
Please squash the patches together as this is the "new way".
Thanks!
^ permalink raw reply
* [Qemu-devel] [PULL for-3.0 1/1] tcg/i386: Mark xmm registers call-clobbered
From: Richard Henderson @ 2018-07-23 17:23 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell, qemu-stable
In-Reply-To: <20180723172311.11316-1-richard.henderson@linaro.org>
When host vector registers and operations were introduced, I failed
to mark the registers call clobbered as required by the ABI.
Fixes: 770c2fc7bb7
Cc: qemu-stable@nongnu.org
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
tcg/i386/tcg-target.inc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tcg/i386/tcg-target.inc.c b/tcg/i386/tcg-target.inc.c
index e87b0d445e..a91e4f1313 100644
--- a/tcg/i386/tcg-target.inc.c
+++ b/tcg/i386/tcg-target.inc.c
@@ -3532,7 +3532,7 @@ static void tcg_target_init(TCGContext *s)
tcg_target_available_regs[TCG_TYPE_V256] = ALL_VECTOR_REGS;
}
- tcg_target_call_clobber_regs = 0;
+ tcg_target_call_clobber_regs = ALL_VECTOR_REGS;
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_EAX);
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_EDX);
tcg_regset_set_reg(tcg_target_call_clobber_regs, TCG_REG_ECX);
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PULL for-3.0 0/1] tcg-next patches
From: Richard Henderson @ 2018-07-23 17:23 UTC (permalink / raw)
To: qemu-devel; +Cc: peter.maydell
One more tcg/i386 patch for 3.0, fixing a testcase
reported over the weekend.
r~
The following changes since commit e596be90393389405c96a5c9534c4c4e2e0b5675:
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180723' into staging (2018-07-23 16:15:24 +0100)
are available in the Git repository at:
https://github.com/rth7680/qemu.git tags/pull-tcg-20180723
for you to fetch changes up to 672189cd586ea38a2c1d8ab91eb1f9dcff5ceb05:
tcg/i386: Mark xmm registers call-clobbered (2018-07-23 09:21:14 -0700)
----------------------------------------------------------------
Mark xmm registers call-clobbered.
----------------------------------------------------------------
Richard Henderson (1):
tcg/i386: Mark xmm registers call-clobbered
tcg/i386/tcg-target.inc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [meta-oe][PATCH] perl: native modules will not trigger build perl for target.
From: Andre McCurdy @ 2018-07-23 17:23 UTC (permalink / raw)
To: Krzysztof Taborski; +Cc: OE Core mailing list
In-Reply-To: <CAFmD+WEeyHwEQs825up0Q=yF4n3gvQU-eav3RZdJ9nt5NLECwQ@mail.gmail.com>
On Mon, Jul 23, 2018 at 5:57 AM, Krzysztof Taborski
<taborskikrzysztof@gmail.com> wrote:
> Change was already merged:
> http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools?id=7dd9772eca6df52db09b65537fdf689f1aa3fd8f
>
> Is your request still valid?
Yes, although the change was merged, it's not clear that it was correct.
Native recipes aren't split into packages, so there are no -native
versions of the perl modules. If you have a recipe which depends on
"perl-module-XXX-native" it's likely a bug in that recipe - not in
perl-native.
What recipe did you find which depends on a -native version of a perl module?
> 2018-07-09 21:40 GMT+02:00 Andre McCurdy <armccurdy@gmail.com>:
>>
>> On Wed, May 9, 2018 at 7:16 AM, taborskikrzysztof
>> <taborskikrzysztof@gmail.com> wrote:
>> > Can I request review?
>> > -------- Oryginalna wiadomość --------
>> > Od: Krzysztof Taborski <taborskikrzysztof@gmail.com>
>> > Data: 08.05.2018 18:46 (GMT+01:00)
>> > Do: openembedded-core@lists.openembedded.org
>> > DW: Krzysztof Taborski <taborskikrzysztof@gmail.com>
>> > Temat: [meta-oe][PATCH] perl: native modules will not trigger build perl
>> > for
>> > target.
>> >
>> > Currently building perl-native modules triggers
>> > build perl for target due to PACKAGES_DYNAMIC regex.
>> >
>> > This commit will cause, that perl native modules will
>> > trigger perl-native build.
>>
>> Can you give an example of how to reproduce the problem?
>>
>> > Signed-off-by: Krzysztof Taborski <taborskikrzysztof@gmail.com>
>> > ---
>> > meta/recipes-devtools/perl/perl-native_5.24.1.bb | 2 ++
>> > meta/recipes-devtools/perl/perl_5.24.1.bb | 2 +-
>> > 2 files changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> > b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> > index a9ab17d16c..71f45890b0 100644
>> > --- a/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> > +++ b/meta/recipes-devtools/perl/perl-native_5.24.1.bb
>> > @@ -135,3 +135,5 @@ EOF
>> >
>> > # Fix the path in sstate
>> > SSTATE_SCAN_FILES += "*.pm *.pod *.h *.pl *.sh"
>> > +PACKAGES_DYNAMIC_class-native += "^perl-module-.*native$"
>>
>> This usage of += with an over-ride is not correct.
>>
>> However, regardless of that, was this change actually needed?
>>
>> If you know of a -native recipe which depends on a
>> perl-module-XXX-native package then it's probably a bug in the -native
>> recipe. Having perl-native pretend to provide perl-module packages
>> probably isn't the right solution.
>>
>> > diff --git a/meta/recipes-devtools/perl/perl_5.24.1.bb
>> > b/meta/recipes-devtools/perl/perl_5.24.1.bb
>> > index 53a426289a..4c6a71082f 100644
>> > --- a/meta/recipes-devtools/perl/perl_5.24.1.bb
>> > +++ b/meta/recipes-devtools/perl/perl_5.24.1.bb
>> > @@ -339,7 +339,7 @@ python split_perl_packages () {
>> > d.setVar(d.expand("RRECOMMENDS_${PN}-modules"), ' '.join(packages))
>> > }
>> >
>> > -PACKAGES_DYNAMIC += "^perl-module-.*"
>> > +PACKAGES_DYNAMIC += "^perl-module-.*(?<!\-native)$"
>> > PACKAGES_DYNAMIC_class-nativesdk += "^nativesdk-perl-module-.*"
>>
>> This usage of += with an over-ride is not correct.
>>
>> > RPROVIDES_perl-lib = "perl-lib"
>> > --
>> > 2.13.6
>> >
>> >
>> > --
>> > _______________________________________________
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> >
>
>
>
>
> --
> Pozdrawiam,
> Krzysiek Taborski
^ permalink raw reply
* Re: [PATCH] firmware: vpd: Fix section enabled flag on vpd_section_destroy
From: Dmitry Torokhov @ 2018-07-23 17:23 UTC (permalink / raw)
To: Guenter Roeck
Cc: Anton Vasilyev, Greg Kroah-Hartman, Samuel Holland, Pan Bian,
linux-kernel, ldv-project
In-Reply-To: <20180723171336.GA15900@roeck-us.net>
On Mon, Jul 23, 2018 at 10:13:36AM -0700, Guenter Roeck wrote:
> On Mon, Jul 23, 2018 at 07:48:57PM +0300, Anton Vasilyev wrote:
> > static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
> > in vpd_probe() based on header's ro and rw sizes.
> > In vpd_remove() vpd_section_destroy() performs deinitialization based
> > on enabled flag, which is set to true by vpd_sections_init().
> > This leads to call of vpd_section_destroy() on already destroyed section
> > for probe-release-probe-release sequence if first probe performs
> > ro_vpd initialization and second probe does not initialize it.
> >
>
> I am not sure if the situation described can be seen in the first place.
> The second probe would only not perform ro_vpd initialization if it fails
> prior to that, ie if it fails to allocate memory or if there is a
> consistency problem. In that case the remove function would not be called.
>
> However, there is a problem in the code: A partially failed probe will
> leave the system in inconsistent state. Example: ro section initializes,
> rw section fails to initialize. The probe will fail, but the ro section
> will not be destroyed, its sysfs attributes still exist, and its memory
> is still mapped. It would make more sense to fix _that_ problem.
> Essentially, vpd_sections_init() should clean up after itself after it
> fails to initialize a section.
>
> Note that I am not convinced that the "enabled" flag is needed in the first
> place. It is only relevant if vpd_section_destroy() is called, which only
> happens from the remove function. The remove function is only called if the
> probe function succeeded. In that case it is always set for both sections.
The problem will happen if coreboot memory changes between 2 probes so
that header.ro_size is not 0 on the first pass and is 0 on the second
pass. Not quite likely to ever happen in real life, but resetting a flag
is pretty cheap to not do it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 08/12] sched/core: uclamp: extend cpu's cgroup controller
From: Patrick Bellasi @ 2018-07-23 17:22 UTC (permalink / raw)
To: Tejun Heo
Cc: linux-kernel, linux-pm, Ingo Molnar, Peter Zijlstra,
Rafael J . Wysocki, Viresh Kumar, Vincent Guittot, Paul Turner,
Dietmar Eggemann, Morten Rasmussen, Juri Lelli, Todd Kjos,
Joel Fernandes, Steve Muckle, Suren Baghdasaryan
In-Reply-To: <20180723153040.GG1934745@devbig577.frc2.facebook.com>
On 23-Jul 08:30, Tejun Heo wrote:
> Hello,
Hi Tejun!
> On Mon, Jul 16, 2018 at 09:29:02AM +0100, Patrick Bellasi wrote:
> > The cgroup's CPU controller allows to assign a specified (maximum)
> > bandwidth to the tasks of a group. However this bandwidth is defined and
> > enforced only on a temporal base, without considering the actual
> > frequency a CPU is running on. Thus, the amount of computation completed
> > by a task within an allocated bandwidth can be very different depending
> > on the actual frequency the CPU is running that task.
> > The amount of computation can be affected also by the specific CPU a
> > task is running on, especially when running on asymmetric capacity
> > systems like Arm's big.LITTLE.
>
> One basic problem I have with this patchset is that what's being
> described is way more generic than what actually got implemented.
> What's described is computation bandwidth control but what's
> implemented is just frequency clamping.
What I meant to describe is that we already have a computation
bandwidth control mechanism which is working quite fine for the
scheduling classes it applies to, i.e. CFS and RT.
For these classes we are usually happy with just a _best effort_
allocation of the bandwidth: nothing enforced in strict terms. Indeed,
there is not (at least not in kernel space) a tracking of the actual
available and allocated bandwidth. If we need strict enforcement, we
already have DL with its CBS servers.
However, the "best effort" bandwidth control we have for CFS and RT
can be further improved if, instead of just looking at time spent on
CPUs, we provide some more hints to the scheduler to know at which
min/max "MIPS" we want to consume the (best effort) time we have been
allocated on a CPU.
Such a simple extension is still quite useful to satisfy many use-case
we have, mainly on mobile systems, like the ones I've described in the
"Newcomer's Short Abstract (Updated)"
section of the cover letter:
https://lore.kernel.org/lkml/20180716082906.6061-1-patrick.bellasi@arm.com/T/#u
> So, there are fundamental discrepancies between
> description+interface vs. what it actually does.
Perhaps then I should just change the description to make it less
generic...
> I really don't think that's something we can fix up later.
... since, really, I don't think we can get to the point to extend
later this interface to provide the strict bandwidth enforcement you
are thinking about.
This would not be a fixup, but something really close to
re-implementing what we already have with the DL class.
> > These attributes:
> >
> > a) are available only for non-root nodes, both on default and legacy
> > hierarchies
> > b) do not enforce any constraints and/or dependency between the parent
> > and its child nodes, thus relying on the delegation model and
> > permission settings defined by the system management software
>
> cgroup does host attributes which only concern the cgroup itself and
> thus don't need any hierarchical behaviors on their own, but what's
> being implemented does control resource allocation,
I'm not completely sure to get your point here.
Maybe it all depends on what we mean by "control resource allocation".
AFAIU, currently both the CFS and RT bandwidth controllers allow you
to define how much CPU time a group of tasks can use. It does that by
looking just within the group: there is no enforced/required relation
between the bandwidth assigned to a group and the bandwidth assigned
to its parent, siblings and/or children.
The resource control allocation is eventually enforced "indirectly" by
means of the fact that, based on tasks priorities and cgroup shares,
the scheduler will prefer to pick and run "more frequently" and
"longer" certain tasks instead of others.
Thus I would say that the resource allocation control is already
performed by the combined action of:
A) priorities / shares to favor certain tasks over others
B) period & bandwidth to further bias the scheduler in _not_ selecting
tasks which already executed for the configured amount of time.
> and what you're describing inherently breaks the delegation model.
What I describe here is just an additional hint to the scheduler which
enrich the above described model. Provided A and B are already
satisfied, when a task gets a chance to run it will be executed at a
min/max configured frequency. That's really all... there is not
additional impact on "resources allocation".
I don't see why you say that this breaks the delegation model?
Maybe an example can help to better explain what you mean?
Best,
Patrick
--
#include <best/regards.h>
Patrick Bellasi
^ permalink raw reply
* Have you read my previous message
From: Lisa Jaster @ 2018-07-23 16:20 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Type: text/html, Size: 26 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 23/40] target/mips: Implement emulation of nanoMIPS LLWP/SCWP pair
From: Aleksandar Markovic @ 2018-07-23 17:21 UTC (permalink / raw)
To: Richard Henderson, Stefan Markovic, qemu-devel@nongnu.org
Cc: laurent@vivier.eu, riku.voipio@iki.fi,
philippe.mathieu.daude@gmail.com, aurelien@aurel32.net,
Stefan Markovic, Petar Jovanovic, Paul Burton
In-Reply-To: <b2be38da-84b6-904c-a826-1c86fed7e03c@linaro.org>
> From: Richard Henderson <richard.henderson@linaro.org>
> Sent: Saturday, July 21, 2018 8:15 PM
> On 07/19/2018 05:54 AM, Stefan Markovic wrote:
> > From: Yongbok Kim <yongbok.kim@mips.com>
> >
> > Implement nanoMIPS LLWP and SCWP instruction pair.
> >
> > Signed-off-by: Yongbok Kim <yongbok.kim@mips.com>
> > Signed-off-by: Aleksandar Markovic <amarkovic@wavecomp.com>
> > Signed-off-by: Stefan Markovic <smarkovic@wavecomp.com>
> > ---
> > linux-user/mips/cpu_loop.c | 25 ++++++++---
> > target/mips/cpu.h | 2 +
> > target/mips/helper.h | 2 +
> > target/mips/op_helper.c | 35 +++++++++++++++
> > target/mips/translate.c | 107 +++++++++++++++++++++++++++++++++++++++++++++
> > 5 files changed, 166 insertions(+), 5 deletions(-)
>
> Hmm. Well, it's ok as far as it goes, but I'd really really like to see
> target/mips to be updated to use actual atomic operations. Otherwise
> mips*-linux-user will never be reliable and mips*-softmmu cannot run SMP in
> multi-threaded mode.
>
> While converting the rest of target/mips to atomic operations is perhaps out of
> scope for this patch set, there's really no reason not to do these two
> instructions correctly from the start. It'll save the trouble of rewriting
> them from scratch later.
>
> Please see target/arm/translate.c, gen_load_exclusive and gen_store_exclusive,
> for the size == 3 case. That is arm32 doing a 64-bit "paired" atomic
> operation, just like you are attempting here.
>
> Note that single-copy atomic semantics apply in both cases, so LLWP must
> perform one 64-bit load, not two 32-bit loads. The store in SCWP must happen
> with a 64-bit atomic cmpxchg operation.
>
>
> r~
Hi, Richard.
The improved version of this patch, that addresses the concerns you mentioned, may be included in the next version of this series, which is scheduled to be sent in next few days.
The reason we are a little sluggish with response to your reviews is that we are still completing functionality (mostly linux-user-related). However, we'll focus on the interaction with reviewers as soon as we are out of that phase.
Regards,
Aleksandar
^ permalink raw reply
* [PATCH] drm/i915: Skip repeated calls to i915_gem_set_wedged()
From: Chris Wilson @ 2018-07-23 17:21 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
If we already wedged, i915_gem_set_wedged() becomes a complicated no-op.
v2: Make sure the double set-wedged is synchronous, a parallel call
should not return before the driver is indeed wedged.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107343
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 26 ++++++++++++++++++++++----
drivers/gpu/drm/i915/i915_gpu_error.h | 3 ++-
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8b52cb768a67..99c91c7ad46c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3298,12 +3298,24 @@ static void nop_complete_submit_request(struct i915_request *request)
spin_unlock_irqrestore(&request->engine->timeline.lock, flags);
}
+static void wait_for_wedged(struct drm_i915_private *i915)
+{
+ struct i915_gpu_error *error = &i915->gpu_error;
+ DEFINE_WAIT_BIT(wq_entry, &error->flags, I915_WEDGED);
+
+ __wait_on_bit(&error->reset_queue,
+ &wq_entry, bit_wait, TASK_UNINTERRUPTIBLE);
+}
+
void i915_gem_set_wedged(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
- GEM_TRACE("start\n");
+ if (test_and_set_bit(I915_WEDGE_IN_PROGRESS, &i915->gpu_error.flags)) {
+ wait_for_wedged(i915);
+ return;
+ }
if (GEM_SHOW_DEBUG()) {
struct drm_printer p = drm_debug_printer(__func__);
@@ -3312,8 +3324,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
intel_engine_dump(engine, &p, "%s\n", engine->name);
}
- set_bit(I915_WEDGED, &i915->gpu_error.flags);
- smp_mb__after_atomic();
+ GEM_TRACE("start\n");
/*
* First, stop submission to hw, but do not yet complete requests by
@@ -3372,6 +3383,9 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
i915_gem_reset_finish_engine(engine);
}
+ smp_mb__before_atomic();
+ set_bit(I915_WEDGED, &i915->gpu_error.flags);
+
GEM_TRACE("end\n");
wake_up_all(&i915->gpu_error.reset_queue);
@@ -3379,10 +3393,14 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
bool i915_gem_unset_wedged(struct drm_i915_private *i915)
{
+ struct i915_gpu_error *error = &i915->gpu_error;
struct i915_timeline *tl;
lockdep_assert_held(&i915->drm.struct_mutex);
- if (!test_bit(I915_WEDGED, &i915->gpu_error.flags))
+
+ while (test_and_clear_bit(I915_WEDGE_IN_PROGRESS, &error->flags))
+ wait_for_wedged(i915);
+ if (!test_bit(I915_WEDGE_IN_PROGRESS, &error->flags))
return true;
GEM_TRACE("start\n");
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h b/drivers/gpu/drm/i915/i915_gpu_error.h
index f893a4e8b783..1a78a8f330f2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -267,8 +267,9 @@ struct i915_gpu_error {
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
#define I915_RESET_MODESET 2
+#define I915_RESET_ENGINE 3
#define I915_WEDGED (BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
+#define I915_WEDGE_IN_PROGRESS (I915_WEDGED - 1)
/** Number of times an engine has been reset */
u32 reset_engine_count[I915_NUM_ENGINES];
--
2.18.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps
From: David Hildenbrand @ 2018-07-23 17:20 UTC (permalink / raw)
To: Michal Hocko, Vlastimil Babka
Cc: linux-mm, linux-kernel, Andrew Morton, Baoquan He, Dave Young,
Greg Kroah-Hartman, Hari Bathini, Huang Ying, Kirill A. Shutemov,
Marc-André Lureau, Matthew Wilcox, Miles Chen,
Pavel Tatashin, Petr Tesarik
In-Reply-To: <20180723123043.GD31229@dhcp22.suse.cz>
On 23.07.2018 14:30, Michal Hocko wrote:
> On Mon 23-07-18 13:45:18, Vlastimil Babka wrote:
>> On 07/20/2018 02:34 PM, David Hildenbrand wrote:
>>> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
>>> So reserved pages might be access by dump tools although nobody except
>>> the owner should touch them.
>>
>> Are you sure about that? Or maybe I understand wrong. Maybe it changed
>> recently, but IIRC pages that are backing memmap (struct pages) are also
>> PG_reserved. And you definitely do want those in the dump.
>
> You are right. reserve_bootmem_region will make all early bootmem
> allocations (including those backing memmaps) PageReserved. I have asked
> several times but I haven't seen a satisfactory answer yet. Why do we
> even care for kdump about those. If they are reserved the nobody should
> really look at those specific struct pages and manipulate them. Kdump
> tools are using a kernel interface to read the content. If the specific
> content is backed by a non-existing memory then they should simply not
> return anything.
>
"new kernel" provides an interface to read memory from "old kernel".
The new kernel has no idea about
- which memory was added/online in the old kernel
- where struct pages of the old kernel are and what their content is
- which memory is save to touch and which not
Dump tools figure all that out by interpreting the VMCORE. They e.g.
identify "struct pages" and see if they should be dumped. The "new
kernel" only allows to read that memory. It cannot hinder to crash the
system (e.g. if a dump tool would try to read a hwpoison page).
So how should the "new kernel" know if a page can be touched or not?
The *only* way would be to have an interface to the hypervisor where we
"sense" if a memory location is safe to touch. I remember that xen or
hyper-v does that - they fake a zero page in that case, after querying
the hypervisor. But this does not sound like a clean approach to me,
especially es we need yet another hypervisor interface to sense for
memory provided via "some" device.
If we can find a way to just tag pages as "don't touch", it would be the
easiest and cleanest solution in my opinion.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: Lucas Stach @ 2018-07-23 17:19 UTC (permalink / raw)
To: Oleksij Rempel, Shawn Guo, Fabio Estevam, Rob Herring,
Mark Rutland, A.s. Dong, Vladimir Zapolskiy
Cc: kernel, devicetree, dl-linux-imx, linux-arm-kernel
In-Reply-To: <20180722063923.30222-6-o.rempel@pengutronix.de>
Am Sonntag, den 22.07.2018, 08:39 +0200 schrieb Oleksij Rempel:
> The Mailbox controller is able to send messages (up to 4 32 bit words)
> between the endpoints.
>
> This driver was tested using the mailbox-test driver sending messages
> between the Cortex-A7 and the Cortex-M4.
>
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> drivers/mailbox/Kconfig | 6 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/imx-mailbox.c | 273 ++++++++++++++++++++++++++++++++++
> 3 files changed, 281 insertions(+)
> create mode 100644 drivers/mailbox/imx-mailbox.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index a2bb27446dce..79060ddc380d 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -15,6 +15,12 @@ config ARM_MHU
> > The controller has 3 mailbox channels, the last of which can be
> > used in Secure mode only.
>
> +config IMX_MBOX
> > + tristate "i.MX Mailbox"
> > + depends on ARCH_MXC || COMPILE_TEST
> > + help
> > + Mailbox implementation for i.MX Messaging Unit (MU).
> +
> config PLATFORM_MHU
> > tristate "Platform MHU Mailbox"
> > depends on OF
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index cc23c3a43fcd..ba2fe1b6dd62 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
>
> > obj-$(CONFIG_ARM_MHU) += arm_mhu.o
>
> > +obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> +
> > obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
>
> > obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> new file mode 100644
> index 000000000000..29cf2876db01
> --- /dev/null
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -0,0 +1,273 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 Pengutronix, Oleksij Rempel <o.rempel@pengutronix.de>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +
> +/* Transmit Register */
> > +#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> +/* Receive Register */
> > +#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> +/* Status Register */
> > +#define IMX_MU_xSR 0x20
> > +#define IMX_MU_xSR_TEn(x) BIT(20 + (3 - (x)))
> > +#define IMX_MU_xSR_RFn(x) BIT(24 + (3 - (x)))
> > +#define IMX_MU_xSR_BRDIP BIT(9)
> +
> +/* Control Register */
> > +#define IMX_MU_xCR 0x24
> +/* Transmit Interrupt Enable */
> > +#define IMX_MU_xCR_TIEn(x) BIT(20 + (3 - (x)))
> +/* Receive Interrupt Enable */
> > +#define IMX_MU_xCR_RIEn(x) BIT(24 + (3 - (x)))
> +
> > +#define IMX_MU_CHANS 4u
> +
> +struct imx_mu_con_priv {
> > > + int irq;
> > > + unsigned int idx;
> > > + char *irq_desc;
> +};
> +
> +struct imx_mu_priv {
> > > + struct device *dev;
> > > + void __iomem *base;
> +
> > > + struct mbox_controller mbox;
> > > + struct mbox_chan mbox_chans[IMX_MU_CHANS];
> +
> > + struct imx_mu_con_priv con_priv[IMX_MU_CHANS];
> > > + struct clk *clk;
> +
> > > + bool side_b;
> +};
> +
> +static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
> +{
> > + return container_of(mbox, struct imx_mu_priv, mbox);
> +}
> +
> +static void imx_mu_write(struct imx_mu_priv *priv, u32 val, u32 offs)
> +{
> + iowrite32(val, priv->base + offs);
This driver is never going to be used on a device with port based IO,
so iowrite doesn't make much sense here, just use writel. Same comment
applies to the below read function.
Also, given that those functions are not really shortening the code in
the user they may also be removed completely IMHO.
> +}
> +
> +static u32 imx_mu_read(struct imx_mu_priv *priv, u32 offs)
> +{
> > + return ioread32(priv->base + offs);
> +}
> +
> +static u32 imx_mu_rmw(struct imx_mu_priv *priv, u32 offs, u32 set, u32 clr)
> +{
> > + u32 val;
> +
> > + val = imx_mu_read(priv, offs);
> > + val &= ~clr;
> > + val |= set;
> > + imx_mu_write(priv, val, offs);
> +
> > + return val;
> +}
> +
> +static irqreturn_t imx_mu_isr(int irq, void *p)
> +{
> > + struct mbox_chan *chan = p;
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val, ctrl, dat;
> +
> > + ctrl = imx_mu_read(priv, IMX_MU_xCR);
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + val &= IMX_MU_xSR_TEn(cp->idx) | IMX_MU_xSR_RFn(cp->idx);
> > + val &= ctrl & (IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
> > + if (!val)
> > + return IRQ_NONE;
> +
> > + if (val & IMX_MU_xSR_TEn(cp->idx)) {
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0, IMX_MU_xCR_TIEn(cp->idx));
> > + mbox_chan_txdone(chan, 0);
> > + }
> +
> > + if (val & IMX_MU_xSR_RFn(cp->idx)) {
> > + dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
> > + mbox_chan_received_data(chan, (void *)&dat);
> > + }
> +
> > + return IRQ_HANDLED;
> +}
> +
> +static bool imx_mu_last_tx_done(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val;
> +
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + /* test if transmit register is empty */
> + return val & IMX_MU_xSR_TEn(cp->idx);
I guess
"return imx_mu_read(priv, IMX_MU_xSR) & IMX_MU_xSR_TEn(cp->idx);" is
shorter and equally well understood.
> +}
> +
> +static int imx_mu_send_data(struct mbox_chan *chan, void *data)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 *arg = data;
> +
> > + if (!imx_mu_last_tx_done(chan))
> > + return -EBUSY;
> +
> > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->idx), 0);
In multi-channel mode this RMW cycle needs some kind of locking. As
this register is also changed from the irq handler, this probably needs
to be a irqsave spinlock.
> +
> > + return 0;
> +}
> +
> +static int imx_mu_startup(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> +
> > + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, "imx_mu_chan[%i]",
> > + cp->idx);
> > + if (!cp->irq_desc)
> > + return -ENOMEM;
> +
> > + ret = devm_request_irq(priv->dev, cp->irq, imx_mu_isr,
> + IRQF_SHARED, cp->irq_desc, chan);
Using the devm_ variants of those functions doesn't make sense when the
resources aren't tied to the device lifetime. As you are tearing them
down manually in imx_mu_shutdown anyways, just use the raw variants of
those functions.
> + if (ret) {
> > + dev_err(priv->dev,
> > + "Unable to acquire IRQ %d\n", cp->irq);
> > + return ret;
> > + }
> +
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xCR_RIEn(cp->idx), 0);
> +
> > + return 0;
> +}
> +
> +static void imx_mu_shutdown(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> +
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0,
> > + IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
> +
> > + devm_free_irq(priv->dev, cp->irq, chan);
> > + devm_kfree(priv->dev, cp->irq_desc);
> +}
> +
> +static const struct mbox_chan_ops imx_mu_ops = {
> > + .send_data = imx_mu_send_data,
> > + .startup = imx_mu_startup,
> > + .shutdown = imx_mu_shutdown,
> +};
> +
> +static void imx_mu_init_generic(struct imx_mu_priv *priv)
> +{
> > + if (priv->side_b)
> > + return;
> +
> > + /* Set default MU configuration */
> > + imx_mu_write(priv, 0, IMX_MU_xCR);
> +}
> +
> +static int imx_mu_probe(struct platform_device *pdev)
> +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + struct resource *iomem;
> > + struct imx_mu_priv *priv;
> > + unsigned int i;
> > + int irq, ret;
> +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> +
> > + priv->dev = dev;
> +
> > + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + priv->base = devm_ioremap_resource(&pdev->dev, iomem);
> > + if (IS_ERR(priv->base))
> > + return PTR_ERR(priv->base);
> +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0)
> > + return irq;
> +
> > + priv->clk = devm_clk_get(dev, NULL);
> > + if (IS_ERR(priv->clk)) {
> > + if (PTR_ERR(priv->clk) != -ENOENT)
> > + return PTR_ERR(priv->clk);
> +
> > + priv->clk = NULL;
> > + }
> +
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock\n");
> > + return ret;
> > + }
> +
> > + for (i = 0; i < IMX_MU_CHANS; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> +
> > + cp->idx = i;
> > + cp->irq = irq;
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> +
> > + if (of_property_read_bool(np, "fsl,mu-side-b"))
> + priv->side_b = true;
No need for the if clause here. Just assign the return value from
of_property_read_bool to priv->side_b.
> +
> > + priv->mbox.dev = dev;
> > + priv->mbox.ops = &imx_mu_ops;
> > + priv->mbox.chans = priv->mbox_chans;
> > + priv->mbox.num_chans = IMX_MU_CHANS;
> > + priv->mbox.txdone_irq = true;
> +
> > + platform_set_drvdata(pdev, priv);
> +
> > + imx_mu_init_generic(priv);
> +
> > + return mbox_controller_register(&priv->mbox);
> +}
> +
> +static int imx_mu_remove(struct platform_device *pdev)
> +{
> > + struct imx_mu_priv *priv = platform_get_drvdata(pdev);
> +
> > + mbox_controller_unregister(&priv->mbox);
> > + clk_disable_unprepare(priv->clk);
> +
> > + return 0;
> +}
> +
> +static const struct of_device_id imx_mu_dt_ids[] = {
> > + { .compatible = "fsl,imx6sx-mu" },
> > + { },
> +};
> +MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
> +
> +static struct platform_driver imx_mu_driver = {
> > > + .probe = imx_mu_probe,
> > > + .remove = imx_mu_remove,
> > + .driver = {
> > > + .name = "imx_mu",
> > + .of_match_table = imx_mu_dt_ids,
> > + },
> +};
> +module_platform_driver(imx_mu_driver);
> +
> > +MODULE_AUTHOR("Oleksij Rempel <o.rempel@pengutronix.de>");
> +MODULE_DESCRIPTION("Message Unit driver for i.MX");
> +MODULE_LICENSE("GPL v2");
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 5/5] mailbox: Add support for i.MX7D messaging unit
From: Lucas Stach @ 2018-07-23 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180722063923.30222-6-o.rempel@pengutronix.de>
Am Sonntag, den 22.07.2018, 08:39 +0200 schrieb Oleksij Rempel:
> The Mailbox controller is able to send messages (up to 4 32 bit words)
> between the endpoints.
>
> This driver was tested using the mailbox-test driver sending messages
> between the Cortex-A7 and the Cortex-M4.
>
> > Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> ?drivers/mailbox/Kconfig???????|???6 +
> ?drivers/mailbox/Makefile??????|???2 +
> ?drivers/mailbox/imx-mailbox.c | 273 ++++++++++++++++++++++++++++++++++
> ?3 files changed, 281 insertions(+)
> ?create mode 100644 drivers/mailbox/imx-mailbox.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index a2bb27446dce..79060ddc380d 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -15,6 +15,12 @@ config ARM_MHU
> > ? ??The controller has 3 mailbox channels, the last of which can be
> > ? ??used in Secure mode only.
> ?
> +config IMX_MBOX
> > + tristate "i.MX Mailbox"
> > + depends on ARCH_MXC || COMPILE_TEST
> > + help
> > + ??Mailbox implementation for i.MX Messaging Unit (MU).
> +
> ?config PLATFORM_MHU
> > ? tristate "Platform MHU Mailbox"
> > ? depends on OF
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index cc23c3a43fcd..ba2fe1b6dd62 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> > @@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
> ?
> > ?obj-$(CONFIG_ARM_MHU) += arm_mhu.o
> ?
> > +obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
> +
> > ?obj-$(CONFIG_PLATFORM_MHU) += platform_mhu.o
> ?
> > ?obj-$(CONFIG_PL320_MBOX) += pl320-ipc.o
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> new file mode 100644
> index 000000000000..29cf2876db01
> --- /dev/null
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -0,0 +1,273 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018 Pengutronix, Oleksij Rempel <o.rempel@pengutronix.de>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/mailbox_controller.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +
> +/* Transmit Register */
> > +#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> +/* Receive Register */
> > +#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> +/* Status Register */
> > +#define IMX_MU_xSR 0x20
> > +#define IMX_MU_xSR_TEn(x) BIT(20 + (3 - (x)))
> > +#define IMX_MU_xSR_RFn(x) BIT(24 + (3 - (x)))
> > +#define IMX_MU_xSR_BRDIP BIT(9)
> +
> +/* Control Register */
> > +#define IMX_MU_xCR 0x24
> +/* Transmit Interrupt Enable */
> > +#define IMX_MU_xCR_TIEn(x) BIT(20 + (3 - (x)))
> +/* Receive Interrupt Enable */
> > +#define IMX_MU_xCR_RIEn(x) BIT(24 + (3 - (x)))
> +
> > +#define IMX_MU_CHANS 4u
> +
> +struct imx_mu_con_priv {
> > > + int irq;
> > > + unsigned int idx;
> > > + char *irq_desc;
> +};
> +
> +struct imx_mu_priv {
> > > + struct device *dev;
> > > + void __iomem *base;
> +
> > > + struct mbox_controller mbox;
> > > + struct mbox_chan mbox_chans[IMX_MU_CHANS];
> +
> > + struct imx_mu_con_priv??con_priv[IMX_MU_CHANS];
> > > + struct clk *clk;
> +
> > > + bool side_b;
> +};
> +
> +static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
> +{
> > + return container_of(mbox, struct imx_mu_priv, mbox);
> +}
> +
> +static void imx_mu_write(struct imx_mu_priv *priv, u32 val, u32 offs)
> +{
> + iowrite32(val, priv->base + offs);
This driver is never going to be used on a device with port based IO,
so iowrite doesn't make much sense here, just use writel. Same comment
applies to the below read function.
Also, given that those functions are not really shortening the code in
the user they may also be removed completely IMHO.
> +}
> +
> +static u32 imx_mu_read(struct imx_mu_priv *priv, u32 offs)
> +{
> > + return ioread32(priv->base + offs);
> +}
> +
> +static u32 imx_mu_rmw(struct imx_mu_priv *priv, u32 offs, u32 set, u32 clr)
> +{
> > + u32 val;
> +
> > + val = imx_mu_read(priv, offs);
> > + val &= ~clr;
> > + val |= set;
> > + imx_mu_write(priv, val, offs);
> +
> > + return val;
> +}
> +
> +static irqreturn_t imx_mu_isr(int irq, void *p)
> +{
> > + struct mbox_chan *chan = p;
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val, ctrl, dat;
> +
> > + ctrl = imx_mu_read(priv, IMX_MU_xCR);
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + val &= IMX_MU_xSR_TEn(cp->idx) | IMX_MU_xSR_RFn(cp->idx);
> > + val &= ctrl & (IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
> > + if (!val)
> > + return IRQ_NONE;
> +
> > + if (val & IMX_MU_xSR_TEn(cp->idx)) {
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0, IMX_MU_xCR_TIEn(cp->idx));
> > + mbox_chan_txdone(chan, 0);
> > + }
> +
> > + if (val & IMX_MU_xSR_RFn(cp->idx)) {
> > + dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
> > + mbox_chan_received_data(chan, (void *)&dat);
> > + }
> +
> > + return IRQ_HANDLED;
> +}
> +
> +static bool imx_mu_last_tx_done(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 val;
> +
> > + val = imx_mu_read(priv, IMX_MU_xSR);
> > + /* test if transmit register is empty */
> + return val & IMX_MU_xSR_TEn(cp->idx);
I guess
"return imx_mu_read(priv, IMX_MU_xSR) & IMX_MU_xSR_TEn(cp->idx);" is
shorter and equally well understood.
> +}
> +
> +static int imx_mu_send_data(struct mbox_chan *chan, void *data)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + u32 *arg = data;
> +
> > + if (!imx_mu_last_tx_done(chan))
> > + return -EBUSY;
> +
> > + imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
> + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xSR_TEn(cp->idx), 0);
In multi-channel mode this RMW cycle needs some kind of locking. As
this register is also changed from the irq handler, this probably needs
to be a irqsave spinlock.
> +
> > + return 0;
> +}
> +
> +static int imx_mu_startup(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> > + int ret;
> +
> > + cp->irq_desc = devm_kasprintf(priv->dev, GFP_KERNEL, "imx_mu_chan[%i]",
> > + ??????cp->idx);
> > + if (!cp->irq_desc)
> > + return -ENOMEM;
> +
> > + ret = devm_request_irq(priv->dev, cp->irq, imx_mu_isr,
> + ???????IRQF_SHARED, cp->irq_desc, chan);
Using the devm_ variants of those functions doesn't make sense when the
resources aren't tied to the device lifetime. As you are tearing them
down manually in imx_mu_shutdown anyways, just use the raw variants of
those functions.
> + if (ret) {
> > + dev_err(priv->dev,
> > + "Unable to acquire IRQ %d\n", cp->irq);
> > + return ret;
> > + }
> +
> > + imx_mu_rmw(priv, IMX_MU_xCR, IMX_MU_xCR_RIEn(cp->idx), 0);
> +
> > + return 0;
> +}
> +
> +static void imx_mu_shutdown(struct mbox_chan *chan)
> +{
> > + struct imx_mu_priv *priv = to_imx_mu_priv(chan->mbox);
> > + struct imx_mu_con_priv *cp = chan->con_priv;
> +
> > + imx_mu_rmw(priv, IMX_MU_xCR, 0,
> > + ???IMX_MU_xCR_TIEn(cp->idx) | IMX_MU_xCR_RIEn(cp->idx));
> +
> > + devm_free_irq(priv->dev, cp->irq, chan);
> > + devm_kfree(priv->dev, cp->irq_desc);
> +}
> +
> +static const struct mbox_chan_ops imx_mu_ops = {
> > + .send_data = imx_mu_send_data,
> > + .startup = imx_mu_startup,
> > + .shutdown = imx_mu_shutdown,
> +};
> +
> +static void imx_mu_init_generic(struct imx_mu_priv *priv)
> +{
> > + if (priv->side_b)
> > + return;
> +
> > + /* Set default MU configuration */
> > + imx_mu_write(priv, 0, IMX_MU_xCR);
> +}
> +
> +static int imx_mu_probe(struct platform_device *pdev)
> +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + struct resource *iomem;
> > + struct imx_mu_priv *priv;
> > + unsigned int i;
> > + int irq, ret;
> +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> +
> > + priv->dev = dev;
> +
> > + iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + priv->base = devm_ioremap_resource(&pdev->dev, iomem);
> > + if (IS_ERR(priv->base))
> > + return PTR_ERR(priv->base);
> +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq < 0)
> > + return irq;
> +
> > + priv->clk = devm_clk_get(dev, NULL);
> > + if (IS_ERR(priv->clk)) {
> > + if (PTR_ERR(priv->clk) != -ENOENT)
> > + return PTR_ERR(priv->clk);
> +
> > + priv->clk = NULL;
> > + }
> +
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable clock\n");
> > + return ret;
> > + }
> +
> > + for (i = 0; i < IMX_MU_CHANS; i++) {
> > + struct imx_mu_con_priv *cp = &priv->con_priv[i];
> +
> > + cp->idx = i;
> > + cp->irq = irq;
> > + priv->mbox_chans[i].con_priv = cp;
> > + }
> +
> > + if (of_property_read_bool(np, "fsl,mu-side-b"))
> + priv->side_b = true;
No need for the if clause here. Just assign the return value from
of_property_read_bool to priv->side_b.
> +
> > + priv->mbox.dev = dev;
> > + priv->mbox.ops = &imx_mu_ops;
> > + priv->mbox.chans = priv->mbox_chans;
> > + priv->mbox.num_chans = IMX_MU_CHANS;
> > + priv->mbox.txdone_irq = true;
> +
> > + platform_set_drvdata(pdev, priv);
> +
> > + imx_mu_init_generic(priv);
> +
> > + return mbox_controller_register(&priv->mbox);
> +}
> +
> +static int imx_mu_remove(struct platform_device *pdev)
> +{
> > + struct imx_mu_priv *priv = platform_get_drvdata(pdev);
> +
> > + mbox_controller_unregister(&priv->mbox);
> > + clk_disable_unprepare(priv->clk);
> +
> > + return 0;
> +}
> +
> +static const struct of_device_id imx_mu_dt_ids[] = {
> > + { .compatible = "fsl,imx6sx-mu" },
> > + { },
> +};
> +MODULE_DEVICE_TABLE(of, imx_mu_dt_ids);
> +
> +static struct platform_driver imx_mu_driver = {
> > > + .probe = imx_mu_probe,
> > > + .remove = imx_mu_remove,
> > + .driver = {
> > > + .name = "imx_mu",
> > + .of_match_table = imx_mu_dt_ids,
> > + },
> +};
> +module_platform_driver(imx_mu_driver);
> +
> > +MODULE_AUTHOR("Oleksij Rempel <o.rempel@pengutronix.de>");
> +MODULE_DESCRIPTION("Message Unit driver for i.MX");
> +MODULE_LICENSE("GPL v2");
^ permalink raw reply
* Re: [PATCH] mmc: renesas_sdhi: Add r8a77990 support
From: Simon Horman @ 2018-07-23 16:17 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-mmc, linux-renesas-soc, Niklas Söderlund
In-Reply-To: <20180721111449.10103-1-wsa+renesas@sang-engineering.com>
On Sat, Jul 21, 2018 at 01:14:49PM +0200, Wolfram Sang wrote:
> This patch adds SDHI support for the R8A77990 SoC (R-Car E3). No driver changes
> needed for anything except HS400 which we will enable separately later.
No driver update should be required for HS400, see below.
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
>
> Note: we shouldn't enable HS400 in the DTS files yet, since we don't have the 8
> tap support. But I think we can enable basic support.
8 tap support is included in the following patch which was accepted
for inclusion in upstream (search for 4TAP):
26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
> Documentation/devicetree/bindings/mmc/tmio_mmc.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> index 839f469f4525..c434200d19d5 100644
> --- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
> @@ -28,6 +28,7 @@ Required properties:
> "renesas,sdhi-r8a7796" - SDHI IP on R8A7796 SoC
> "renesas,sdhi-r8a77965" - SDHI IP on R8A77965 SoC
> "renesas,sdhi-r8a77980" - SDHI IP on R8A77980 SoC
> + "renesas,sdhi-r8a77990" - SDHI IP on R8A77990 SoC
> "renesas,sdhi-r8a77995" - SDHI IP on R8A77995 SoC
> "renesas,sdhi-shmobile" - a generic sh-mobile SDHI controller
> "renesas,rcar-gen1-sdhi" - a generic R-Car Gen1 SDHI controller
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH] ACPI/IORT: Support address size limit for root complexes
From: Robin Murphy @ 2018-07-23 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180718163622.GA21924@red-moon>
[+Christoph]
On 18/07/18 17:36, Lorenzo Pieralisi wrote:
> [+Catalin, Will]
>
> On Mon, Jul 16, 2018 at 04:34:51PM +0100, Robin Murphy wrote:
>> On 2018-07-16 4:10 PM, Lorenzo Pieralisi wrote:
>>> On Tue, Jul 10, 2018 at 05:13:45PM +0100, Robin Murphy wrote:
>>>> IORT revision D allows PCI root complex nodes to specify a memory
>>>> address size limit equivalently to named components, to help describe
>>>> straightforward integrations which don't really warrant a full-blown
>>>> _DMA method. Now that our headers are up-to-date, plumb it in.
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>>> ---
>>>> drivers/acpi/arm64/iort.c | 25 +++++++++++++++++++++++--
>>>> 1 file changed, 23 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>>> index 7a3a541046ed..4a66896e2aa3 100644
>>>> --- a/drivers/acpi/arm64/iort.c
>>>> +++ b/drivers/acpi/arm64/iort.c
>>>> @@ -947,6 +947,24 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
>>>> return 0;
>>>> }
>>>> +static int rc_dma_get_range(struct device *dev, u64 *size)
>>>> +{
>>>> + struct acpi_iort_node *node;
>>>> + struct acpi_iort_root_complex *rc;
>>>> +
>>>> + node = iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
>>>> + iort_match_node_callback, dev);
>>>> + if (!node || node->revision < 1)
>>>> + return -ENODEV;
>>>> +
>>>> + rc = (struct acpi_iort_root_complex *)node->node_data;
>>>> +
>>>> + *size = rc->memory_address_limit >= 64 ? U64_MAX :
>>>> + 1ULL<<rc->memory_address_limit;
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> /**
>>>> * iort_dma_setup() - Set-up device DMA parameters.
>>>> *
>>>> @@ -975,10 +993,13 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
>>>> size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>>> - if (dev_is_pci(dev))
>>>> + if (dev_is_pci(dev)) {
>>>> ret = acpi_dma_get_range(dev, &dmaaddr, &offset, &size);
>>>> - else
>>>> + if (ret == -ENODEV)
>>>> + ret = rc_dma_get_range(dev, &size);
>>>
>>> Thank you for putting together the patch.
>>>
>>> The question is whether it is OK to ignore the IORT address limits
>>> when _DMA is actually specified. It is a sort of grey area that
>>> has to be clarified, maybe we can add a check to detect a size
>>> mismatch, I do not know if something should be added at IORT spec
>>> level to clarify its relation to the _DMA object, if present.
>>
>> Yeah, I'm assuming that _DMA would be used to describe conditions
>> more specific than the simple address size limit (i.e. bridge
>> windows), so even if both are present, the range inferred from _DMA
>> will always be less than or equal to that inferred from IORT, and
>> thus rather than explicitly calculating the intersection of the two
>> we can simply do this short-circuit.
>>
>> If IORT accurately reflects the total number of usable address bits,
>> then I can't see that it would ever make sense for _DMA to specify
>> an address range which exceeds that; I guess it comes down to how
>> much effort we want to spend verifying firmware instead of trusting
>> it.
>
> I agree with this reasoning and the patch looks fine, I have not
> queued anything for this cycle for IORT so I would ask Will/Catalin
> to pick it up (if we still have time for v4.19):
>
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cheers Lorenzo (and Hanjun). Given that my DMA mask series[1] is
nominally based on top of this, it might make sense for Christoph to
pick it up through the dma-mapping tree. Since I'm about to send a new
version of that series I'll resend this one as part of that.
Thanks,
Robin.
[1]
https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg24358.html
^ permalink raw reply
* Re: [PATCH] ACPI/IORT: Support address size limit for root complexes
From: Robin Murphy @ 2018-07-23 17:18 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: catalin.marinas, will.deacon, linux-acpi, hanjun.guo,
sudeep.holla, Christoph Hellwig, linux-arm-kernel
In-Reply-To: <20180718163622.GA21924@red-moon>
[+Christoph]
On 18/07/18 17:36, Lorenzo Pieralisi wrote:
> [+Catalin, Will]
>
> On Mon, Jul 16, 2018 at 04:34:51PM +0100, Robin Murphy wrote:
>> On 2018-07-16 4:10 PM, Lorenzo Pieralisi wrote:
>>> On Tue, Jul 10, 2018 at 05:13:45PM +0100, Robin Murphy wrote:
>>>> IORT revision D allows PCI root complex nodes to specify a memory
>>>> address size limit equivalently to named components, to help describe
>>>> straightforward integrations which don't really warrant a full-blown
>>>> _DMA method. Now that our headers are up-to-date, plumb it in.
>>>>
>>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>>> ---
>>>> drivers/acpi/arm64/iort.c | 25 +++++++++++++++++++++++--
>>>> 1 file changed, 23 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>>>> index 7a3a541046ed..4a66896e2aa3 100644
>>>> --- a/drivers/acpi/arm64/iort.c
>>>> +++ b/drivers/acpi/arm64/iort.c
>>>> @@ -947,6 +947,24 @@ static int nc_dma_get_range(struct device *dev, u64 *size)
>>>> return 0;
>>>> }
>>>> +static int rc_dma_get_range(struct device *dev, u64 *size)
>>>> +{
>>>> + struct acpi_iort_node *node;
>>>> + struct acpi_iort_root_complex *rc;
>>>> +
>>>> + node = iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
>>>> + iort_match_node_callback, dev);
>>>> + if (!node || node->revision < 1)
>>>> + return -ENODEV;
>>>> +
>>>> + rc = (struct acpi_iort_root_complex *)node->node_data;
>>>> +
>>>> + *size = rc->memory_address_limit >= 64 ? U64_MAX :
>>>> + 1ULL<<rc->memory_address_limit;
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> /**
>>>> * iort_dma_setup() - Set-up device DMA parameters.
>>>> *
>>>> @@ -975,10 +993,13 @@ void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size)
>>>> size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>>> - if (dev_is_pci(dev))
>>>> + if (dev_is_pci(dev)) {
>>>> ret = acpi_dma_get_range(dev, &dmaaddr, &offset, &size);
>>>> - else
>>>> + if (ret == -ENODEV)
>>>> + ret = rc_dma_get_range(dev, &size);
>>>
>>> Thank you for putting together the patch.
>>>
>>> The question is whether it is OK to ignore the IORT address limits
>>> when _DMA is actually specified. It is a sort of grey area that
>>> has to be clarified, maybe we can add a check to detect a size
>>> mismatch, I do not know if something should be added at IORT spec
>>> level to clarify its relation to the _DMA object, if present.
>>
>> Yeah, I'm assuming that _DMA would be used to describe conditions
>> more specific than the simple address size limit (i.e. bridge
>> windows), so even if both are present, the range inferred from _DMA
>> will always be less than or equal to that inferred from IORT, and
>> thus rather than explicitly calculating the intersection of the two
>> we can simply do this short-circuit.
>>
>> If IORT accurately reflects the total number of usable address bits,
>> then I can't see that it would ever make sense for _DMA to specify
>> an address range which exceeds that; I guess it comes down to how
>> much effort we want to spend verifying firmware instead of trusting
>> it.
>
> I agree with this reasoning and the patch looks fine, I have not
> queued anything for this cycle for IORT so I would ask Will/Catalin
> to pick it up (if we still have time for v4.19):
>
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cheers Lorenzo (and Hanjun). Given that my DMA mask series[1] is
nominally based on top of this, it might make sense for Christoph to
pick it up through the dma-mapping tree. Since I'm about to send a new
version of that series I'll resend this one as part of that.
Thanks,
Robin.
[1]
https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg24358.html
^ permalink raw reply
* Re: [PATCH 05/11] touchscreen: elants: Use octal permissions
From: Dmitry Torokhov @ 2018-07-23 17:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: dev-harsh1998, trivial, Simon Budig, Andi Shyti, Luca Ceresoli,
Joe Perches, Guenter Roeck, linux-input, linux-kernel
In-Reply-To: <20180723133200.GA1167@kroah.com>
On Mon, Jul 23, 2018 at 03:32:00PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jul 23, 2018 at 06:49:20PM +0530, dev-harsh1998 wrote:
> > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> > +static DEVICE_ATTR(iap_mode, S_IRUGO, show_iap_mode, NULL);
> >
> > WARNING: Symbolic permissions 'S_IWUSR' are not preferred. Consider using octal permissions '0200'.
> > +static DEVICE_ATTR(update_fw, S_IWUSR, NULL, write_update_fw)
> >
> > WARNING: Symbolic permissions 'S_IRUGO' are not preferred. Consider using octal permissions '0444'.
> > + .dattr = __ATTR(_field, S_IRUGO, \
> >
> > Signed-off-by: Harshit Jain <harshitjain6751@gmail.com>
>
> This name doesn't match up with the From: line above :(
>
> Please fix up and try again.
dtor@dtor-ws:~/kernel/linux-next$ git grep S_IRU | wc -l
7605
We either need to run a tree-wide script or leave this alone. FWIW I am
perfectly fine with either octals or symbolic names so I do not see
benefit of doing conversion for code that is not known to be broken.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
From: Verma, Shally @ 2018-07-23 17:14 UTC (permalink / raw)
To: Stephen Hemminger
Cc: pablo.de.lara.guarch@intel.com, dev@dpdk.org,
Athreya, Narayana Prasad, Challa, Mahipal, Gupta, Ashish,
Sahu, Sunila, Sahu, Sunila
In-Reply-To: <20180723095357.5a85b206@xeon-e3>
>-----Original Message-----
>From: Stephen Hemminger <stephen@networkplumber.org>
>Sent: 23 July 2018 22:24
>To: Verma, Shally <Shally.Verma@cavium.com>
>Cc: pablo.de.lara.guarch@intel.com; dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Challa,
>Mahipal <Mahipal.Challa@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>;
>Sahu, Sunila <Sunila.Sahu@cavium.com>
>Subject: Re: [dpdk-dev] [PATCH v3 4/5] compress/zlib: support burst enqueue/dequeue
>
>External Email
>
>On Sat, 21 Jul 2018 23:47:48 +0530
>Shally Verma <shally.verma@caviumnetworks.com> wrote:
>
>> -/** Parse comp xform and set private xform/stream parameters */
>> +/** Compute next mbuf in the list, assign data buffer and length,
>> + * returns 0 if mbuf is NULL
>> + */
>> +#define COMPUTE_BUF(mbuf, data, len) \
>> + ((mbuf = mbuf->next) ? \
>> + (data = rte_pktmbuf_mtod(mbuf, uint8_t *)), \
>> + (len = rte_pktmbuf_data_len(mbuf)) : 0)
>> +
>
>Could this be an inline not a macro?
[Shally] Again what goes in favour of inline here? Just curious to know if DPDK has any preferred guidelines regarding this?
Thanks
Shally
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.