Re: [PATCH v2 00/24] exec: Move unshare_files and guarantee files_struct.count is correct
On Fri, Nov 20, 2020 at 04:05:47PM -0800, Linus Torvalds wrote: > On Fri, Nov 20, 2020 at 3:11 PM Eric W. Biederman > wrote: > > > > This set of changes cleanups of the code in exec so hopefully this code > > will not regress again. Then it adds helpers and fixes the users of > > files_struct so the reference count is only incremented if COPY_FILES is > > passed to clone (or if io_uring takes a reference). Then it removes > > helpers (get_files_struct, __install_fd, __alloc_fd, __close_fd) that > > are no longer needed and if used would encourage code that increments > > the count of files_struct somewhere besides in clone when COPY_FILES is > > passed. > > I'm not seeing anything that triggered me going "that looks dodgy". It > all looks like nice cleanups. > > But that's just from reading the patches (and in some cases going and > looking at the context), so I didn't actually _test_ any of it. It all > looks sane to me, though, and the fact that it removes a fair number > of lines of code is always a good sign. > > It would be good for people to review and test (Al? Oleg? others?), > but my gut feel is "this is good". Will check (sorry, the last couple of weeks had been bloody awful - off-net and very short on sleep); I'm digging through the piles of email right now.
Re: [PATCH 1/2] dt-bindings: reset: document Broadcom's BCM4908 PCIe reset binding
On 11/27/2020 3:14 AM, Rafał Miłecki wrote: > From: Rafał Miłecki > > BCM4908 was built using older PCIe hardware block that requires using > external reset block controlling PERST# signals. > > Signed-off-by: Rafał Miłecki Acked-by: Florian Fainelli -- Florian
Re: [PATCH] media: vb2: always set buffer cache sync hints
On (20/11/28 01:50), Tomasz Figa wrote:
> On Sat, Nov 28, 2020 at 1:35 AM Sergey Senozhatsky
> wrote:
> >
> > On (20/11/27 15:56), Hans Verkuil wrote:
> > > Yes.
> > >
> > > BTW, wouldn't it be sufficient to change this code to:
> > >
> > > if (!q->allow_cache_hints && q->memory != VB2_MEMORY_DMABUF) {
> > > vb->need_cache_sync_on_prepare = 1;
> > > vb->need_cache_sync_on_finish = 1;
> > > }
> >
> > I think it would be sufficient.
>
> Does it matter at this point if allow_cache_hints is set or not?
That's a good question. I'd say that it'll probably make sense to set
need_cache_sync for as many buffers as possible, regardless the queue
configuration (except for ->memory type), just to stay on the safe side.
I can spin another patch version.
-ss
Re: [PATCH] mm: memcg/slab: fix obj_cgroup_charge() return value handling
On Fri, Nov 27, 2020 at 8:18 AM Roman Gushchin wrote:
>
> On Thu, Nov 26, 2020 at 09:55:24PM -0800, Shakeel Butt wrote:
> > On Thu, Nov 26, 2020 at 8:14 PM Roman Gushchin wrote:
> > >
> > > Commit 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches
> > > for all allocations") introduced a regression into the handling of the
> > > obj_cgroup_charge() return value. If a non-zero value is returned
> > > (indicating of exceeding one of memory.max limits), the allocation
> > > should fail, instead of falling back to non-accounted mode.
> > >
> > > To make the code more readable, move memcg_slab_pre_alloc_hook()
> > > and memcg_slab_post_alloc_hook() calling conditions into bodies
> > > of these hooks.
> > >
> > > Fixes: 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for
> > > all allocations")
> > > Signed-off-by: Roman Gushchin
> > > Cc: sta...@vger.kernel.org
> > > ---
> > > mm/slab.h | 40
> > > 1 file changed, 24 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/mm/slab.h b/mm/slab.h
> > > index 59aeb0d9f11b..5dc89d8fb05e 100644
> > > --- a/mm/slab.h
> > > +++ b/mm/slab.h
> > > @@ -257,22 +257,32 @@ static inline size_t obj_full_size(struct
> > > kmem_cache *s)
> > > return s->size + sizeof(struct obj_cgroup *);
> > > }
> > >
> > > -static inline struct obj_cgroup *memcg_slab_pre_alloc_hook(struct
> > > kmem_cache *s,
> > > - size_t objects,
> > > - gfp_t flags)
> > > +/*
> > > + * Returns true if the allocation should fail.
> >
> > IMO returning false if the allocation should fail makes this more
> > clear. Otherwise the patch looks good to me.
>
> Ok, I agree. Here is an updated version.
>
> Thank you for looking in!
>
> --
>
> From 456ce03f1c91baf5e2441dce0649e09617437fe4 Mon Sep 17 00:00:00 2001
> From: Roman Gushchin
> Date: Thu, 26 Nov 2020 07:39:57 -0800
> Subject: [PATCH v2] mm: memcg/slab: fix obj_cgroup_charge() return value
> handling
>
> Commit 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches
> for all allocations") introduced a regression into the handling of the
> obj_cgroup_charge() return value. If a non-zero value is returned
> (indicating of exceeding one of memory.max limits), the allocation
> should fail, instead of falling back to non-accounted mode.
>
> To make the code more readable, move memcg_slab_pre_alloc_hook()
> and memcg_slab_post_alloc_hook() calling conditions into bodies
> of these hooks.
>
> Fixes: 10befea91b61 ("mm: memcg/slab: use a single set of kmem_caches for all
> allocations")
> Signed-off-by: Roman Gushchin
> Cc: sta...@vger.kernel.org
Reviewed-by: Shakeel Butt
[PATCH v2 5/5] x86/platform/uv: Update sysfs document file
Update sysfs Document file to include moved /proc leaves.
Signed-off-by: Mike Travis
---
Documentation/ABI/testing/sysfs-firmware-sgi_uv | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
index 50e25ce80fa2..b377f1470ba2 100644
--- a/Documentation/ABI/testing/sysfs-firmware-sgi_uv
+++ b/Documentation/ABI/testing/sysfs-firmware-sgi_uv
@@ -7,10 +7,25 @@ Description:
Under that directory are a number of read-only attributes:
+ archtype
+ hub_type
+ hubless
partition_id
coherence_id
uv_type
+ The archtype entry contains the UV architecture type that
+ is used to select arch-dependent addresses and features.
+ If can be set via the OEM_ID in the ACPI MADT table or by
+ UVsystab entry both passed from UV BIOS.
+
+ The hub_type entry is used to select the type of hub which is
+ similar to uv_type but encoded in a binary format. Include
+ the file uv_hub.h to get the definitions.
+
+ The hubless entry basically is present and set only if there
+ is no hub. In this case the hub_type entry is not present.
+
The partition_id entry contains the partition id.
UV systems can be partitioned into multiple physical
machines, which each partition running a unique copy
@@ -24,6 +39,7 @@ Description:
The uv_type entry contains the hub revision number.
This value can be used to identify the UV system version:
+ "0.*" = Hubless UV ('*' is subtype)
"3.0" = UV2
"5.0" = UV3
"7.0" = UV4
--
2.21.0
Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC
On 11/27/2020 4:33 PM, Lukasz Majewski wrote:
>> So why use DSA at all? What benefit does it bring you? Why not do the
>> entire switch configuration from within FEC, or a separate driver very
>> closely related to it?
>
> Mine rationale to use DSA and FEC:
> - Make as little changes to FEC as possible
Which is entirely possible if you stick to Vladimir suggestions of
exporting services for the MTIP switch driver.
>
> - Provide separate driver to allow programming FDB, MDB, VLAN setup.
> This seems straightforward as MTIP has separate memory region (from
> FEC) for switch configuration, statistics, learning, static table
> programming. What is even more bizarre FEC and MTIP have the same 8
> registers (with different base address and +4 offset :-) ) as
> interface to handle DMA0 transfers.
OK, not sure how that is relevant here? The register organization should
never ever dictate how to pick a particular subsystem.
>
> - According to MTIP description from NXP documentation, there is a
> separate register for frame forwarding, so it _shall_ also fit into
> DSA.
And yet it does not, Vladimir went into great length into explaining
what makes the MTIP + dual FEC different here and why it does not
qualify for DSA. Basically any time you have DMA + integrated switch
tightly coupled you have what we have coined a "pure switchdev" wrapper.
>
>
> For me it would be enough to have:
>
> - lan{12} - so I could enable/disable it on demand (control when switch
> ports are passing or not packets).
>
> - Use standard net tools (like bridge) to setup FDB/MDB, vlan
>
> - Read statistics from MTIP ports (all of them)
>
> - I can use lan1 (bridged or not) to send data outside. It would be
> also correct to use eth0.
You know you can do that without having DSA, right? Look at mlxsw, look
at rocker. You can call multiple times register_netdevice() with custom
network devices that behave differently whether HW bridging offload is
offered or not, whether the switch is declared in Device Tree or not.
>
> I'm for the most pragmatic (and simple) solution, which fulfill above
> requirements.
The most pragmatic solution is to implement switchdev operations to
offer HW bridging offload, VLAN programming, FDB/MDB programming.
It seems to me that you are trying to look for a framework to avoid
doing a bit of middle layer work between switchdev and the FEC driver
and that is not setting you for success.
--
Florian
Re: [RFC 1/3] mm/hotplug: Pre-validate the address range with platform
On 11/27/20 2:31 PM, David Hildenbrand wrote:
>>>
>>> "arch_get_mappable_range(void)" (or similar) ?
>>
>> The current name seems bit better (I guess). Because we are asking for
>> max addressable range with or without the linear mapping.
>>
>>>
>>> AFAIKs, both implementations (arm64/s390x) simply do the exact same
>>> thing as memhp_get_pluggable_range() for !need_mapping.
>>
>> That is for now. Even the range without requiring linear mapping might not
>> be the same (like now) for every platform as some might have constraints.
>> So asking the platform ranges with or without linear mapping seems to be
>> better and could accommodate special cases going forward. Anyways, there
>> is an always an "all allowing" fallback option nonetheless.
>
> Let's keep it simple as long as we don't have a real scenario where this
> would apply.
Sure, will have the arch callback only when the range needs linear mapping.
Otherwise, memhp_get_pluggable_range() can just fallback on [0...max_phys]
for non linear mapping requests.
>
> [...]
>
>>
>>>
+ return true;
+
+ WARN(1, "Hotplug memory [%#llx-%#llx] exceeds maximum addressable range
[%#llx-%#llx]\n",
+ start, end, memhp_range.start, memhp_range.end);
>>>
>>> pr_warn() (or even pr_warn_once())
>>>
>>> while we're at it. No reason to eventually crash a system :)
>>
>> Didn't quite get it. How could this crash the system ?
>
> With panic_on_warn, which some distributions started to enable.
Okay, got it.
>
> [...]
>
/*
* Validate altmap is within bounds of the total request
@@ -1109,6 +1089,9 @@ int __ref __add_memory(int nid, u64 start, u64 size,
mhp_t mhp_flags)
struct resource *res;
int ret;
+ if (!memhp_range_allowed(start, size, 1))
+ return -ERANGE;
>>>
>>> We used to return -E2BIG, no? Maybe better keep that.
>>
>> ERANGE seems to be better as the range can overrun on either side.
>
> Did you check all callers that they can handle it? Should mention that
> in the patch description then.
Hmm, okay then. Lets keep -E2BIG to be less disruptive for the callers.
>
>>
>>>
+
res = register_memory_resource(start, size, "System RAM");
if (IS_ERR(res))
return PTR_ERR(res);
@@ -1123,6 +1106,9 @@ int add_memory(int nid, u64 start, u64 size, mhp_t
mhp_flags)
{
int rc;
+ if (!memhp_range_allowed(start, size, 1))
+ return -ERANGE;
+
lock_device_hotplug();
rc = __add_memory(nid, start, size, mhp_flags);
unlock_device_hotplug();
@@ -1163,6 +1149,9 @@ int add_memory_driver_managed(int nid, u64 start,
u64 size,
resource_name[strlen(resource_name) - 1] != ')')
return -EINVAL;
+ if (!memhp_range_allowed(start, size, 0))
+ return -ERANGE;
+
lock_device_hotplug();
>>>
>>> For all 3 cases, doing a single check in register_memory_resource() is
>>> sufficient.
>>
>> Will replace with a single check in register_memory_resource(). But does
>> add_memory_driver_managed() always require linear mapping ? The proposed
>> check here did not ask for linear mapping in add_memory_driver_managed().
>
> Yes, in that regard, it behaves just like add_memory().
Sure.
[PATCH V2 net-next 1/7] net: hns3: add support for RX completion checksum
In some cases (for example ip fragment), hardware will
calculate the checksum of whole packet in RX, and setup
the HNS3_RXD_L2_CSUM_B flag in the descriptor, so add
support to utilize this checksum.
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 21 +
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 7 +++
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 1 +
3 files changed, 29 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 632ad42..1647877 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2798,6 +2798,22 @@ static int hns3_gro_complete(struct sk_buff *skb, u32
l234info)
return 0;
}
+static void hns3_checksum_complete(struct hns3_enet_ring *ring,
+ struct sk_buff *skb, u32 l234info)
+{
+ u32 lo, hi;
+
+ u64_stats_update_begin(&ring->syncp);
+ ring->stats.csum_complete++;
+ u64_stats_update_end(&ring->syncp);
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ lo = hnae3_get_field(l234info, HNS3_RXD_L2_CSUM_L_M,
+HNS3_RXD_L2_CSUM_L_S);
+ hi = hnae3_get_field(l234info, HNS3_RXD_L2_CSUM_H_M,
+HNS3_RXD_L2_CSUM_H_S);
+ skb->csum = csum_unfold((__force __sum16)(lo | hi << 8));
+}
+
static void hns3_rx_checksum(struct hns3_enet_ring *ring, struct sk_buff *skb,
u32 l234info, u32 bd_base_info, u32 ol_info)
{
@@ -2812,6 +2828,11 @@ static void hns3_rx_checksum(struct hns3_enet_ring
*ring, struct sk_buff *skb,
if (!(netdev->features & NETIF_F_RXCSUM))
return;
+ if (l234info & BIT(HNS3_RXD_L2_CSUM_B)) {
+ hns3_checksum_complete(ring, skb, l234info);
+ return;
+ }
+
/* check if hardware has done checksum */
if (!(bd_base_info & BIT(HNS3_RXD_L3L4P_B)))
return;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 8d33652..40681a0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -82,6 +82,12 @@ enum hns3_nic_state {
#define HNS3_RXD_STRP_TAGP_S 13
#define HNS3_RXD_STRP_TAGP_M (0x3 << HNS3_RXD_STRP_TAGP_S)
+#define HNS3_RXD_L2_CSUM_B 15
+#define HNS3_RXD_L2_CSUM_L_S 4
+#define HNS3_RXD_L2_CSUM_L_M (0xff << HNS3_RXD_L2_CSUM_L_S)
+#define HNS3_RXD_L2_CSUM_H_S 24
+#define HNS3_RXD_L2_CSUM_H_M (0xff << HNS3_RXD_L2_CSUM_H_S)
+
#define HNS3_RXD_L2E_B 16
#define HNS3_RXD_L3E_B 17
#define HNS3_RXD_L4E_B 18
@@ -371,6 +377,7 @@ struct ring_stats {
u64 err_bd_num;
u64 l2_err;
u64 l3l4_csum_err;
+ u64 csum_complete;
u64 rx_multicast;
u64 non_reuse_pg;
};
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index c30d5d3..3cca3c1 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -55,6 +55,7 @@ static const struct hns3_stats hns3_rxq_stats[] = {
HNS3_TQP_STAT("err_bd_num", err_bd_num),
HNS3_TQP_STAT("l2_err", l2_err),
HNS3_TQP_STAT("l3l4_csum_err", l3l4_csum_err),
+ HNS3_TQP_STAT("csum_complete", csum_complete),
HNS3_TQP_STAT("multicast", rx_multicast),
HNS3_TQP_STAT("non_reuse_pg", non_reuse_pg),
};
--
2.7.4
[PATCH V2 net-next 0/7] net: hns3: updates for -next
This series includes some updates for the HNS3 ethernet driver. #1~#6: add some updates related to the checksum offload. #7: add support for multiple TCs' MAC pauce mode. change log: V2: fixes some sparse errors in #1 & #5. previous version: V1: https://patchwork.kernel.org/project/netdevbpf/cover/1606466842-57749-1-git-send-email-tanhuazh...@huawei.com/ Huazhong Tan (6): net: hns3: add support for RX completion checksum net: hns3: add support for TX hardware checksum offload net: hns3: remove unsupported NETIF_F_GSO_UDP_TUNNEL_CSUM net: hns3: add udp tunnel checksum segmentation support net: hns3: add more info to hns3_dbg_bd_info() net: hns3: add a check for devcie's verion in hns3_tunnel_csum_bug() Yonglong Liu (1): net: hns3: keep MAC pause mode when multiple TCs are enabled drivers/net/ethernet/hisilicon/hns3/hnae3.h| 7 +- drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 62 -- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 131 - drivers/net/ethernet/hisilicon/hns3/hns3_enet.h| 21 +++- drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 1 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 4 + .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 3 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 23 +++- .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 4 + .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 3 +- 10 files changed, 207 insertions(+), 52 deletions(-) -- 2.7.4
[PATCH V2 net-next 6/7] net: hns3: add a check for devcie's verion in hns3_tunnel_csum_bug()
For the device whose version is above V3(include V3), the hardware
can do checksum offload for the non-tunnel udp packet, who has
a dest port as the IANA assigned. So add a check for devcie's verion
in hns3_tunnel_csum_bug().
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 3ad7f98..1798c0a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -828,8 +828,16 @@ static int hns3_get_l4_protocol(struct sk_buff *skb, u8
*ol4_proto,
*/
static bool hns3_tunnel_csum_bug(struct sk_buff *skb)
{
+ struct hns3_nic_priv *priv = netdev_priv(skb->dev);
+ struct hnae3_ae_dev *ae_dev = pci_get_drvdata(priv->ae_handle->pdev);
union l4_hdr_info l4;
+ /* device version above V3(include V3), the hardware can
+* do this checksum offload.
+*/
+ if (ae_dev->dev_version >= HNAE3_DEVICE_VERSION_V3)
+ return false;
+
l4.hdr = skb_transport_header(skb);
if (!(!skb->encapsulation &&
--
2.7.4
[PATCH v13 0/4] userspace MHI client interface driver
This patch series adds support for UCI driver. UCI driver enables userspace clients to communicate to external MHI devices like modem and WLAN. UCI driver probe creates standard character device file nodes for userspace clients to perform open, read, write, poll and release file operations. These file operations call MHI core layer APIs to perform data transfer using MHI bus to communicate with MHI device. Patch is tested using arm64 based platform. V13: - Removed LOOPBACK channel from mhi_device_id table from this patch series. Pushing a new patch series to add support for LOOPBACK channel and the user space test application. Also removed the description from kernel documentation. - Added QMI channel to mhi_device_id table. QMI channel has existing libqmi support from user space. - Updated kernel Documentation for QMI channel and provided external reference for libqmi. - Updated device file node name by appending mhi device name only, which already includes mhi controller device name. V12: - Added loopback test driver under selftest/drivers/mhi. Updated kernel documentation for the usage of the loopback test application. - Addressed review comments for renaming variable names, updated inline comments and removed two redundant dev_dbg. V11: - Fixed review comments for UCI documentation by expanding TLAs and rewording some sentences. V10: - Replaced mutex_lock with mutex_lock_interruptible in read() and write() file ops call back. V9: - Renamed dl_lock to dl_pending _lock and pending list to dl_pending for clarity. - Used read lock to protect cur_buf. - Change transfer status check logic and only consider 0 and -EOVERFLOW as only success. - Added __int to module init function. - Print channel name instead of minor number upon successful probe. V8: - Fixed kernel test robot compilation error by changing %lu to %zu for size_t. - Replaced uci with UCI in Kconfig, commit text, and comments in driver code. - Fixed minor style related comments. V7: - Decoupled uci device and uci channel objects. uci device is associated with device file node. uci channel is associated with MHI channels. uci device refers to uci channel to perform MHI channel operations for device file operations like read() and write(). uci device increments its reference count for every open(). uci device calls mhi_uci_dev_start_chan() to start the MHI channel. uci channel object is tracking number of times MHI channel is referred. This allows to keep the MHI channel in start state until last release() is called. After that uci channel reference count goes to 0 and uci channel clean up is performed which stops the MHI channel. After the last call to release() if driver is removed uci reference count becomes 0 and uci object is cleaned up. - Use separate uci channel read and write lock to fine grain locking between reader and writer. - Use uci device lock to synchronize open, release and driver remove. - Optimize for downlink only or uplink only UCI device. V6: - Moved uci.c to mhi directory. - Updated Kconfig to add module information. - Updated Makefile to rename uci object file name as mhi_uci - Removed kref for open count V5: - Removed mhi_uci_drv structure. - Used idr instead of creating global list of uci devices. - Used kref instead of local ref counting for uci device and open count. - Removed unlikely macro. V4: - Fix locking to protect proper struct members. - Updated documentation describing uci client driver use cases. - Fixed uci ref counting in mhi_uci_open for error case. - Addressed style related review comments. V3: Added documentation for MHI UCI driver. V2: - Added mutex lock to prevent multiple readers to access same - mhi buffer which can result into use after free. Hemant Kumar (4): bus: mhi: core: Add helper API to return number of free TREs bus: mhi: core: Move MHI_MAX_MTU to external header file docs: Add documentation for userspace client interface bus: mhi: Add userspace client interface driver Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 94 ++ drivers/bus/mhi/Kconfig | 13 + drivers/bus/mhi/Makefile| 3 + drivers/bus/mhi/core/internal.h | 1 - drivers/bus/mhi/core/main.c | 12 + drivers/bus/mhi/uci.c | 665 include/linux/mhi.h | 12 + 8 files changed, 800 insertions(+), 1 deletion(-) create mode 100644 Documentation/mhi/uci.rst create mode 100644 drivers/bus/mhi/uci.c -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2 0/5] x86/platform/uv: Move UV procfs leaves to sysfs
Duplicate the current UV procfs leaves to the uv_sysfs driver so they show up under /sys/firmware/sgi_uv. Show a 'deprecated' warning message if any of the old /proc/sgi_uv leaves are used. These patches depend on the prior v3 patchset sent by Justin Ernst x86/platform/uv: Remove existing /sys/firmware/sgi_uv/ interface x86/platform/uv: Add and export uv_bios_* functions x86/platform/uv: Add new uv_sysfs platform driver x86/platform/uv: Update ABI documentation of /sys/firmware/sgi_uv/ x86/platform/uv: Update MAINTAINERS for uv_sysfs driver v2: Updated to apply to v3 of dependency patch set listed above. Mike Travis (5): x86/platform/uv: Add kernel interfaces for obtaining system info. x86/platform/uv: Add sysfs leaves to replace those in procfs x86/platform/uv: Add sysfs hubless leaves x86/platform/uv: Add deprecated messages to /proc info leaves x86/platform/uv: Update sysfs document file .../ABI/testing/sysfs-firmware-sgi_uv | 16 + arch/x86/include/asm/uv/bios.h| 2 + arch/x86/kernel/apic/x2apic_uv_x.c| 26 ++- drivers/platform/x86/uv_sysfs.c | 70 ++- 4 files changed, 111 insertions(+), 3 deletions(-) -- 2.21.0
[PATCH v2 2/5] x86/platform/uv: Add sysfs leaves to replace those in procfs
Add uv_sysfs leaves to display the info.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
drivers/platform/x86/uv_sysfs.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/platform/x86/uv_sysfs.c b/drivers/platform/x86/uv_sysfs.c
index 54c342579f1c..115754cdcd89 100644
--- a/drivers/platform/x86/uv_sysfs.c
+++ b/drivers/platform/x86/uv_sysfs.c
@@ -735,17 +735,35 @@ static ssize_t uv_type_show(struct kobject *kobj,
return scnprintf(buf, PAGE_SIZE, "%s\n", uv_type_string());
}
+static ssize_t uv_archtype_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return uv_get_archtype(buf, PAGE_SIZE);
+}
+
+static ssize_t uv_hub_type_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return scnprintf(buf, PAGE_SIZE, "0x%x\n", uv_hub_type());
+}
+
static struct kobj_attribute partition_id_attr =
__ATTR(partition_id, 0444, partition_id_show, NULL);
static struct kobj_attribute coherence_id_attr =
__ATTR(coherence_id, 0444, coherence_id_show, NULL);
static struct kobj_attribute uv_type_attr =
__ATTR(uv_type, 0444, uv_type_show, NULL);
+static struct kobj_attribute uv_archtype_attr =
+ __ATTR(archtype, 0444, uv_archtype_show, NULL);
+static struct kobj_attribute uv_hub_type_attr =
+ __ATTR(hub_type, 0444, uv_hub_type_show, NULL);
static struct attribute *base_attrs[] = {
&partition_id_attr.attr,
&coherence_id_attr.attr,
&uv_type_attr.attr,
+ &uv_archtype_attr.attr,
+ &uv_hub_type_attr.attr,
NULL,
};
--
2.21.0
[PATCH v2 4/5] x86/platform/uv: Add deprecated messages to /proc info leaves
Add "deprecated" message to any access to old /proc/sgi_uv/* leaves.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
arch/x86/kernel/apic/x2apic_uv_x.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 48746031b39a..4248579825fb 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -1615,21 +1615,33 @@ static void check_efi_reboot(void)
reboot_type = BOOT_ACPI;
}
-/* Setup user proc fs files */
+/*
+ * User proc fs file handling now deprecated.
+ * Recommend using /sys/firmware/sgi_uv/... instead.
+ */
static int __maybe_unused proc_hubbed_show(struct seq_file *file, void *data)
{
+ pr_notice_once(
+ "%s: using deprecated /proc/sgi_uv/hubbed, use
/sys/firmware/sgi_uv/hub_type\n",
+ current->comm);
seq_printf(file, "0x%x\n", uv_hubbed_system);
return 0;
}
static int __maybe_unused proc_hubless_show(struct seq_file *file, void *data)
{
+ pr_notice_once(
+ "%s: using deprecated /proc/sgi_uv/hubless, use
/sys/firmware/sgi_uv/hubless\n",
+ current->comm);
seq_printf(file, "0x%x\n", uv_hubless_system);
return 0;
}
static int __maybe_unused proc_archtype_show(struct seq_file *file, void *data)
{
+ pr_notice_once(
+ "%s: using deprecated /proc/sgi_uv/archtype, use
/sys/firmware/sgi_uv/archtype\n",
+ current->comm);
seq_printf(file, "%s/%s\n", uv_archtype, oem_table_id);
return 0;
}
--
2.21.0
[PATCH v2 1/5] x86/platform/uv: Add kernel interfaces for obtaining system info.
Add kernel interfaces used to obtain info for the uv_sysfs driver
to display.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
arch/x86/include/asm/uv/bios.h | 2 ++
arch/x86/kernel/apic/x2apic_uv_x.c | 12
2 files changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/uv/bios.h b/arch/x86/include/asm/uv/bios.h
index 01ba080887b3..1b6455f881f9 100644
--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -200,6 +200,8 @@ extern long sn_partition_id;
extern long sn_coherency_id;
extern long sn_region_size;
extern long system_serial_number;
+extern ssize_t uv_get_archtype(char *buf, int len);
+extern int uv_get_hubless_system(void);
extern struct kobject *sgi_uv_kobj;/* /sys/firmware/sgi_uv */
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 1b98f8c12b96..48746031b39a 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -502,6 +502,18 @@ enum uv_system_type get_uv_system_type(void)
return uv_system_type;
}
+int uv_get_hubless_system(void)
+{
+ return uv_hubless_system;
+}
+EXPORT_SYMBOL_GPL(uv_get_hubless_system);
+
+ssize_t uv_get_archtype(char *buf, int len)
+{
+ return scnprintf(buf, len, "%s/%s", uv_archtype, oem_table_id);
+}
+EXPORT_SYMBOL_GPL(uv_get_archtype);
+
int is_uv_system(void)
{
return uv_system_type != UV_NONE;
--
2.21.0
Re: memory leak in prepare_creds
syzbot has found a reproducer for the following issue on: HEAD commit:99c710c4 Merge tag 'platform-drivers-x86-v5.10-2' of git:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12a77ddd50 kernel config: https://syzkaller.appspot.com/x/.config?x=c7a27a77f20fbc95 dashboard link: https://syzkaller.appspot.com/bug?extid=71c4697e27c99fddcf17 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12d6161d50 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16f15e6550 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+71c4697e27c99fddc...@syzkaller.appspotmail.com BUG: memory leak unreferenced object 0x888101401300 (size 168): comm "syz-executor355", pid 8461, jiffies 4294953658 (age 32.400s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [] prepare_creds+0x25/0x390 kernel/cred.c:258 [<1821b99d>] copy_creds+0x3a/0x230 kernel/cred.c:358 [<22c32914>] copy_process+0x661/0x24d0 kernel/fork.c:1971 [ ] kernel_clone+0xf3/0x670 kernel/fork.c:2456 [ ] __do_sys_clone+0x76/0xa0 kernel/fork.c:2573 [<8280baad>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [<685d8cf0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x88810b0a6f20 (size 32): comm "syz-executor355", pid 8461, jiffies 4294953658 (age 32.400s) hex dump (first 32 bytes): b0 6e 93 00 81 88 ff ff 00 00 00 00 00 00 00 00 .n.. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 backtrace: [<7d750ba1>] kmalloc include/linux/slab.h:557 [inline] [<7d750ba1>] kzalloc include/linux/slab.h:664 [inline] [<7d750ba1>] lsm_cred_alloc security/security.c:533 [inline] [<7d750ba1>] security_prepare_creds+0xa5/0xd0 security/security.c:1632 [ ] prepare_creds+0x277/0x390 kernel/cred.c:285 [<1821b99d>] copy_creds+0x3a/0x230 kernel/cred.c:358 [<22c32914>] copy_process+0x661/0x24d0 kernel/fork.c:1971 [ ] kernel_clone+0xf3/0x670 kernel/fork.c:2456 [ ] __do_sys_clone+0x76/0xa0 kernel/fork.c:2573 [<8280baad>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [<685d8cf0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 BUG: memory leak unreferenced object 0x888101ea2200 (size 256): comm "syz-executor355", pid 8470, jiffies 4294953658 (age 32.400s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 59 03 01 81 88 ff ff 80 87 a8 10 81 88 ff ff Y.. backtrace: [<2e0a7c5f>] kmem_cache_zalloc include/linux/slab.h:654 [inline] [<2e0a7c5f>] __alloc_file+0x1f/0x130 fs/file_table.c:101 [<1a55b73a>] alloc_empty_file+0x69/0x120 fs/file_table.c:151 [ ] alloc_file+0x33/0x1b0 fs/file_table.c:193 [<6e1465bb>] alloc_file_pseudo+0xb2/0x140 fs/file_table.c:233 [<7118092a>] anon_inode_getfile fs/anon_inodes.c:91 [inline] [<7118092a>] anon_inode_getfile+0xaa/0x120 fs/anon_inodes.c:74 [<2ae99012>] io_uring_get_fd fs/io_uring.c:9198 [inline] [<2ae99012>] io_uring_create fs/io_uring.c:9377 [inline] [<2ae99012>] io_uring_setup+0x1125/0x1630 fs/io_uring.c:9411 [<8280baad>] do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 [<685d8cf0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[PATCH v2 3/5] x86/platform/uv: Add sysfs hubless leaves
Add uv_sysfs hubless leaves for UV hubless systems.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
---
drivers/platform/x86/uv_sysfs.c | 52 +++--
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/uv_sysfs.c b/drivers/platform/x86/uv_sysfs.c
index 115754cdcd89..913559797ba4 100644
--- a/drivers/platform/x86/uv_sysfs.c
+++ b/drivers/platform/x86/uv_sysfs.c
@@ -44,6 +44,8 @@ static const char *uv_type_string(void)
return "5.0";
else if (is_uv2_hub())
return "3.0";
+ else if (uv_get_hubless_system())
+ return "0.1";
else
return "unknown";
}
@@ -747,6 +749,12 @@ static ssize_t uv_hub_type_show(struct kobject *kobj,
return scnprintf(buf, PAGE_SIZE, "0x%x\n", uv_hub_type());
}
+static ssize_t uv_hubless_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return scnprintf(buf, PAGE_SIZE, "0x%x\n", uv_get_hubless_system());
+}
+
static struct kobj_attribute partition_id_attr =
__ATTR(partition_id, 0444, partition_id_show, NULL);
static struct kobj_attribute coherence_id_attr =
@@ -757,6 +765,8 @@ static struct kobj_attribute uv_archtype_attr =
__ATTR(archtype, 0444, uv_archtype_show, NULL);
static struct kobj_attribute uv_hub_type_attr =
__ATTR(hub_type, 0444, uv_hub_type_show, NULL);
+static struct kobj_attribute uv_hubless_attr =
+ __ATTR(hubless, 0444, uv_hubless_show, NULL);
static struct attribute *base_attrs[] = {
&partition_id_attr.attr,
@@ -804,11 +814,36 @@ static int initial_bios_setup(void)
return 0;
}
+static struct attribute *hubless_base_attrs[] = {
+ &partition_id_attr.attr,
+ &uv_type_attr.attr,
+ &uv_archtype_attr.attr,
+ &uv_hubless_attr.attr,
+ NULL,
+};
+
+static struct attribute_group hubless_base_attr_group = {
+ .attrs = hubless_base_attrs
+};
+
+
+static int __init uv_sysfs_hubless_init(void)
+{
+ int ret;
+
+ ret = sysfs_create_group(sgi_uv_kobj, &hubless_base_attr_group);
+ if (ret) {
+ pr_warn("sysfs_create_group hubless_base_attr_group failed\n");
+ kobject_put(sgi_uv_kobj);
+ }
+ return ret;
+}
+
static int __init uv_sysfs_init(void)
{
int ret = 0;
- if (!is_uv_system())
+ if (!is_uv_system() && !uv_get_hubless_system())
return -ENODEV;
num_cnodes = uv_num_possible_blades();
@@ -819,6 +854,10 @@ static int __init uv_sysfs_init(void)
pr_warn("kobject_create_and_add sgi_uv failed\n");
return -EINVAL;
}
+
+ if (uv_get_hubless_system())
+ return uv_sysfs_hubless_init();
+
ret = sysfs_create_group(sgi_uv_kobj, &base_attr_group);
if (ret) {
pr_warn("sysfs_create_group base_attr_group failed\n");
@@ -856,10 +895,19 @@ static int __init uv_sysfs_init(void)
return ret;
}
+static void __exit uv_sysfs_hubless_exit(void)
+{
+ sysfs_remove_group(sgi_uv_kobj, &hubless_base_attr_group);
+ kobject_put(sgi_uv_kobj);
+}
+
static void __exit uv_sysfs_exit(void)
{
- if (!is_uv_system())
+ if (!is_uv_system()) {
+ if (uv_get_hubless_system())
+ uv_sysfs_hubless_exit();
return;
+ }
pci_topology_exit();
uv_ports_exit();
--
2.21.0
[PATCH] arm64: dts: qcom: c630: Define eDP bridge and panel
The Lenovo Yoga C630 drives the Boe NV133FHM-N61 eDP display from DSI
using a TI SN65DSI86 bridge chip on I2C 10. Define the bridge and eDP
panel and enable the display blocks.
Signed-off-by: Bjorn Andersson
---
.../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 100 ++
1 file changed, 100 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
index f956dbf664c1..bdd5d92ee6c3 100644
--- a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
+++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
@@ -44,6 +44,26 @@ mode {
linux,code = ;
};
};
+
+ panel {
+ compatible = "boe,nv133fhm-n61";
+ no-hpd;
+
+ ports {
+ port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&sn65dsi86_out>;
+ };
+ };
+ };
+ };
+
+ sn65dsi86_refclk: sn65dsi86-refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+
+ clock-frequency = <1920>;
+ };
};
&adsp_pas {
@@ -260,6 +280,25 @@ &cdsp_pas {
status = "okay";
};
+&dsi0 {
+ status = "okay";
+ vdda-supply = <&vreg_l26a_1p2>;
+
+ ports {
+ port@1 {
+ endpoint {
+ remote-endpoint = <&sn65dsi86_in_a>;
+ data-lanes = <0 1 2 3>;
+ };
+ };
+ };
+};
+
+&dsi0_phy {
+ status = "okay";
+ vdds-supply = <&vreg_l1a_0p875>;
+};
+
&gcc {
protected-clocks = ,
,
@@ -328,6 +367,45 @@ tsc1: hid@10 {
};
};
+&i2c10 {
+ status = "okay";
+ clock-frequency = <40>;
+
+ sn65dsi86: bridge@2c {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sn65dsi86_pin_active>;
+
+ enable-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+
+ vpll-supply = <&vreg_l14a_1p88>;
+ vccio-supply = <&vreg_l14a_1p88>;
+
+ clocks = <&sn65dsi86_refclk>;
+ clock-names = "refclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ sn65dsi86_in_a: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ sn65dsi86_out: endpoint {
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
+};
+
&i2c11 {
status = "okay";
clock-frequency = <40>;
@@ -344,10 +422,26 @@ ecsh: hid@5c {
};
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_mdp {
+ status = "okay";
+};
+
&mss_pil {
firmware-name = "qcom/LENOVO/81JL/qcdsp1v2850.mbn",
"qcom/LENOVO/81JL/qcdsp2850.mbn";
};
+&qup_i2c10_default {
+ pinconf {
+ pins = "gpio55", "gpio56";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
&qup_i2c12_default {
drive-strength = <2>;
bias-disable;
@@ -454,6 +548,12 @@ codec {
&tlmm {
gpio-reserved-ranges = <0 4>, <81 4>;
+ sn65dsi86_pin_active: sn65dsi86-enable {
+ pins = "gpio96";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
i2c3_hid_active: i2c2-hid-active {
pins = "gpio37";
function = "gpio";
--
2.29.2
[PATCH] x86: fix some spelling mistakes in the comments
Fix some spelling mistakes in the comments: reqeust ==> request Runing ==> Running interupts ==> interrupts requsted ==> requested Signed-off-by: laiyuanyuan --- arch/x86/kernel/e820.c | 2 +- arch/x86/kernel/hpet.c | 2 +- arch/x86/kernel/smp.c | 2 +- arch/x86/kernel/traps.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index 22aad412f965..f74cb7da9557 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -793,7 +793,7 @@ core_initcall(e820__register_nvs_regions); #endif /* - * Allocate the requested number of bytes with the requsted alignment + * Allocate the requested number of bytes with the requested alignment * and return (the physical address) to the caller. Also register this * range in the 'kexec' E820 table as a reserved range. * diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 7a50f0b62a70..71cb347ddd24 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -596,7 +596,7 @@ static void __init hpet_select_clockevents(void) hpet_base.nr_clockevents = 0; - /* No point if MSI is disabled or CPU has an Always Runing APIC Timer */ + /* No point if MSI is disabled or CPU has an Always Running APIC Timer */ if (hpet_msi_disable || boot_cpu_has(X86_FEATURE_ARAT)) return; diff --git a/arch/x86/kernel/smp.c b/arch/x86/kernel/smp.c index eff4ce3b10da..ec640fec787c 100644 --- a/arch/x86/kernel/smp.c +++ b/arch/x86/kernel/smp.c @@ -204,7 +204,7 @@ static void native_stop_other_cpus(int wait) } /* * Don't wait longer than 10 ms if the caller didn't -* reqeust it. If wait is true, the machine hangs here if +* request it. If wait is true, the machine hangs here if * one or more CPUs do not reach shutdown state. */ timeout = USEC_PER_MSEC * 10; diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c index e19df6cde35d..5f999b4154e0 100644 --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -390,7 +390,7 @@ DEFINE_IDTENTRY_DF(exc_double_fault) /* * Adjust our frame so that we return straight to the #GP * vector with the expected RSP value. This is safe because -* we won't enable interupts or schedule before we invoke +* we won't enable interrupts or schedule before we invoke * general_protection, so nothing will clobber the stack * frame we just set up. * -- 2.12.3
[PATCH v13 4/4] bus: mhi: Add userspace client interface driver
This MHI client driver allows userspace clients to transfer
raw data between MHI device and host using standard file operations.
Driver instantiates UCI device object which is associated to device
file node. UCI device object instantiates UCI channel object when device
file node is opened. UCI channel object is used to manage MHI channels
by calling MHI core APIs for read and write operations. MHI channels
are started as part of device open(). MHI channels remain in start
state until last release() is called on UCI device file node. Device
file node is created with format
/dev/mhi_
Currently it supports QMI channel.
Signed-off-by: Hemant Kumar
---
drivers/bus/mhi/Kconfig | 13 +
drivers/bus/mhi/Makefile | 3 +
drivers/bus/mhi/uci.c| 665 +++
3 files changed, 681 insertions(+)
create mode 100644 drivers/bus/mhi/uci.c
diff --git a/drivers/bus/mhi/Kconfig b/drivers/bus/mhi/Kconfig
index da5cd0c..5194e8e 100644
--- a/drivers/bus/mhi/Kconfig
+++ b/drivers/bus/mhi/Kconfig
@@ -29,3 +29,16 @@ config MHI_BUS_PCI_GENERIC
This driver provides MHI PCI controller driver for devices such as
Qualcomm SDX55 based PCIe modems.
+config MHI_UCI
+ tristate "MHI UCI"
+ depends on MHI_BUS
+ help
+ MHI based Userspace Client Interface (UCI) driver is used for
+ transferring raw data between host and device using standard file
+ operations from userspace. Open, read, write, poll and close
+ operations are supported by this driver. Please check
+ mhi_uci_match_table for all supported channels that are exposed to
+ userspace.
+
+ To compile this driver as a module, choose M here: the module will be
+ called mhi_uci.
diff --git a/drivers/bus/mhi/Makefile b/drivers/bus/mhi/Makefile
index 0a2d778..69f2111 100644
--- a/drivers/bus/mhi/Makefile
+++ b/drivers/bus/mhi/Makefile
@@ -4,3 +4,6 @@ obj-y += core/
obj-$(CONFIG_MHI_BUS_PCI_GENERIC) += mhi_pci_generic.o
mhi_pci_generic-y += pci_generic.o
+# MHI client
+mhi_uci-y := uci.o
+obj-$(CONFIG_MHI_UCI) += mhi_uci.o
diff --git a/drivers/bus/mhi/uci.c b/drivers/bus/mhi/uci.c
new file mode 100644
index 000..fb9c183
--- /dev/null
+++ b/drivers/bus/mhi/uci.c
@@ -0,0 +1,665 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Copyright (c) 2018-2020, The Linux Foundation. All rights reserved.*/
+
+#include
+#include
+#include
+#include
+#include
+
+#define MHI_DEVICE_NAME "mhi"
+#define MHI_UCI_DRIVER_NAME "mhi_uci"
+#define MHI_MAX_UCI_MINORS 128
+
+static DEFINE_IDR(uci_idr);
+static DEFINE_MUTEX(uci_drv_mutex);
+static struct class *uci_dev_class;
+static int uci_dev_major;
+
+/**
+ * struct uci_chan - MHI channel for a UCI device
+ * @udev: associated UCI device object
+ * @ul_wq: wait queue for writer
+ * @write_lock: mutex write lock for ul channel
+ * @dl_wq: wait queue for reader
+ * @read_lock: mutex read lock for dl channel
+ * @dl_pending_lock: spin lock for dl_pending list
+ * @dl_pending: list of dl buffers userspace is waiting to read
+ * @cur_buf: current buffer userspace is reading
+ * @dl_size: size of the current dl buffer userspace is reading
+ * @ref_count: uci_chan reference count
+ */
+struct uci_chan {
+ struct uci_dev *udev;
+ wait_queue_head_t ul_wq;
+
+ /* ul channel lock to synchronize multiple writes */
+ struct mutex write_lock;
+
+ wait_queue_head_t dl_wq;
+
+ /* dl channel lock to synchronize multiple reads */
+ struct mutex read_lock;
+
+ /*
+* protects pending list in bh context, channel release, read and
+* poll
+*/
+ spinlock_t dl_pending_lock;
+
+ struct list_head dl_pending;
+ struct uci_buf *cur_buf;
+ size_t dl_size;
+ struct kref ref_count;
+};
+
+/**
+ * struct uci_buf - UCI buffer
+ * @data: data buffer
+ * @len: length of data buffer
+ * @node: list node of the UCI buffer
+ */
+struct uci_buf {
+ void *data;
+ size_t len;
+ struct list_head node;
+};
+
+/**
+ * struct uci_dev - MHI UCI device
+ * @minor: UCI device node minor number
+ * @mhi_dev: associated mhi device object
+ * @uchan: UCI uplink and downlink channel object
+ * @mtu: max TRE buffer length
+ * @enabled: Flag to track the state of the UCI device
+ * @lock: mutex lock to manage uchan object
+ * @ref_count: uci_dev reference count
+ */
+struct uci_dev {
+ unsigned int minor;
+ struct mhi_device *mhi_dev;
+ struct uci_chan *uchan;
+ size_t mtu;
+ bool enabled;
+
+ /* synchronize open, release and driver remove */
+ struct mutex lock;
+ struct kref ref_count;
+};
+
+static void mhi_uci_dev_chan_release(struct kref *ref)
+{
+ struct uci_buf *buf_itr, *tmp;
+ struct uci_chan *uchan =
+ container_of(ref, struct uci_chan, ref_count);
+
+ if (uchan->udev->enabled)
+ mhi_unprepare_from_transfer(uchan->udev->mhi_dev);
+
[PATCH v13 3/4] docs: Add documentation for userspace client interface
MHI userspace client driver is creating device file node for user application to perform file operations. File operations are handled by MHI core driver. Currently QMI MHI channel is supported by this driver. Signed-off-by: Hemant Kumar --- Documentation/mhi/index.rst | 1 + Documentation/mhi/uci.rst | 94 + 2 files changed, 95 insertions(+) create mode 100644 Documentation/mhi/uci.rst diff --git a/Documentation/mhi/index.rst b/Documentation/mhi/index.rst index 1d8dec3..c75a371 100644 --- a/Documentation/mhi/index.rst +++ b/Documentation/mhi/index.rst @@ -9,6 +9,7 @@ MHI mhi topology + uci .. only:: subproject and html diff --git a/Documentation/mhi/uci.rst b/Documentation/mhi/uci.rst new file mode 100644 index 000..ad22650 --- /dev/null +++ b/Documentation/mhi/uci.rst @@ -0,0 +1,94 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +Userspace Client Interface (UCI) += + +UCI driver enables userspace clients to communicate to external MHI devices +like modem and WLAN. UCI driver probe creates standard character device file +nodes for userspace clients to perform open, read, write, poll and release file +operations. UCI device object represents UCI device file node which gets +instantiated as part of MHI UCI driver probe. UCI channel object represents +MHI uplink or downlink channel. + +Operations +== + +open + + +Instantiates UCI channel object and starts MHI channels to move it to running +state. Inbound buffers are queued to downlink channel transfer ring. Every +subsequent open() increments UCI device reference count as well as UCI channel +reference count. + +read + + +When data transfer is completed on downlink channel, transfer ring element +buffer is copied to pending list. Reader is unblocked and data is copied to +userspace buffer. Transfer ring element buffer is queued back to downlink +channel transfer ring. + +write +- + +Write buffer is queued to uplink channel transfer ring if ring is not full. Upon +uplink transfer completion buffer is freed. + +poll + + +Returns EPOLLIN | EPOLLRDNORM mask if pending list has buffers to be read by +userspace. Returns EPOLLOUT | EPOLLWRNORM mask if MHI uplink channel transfer +ring is not empty. Returns EPOLLERR when UCI driver is removed. + +release +--- + +Decrements UCI device reference count and UCI channel reference count upon last +release(). UCI channel clean up is performed. MHI channel moves to disable +state and inbound buffers are freed. + +Usage += + +Device file node is created with format:- + +/dev/mhi_ + +mhi_device_name includes mhi controller name and the name of the MHI channel +being used by MHI client in userspace to send or receive data using MHI +protocol. + +There is a separate character device file node created for each channel +specified in MHI device id table. MHI channels are statically defined by MHI +specification. The list of supported channels is in the channel list variable +of mhi_device_id table in UCI driver. + +Qualcomm MSM Interface(QMI) Channel +--- + +Qualcomm MSM Interface(QMI) is a modem control messaging protocol used to +communicate between software components in the modem and other peripheral +subsystems. QMI communication is of request/response type or an unsolicited +event type. libqmi is userspace MHI client which communicates to a QMI service +using UCI device. It sends a QMI request to a QMI service using MHI channel 14 +or 16. QMI response is received using MHI channel 15 or 17 respectively. libqmi +is a glib-based library for talking to WWAN modems and devices which speaks QMI +protocol. For more information about libqmi please refer +https://www.freedesktop.org/wiki/Software/libqmi/ + +Usage Example +~ + +QMI command to retrieve device mode +$ sudo qmicli -d /dev/mhi_\:02\:00.0_QMI --dms-get-model +[/dev/mhi_:02:00.0_QMI] Device model retrieved: +Model: 'FN980m' + +Other Use Cases +--- + +Getting MHI device specific diagnostics information to userspace MHI diagnostic +client using DIAG channel 4 (Host to device) and 5 (Device to Host). -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] locks: remove trailing semicolon in macro definition
On Fri, Nov 27, 2020 at 11:07:07AM -0800, t...@redhat.com wrote:
> +++ b/fs/fcntl.c
> @@ -526,7 +526,7 @@ SYSCALL_DEFINE3(fcntl64, unsigned int, fd, unsigned int,
> cmd,
> (dst)->l_whence = (src)->l_whence; \
> (dst)->l_start = (src)->l_start;\
> (dst)->l_len = (src)->l_len;\
> - (dst)->l_pid = (src)->l_pid;
> + (dst)->l_pid = (src)->l_pid
This should be wrapped in a do { } while (0).
Look, this warning is clearly great at finding smelly code, but the
fixes being generated to shut up the warning are low quality.
Re: [RFC PATCH v3 0/5] sched: support schedstats for RT sched class
On Sat, Nov 28, 2020 at 12:12 AM Yafang Shao wrote:
>
> We want to measure the latency of RT tasks in our production
> environment with schedstats facility, but currently schedstats is only
> supported for fair sched class. This patch enable it for RT sched class
> as well.
>
> - Structure
>
> Before we make schedstats available for RT sched class, we should make
> struct sched_statistics independent of fair sched class first.
>
>
> The struct sched_statistics is the schedular statistics of a task_struct
> or a task_group. So we can move it into struct task_struct and
> struct task_group to achieve the goal.
>
> Below is the detailed explaination of the change in the structs.
>
> The struct before this patch:
>
> struct task_struct {|-> struct sched_entity {
> ... | ...
> struct sched_entity *se; ---| struct sched_statistics statistics;
> struct sched_rt_entity *rt; ...
> ... ...
> }; };
>
> struct task_group { |--> se[0]->statistics : schedstats of CPU0
> ... |
> #ifdef CONFIG_FAIR_GROUP_SCHED |
> struct sched_entity **se; --|--> se[1]->statistics : schedstats of CPU1
> |
> #endif |
> |--> se[N]->statistics : schedstats of CPUn
>
> #ifdef CONFIG_FAIR_GROUP_SCHED
> struct sched_rt_entity **rt_se; (N/A)
> #endif
> ...
> };
>
> The '**se' in task_group is allocated in the fair sched class, which is
> hard to be reused by other sched class.
>
> The struct after this patch:
> struct task_struct {
> ...
> struct sched_statistics statistics;
> ...
> struct sched_entity *se;
> struct sched_rt_entity *rt;
> ...
> };
>
> struct task_group {|---> stats[0] : of CPU0
> ...|
> struct sched_statistics **stats; --|---> stats[1] : of CPU1
> ...|
>|---> stats[n] : of CPUn
> #ifdef CONFIG_FAIR_GROUP_SCHED
> struct sched_entity **se;
> #endif
> #ifdef CONFIG_RT_GROUP_SCHED
> struct sched_rt_entity **rt_se;
> #endif
> ...
> };
>
> After the patch it is clearly that both of se or rt_se can easily get the
> sched_statistics by a task_struct or a task_group.
>
> - Function Interface
>
> The original prototype of the schedstats helpers are
>
> update_stats_wait_*(struct cfs_rq *cfs_rq, struct sched_entity *se)
>
> The cfs_rq in these helpers is used to get the rq_clock, and the se is
> used to get the struct sched_statistics and the struct task_struct. In
> order to make these helpers available by all sched classes, we can pass
> the rq, sched_statistics and task_struct directly.
>
> Then the new helpers are
>
> update_stats_wait_*(struct rq *rq, struct task_struct *p,
> struct sched_statistics *stats)
>
> which are independent of fair sched class.
>
> To avoid vmlinux growing too large or introducing ovehead when
> !schedstat_enabled(), some new helpers after schedstat_enabled() are also
> introduced, Suggested by Mel. These helpers are in sched/stats.c,
>
> __update_stats_wait_*(struct rq *rq, struct task_struct *p,
> struct sched_statistics *stats)
>
> - Implementation
>
> After we make the struct sched_statistics and the helpers of it
> independent of fair sched class, we can easily use the schedstats
> facility for RT sched class.
>
> The schedstat usage in RT sched class is similar with fair sched class,
> for example,
> fairRT
> enqueue update_stats_enqueue_fair update_stats_enqueue_rt
> dequeue update_stats_dequeue_fair update_stats_dequeue_rt
> put_prev_task update_stats_wait_start update_stats_wait_start
> set_next_task update_stats_wait_end update_stats_wait_end
>
> - Usage
>
> The user can get the schedstats information in the same way in fair sched
> class. For example,
> fairRT
> task show /proc/[pid]/sched /proc/[pid]/sched
> group show cpu.stat in cgroup cpu.stat in cgroup
>
> The sched:sched_stat_{wait, sleep, iowait, blocked} tracepoints can
> be used to trace RT tasks as well. sched_stat_runtime can also be
> supported in the future if it is helpful.
>
> Yafang Shao (5):
> sched: don't include stats.h in sched.h
> sched, fair: use __schedstat_set() in set_next_entity()
> sched: make struct sched_statistics independent of fair sched class
> sched: make schedstats helpers independent of fair sched class
> sched, rt: support schedstats for RT sched class
>
> include/linux/sched.h| 3 +-
> kernel/sched/core.c | 25 +++--
> kernel/sched/deadline.c | 5 +-
> kernel/sched/debug.c | 82 +++
> kernel/sched/fair.c
Re: [PATCH 22/25] perf buildid-cache: Add support to add build ids from perf data
On Thu, Nov 26, 2020 at 02:57:06PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Nov 26, 2020 at 06:00:23PM +0100, Jiri Olsa escreveu: > > Adding support to specify perf data file as -a option file > > argument, > > > > If the file is detected to be perf data file, it is processed > > and all dso objects with sample hit are stored to the build > > id cache. > > Would be interesting if the steps to have that debuginfod server running > at that 192.168.122.174:8002 URL were spelled out here, for > completeness. right, will add that jirka > > - Arnaldo > > > $ DEBUGINFOD_URLS=http://192.168.122.174:8002 perf buildid-cache -a > > perf.data > > OK 5dcec522abf136fcfd3128f47e131f2365834dd7 > > /home/jolsa/.debug/.build-id/5d/cec522abf136fcfd3128f47e131f2365834dd7/elf > > OK 5784f813b727a50cfd3363234aef9fcbab685cc4 > > /lib/modules/5.10.0-rc2speed+/kernel/fs/xfs/xfs.ko > > > > By default we store only dso with hits, but it's possible to > > specify 'all' to store all dso objects, like: > > -a perf.data,all > > > > $ DEBUGINFOD_URLS=http://192.168.122.174:8002 perf buildid-cache -a > > perf.data,all > > OK 5dcec522abf136fcfd3128f47e131f2365834dd7 > > /home/jolsa/.debug/.build-id/5d/cec522abf136fcfd3128f47e131f2365834dd7/elf > > OK 6ce92dc7c31f12fe5b7775a2bb8b14a3546ce2cd > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/firmware/qemu_fw_cfg.ko > > OK bf3f6d32dccc159f841fc3658c241d0e74c61fbb > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/block/virtio_blk.ko > > OK e896b4329cf9f190f1a0fae933f425ff8f71b052 > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/char/virtio_console.ko > > OK 5bedc933cb59e053ecb472f327bd73c548364479 > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/input/serio/serio_raw.ko > > OK cecc506368a8b7a473a5f900d26f0d3d914a9c23 > > /lib/modules/5.10.0-rc2speed+/kernel/arch/x86/crypto/crc32c-intel.ko > > OK 91076fb3646d061a0a42cf7bddb339a665ee4f80 > > /lib/modules/5.10.0-rc2speed+/kernel/arch/x86/crypto/ghash-clmulni-intel.ko > > OK 4e2a304d788bb8e2e950bc82a5944e042afa0bf2 > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/media/cec/core/cec.ko > > OK 31ab0da5ad81e6803280177f507a95f3053d585e > > /lib/modules/5.10.0-rc2speed+/kernel/lib/libcrc32c.ko > > OK f6154bca47c149f48c942fcc3d653041dd285c65 > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/gpu/drm/ttm/ttm.ko > > OK 723f5852de81590d54b23b38c160d3618b41951b > > /lib/modules/5.10.0-rc2speed+/kernel/arch/x86/crypto/crct10dif-pclmul.ko > > OK 06b1eab7f141cbc3e5a5db47909c8ab5cb242e40 > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/gpu/drm/drm_ttm_helper.ko > > OK 38292b862cf3ff87489508fdb4895efa45780813 > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/gpu/drm/qxl/qxl.ko > > OK cdf51e58609bf2ce4837a7b195e0ccae0a930907 > > /lib/modules/5.10.0-rc2speed+/kernel/arch/x86/crypto/crc32-pclmul.ko > > OK 5ca8958388f6688452ecc2cb83d6031394c659ad > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/gpu/drm/drm.ko > > OK 236bc4e4f38bf3559007566cb32b3dcc1bc28d2d > > /lib/modules/5.10.0-rc2speed+/kernel/drivers/gpu/drm/drm_kms_helper.ko > > OK 5784f813b727a50cfd3363234aef9fcbab685cc4 > > /lib/modules/5.10.0-rc2speed+/kernel/fs/xfs/xfs.ko > > OK 66db2be3efaa43bb5a5c481986e9554e1885cc69 /usr/lib/systemd/systemd > > OK 7db607d9f2de89860d9639712da64c8bacd31e4b /usr/lib64/libm-2.30.so > > OK 55b5f9652e1d17c1dd58f62628d5063428e5db91 /usr/lib64/libudev.so.1.6.15 > > OK 63b97070bf097130713bb6c89cf7100b5f3c9b17 > > /usr/lib64/libunistring.so.2.1.0 > > ... > > > > Once perf data is specified, no other file can be specified in > > the option, otherwise it causes syntax error. > > > > Signed-off-by: Jiri Olsa > > --- > > .../perf/Documentation/perf-buildid-cache.txt | 12 +- > > tools/perf/builtin-buildid-cache.c| 213 +- > > tools/perf/util/probe-event.c | 6 +- > > 3 files changed, 225 insertions(+), 6 deletions(-) > > > > diff --git a/tools/perf/Documentation/perf-buildid-cache.txt > > b/tools/perf/Documentation/perf-buildid-cache.txt > > index f6de0952ff3c..b77da5138bca 100644 > > --- a/tools/perf/Documentation/perf-buildid-cache.txt > > +++ b/tools/perf/Documentation/perf-buildid-cache.txt > > @@ -23,7 +23,17 @@ OPTIONS > > --- > > -a:: > > --add=:: > > -Add specified file to the cache. > > +Add specified file or perf.data binaries to the cache. > > + > > +If the file is detected to be perf data file, it is processed > > +and all dso objects with sample hit are stored to the cache. > > + > > +It's possible to specify 'all' to store all dso objects, like: > > +-a perf.data,all > > + > > +Once perf data is specified, no other file can be specified in > > +the option, otherwise it causes syntax error. > > + > > -f:: > > --force:: > > Don't complain, do it. > > diff --git a/tools/perf/builtin-buildid-cache.c > > b/to
Re: [PATCH] irqchip/gic-v4.1: Optimize the wait for the completion of the analysis of the VPT
Shenming,
Somehow this patch ended up in the wrong folder.
Apologies for the delay reviewing it.
On 2020-09-23 07:35, Shenming Lu wrote:
Right after a vPE is made resident, the code starts polling the
GICR_VPENDBASER.Dirty bit until it becomes 0, where the delay_us
is set to 10. But in our measurement, it takes only hundreds of
nanoseconds, or 1~2 microseconds, to finish parsing the VPT in most
cases. And we also measured the time from vcpu_load() (include it)
to __guest_enter() on Kunpeng 920. On average, it takes 2.55
microseconds
(not first run && the VPT is empty). So 10 microseconds delay might
really hurt performance.
To avoid this, we can set the delay_us to 1, which is more appropriate
in this situation and universal. Besides, we can delay the execution
of its_wait_vpt_parse_complete() (call it from kvm_vgic_flush_hwstate()
corresponding to vPE resident), giving the GIC a chance to work in
parallel with the CPU on the entry path.
Signed-off-by: Shenming Lu
---
arch/arm64/kvm/vgic/vgic-v4.c | 18 ++
arch/arm64/kvm/vgic/vgic.c | 2 ++
drivers/irqchip/irq-gic-v3-its.c | 14 +++---
drivers/irqchip/irq-gic-v4.c | 11 +++
include/kvm/arm_vgic.h | 3 +++
include/linux/irqchip/arm-gic-v4.h | 4
6 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-v4.c
b/arch/arm64/kvm/vgic/vgic-v4.c
index b5fa73c9fd35..1d5d2d6894d3 100644
--- a/arch/arm64/kvm/vgic/vgic-v4.c
+++ b/arch/arm64/kvm/vgic/vgic-v4.c
@@ -353,6 +353,24 @@ int vgic_v4_load(struct kvm_vcpu *vcpu)
return err;
}
+void vgic_v4_wait_vpt(struct kvm_vcpu *vcpu)
I'd like something a bit more abstract as a name.
vgic_v4_commit() seems more appropriate, and could be used for other
purposes.
+{
+ struct its_vpe *vpe;
+
+ if (kvm_vgic_global_state.type == VGIC_V2 ||
Why do you test for GICv2? Isn't the vgic_supports_direct_msis() test
enough?
And the test should be moved to kvm_vgic_flush_hwstate(), as we already
have
similar checks there.
!vgic_supports_direct_msis(vcpu->kvm))
+ return;
+
+ vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe;
+
+ if (vpe->vpt_ready)
+ return;
+
+ if (its_wait_vpt(vpe))
+ return;
How can that happen?
+
+ vpe->vpt_ready = true;
This is nasty. You need to explain what happens with this state (you are
trying not to access VPENDBASER across a shallow exit, as only a
vcpu_put
will invalidate the GIC state). And something like vpe_ready is more
generic (we try not to have too much of the GICv4 gunk in the KVM code).
+}
+
static struct vgic_its *vgic_get_its(struct kvm *kvm,
struct kvm_kernel_irq_routing_entry
*irq_entry)
{
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index c3643b7f101b..ed810a80cda2 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -915,6 +915,8 @@ void kvm_vgic_flush_hwstate(struct kvm_vcpu *vcpu)
if (can_access_vgic_from_kernel())
vgic_restore_state(vcpu);
+
+ vgic_v4_wait_vpt(vcpu);
}
void kvm_vgic_load(struct kvm_vcpu *vcpu)
diff --git a/drivers/irqchip/irq-gic-v3-its.c
b/drivers/irqchip/irq-gic-v3-its.c
index 548de7538632..b7cbc9bcab9d 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3803,7 +3803,7 @@ static void its_wait_vpt_parse_complete(void)
WARN_ON_ONCE(readq_relaxed_poll_timeout_atomic(vlpi_base +
GICR_VPENDBASER,
val,
!(val &
GICR_VPENDBASER_Dirty),
- 10, 500));
+ 1, 500));
This really should be in a separate patch.
}
static void its_vpe_schedule(struct its_vpe *vpe)
@@ -3837,7 +3837,7 @@ static void its_vpe_schedule(struct its_vpe *vpe)
val |= GICR_VPENDBASER_Valid;
gicr_write_vpendbaser(val, vlpi_base + GICR_VPENDBASER);
- its_wait_vpt_parse_complete();
+ vpe->vpt_ready = false;
This really belongs to the deschedule path, doesn't it? Given that
it can only be set from vgic_flush_hwstate(), it should be fairly
foolproof.
}
static void its_vpe_deschedule(struct its_vpe *vpe)
@@ -3881,6 +3881,10 @@ static int its_vpe_set_vcpu_affinity(struct
irq_data *d, void *vcpu_info)
its_vpe_schedule(vpe);
return 0;
+ case WAIT_VPT:
COMMIT_VPE seems a better name.
+ its_wait_vpt_parse_complete();
+ return 0;
+
case DESCHEDULE_VPE:
its_vpe_deschedule(vpe);
return 0;
@@ -4047,7 +4051,7 @@ static void its_vpe_4_1_schedule(struct its_vpe
*vpe,
gicr_write_vpendbaser(val, vlpi_base + GICR_VPENDBASER);
- its_wait_vpt_parse_complete();
+ vpe->vpt_ready =
Re: [PATCH] powerpc: fix the allyesconfig build
On 2020/11/28 9:56, Jakub Kicinski wrote:
> On Sat, 28 Nov 2020 12:28:19 +1100 Stephen Rothwell wrote:
>> There are 2 drivers that have arrays of packed structures that contain
>> pointers that end up at unaligned offsets. These produce warnings in
>> the PowerPC allyesconfig build like this:
>>
>> WARNING: 148 bad relocations
>> ce56510b R_PPC64_UADDR64 .rodata+0x01c72378
>> ce565126 R_PPC64_UADDR64 .rodata+0x01c723c0
>>
>> They are not drivers that are used on PowerPC (I assume), so mark them
>> to not be built on PPC64 when CONFIG_RELOCATABLE is enabled.
>
> 😳😳
>
> What's the offending structure in hisilicon? I'd rather have a look
> packing structs with pointers in 'em sounds questionable.
>
> I only see these two:
>
> $ git grep packed drivers/net/ethernet/hisilicon/
> drivers/net/ethernet/hisilicon/hns/hnae.h:struct __packed hnae_desc {
> drivers/net/ethernet/hisilicon/hns3/hns3_enet.h:struct __packed hns3_desc {
I assmue "struct __packed hnae_desc" is the offending structure, because
flag_ipoffset field is defined as __le32 and is not 32 bit aligned.
struct __packed hnae_desc {
__le64 addr;//0
union {
struct {//64
union {
__le16 asid_bufnum_pid;
__le16 asid;
};
__le16 send_size; //92
union {
__le32 flag_ipoffset; //*108*
struct {
__u8 bn_pid;
__u8 ra_ri_cs_fe_vld;
__u8 ip_offset;
__u8 tse_vlan_snap_v6_sctp_nth;
};
};
__le16 mss;
__u8 l4_len;
__u8 reserved1;
__le16 paylen;
__u8 vmid;
__u8 qid;
__le32 reserved2[2];
} tx;
struct {
__le32 ipoff_bnum_pid_flag;
__le16 pkt_len;
__le16 size;
union {
__le32 vlan_pri_asid;
struct {
__le16 asid;
__le16 vlan_cfi_pri;
};
};
__le32 rss_hash;
__le32 reserved_1[2];
} rx;
};
};
> .
>
Re: [PATCH] irqchip/gic-v4.1: Optimize the wait for the completion of the analysis of the VPT
On 2020/11/28 3:35, Marc Zyngier wrote:
> Shenming,
>
> Somehow this patch ended up in the wrong folder.
> Apologies for the delay reviewing it.>
> On 2020-09-23 07:35, Shenming Lu wrote:
>> Right after a vPE is made resident, the code starts polling the
>> GICR_VPENDBASER.Dirty bit until it becomes 0, where the delay_us
>> is set to 10. But in our measurement, it takes only hundreds of
>> nanoseconds, or 1~2 microseconds, to finish parsing the VPT in most
>> cases. And we also measured the time from vcpu_load() (include it)
>> to __guest_enter() on Kunpeng 920. On average, it takes 2.55 microseconds
>> (not first run && the VPT is empty). So 10 microseconds delay might
>> really hurt performance.
>>
>> To avoid this, we can set the delay_us to 1, which is more appropriate
>> in this situation and universal. Besides, we can delay the execution
>> of its_wait_vpt_parse_complete() (call it from kvm_vgic_flush_hwstate()
>> corresponding to vPE resident), giving the GIC a chance to work in
>> parallel with the CPU on the entry path.
>>
>> Signed-off-by: Shenming Lu
>> ---
>> arch/arm64/kvm/vgic/vgic-v4.c | 18 ++
>> arch/arm64/kvm/vgic/vgic.c | 2 ++
>> drivers/irqchip/irq-gic-v3-its.c | 14 +++---
>> drivers/irqchip/irq-gic-v4.c | 11 +++
>> include/kvm/arm_vgic.h | 3 +++
>> include/linux/irqchip/arm-gic-v4.h | 4
>> 6 files changed, 49 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
>> index b5fa73c9fd35..1d5d2d6894d3 100644
>> --- a/arch/arm64/kvm/vgic/vgic-v4.c
>> +++ b/arch/arm64/kvm/vgic/vgic-v4.c
>> @@ -353,6 +353,24 @@ int vgic_v4_load(struct kvm_vcpu *vcpu)
>> return err;
>> }
>>
>> +void vgic_v4_wait_vpt(struct kvm_vcpu *vcpu)
>
> I'd like something a bit more abstract as a name.
>
> vgic_v4_commit() seems more appropriate, and could be used for other
> purposes.
Yes, it looks more appropriate.
>
>> +{
>> + struct its_vpe *vpe;
>> +
>> + if (kvm_vgic_global_state.type == VGIC_V2 ||
>
> Why do you test for GICv2? Isn't the vgic_supports_direct_msis() test enough?
> And the test should be moved to kvm_vgic_flush_hwstate(), as we already have
> similar checks there.
Yes, the test for GICv2 is unnecessary I will correct it.
>
>> !vgic_supports_direct_msis(vcpu->kvm))
>> + return;
>> +
>> + vpe = &vcpu->arch.vgic_cpu.vgic_v3.its_vpe;
>> +
>> + if (vpe->vpt_ready)
>> + return;
>> +
>> + if (its_wait_vpt(vpe))
>> + return;
>
> How can that happen?
Yes, it seems that its_wait_vpt() would always return 0.
>
>> +
>> + vpe->vpt_ready = true;
>
> This is nasty. You need to explain what happens with this state (you are
> trying not to access VPENDBASER across a shallow exit, as only a vcpu_put
Ok, I will add a comment here.
> will invalidate the GIC state). And something like vpe_ready is more
> generic (we try not to have too much of the GICv4 gunk in the KVM code).
Yes, that's better.
>
>> +}
>> +
>> static struct vgic_its *vgic_get_its(struct kvm *kvm,
>> struct kvm_kernel_irq_routing_entry *irq_entry)
>> {
>> diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
>> index c3643b7f101b..ed810a80cda2 100644
>> --- a/arch/arm64/kvm/vgic/vgic.c
>> +++ b/arch/arm64/kvm/vgic/vgic.c
>> @@ -915,6 +915,8 @@ void kvm_vgic_flush_hwstate(struct kvm_vcpu *vcpu)
>>
>> if (can_access_vgic_from_kernel())
>> vgic_restore_state(vcpu);
>> +
>> + vgic_v4_wait_vpt(vcpu);
>> }
>>
>> void kvm_vgic_load(struct kvm_vcpu *vcpu)
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c
>> b/drivers/irqchip/irq-gic-v3-its.c
>> index 548de7538632..b7cbc9bcab9d 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -3803,7 +3803,7 @@ static void its_wait_vpt_parse_complete(void)
>> WARN_ON_ONCE(readq_relaxed_poll_timeout_atomic(vlpi_base +
>> GICR_VPENDBASER,
>> val,
>> !(val & GICR_VPENDBASER_Dirty),
>> - 10, 500));
>> + 1, 500));
>
> This really should be in a separate patch.
Ok, I will separate it.
>
>> }
>>
>> static void its_vpe_schedule(struct its_vpe *vpe)
>> @@ -3837,7 +3837,7 @@ static void its_vpe_schedule(struct its_vpe *vpe)
>> val |= GICR_VPENDBASER_Valid;
>> gicr_write_vpendbaser(val, vlpi_base + GICR_VPENDBASER);
>>
>> - its_wait_vpt_parse_complete();
>> + vpe->vpt_ready = false;
>
> This really belongs to the deschedule path, doesn't it? Given that
> it can only be set from vgic_flush_hwstate(), it should be fairly
> foolproof.
Yes, that's better.
>
>> }
>>
>> static void its_vpe_deschedule(struct its_vpe *vpe)
>> @@ -3881,6 +3881,10 @@ static int its_vpe_set_vcpu_affinity(struct
>> irq_data *d, void *vcpu_info)
>> its_vpe_schedule(vpe);
>> return 0;
>>
>>
Re: [PATCH v4 1/5] usb: dwc3: core: Host wake up support from system suspend
Hi,
On 2020-10-28 02:07, Sandeep Maheswaram wrote:
Avoiding phy powerdown in host mode so that it can be woken up by
devices.
Added hs_phy_mode flag to check connection status and set phy mode
and configure interrupts.
Signed-off-by: Sandeep Maheswaram
---
drivers/usb/dwc3/core.c | 14 +++---
drivers/usb/dwc3/core.h | 2 ++
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index bdf0925..0e4bc1e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1672,10 +1672,6 @@ static int dwc3_suspend_common(struct dwc3
*dwc, pm_message_t msg)
dwc3_core_exit(dwc);
break;
case DWC3_GCTL_PRTCAP_HOST:
- if (!PMSG_IS_AUTO(msg)) {
- dwc3_core_exit(dwc);
- break;
- }
This could be a problem for platforms that don't support runtime_suspend
and rely on dwc3_core_exit to power-down PHY.
IMO you can continue to do dwc3_core_exit() if runtime_pm isn't enabled
for the device.
/* Let controller to suspend HSPHY before PHY driver suspends */
if (dwc->dis_u2_susphy_quirk ||
@@ -1733,13 +1729,9 @@ static int dwc3_resume_common(struct dwc3 *dwc,
pm_message_t msg)
spin_unlock_irqrestore(&dwc->lock, flags);
break;
case DWC3_GCTL_PRTCAP_HOST:
- if (!PMSG_IS_AUTO(msg)) {
- ret = dwc3_core_init_for_resume(dwc);
- if (ret)
- return ret;
- dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
- break;
- }
+
+ dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
+
/* Restore GUSB2PHYCFG bits that were modified in suspend */
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
if (dwc->dis_u2_susphy_quirk)
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 74323b1..da63d4a3 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1101,6 +1101,8 @@ struct dwc3 {
boolphys_ready;
+ unsigned inths_phy_mode;
+
This change should instead be part of the other patch ?
"usb: dwc3: host: Add suspend_quirk for dwc3 host"
struct ulpi *ulpi;
boolulpi_ready;
Re: [GIT PULL] SPI fixes for v5.10-rc5
On Fri, Nov 27, 2020 at 5:49 AM Mark Brown wrote: > > A few fixes for v5.10, one for the core which fixes some potential races > for controllers with multiple chip selects when configuration of the > chip select for one client device races with the addition and initial > setup of an additional client. That's a really hard long sentence to read. I was going to try to rephrase it to be a bit more readable, but gave up. Anyway, pulled, I just reacted to that explanation not being easy to parse. Linus
[PATCH] locking/selftest: remove trailing semicolon in macro definition
From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix --- lib/locking-selftest.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/locking-selftest.c b/lib/locking-selftest.c index a899b3f0e2e5..69b4a1160094 100644 --- a/lib/locking-selftest.c +++ b/lib/locking-selftest.c @@ -935,7 +935,7 @@ GENERATE_PERMUTATIONS_3_EVENTS(irqsafe3_soft_wlock) LOCK(B);\ UNLOCK(B); \ UNLOCK(A); \ - IRQ_ENABLE(); + IRQ_ENABLE() #define E2() \ LOCK(B);\ @@ -995,7 +995,7 @@ GENERATE_PERMUTATIONS_3_EVENTS(irqsafe4_soft_wlock) LOCK(B);\ UNLOCK(B); \ WU(A); \ - IRQ_ENABLE(); + IRQ_ENABLE() #define E2() \ \ @@ -1170,7 +1170,7 @@ GENERATE_PERMUTATIONS_3_EVENTS(W1W2_R2R3_R3W1) IRQ_DISABLE(); \ WL(A); \ WU(A); \ - IRQ_ENABLE(); + IRQ_ENABLE() #define E2() \ \ @@ -1218,7 +1218,7 @@ GENERATE_PERMUTATIONS_3_EVENTS(irq_read_recursion_soft_wlock) LOCK(A);\ UNLOCK(A); \ U(B); \ - IRQ_ENABLE(); + IRQ_ENABLE() #define E2() \ \ @@ -1272,7 +1272,7 @@ GENERATE_PERMUTATIONS_3_EVENTS(irq_read_recursion2_soft_wlock) LOCK(A);\ UNLOCK(A); \ WU(B); \ - IRQ_ENABLE(); + IRQ_ENABLE() #define E2() \ \ -- 2.18.4
Re: [PATCH v1] net: phy: micrel: fix interrupt handling
On Fri, 27 Nov 2020 15:11:08 + Ioana Ciornei wrote:
> On Fri, Nov 27, 2020 at 03:45:45PM +0100, Andrew Lunn wrote:
> > On Fri, Nov 27, 2020 at 01:36:21PM +0100, Oleksij Rempel wrote:
> > > After migration to the shared interrupt support, the KSZ8031 PHY with
> > > enabled interrupt support was not able to notify about link status
> > > change.
> > >
> > > Fixes: 59ca4e58b917 ("net: phy: micrel: implement generic
> > > .handle_interrupt() callback")
> > > Signed-off-by: Oleksij Rempel
> >
> > Reviewed-by: Andrew Lunn
> >
> > I took a quick look at all the other patches like this. I did not spot
> > any other missing the !
> >
> > Andrew
>
> Uhh, really sorry for this!
>
> Thanks for double checking.
Applied, thanks!
[RESEND PATCH V3] PM / EM: Micro optimization in em_cpu_energy
When the sum of the utilization of CPUs in a power domain is zero, return the energy as 0 without doing any computations. Acked-by: Quentin Perret Reviewed-by: Dietmar Eggemann Signed-off-by: Pavankumar Kondeti --- include/linux/energy_model.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h index b67a51c..8810f1f 100644 --- a/include/linux/energy_model.h +++ b/include/linux/energy_model.h @@ -103,6 +103,9 @@ static inline unsigned long em_cpu_energy(struct em_perf_domain *pd, struct em_perf_state *ps; int i, cpu; + if (!sum_util) + return 0; + /* * In order to predict the performance state, map the utilization of * the most utilized CPU of the performance domain to a requested -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v2 tip/core/rcu 1/6] srcu: Make Tiny SRCU use multi-bit grace-period counter
On Wed, Nov 25, 2020 at 10:03:26AM +0530, Neeraj Upadhyay wrote:
>
>
> On 11/24/2020 10:48 AM, Neeraj Upadhyay wrote:
> >
> >
> > On 11/24/2020 1:25 AM, Paul E. McKenney wrote:
> > > On Mon, Nov 23, 2020 at 10:01:13AM +0530, Neeraj Upadhyay wrote:
> > > > On 11/21/2020 6:29 AM, paul...@kernel.org wrote:
> > > > > From: "Paul E. McKenney"
> > > > >
> > > > > There is a need for a polling interface for SRCU grace periods. This
> > > > > polling needs to distinguish between an SRCU instance being idle on
> > > > > the
> > > > > one hand or in the middle of a grace period on the other. This commit
> > > > > therefore converts the Tiny SRCU srcu_struct structure's srcu_idx from
> > > > > a defacto boolean to a free-running counter, using the bottom bit to
> > > > > indicate that a grace period is in progress. The second-from-bottom
> > > > > bit is thus used as the index returned by srcu_read_lock().
> > > > >
> > > > > Link:
> > > > > https://lore.kernel.org/rcu/20201112201547.gf3365...@moria.home.lan/
> > > > > Reported-by: Kent Overstreet
> > > > > [ paulmck: Fix __srcu_read_lock() idx computation Neeraj per
> > > > > Upadhyay. ]
> > > > > Signed-off-by: Paul E. McKenney
> > > > > ---
> > > > > include/linux/srcutiny.h | 4 ++--
> > > > > kernel/rcu/srcutiny.c | 5 +++--
> > > > > 2 files changed, 5 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/include/linux/srcutiny.h b/include/linux/srcutiny.h
> > > > > index 5a5a194..d9edb67 100644
> > > > > --- a/include/linux/srcutiny.h
> > > > > +++ b/include/linux/srcutiny.h
> > > > > @@ -15,7 +15,7 @@
> > > > > struct srcu_struct {
> > > > > short srcu_lock_nesting[2]; /* srcu_read_lock()
> > > > > nesting depth. */
> > > > > - short srcu_idx; /* Current reader array element. */
> > > > > + unsigned short srcu_idx; /* Current reader array
> > > > > element in bit 0x2. */
> > > > > u8 srcu_gp_running; /* GP workqueue running? */
> > > > > u8 srcu_gp_waiting; /* GP waiting for readers? */
> > > > > struct swait_queue_head srcu_wq;
> > > > > @@ -59,7 +59,7 @@ static inline int __srcu_read_lock(struct
> > > > > srcu_struct *ssp)
> > > > > {
> > > > > int idx;
> > > > > - idx = READ_ONCE(ssp->srcu_idx);
> > > > > + idx = ((READ_ONCE(ssp->srcu_idx) + 1) & 0x2) >> 1;
> > > > > WRITE_ONCE(ssp->srcu_lock_nesting[idx],
> > > > > ssp->srcu_lock_nesting[idx] + 1);
> > > > > return idx;
> > > > > }
> > > >
> > > > Need change in idx calcultion in srcu_torture_stats_print() ?
> > > >
> > > > static inline void srcu_torture_stats_print(struct srcu_struct *ssp,
> > > > idx = READ_ONCE(ssp->srcu_idx) & 0x1;
> > >
> > > Excellent point! It should match the calculation in __srcu_read_lock(),
> > > shouldn't it? I have updated this, thank you!
> > >
> > > Thanx, Paul
> > >
> >
> > Updated version looks good!
> >
> >
> > Thanks
> > Neeraj
> >
>
> For the version in rcu -dev:
>
> Reviewed-by: Neeraj Upadhyay
I applied all of these, thank you very much!
> Only minor point which I have is, the idx calculation can be made an inline
> func (though srcu_drive_gp() does not require a READ_ONCE for ->srcu_idx):
>
> __srcu_read_lock() and srcu_torture_stats_print() are using
>
> idx = ((READ_ONCE(ssp->srcu_idx) + 1) & 0x2) >> 1;
>
> whereas srcu_drive_gp() uses:
>
> idx = (ssp->srcu_idx & 0x2) / 2;
They do work on different elements of the various arrays. Or do you
believe that the srcu_drive_gp() use needs adjusting?
Either way, the overhead of READ_ONCE() is absolutely not at all
a problem. Would you like to put together a patch so that I can see
exactly what you are suggesting?
Thanx, Paul
> Thanks
> Neeraj
>
> > > > Thanks
> > > > Neeraj
> > > >
> > > > > diff --git a/kernel/rcu/srcutiny.c b/kernel/rcu/srcutiny.c
> > > > > index 6208c1d..5598cf6 100644
> > > > > --- a/kernel/rcu/srcutiny.c
> > > > > +++ b/kernel/rcu/srcutiny.c
> > > > > @@ -124,11 +124,12 @@ void srcu_drive_gp(struct work_struct *wp)
> > > > > ssp->srcu_cb_head = NULL;
> > > > > ssp->srcu_cb_tail = &ssp->srcu_cb_head;
> > > > > local_irq_enable();
> > > > > - idx = ssp->srcu_idx;
> > > > > - WRITE_ONCE(ssp->srcu_idx, !ssp->srcu_idx);
> > > > > + idx = (ssp->srcu_idx & 0x2) / 2;
> > > > > + WRITE_ONCE(ssp->srcu_idx, ssp->srcu_idx + 1);
> > > > > WRITE_ONCE(ssp->srcu_gp_waiting, true); /*
> > > > > srcu_read_unlock() wakes! */
> > > > > swait_event_exclusive(ssp->srcu_wq,
> > > > > !READ_ONCE(ssp->srcu_lock_nesting[idx]));
> > > > > WRITE_ONCE(ssp->srcu_gp_waiting, false); /*
> > > > > srcu_read_unlock() cheap. */
> > > > > + WRITE_ONCE(ssp->srcu_idx, ssp->srcu_idx + 1);
> > > > > /* Invoke the callbacks we removed above. */
> > > > > while (lh) {
> > > > >
> > > >
> > > > --
> > > > QUALCOMM INDIA, on
Re: [PATCH V10 0/5] fuse: Add support for passthrough read/write
On Tue, Oct 27, 2020 at 1:00 AM Alessio Balsini wrote: > > This is the 10th version of the series. Please find the changelog at the > bottom of this cover letter. > > Add support for file system passthrough read/write of files when enabled in > userspace through the option FUSE_PASSTHROUGH. > > There are file systems based on FUSE that are intended to enforce special > policies or trigger complicated decision makings at the file operations > level. Android, for example, uses FUSE to enforce fine-grained access > policies that also depend on the file contents. > Sometimes it happens that at open or create time a file is identified as > not requiring additional checks for consequent reads/writes, thus FUSE > would simply act as a passive bridge between the process accessing the FUSE > file system and the lower file system. Splicing and caching help reduce the > FUSE overhead, but there are still read/write operations forwarded to the > userspace FUSE daemon that could be avoided. > > This series has been inspired by the original patches from Nikhilesh Reddy, > the idea and code of which has been elaborated and improved thanks to the > community support. > > When the FUSE_PASSTHROUGH capability is enabled, the FUSE daemon may decide > while handling the open/create operations, if the given file can be > accessed in passthrough mode. This means that all the further read and > write operations would be forwarded by the kernel directly to the lower > file system using the VFS layer rather than to the FUSE daemon. > All the requests other than reads or writes are still handled by the > userspace FUSE daemon. > This allows for improved performance on reads and writes, especially in the > case of reads at random offsets, for which no (readahead) caching mechanism > would help. > Benchmarks show improved performance that is close to native file system > access when doing massive manipulations on a single opened file, especially > in the case of random reads, for which the bandwidth increased by almost 2X > or sequential writes for which the improvement is close to 3X. > > The creation of this direct connection (passthrough) between FUSE file > objects and file objects in the lower file system happens in a way that > reminds of passing file descriptors via sockets: > - a process requests the opening of a file handled by FUSE, so the kernel > forwards the request to the FUSE daemon; > - the FUSE daemon opens the target file in the lower file system, getting > its file descriptor; > - the FUSE daemon also decides according to its internal policies if > passthrough can be enabled for that file, and, if so, can perform a > FUSE_DEV_IOC_PASSTHROUGH_OPEN ioctl() on /dev/fuse, passing the file > descriptor obtained at the previous step and the fuse_req unique > identifier; > - the kernel translates the file descriptor to the file pointer navigating > through the opened files of the "current" process and temporarily stores > it in the associated open/create fuse_req's passthrough_filp; > - when the FUSE daemon has done with the request and it's time for the > kernel to close it, it checks if the passthrough_filp is available and in > case updates the additional field in the fuse_file owned by the process > accessing the FUSE file system. > From now on, all the read/write operations performed by that process will > be redirected to the corresponding lower file system file by creating new > VFS requests. > Since the read/write operation to the lower file system is executed with > the current process's credentials, it might happen that it does not have > enough privileges to succeed. For this reason, the process temporarily > receives the same credentials as the FUSE daemon, that are reverted as soon > as the read/write operation completes, emulating the behavior of the > request to be performed by the FUSE daemon itself. This solution has been > inspired by the way overlayfs handles read/write operations. > Asynchronous IO is supported as well, handled by creating separate AIO > requests for the lower file system that will be internally tracked by FUSE, > that intercepts and propagates their completion through an internal > ki_completed callback similar to the current implementation of overlayfs. > The ioctl() has been designed taking as a reference and trying to converge > to the fuse2 implementation. For example, the fuse_passthrough_out data > structure has extra fields that will allow for further extensions of the > feature. > > > Performance on SSD > > What follows has been performed with this change [V6] rebased on top of > vanilla v5.8 Linux kernel, using a custom passthrough_hp FUSE daemon that > enables pass-through for each file that is opened during both "open" and > "create". Tests were run on an Intel Xeon E5-2678V3, 32GiB of RAM, with an > ext4-formatted SSD as the lower file system, with no special tuning, e.g., > all the involved processes are SCHED_OTHER, ondemand is the frequency >
Re: [PATCH] kvm/x86/mmu: use the correct inherited permissions to get shadow page
On Sat, Nov 28, 2020 at 12:48 AM Paolo Bonzini wrote:
>
> On 26/11/20 01:05, Sean Christopherson wrote:
> > On Fri, Nov 20, 2020, Lai Jiangshan wrote:
> >> From: Lai Jiangshan
> >>
> >> Commit 41074d07c78b ("KVM: MMU: Fix inherited permissions for emulated
> >> guest pte updates") said role.access is common access permissions for
> >> all ptes in this shadow page, which is the inherited permissions from
> >> the parent ptes.
> >>
> >> But the commit did not enforce this definition when kvm_mmu_get_page()
> >> is called in FNAME(fetch). Rather, it uses a random (last level pte's
> >> combined) access permissions.
> >
> > I wouldn't say it's random, the issue is specifically that all shadow pages
> > end
> > up using the combined set of permissions of the entire walk, as opposed to
> > the
> > only combined permissions of its parents.
> >
> >> And the permissions won't be checked again in next FNAME(fetch) since the
> >> spte is present. It might fail to meet guest's expectation when guest sets
> >> up
> >> spaghetti pagetables.
> >
> > Can you provide details on the exact failure scenario? It would be very
> > helpful
> > for documentation and understanding. I can see how using the full combined
> > permissions will cause weirdness for upper level SPs in kvm_mmu_get_page(),
> > but
> > I'm struggling to connect the dots to understand how that will cause
> > incorrect
> > behavior for the guest. AFAICT, outside of the SP cache, KVM only consumes
> > role.access for the final/last SP.
> >
>
> Agreed, a unit test would be even better, but just a description in the
> commit message would be enough.
>
> Paolo
>
Something in my mind, but I haven't test it:
pgd[]pud[] pmd[]pte[]virtual address pointers
(same hpa as pmd2\) /->pte1(u--)->page1 <- ptr1 (u--)
/->pmd1(uw-)--->pte2(uw-)->page2 <- ptr2 (uw-)
pgd->pud-| (shared pte[] as above)
\->pmd2(u--)--->pte1(u--)->page1 <- ptr3 (u--)
(same hpa as pmd1/) \->pte2(uw-)->page2 <- ptr4 (u--)
pmd1 and pmd2 point to the same pte table, so:
ptr1 and ptr3 points to the same page.
ptr2 and ptr4 points to the same page.
The guess read-accesses to ptr1 first. So the hypervisor gets the
shadow pte page table with role.access=u-- among other things.
(Note the shadowed pmd1's access is uwx)
And then the guest write-accesses to ptr2, and the hypervisor
set up shadow page for ptr2.
(Note the hypervisor silencely accepts the role.access=u--
shadow pte page table in FNAME(fetch))
After that, the guess read-accesses to ptr3, the hypervisor
reused the same shadow pte page table as above.
At last, the guest writes to ptr4 without vmexit nor pagefault,
Which should cause vmexit as the guest expects.
In theory, guest userspace can trick the guest kernel if the guest
kernel sets up page table like this.
Such spaghetti pagetables are unlikely to be seen in the guest.
But when the guest is using KPTI and not using SMEP. KPTI means
all pgd entries are marked NX on the lower/userspace part of
the kernel pagetable. Which means SMEP is not needed.
(see arch/x86/mm/pti.c)
Assume the guest does disable SMEP and the guest has the flaw
that the guest user can trick guest kernel to execute on lower
part of the address space.
Normally, NX bit marked on the kernel pagetable's lower pgd
entries can help in this case. But when in guest with shadowpage
in hypervisor, the guest user can make those NX bit useless.
Again, I haven't tested it neither. I will try it later and
update the patch including adding some more checks in the mmu.c.
Thanks,
Lai
Re: [PATCH net-next 1/7] net: hns3: add support for RX completion checksum
On 2020/11/28 4:52, Jakub Kicinski wrote: On Fri, 27 Nov 2020 16:47:16 +0800 Huazhong Tan wrote: In some cases (for example ip fragment), hardware will calculate the checksum of whole packet in RX, and setup the HNS3_RXD_L2_CSUM_B flag in the descriptor, so add support to utilize this checksum. Signed-off-by: Huazhong Tan drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2810:14: warning: incorrect type in assignment (different base types) drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2810:14:expected restricted __sum16 [usertype] csum drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2810:14:got unsigned int drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2812:14: warning: invalid assignment: |= drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2812:14:left side has type restricted __sum16 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2812:14:right side has type unsigned int Will fix it, thanks. .
Re: [PATCH net-next 5/7] net: hns3: add more info to hns3_dbg_bd_info()
On 2020/11/28 4:53, Jakub Kicinski wrote: On Fri, 27 Nov 2020 16:47:20 +0800 Huazhong Tan wrote: Since TX hardware checksum and RX completion checksum have been supported now, so add related information in hns3_dbg_bd_info(). Signed-off-by: Huazhong Tan drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:266:22: warning: incorrect type in assignment (different base types) drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:266:22:expected restricted __sum16 [usertype] csum drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:266:22:got unsigned int drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:268:22: warning: invalid assignment: |= drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:268:22:left side has type restricted __sum16 drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:268:22:right side has type unsigned int Will fix it, thanks. .
Re: [PATCH V10 2/5] fuse: Passthrough initialization and release
On Fri, Nov 27, 2020 at 9:41 PM Alessio Balsini wrote:
>
> Hi Peng,
>
> Thanks for the heads up!
>
> On Thu, Nov 26, 2020 at 09:33:34PM +0800, Peng Tao wrote:
> > On Tue, Oct 27, 2020 at 12:19 AM Alessio Balsini
> > wrote:
> > > [...]
> > > int fuse_passthrough_setup(struct fuse_conn *fc, struct fuse_file *ff,
> > >struct fuse_open_out *openarg)
> > > {
> > > - return -EINVAL;
> > > + struct inode *passthrough_inode;
> > > + struct super_block *passthrough_sb;
> > > + struct fuse_passthrough *passthrough;
> > > + int passthrough_fh = openarg->passthrough_fh;
> > > +
> > > + if (!fc->passthrough)
> > > + return -EPERM;
> > > +
> > > + /* Default case, passthrough is not requested */
> > > + if (passthrough_fh <= 0)
> > > + return -EINVAL;
> > > +
> > > + spin_lock(&fc->passthrough_req_lock);
> > > + passthrough = idr_remove(&fc->passthrough_req, passthrough_fh);
> > > + spin_unlock(&fc->passthrough_req_lock);
> > > +
> > > + if (!passthrough)
> > > + return -EINVAL;
> > > +
> > > + passthrough_inode = file_inode(passthrough->filp);
> > > + passthrough_sb = passthrough_inode->i_sb;
> > > + if (passthrough_sb->s_stack_depth >= FILESYSTEM_MAX_STACK_DEPTH) {
> > Hi Alessio,
> >
> > passthrough_sb is the underlying filesystem superblock, right? It
> > seems to prevent fuse passthrough fs from stacking on another fully
> > stacked file system, instead of preventing other file systems from
> > stacking on this fuse passthrough file system. Am I misunderstanding
> > it?
>
> Correct, this checks the stacking depth on the lower filesystem.
> This is an intended behavior to avoid the stacking of multiple FUSE
> passthrough filesystems, and works because when a FUSE connection has
> the passthrough feature activated, the file system updates its
> s_stack_depth to FILESYSTEM_MAX_STACK_DEPTH in process_init_reply()
> (PATCH 1/5), avoiding further stacking.
>
> Do you see issues with that?
I'm considering a use case where a fuse passthrough file system is
stacked on top of an overlayfs and/or an ecryptfs. The underlying
s_stack_depth FILESYSTEM_MAX_STACK_DEPTH is rejected here so it is
possible to have an overlayfs or an ecryptfs underneath but not both
(with current FILESYSTEM_MAX_STACK_DEPTH being 2). How about changing
passthrough fuse sb s_stack_depth to FILESYSTEM_MAX_STACK_DEPTH + 1 in
PATCH 1/5, and allow passthrough_sb->s_stack_depth to be
FILESYSTEM_MAX_STACK_DEPTH here? So that existing kernel stacking file
system setups can all work as the underlying file system, while the
stacking of multiple FUSE passthrough filesystems is still blocked.
>
> What I'm now thinking is that fuse_passthrough_open would probably be a
> better place for this check, so that the ioctl() would fail and the user
> space daemon may decide to skip passthrough and use legacy FUSE access
> for that file (or, at least, be aware that something went wrong).
>
+1, fuse_passthrough_open seems to be a better place for the check.
> A more aggressive approach would be instead to move the stacking depth
> check to fuse_fill_super_common, where we can update s_stack_depth to
> lower-fs depth+1 and fail if passthrough is active and s_stack_depth is
> greater than FILESYSTEM_MAX_STACK_DEPTH.
>
The lower layer files/directories might actually spread on different
file systems. I'm not sure if s_stack_depth check is still possible at
mount time. Even if we can calculate the substree s_stack_depth, it is
still more flexible to determine on a per inode basis, right?
Cheers,
Tao
--
Into Sth. Rich & Strange
Re: [PATCH] powerpc: fix the allyesconfig build
On Sat, 28 Nov 2020 12:28:19 +1100 Stephen Rothwell wrote:
> There are 2 drivers that have arrays of packed structures that contain
> pointers that end up at unaligned offsets. These produce warnings in
> the PowerPC allyesconfig build like this:
>
> WARNING: 148 bad relocations
> ce56510b R_PPC64_UADDR64 .rodata+0x01c72378
> ce565126 R_PPC64_UADDR64 .rodata+0x01c723c0
>
> They are not drivers that are used on PowerPC (I assume), so mark them
> to not be built on PPC64 when CONFIG_RELOCATABLE is enabled.
😳😳
What's the offending structure in hisilicon? I'd rather have a look
packing structs with pointers in 'em sounds questionable.
I only see these two:
$ git grep packed drivers/net/ethernet/hisilicon/
drivers/net/ethernet/hisilicon/hns/hnae.h:struct __packed hnae_desc {
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h:struct __packed hns3_desc {
Re: [PATCH 1/1] perf diff: fix error return value in __cmd_diff()
On 2020/11/28 1:25, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 27, 2020 at 02:22:02PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Nov 27, 2020 at 10:35:37PM +0900, Namhyung Kim escreveu:
>>> On Tue, Nov 24, 2020 at 7:37 PM Zhen Lei wrote:
>
An appropriate return value should be set on the failed path.
>
Reported-by: Hulk Robot
Signed-off-by: Zhen Lei
>
>>> Acked-by: Namhyung Kim
>
>> Thanks, applied.
>
> I also added this:
>
> Cc: Jin Yao
> Fixes: 2a09a84c720b436a ("perf diff: Support hot streams comparison")
>
> Please add the fixes line and CC the author of the patch introducing the
> bug next time,
Okay, I'll do that next time. Thanks for the heads-up.
>
> Thanks
>
> - Arnaldo
>
> .
>
Re: [PATCH -next] fs/ntfs: fix set but not used variable 'log_page_mask'
Ping... Fixes gcc '-Wunused-but-set-variable' warning: fs/ntfs/logfile.c: In function ntfs_check_logfile: fs/ntfs/logfile.c:481:21: warning: variable log_page_mask set but not used [-Wunused-but-set-variable] Actually log_page_mask can be used to replace 'log_page_size - 1' as it is set. Signed-off-by: Zheng Zengkai --- fs/ntfs/logfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ntfs/logfile.c b/fs/ntfs/logfile.c index a0c40f1be7ac..c35fcf389369 100644 --- a/fs/ntfs/logfile.c +++ b/fs/ntfs/logfile.c @@ -507,7 +507,7 @@ bool ntfs_check_logfile(struct inode *log_vi, RESTART_PAGE_HEADER **rp) * optimize log_page_size and log_page_bits into constants. */ log_page_bits = ntfs_ffs(log_page_size) - 1; - size &= ~(s64)(log_page_size - 1); + size &= ~(s64)(log_page_mask); /* * Ensure the log file is big enough to store at least the two restart * pages and the minimum number of log record pages.
Re: WARNING in try_to_wake_up
syzbot has found a reproducer for the following issue on: HEAD commit:99c710c4 Merge tag 'platform-drivers-x86-v5.10-2' of git:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1780c56350 kernel config: https://syzkaller.appspot.com/x/.config?x=6d1e98d0b97781e4 dashboard link: https://syzkaller.appspot.com/bug?extid=dd74984384afdb86e904 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11e6161d50 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1651b32d50 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+dd74984384afdb86e...@syzkaller.appspotmail.com [ cut here ] WARNING: CPU: 1 PID: 9857 at include/linux/cpumask.h:137 rcu_read_unlock include/linux/rcupdate.h:696 [inline] WARNING: CPU: 1 PID: 9857 at include/linux/cpumask.h:137 ttwu_stat kernel/sched/core.c:2441 [inline] WARNING: CPU: 1 PID: 9857 at include/linux/cpumask.h:137 try_to_wake_up+0xef6/0x1330 kernel/sched/core.c:2984 Modules linked in: CPU: 1 PID: 9857 Comm: io_wq_manager Not tainted 5.10.0-rc5-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:cpu_max_bits_warn include/linux/cpumask.h:137 [inline] RIP: 0010:cpumask_check include/linux/cpumask.h:144 [inline] RIP: 0010:cpumask_check include/linux/cpumask.h:142 [inline] RIP: 0010:cpumask_test_cpu include/linux/cpumask.h:367 [inline] RIP: 0010:is_cpu_allowed kernel/sched/core.c:1705 [inline] RIP: 0010:select_task_rq kernel/sched/core.c:2370 [inline] RIP: 0010:try_to_wake_up+0xef6/0x1330 kernel/sched/core.c:2964 Code: 80 3d 93 2a 8c 0b 00 0f 84 f1 00 00 00 e8 82 80 10 00 48 c7 c6 d9 6d 4c 81 48 c7 c7 e0 77 33 8b e8 0f b7 09 00 e9 15 f9 ff ff <0f> 0b e9 65 f4 ff ff 4c 89 ff 48 89 4c 24 08 e8 b6 51 ff ff 48 8b RSP: 0018:c99c7d50 EFLAGS: 00010002 RAX: dc00 RBX: 192000138faf RCX: 88804825c438 RDX: 11100904b886 RSI: 83b63c9b RDI: 0006 RBP: 88804825c0c0 R08: 88804825c0d0 R09: 8cecc98f R10: 0040 R11: R12: 0202 R13: 88804825c8f8 R14: 0008 R15: 88804825c430 FS: () GS:88802cb0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 560a8007e384 CR3: 133db000 CR4: 00350ee0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: create_io_worker+0x590/0x8d0 fs/io-wq.c:720 io_wq_manager+0x16b/0xb80 fs/io-wq.c:785 kthread+0x3b1/0x4a0 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
[PATCH] powerpc: fix the allyesconfig build
There are 2 drivers that have arrays of packed structures that contain pointers that end up at unaligned offsets. These produce warnings in the PowerPC allyesconfig build like this: WARNING: 148 bad relocations ce56510b R_PPC64_UADDR64 .rodata+0x01c72378 ce565126 R_PPC64_UADDR64 .rodata+0x01c723c0 They are not drivers that are used on PowerPC (I assume), so mark them to not be built on PPC64 when CONFIG_RELOCATABLE is enabled. Cc: Geert Uytterhoeven Cc: Michael Turquette Cc: Stephen Boyd Cc: Yisen Zhuang Cc: Salil Mehta Cc: David S. Miller Cc: Jakub Kicinski Cc: Nicholas Piggin Cc: Daniel Axtens Cc: Joel Stanley Signed-off-by: Stephen Rothwell --- drivers/clk/renesas/Kconfig| 4 drivers/net/ethernet/hisilicon/Kconfig | 4 2 files changed, 8 insertions(+) It might be easiest to put this through the PowerPC (fixes?) tree, if people woulf just sned ACKs, please? diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig index 18915d668a30..53f24a0cad7a 100644 --- a/drivers/clk/renesas/Kconfig +++ b/drivers/clk/renesas/Kconfig @@ -151,6 +151,10 @@ config CLK_R8A779A0 select CLK_RENESAS_CPG_MSSR config CLK_R9A06G032 + # PPC64 RELOCATABLE kernels cannot handle relocations to + # unaligned locations that are produced by the array of + # packed structures in this driver. + depends on !(PPC64 && RELOCATABLE) bool "Renesas R9A06G032 clock driver" help This is a driver for R9A06G032 clocks diff --git a/drivers/net/ethernet/hisilicon/Kconfig b/drivers/net/ethernet/hisilicon/Kconfig index 44f9279cdde1..bf47e504b365 100644 --- a/drivers/net/ethernet/hisilicon/Kconfig +++ b/drivers/net/ethernet/hisilicon/Kconfig @@ -102,6 +102,10 @@ config HNS3_HCLGE tristate "Hisilicon HNS3 HCLGE Acceleration Engine & Compatibility Layer Support" default m depends on PCI_MSI + # PPC64 RELOCATABLE kernels cannot handle relocations to + # unaligned locations that are produced by the array of + # packed structures in this driver. + depends on !(PPC64 && RELOCATABLE) help This selects the HNS3_HCLGE network acceleration engine & its hardware compatibility layer. The engine would be used in Hisilicon hip08 family of -- 2.29.2 -- Cheers, Stephen Rothwell pgp0MoVXjiwvv.pgp Description: OpenPGP digital signature
Re: 5.10 regression caused by: "uas: fix sdev->host->dma_dev": many XHCI swiotlb buffer is full / DMAR: Device bounce map failed errors on thunderbolt connected XHCI controller
Should we still be clamping max_sectors to dma_max_mapping_size(dev) (for now)? with dev being us->pusb_dev->bus->sysdev and devinfo->udev->bus->sysdev respectively (i.e. revert only scsi_add_host_with_dma() to scsi_add_host())? On Sat, 28 Nov 2020 at 02:12, Hans de Goede wrote: > > Hi, > > On 11/27/20 5:19 PM, Christoph Hellwig wrote: > > On Fri, Nov 27, 2020 at 01:32:16PM +0100, Hans de Goede wrote: > >> I ran some more tests, I can confirm that reverting: > >> > >> 5df7ef7d32fe "uas: bump hw_max_sectors to 2048 blocks for SS or faster > >> drives" > >> 558033c2828f "uas: fix sdev->host->dma_dev" > >> > >> Makes the problem go away while running a 5.10 kernel. I also tried > >> doubling > >> the swiotlb size by adding: swiotlb=65536 to the kernel commandline but > >> that > >> does not help. > >> > >> Some more observations: > >> > >> 1. The usb-storage driver does not cause this issue, even though it has a > >> very similar change. > >> > >> 2. The problem does not happen until I plug an UAS decvice into the dock. > >> > >> 3. The problem continues to happen even after I unplug the UAS device and > >> rmmod the uas module > >> > >> 3. made me take a bit closer look to the troublesome commit, it passes: > >> udev->bus->sysdev, which I assume is the XHCI controller itself as device > >> to scsi_add_host_with_dma, which in turn seems to cause permanent changes > >> to the dma settings for the XHCI controller. I'm not all that familiar with > >> the DMA APIs but I'm getting the feeling that passing the actual > >> XHCI-controller's > >> device as dma-device to scsi_add_host_with_dma is simply the wrong thing to > >> do; and that the intended effects (honor XHCI dma limits, but do not cause > >> any changes the XHCI dma settings) should be achieved differently. > >> > >> Note that if this is indeed wrong, the matching usb-storage change should > >> likely also be dropped. > > > > One problem in this area is that the clamping of the DMA size through > > dma_max_mapping_size mentioned in the commit log doesn't work when > > swiotlb is called from intel-iommu. I think we need to wire up those > > calls there as well. > > Ok, but that does not sound like a quick last minute fix for 5.10, so maybe > for 5.10 we should just revert the uas and usb-storage changes which trigger > this problem and then retry those for 5.11 ? > > Regards, > > Hans >
Re: [PATCH net-next v7 0/5] net/x25: netdev event handling
On Thu, 26 Nov 2020 07:35:52 +0100 Martin Schiller wrote: > Changes to v6: > o integrated some code styling suggestions by Jakub. > > Changes to v5: > o fix numbering in commit message of patch 2/5. > > Changes to v4: > o also establish layer2 (LAPB) on NETDEV_UP events, if the carrier is > already UP. > > Changes to v3: > o another complete rework of the patch-set to split event handling > for layer2 (LAPB) and layer3 (X.25) > > Changes to v2: > o restructure complete patch-set > o keep netdev event handling in layer3 (X.25) > o add patch to fix lapb_connect_request() for DCE > o add patch to handle carrier loss correctly in lapb > o drop patch for x25_neighbour param handling > this may need fixes/cleanup and will be resubmitted later. > > Changes to v1: > o fix 'subject_prefix' and 'checkpatch' warnings Applied, thank you!
[PATCH] netfilter: remove trailing semicolon in macro definition
From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix --- include/net/netfilter/nf_tables_offload.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/netfilter/nf_tables_offload.h b/include/net/netfilter/nf_tables_offload.h index 1d34fe154fe0..ae8160b62b10 100644 --- a/include/net/netfilter/nf_tables_offload.h +++ b/include/net/netfilter/nf_tables_offload.h @@ -81,7 +81,7 @@ int nft_flow_rule_offload_commit(struct net *net); #define NFT_OFFLOAD_MATCH_EXACT(__key, __base, __field, __len, __reg) \ NFT_OFFLOAD_MATCH(__key, __base, __field, __len, __reg) \ - memset(&(__reg)->mask, 0xff, (__reg)->len); + memset(&(__reg)->mask, 0xff, (__reg)->len) int nft_chain_offload_priority(struct nft_base_chain *basechain); -- 2.18.4
[PATCH] scsi: remove trailing semicolon in macro definition
From: Tom Rix
The macro use will already have a semicolon.
Signed-off-by: Tom Rix
---
include/scsi/scsi_driver.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/scsi/scsi_driver.h b/include/scsi/scsi_driver.h
index 6dffa8555a39..f6221c006aa7 100644
--- a/include/scsi/scsi_driver.h
+++ b/include/scsi/scsi_driver.h
@@ -25,7 +25,7 @@ struct scsi_driver {
extern int scsi_register_driver(struct device_driver *);
#define scsi_unregister_driver(drv) \
- driver_unregister(drv);
+ driver_unregister(drv)
extern int scsi_register_interface(struct class_interface *);
#define scsi_unregister_interface(intf) \
--
2.18.4
Re: [PATCH] clk: rockchip: Remove redundant null check before clk_prepare_enable
Quoting Xu Wang (2020-11-27 01:05:51) > Because clk_prepare_enable() already checked NULL clock parameter, > so the additional check is unnecessary, just remove it. > > Signed-off-by: Xu Wang > --- Acked-by: Stephen Boyd
[PATCH] ALSA: remove trailing semicolon in macro definition
From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix --- include/sound/hda_codec.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/sound/hda_codec.h b/include/sound/hda_codec.h index 73827b7d17e0..2e8d51937acd 100644 --- a/include/sound/hda_codec.h +++ b/include/sound/hda_codec.h @@ -344,7 +344,7 @@ snd_hda_get_num_conns(struct hda_codec *codec, hda_nid_t nid) #define snd_hda_get_raw_connections(codec, nid, list, max_conns) \ snd_hdac_get_connections(&(codec)->core, nid, list, max_conns) #define snd_hda_get_num_raw_conns(codec, nid) \ - snd_hdac_get_connections(&(codec)->core, nid, NULL, 0); + snd_hdac_get_connections(&(codec)->core, nid, NULL, 0) int snd_hda_get_conn_list(struct hda_codec *codec, hda_nid_t nid, const hda_nid_t **listp); -- 2.18.4
Re: ACK: [PATCH 1/1] efi/efi_test: read RuntimeServicesSupported
On 27/11/2020 19:29, Ard Biesheuvel wrote:
> On Fri, 27 Nov 2020 at 20:28, Colin Ian King wrote:
>>
>> On 27/11/2020 19:20, Heinrich Schuchardt wrote:
>>> Since the UEFI 2.8A specification the UEFI enabled firmware provides a
>>> configuration table EFI_RT_PROPERTIES_TABLE which indicates which runtime
>>> services are enabled. The EFI stub reads this table and saves the value of
>>> the field RuntimeServicesSupported internally.
>>>
>>> The Firmware Test Suite requires the value to determine if UEFI runtime
>>> services are correctly implemented.
>>>
>>> With this patch an IOCTL call is provided to read the value of the field
>>> RuntimeServicesSupported, e.g.
>>>
>>> #define EFI_RUNTIME_GET_SUPPORTED_MASK \
>>> _IOR('p', 0x0C, unsigned int)
>>> unsigned int mask;
>>> fd = open("/dev/efi_test", O_RDWR);
>>> ret = ioctl(fd, EFI_RUNTIME_GET_SUPPORTED_MASK, &mask);
>>>
>>> Signed-off-by: Heinrich Schuchardt
>>> ---
>>> drivers/firmware/efi/test/efi_test.c | 16
>>> drivers/firmware/efi/test/efi_test.h | 3 +++
>>> 2 files changed, 19 insertions(+)
>>>
>>> diff --git a/drivers/firmware/efi/test/efi_test.c
>>> b/drivers/firmware/efi/test/efi_test.c
>>> index ddf9eae396fe..47d67bb0a516 100644
>>> --- a/drivers/firmware/efi/test/efi_test.c
>>> +++ b/drivers/firmware/efi/test/efi_test.c
>>> @@ -663,6 +663,19 @@ static long efi_runtime_query_capsulecaps(unsigned
>>> long arg)
>>> return rv;
>>> }
>>>
>>> +static long efi_runtime_get_supported_mask(unsigned long arg)
>>> +{
>>> + unsigned int __user *supported_mask;
>>> + int rv = 0;
>>> +
>>> + supported_mask = (unsigned int *)arg;
>>> +
>>> + if (put_user(efi.runtime_supported_mask, supported_mask))
>>> + rv = -EFAULT;
>>> +
>>> + return rv;
>>> +}
>>> +
>>> static long efi_test_ioctl(struct file *file, unsigned int cmd,
>>> unsigned long arg)
>>> {
>>> @@ -699,6 +712,9 @@ static long efi_test_ioctl(struct file *file, unsigned
>>> int cmd,
>>>
>>> case EFI_RUNTIME_RESET_SYSTEM:
>>> return efi_runtime_reset_system(arg);
>>> +
>>> + case EFI_RUNTIME_GET_SUPPORTED_MASK:
>>> + return efi_runtime_get_supported_mask(arg);
>>> }
>>>
>>> return -ENOTTY;
>>> diff --git a/drivers/firmware/efi/test/efi_test.h
>>> b/drivers/firmware/efi/test/efi_test.h
>>> index f2446aa1c2e3..117349e57993 100644
>>> --- a/drivers/firmware/efi/test/efi_test.h
>>> +++ b/drivers/firmware/efi/test/efi_test.h
>>> @@ -118,4 +118,7 @@ struct efi_resetsystem {
>>> #define EFI_RUNTIME_RESET_SYSTEM \
>>> _IOW('p', 0x0B, struct efi_resetsystem)
>>>
>>> +#define EFI_RUNTIME_GET_SUPPORTED_MASK \
>>> + _IOR('p', 0x0C, unsigned int)
>>> +
>>> #endif /* _DRIVERS_FIRMWARE_EFI_TEST_H_ */
>>> --
>>> 2.29.2
>>>
>>
>> Looks good to me. Thanks Heinrich.
>>
>> The EFI driver needs to be also updated in the linux kernel - has that
>> fix been submitted or do you require the fwts team to do that?
Oops. It's been a lot week :-(
>>
>
> This /is/ the EFI driver.
>
> I'll take this as an acked-by but I'd like Ivan to chime in as well.
>
+1
Re: [GIT PULL] arm64 fixes for -rc6
The pull request you sent on Fri, 27 Nov 2020 11:40:27 +: > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e4e9458073ae7ab0e7c28e7380a26ad1fccf0296 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] IOMMU fixes for -rc6
The pull request you sent on Fri, 27 Nov 2020 11:45:29 +: > git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/iommu-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6adf33a5e42feada39d52eebd389d2019202e993 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[tip:x86/cleanups] BUILD SUCCESS 638920a66a17c8e1f4415cbab0d49dc4a344c2a7
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cleanups branch HEAD: 638920a66a17c8e1f4415cbab0d49dc4a344c2a7 x86/PCI: Make a kernel-doc comment a normal one elapsed time: 723m configs tested: 115 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm efm32_defconfig powerpcsam440ep_defconfig m68k m5475evb_defconfig xtensasmp_lx200_defconfig arm mv78xx0_defconfig armqcom_defconfig m68k atari_defconfig arm omap1_defconfig mips pistachio_defconfig powerpc mpc85xx_cds_defconfig powerpc ppc40x_defconfig armdove_defconfig arm jornada720_defconfig powerpc mpc837x_rdb_defconfig nds32 defconfig arm cm_x300_defconfig mips malta_defconfig arm pxa168_defconfig openrisc simple_smp_defconfig mips rt305x_defconfig sh sh03_defconfig sparc64 defconfig mipsgpr_defconfig arm colibri_pxa300_defconfig arm corgi_defconfig sh kfr2r09_defconfig sh sdk7786_defconfig mips ip22_defconfig sh se7722_defconfig powerpc linkstation_defconfig armoxnas_v6_defconfig riscv rv32_defconfig sh rsk7201_defconfig mipsmalta_kvm_guest_defconfig powerpc tqm8541_defconfig sh ap325rxa_defconfig openriscdefconfig powerpc pseries_defconfig mips lemote2f_defconfig h8300 h8s-sim_defconfig arm pxa3xx_defconfig ia64 alldefconfig sh se7721_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201127 i386 randconfig-a003-20201127 i386 randconfig-a002-20201127 i386 randconfig-a005-20201127 i386 randconfig-a001-20201127 i386 randconfig-a006-20201127 x86_64 randconfig-a015-20201127 x86_64 randconfig-a011-20201127 x86_64 randconfig-a014-20201127 x86_64 randconfig-a016-20201127 x86_64 randconfig-a012-20201127 x86_64 randconfig-a013-20201127 i386 randconfig-a012-20201127 i386 randconfig-a013-20201127 i386 randconfig-a011-20201127 i386 randconfig-a016-20201127 i386 randconfig-a014-20201127 i386 randconfig-a015-20201127 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv
Re: [GIT PULL] printk for 5.10 (includes lockless ringbuffer)
The pull request you sent on Fri, 27 Nov 2020 14:47:15 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux.git > tags/printk-for-5.10-rc6-fixup has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/43d6ecd97c0c69acffc918cc18cdabdfcaa55354 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 6/7] mm,hwpoison: Disable pcplists before grabbing a refcount
On Thu, 26 Nov 2020 14:45:30 +0100 Vlastimil Babka wrote: > Note as you say the series should go after [1] above, which means after > mm-page_alloc-disable-pcplists-during-memory-offline.patch in mmots, but > currently it's ordered before, where zone_pcp_disable() etc doesn't yet > exist. > Found out as I review using checked out this commit from -next. Thanks, I reordered them.
[PATCH] hwmon: (pwm-fan): Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
drivers/hwmon//pwm-fan.c:152:60-61: WARNING opportunity for kobj_to_dev().
Signed-off-by: Tian Tao
---
drivers/hwmon/pwm-fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 1f63807..7849011 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -149,7 +149,7 @@ static struct attribute *pwm_fan_attrs[] = {
static umode_t pwm_fan_attrs_visible(struct kobject *kobj, struct attribute *a,
int n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct pwm_fan_ctx *ctx = dev_get_drvdata(dev);
/* Hide fan_input in case no interrupt is available */
--
2.7.4
[PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
From: Bruce Ashfield In some cross build environments such as the Yocto Project build environment it provides an ncurses library that is compiled differently than the host's version. This causes display corruption problems when the host's curses includes are used instead of the includes from the provided compiler are overridden. There is a second case where there is no curses libraries at all on the host system and menuconfig will just fail entirely. The solution is simply to allow an override variable in check-lxdialog.sh for environments such as the Yocto Project. Adding a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing compiling and linking against the right headers and libraries. Signed-off-by: Jason Wessel cc: Michal Marek cc: linux-kbu...@vger.kernel.org Signed-off-by: Bruce Ashfield Signed-off-by: Scott Branden --- scripts/kconfig/mconf-cfg.sh | 8 1 file changed, 8 insertions(+) mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh old mode 100755 new mode 100644 index aa68ec95620d..32448bc198a5 --- a/scripts/kconfig/mconf-cfg.sh +++ b/scripts/kconfig/mconf-cfg.sh @@ -4,6 +4,14 @@ PKG="ncursesw" PKG2="ncurses" +if [ "$CROSS_CURSES_LIB" != "" ]; then +echo libs=\'$CROSS_CURSES_LIB\' +if [ x"$CROSS_CURSES_INC" != x ]; then + echo cflags=\'$CROSS_CURSES_INC\' +fi +exit 0 +fi + if [ -n "$(command -v pkg-config)" ]; then if pkg-config --exists $PKG; then echo cflags=\"$(pkg-config --cflags $PKG)\" -- 2.17.1
[PATCH] pwm: bcm2835: Support apply function for atomic configuration
Use the newer apply function of pwm_ops instead of config, enable, disable
and set_polarity.
This guarantees atomic changes of the pwm controller configuration. It also
reduces the size of the driver.
This has been tested on a Raspberry PI 4.
Signed-off-by: Lino Sanfilippo
---
drivers/pwm/pwm-bcm2835.c | 64 ---
1 file changed, 21 insertions(+), 43 deletions(-)
diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
index d78f86f..2eadfa5 100644
--- a/drivers/pwm/pwm-bcm2835.c
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -58,13 +58,14 @@ static void bcm2835_pwm_free(struct pwm_chip *chip, struct
pwm_device *pwm)
writel(value, pc->base + PWM_CONTROL);
}
-static int bcm2835_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
- int duty_ns, int period_ns)
+static int bcm2835_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+const struct pwm_state *state)
{
+
struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
unsigned long rate = clk_get_rate(pc->clk);
unsigned long scaler;
- u32 period;
+ u32 value;
if (!rate) {
dev_err(pc->dev, "failed to get clock rate\n");
@@ -72,65 +73,42 @@ static int bcm2835_pwm_config(struct pwm_chip *chip, struct
pwm_device *pwm,
}
scaler = DIV_ROUND_CLOSEST(NSEC_PER_SEC, rate);
- period = DIV_ROUND_CLOSEST(period_ns, scaler);
+ /* set period */
+ value = DIV_ROUND_CLOSEST(state->period, scaler);
- if (period < PERIOD_MIN)
+ if (value < PERIOD_MIN)
return -EINVAL;
- writel(DIV_ROUND_CLOSEST(duty_ns, scaler),
- pc->base + DUTY(pwm->hwpwm));
- writel(period, pc->base + PERIOD(pwm->hwpwm));
-
- return 0;
-}
+ writel(value, pc->base + PERIOD(pwm->hwpwm));
-static int bcm2835_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
- u32 value;
+ /* set duty cycle */
+ value = DIV_ROUND_CLOSEST(state->duty_cycle, scaler);
+ writel(value, pc->base + DUTY(pwm->hwpwm));
+ /* set polarity */
value = readl(pc->base + PWM_CONTROL);
- value |= PWM_ENABLE << PWM_CONTROL_SHIFT(pwm->hwpwm);
- writel(value, pc->base + PWM_CONTROL);
-
- return 0;
-}
-static void bcm2835_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
- struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
- u32 value;
-
- value = readl(pc->base + PWM_CONTROL);
- value &= ~(PWM_ENABLE << PWM_CONTROL_SHIFT(pwm->hwpwm));
- writel(value, pc->base + PWM_CONTROL);
-}
-
-static int bcm2835_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm,
- enum pwm_polarity polarity)
-{
- struct bcm2835_pwm *pc = to_bcm2835_pwm(chip);
- u32 value;
-
- value = readl(pc->base + PWM_CONTROL);
-
- if (polarity == PWM_POLARITY_NORMAL)
+ if (state->polarity == PWM_POLARITY_NORMAL)
value &= ~(PWM_POLARITY << PWM_CONTROL_SHIFT(pwm->hwpwm));
else
value |= PWM_POLARITY << PWM_CONTROL_SHIFT(pwm->hwpwm);
+ /* enable/disable */
+ if (state->enabled)
+ value |= PWM_ENABLE << PWM_CONTROL_SHIFT(pwm->hwpwm);
+ else
+ value &= ~(PWM_ENABLE << PWM_CONTROL_SHIFT(pwm->hwpwm));
+
writel(value, pc->base + PWM_CONTROL);
return 0;
}
+
static const struct pwm_ops bcm2835_pwm_ops = {
.request = bcm2835_pwm_request,
.free = bcm2835_pwm_free,
- .config = bcm2835_pwm_config,
- .enable = bcm2835_pwm_enable,
- .disable = bcm2835_pwm_disable,
- .set_polarity = bcm2835_set_polarity,
+ .apply = bcm2835_pwm_apply,
.owner = THIS_MODULE,
};
--
2.7.4
Re: [PATCH] bpf: remove trailing semicolon in macro definition
On 11/27/20 8:27 PM, t...@redhat.com wrote: From: Tom Rix The macro use will already have a semicolon. Signed-off-by: Tom Rix --- include/trace/events/xdp.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/trace/events/xdp.h b/include/trace/events/xdp.h index cd24e8a59529..65ffedf8386f 100644 --- a/include/trace/events/xdp.h +++ b/include/trace/events/xdp.h @@ -146,13 +146,13 @@ DEFINE_EVENT(xdp_redirect_template, xdp_redirect_err, ); #define _trace_xdp_redirect(dev, xdp, to) \ -trace_xdp_redirect(dev, xdp, NULL, 0, NULL, to); +trace_xdp_redirect(dev, xdp, NULL, 0, NULL, to) #define _trace_xdp_redirect_err(dev, xdp, to, err) \ trace_xdp_redirect_err(dev, xdp, NULL, err, NULL, to); #define _trace_xdp_redirect_map(dev, xdp, to, map, index) \ -trace_xdp_redirect(dev, xdp, to, 0, map, index); +trace_xdp_redirect(dev, xdp, to, 0, map, index) #define _trace_xdp_redirect_map_err(dev, xdp, to, map, index, err) \ trace_xdp_redirect_err(dev, xdp, to, err, map, index); This looks random, why those but not other locations ? Thanks, Daniel
Re: [PATCH] mm: Don't fault around userfaultfd-registered regions on reads
Hello,
On Fri, Nov 27, 2020 at 12:22:24PM +, Matthew Wilcox wrote:
> On Thu, Nov 26, 2020 at 05:23:59PM -0500, Peter Xu wrote:
> > For wr-protected mode uffds, errornously fault in those pages around could
> > lead
> > to threads accessing the pages without uffd server's awareness. For
> > example,
> > when punching holes on uffd-wp registered shmem regions, we'll first try to
> > unmap all the pages before evicting the page cache but without locking the
> > page (please refer to shmem_fallocate(), where unmap_mapping_range() is
> > called
> > before shmem_truncate_range()). When fault-around happens near a hole being
> > punched, we might errornously fault in the "holes" right before it will be
> > punched. Then there's a small window before the page cache was finally
> > dropped, and after the page will be writable again (NOTE: the uffd-wp
> > protect
> > information is totally lost due to the pre-unmap in shmem_fallocate(), so
> > the
> > page can be writable within the small window). That's severe data loss.
>
> Sounds like you have a missing page_mkwrite implementation.
If the real fault happened through the pagetable (which got dropped by
the hole punching), a "missing type" userfault would be delivered to
userland (because the pte would be none). Userland would invoke
UFFDIO_COPY with the UFFDIO_COPY_MODE_WP flag. Such flag would then
map the filled shmem page (not necessarily all zero and not
necessarily the old content before the hole punch) with _PAGE_RW not
set and _PAGE_UFFD_WP set, so the next write would also trigger a
wrprotect userfault (this is what the uffd-wp app expects).
filemap_map_pages doesn't notify userland when it fills a pte and it
will map again the page read-write.
However filemap_map_pages isn't capable to fill a hole and to undo the
hole punch, all it can do are minor faults to re-fill the ptes from a
not-yet-truncated inode page.
Now it would be ok if filemap_map_pages re-filled the ptes, after they
were zapped the first time by fallocate, and then the fallocate would
zap them again before truncating the page, but I don't see a second
pte zap... there's just the below single call of unmap_mapping_range:
if ((u64)unmap_end > (u64)unmap_start)
unmap_mapping_range(mapping, unmap_start,
1 + unmap_end - unmap_start, 0);
shmem_truncate_range(inode, offset, offset + len - 1);
So looking at filemap_map_pages in shmem, I'm really wondering if the
non-uffd case is correct or not.
Do we end up with ptes pointing to non pagecache, so then the virtual
mapping is out of sync also with read/write syscalls that will then
allocate another shmem page out of sync of the ptes?
If a real page fault happened instead of filemap_map_pages, the
shmem_fault() would block during fallocate punch hole by checking
inode->i_private, as the comment says:
* So refrain from
* faulting pages into the hole while it's being punched.
It's not immediately clear where filemap_map_pages refrains from
faulting pages into the hole while it's being punched... given it's
ignoring inode->i_private.
So I'm not exactly sure how shmem can safely faulted in through
filemap_map_pages, without going through shmem_fault... I suppose
shmem simply is unsafe to use filemap_map_pages and it'd require
a specific shmem_map_pages?
If only filemap_map_pages was refraining re-faulting ptes of a shmem
page that is about to be truncated (whose original ptes had _PAGE_RW
unset and _PAGE_UFFD_WP set) there would be no problem with the uffd
interaction. So a proper shmem_map_pages could co-exist with uffd, the
userfaultfd_armed check would be only an optimization but it wouldn't
be required to avoid userland memory corruption?
>From 8c6fb1b7dde309f0c8b5666a8e13557ae46369b4 Mon Sep 17 00:00:00 2001
From: Andrea Arcangeli
Date: Fri, 27 Nov 2020 19:12:44 -0500
Subject: [PATCH 1/1] shmem: stop faulting in pages without checking
inode->i_private
Per shmem_fault comment shmem need to "refrain from faulting pages
into the hole while it's being punched" and to do so it must check
inode->i_private, which filemap_map_pages won't so it's unsafe to use
in shmem because it can leave ptes pointing to non-pagecache pages in
shmem backed vmas.
Signed-off-by: Andrea Arcangeli
---
mm/shmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 8e2b35ba93ad..f6f29b3e67c6 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -3942,7 +3942,6 @@ static const struct super_operations shmem_ops = {
static const struct vm_operations_struct shmem_vm_ops = {
.fault = shmem_fault,
- .map_pages = filemap_map_pages,
#ifdef CONFIG_NUMA
.set_policy = shmem_set_policy,
.get_policy = shmem_get_policy,
Thanks,
Andrea
Re: [RFC 0/4] net: l2switch: Provide support for L2 switch on i.MX28 SoC
Hi Vladimir,
> On Fri, Nov 27, 2020 at 12:35:49AM +0100, Lukasz Majewski wrote:
> > > > - The question regarding power management - at least for my use
> > > > case there is no need for runtime power management. The L2
> > > > switch shall work always at it connects other devices.
> > > >
> > > > - The FEC clock is also used for L2 switch management and
> > > > configuration (as the L2 switch is just in the same, large IP
> > > > block). For now I just keep it enabled so DSA code can use it.
> > > > It looks a bit problematic to export fec_enet_clk_enable() to be
> > > > reused on DSA code.
> > > >
> > > > Links:
> > > > [0] - "i.MX28 Applications Processor Reference Manual, Rev. 2,
> > > > 08/2013" [1] -
> > > > https://github.com/lmajewski/linux-imx28-l2switch/commit/e3c7a6eab73401e021aef0070e1935a0dba84fb5
> > > >
> > >
> > > Disclaimer: I don't know the details of imx28, it's just now that
> > > I downloaded the reference manual to see what it's about.
> > >
> > > I would push back and say that the switch offers bridge
> > > acceleration for the FEC.
> >
> > Am I correct, that the "bridge acceleration" means in-hardware
> > support for L2 packet bridging?
> >
> > And without the switch IP block enabled one shall be able to have
> > software bridging in Linux in those two interfaces?
>
> So if the switch is bypassed through pin strapping of sx_ena, then the
> DMA0 would be connected to ENETC-MAC 0, DMA1 to ENET-MAC 1, and both
> these ports could be driven by the regular fec driver, am I right?
> This is how people use the imx28 with mainline linux right now, no?
Yes. This is the current situation.
>
> When the sx_ena signal enables the switch, a hardware accelerator
> appears between the DMA engine and the same MACs.
Yes.
> But that DMA engine
> is still compatible with the expectations of the fec driver.
Yes. This is why I can reuse the fec_main.c driver.
> And the
> MACs still belong to the FEC.
Yes. I do use mdio communication between MAC and PHYs (by re-using FEC
driver code).
> So, at the end of the day, there are
> still 2 FEC interfaces.
I'm a bit confused with the above sentence. What do you mean "2 FEC
interfaces"?
There is the FEC driver (fec_main.c), which handles DMA0
management/setup and communication with PHYs via MDIO (the FEC driver
setups MDIO, link type, speed, provides info if link is up or down).
>
> Where I was going is that from a user's perspective, it would be
> natural to have the exact same view of the system in both cases, aka
> still two network interfaces for MAC 0 and MAC 1, they still function
> in the same way (i.e. you can still ping through them) but with the
> additional ability to do hardware-accelerating bridging, if the MAC 0
> and MAC 1 network interfaces are put under the same bridge.
At least on imx287 ENET-MAC1 needs MAC0 to be configured:
https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/freescale/fec_main.c#L2065
Those two MACs are not fully independent - functionality of MAC1 is
reduced.
>
> Currently, you do not offer that, at all.
> You split the MTIP switch configuration between DSA and the FEC
> driver. But you are still not exposing networking-capable net devices
> for MAC 0 and MAC 1.
As fair as I can tell (and tested it) - it is possible to bring up
"lan{12}" interfaces with `ip l s lan{12}`
I would also like to set the static table with altering the FDB switch
memory/configuration. Access to it seems natural via lan{12} interfaces
(but of course could be possible from eth0).
Yes, I can send data via eth0 as I don't add tag to it. As pointed out
by Andrew - I could use VLAN tags (or play with FEC_FFEN register).
> You still do I/O through the DMA engine.
Yes, DMA0 is connected to MTIP port0 (input port from the imx28 SoC).
The MTIP port1 -> MAC0 and port2 -> MAC1
>
> So why use DSA at all? What benefit does it bring you? Why not do the
> entire switch configuration from within FEC, or a separate driver very
> closely related to it?
Mine rationale to use DSA and FEC:
- Make as little changes to FEC as possible
- Provide separate driver to allow programming FDB, MDB, VLAN setup.
This seems straightforward as MTIP has separate memory region (from
FEC) for switch configuration, statistics, learning, static table
programming. What is even more bizarre FEC and MTIP have the same 8
registers (with different base address and +4 offset :-) ) as
interface to handle DMA0 transfers.
- According to MTIP description from NXP documentation, there is a
separate register for frame forwarding, so it _shall_ also fit into
DSA.
For me it would be enough to have:
- lan{12} - so I could enable/disable it on demand (control when switch
ports are passing or not packets).
- Use standard net tools (like bridge) to setup FDB/MDB, vlan
- Read statistics from MTIP ports (all of them)
- I can use lan1 (bridged or not) to send data outside. It would be
also correct to use eth0.
I'm for the most pragmatic
ACK: [PATCH 1/1] efi/efi_test: read RuntimeServicesSupported
On 27/11/2020 19:20, Heinrich Schuchardt wrote:
> Since the UEFI 2.8A specification the UEFI enabled firmware provides a
> configuration table EFI_RT_PROPERTIES_TABLE which indicates which runtime
> services are enabled. The EFI stub reads this table and saves the value of
> the field RuntimeServicesSupported internally.
>
> The Firmware Test Suite requires the value to determine if UEFI runtime
> services are correctly implemented.
>
> With this patch an IOCTL call is provided to read the value of the field
> RuntimeServicesSupported, e.g.
>
> #define EFI_RUNTIME_GET_SUPPORTED_MASK \
> _IOR('p', 0x0C, unsigned int)
> unsigned int mask;
> fd = open("/dev/efi_test", O_RDWR);
> ret = ioctl(fd, EFI_RUNTIME_GET_SUPPORTED_MASK, &mask);
>
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/firmware/efi/test/efi_test.c | 16
> drivers/firmware/efi/test/efi_test.h | 3 +++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/firmware/efi/test/efi_test.c
> b/drivers/firmware/efi/test/efi_test.c
> index ddf9eae396fe..47d67bb0a516 100644
> --- a/drivers/firmware/efi/test/efi_test.c
> +++ b/drivers/firmware/efi/test/efi_test.c
> @@ -663,6 +663,19 @@ static long efi_runtime_query_capsulecaps(unsigned long
> arg)
> return rv;
> }
>
> +static long efi_runtime_get_supported_mask(unsigned long arg)
> +{
> + unsigned int __user *supported_mask;
> + int rv = 0;
> +
> + supported_mask = (unsigned int *)arg;
> +
> + if (put_user(efi.runtime_supported_mask, supported_mask))
> + rv = -EFAULT;
> +
> + return rv;
> +}
> +
> static long efi_test_ioctl(struct file *file, unsigned int cmd,
> unsigned long arg)
> {
> @@ -699,6 +712,9 @@ static long efi_test_ioctl(struct file *file, unsigned
> int cmd,
>
> case EFI_RUNTIME_RESET_SYSTEM:
> return efi_runtime_reset_system(arg);
> +
> + case EFI_RUNTIME_GET_SUPPORTED_MASK:
> + return efi_runtime_get_supported_mask(arg);
> }
>
> return -ENOTTY;
> diff --git a/drivers/firmware/efi/test/efi_test.h
> b/drivers/firmware/efi/test/efi_test.h
> index f2446aa1c2e3..117349e57993 100644
> --- a/drivers/firmware/efi/test/efi_test.h
> +++ b/drivers/firmware/efi/test/efi_test.h
> @@ -118,4 +118,7 @@ struct efi_resetsystem {
> #define EFI_RUNTIME_RESET_SYSTEM \
> _IOW('p', 0x0B, struct efi_resetsystem)
>
> +#define EFI_RUNTIME_GET_SUPPORTED_MASK \
> + _IOR('p', 0x0C, unsigned int)
> +
> #endif /* _DRIVERS_FIRMWARE_EFI_TEST_H_ */
> --
> 2.29.2
>
Looks good to me. Thanks Heinrich.
The EFI driver needs to be also updated in the linux kernel - has that
fix been submitted or do you require the fwts team to do that?
Colin
Re: nohz: Update tick instead of restarting tick in tick_nohz_idle_exit()
On 2020/11/27 20:15, Frederic Weisbecker wrote: > On Mon, Nov 23, 2020 at 09:22:08PM +0800, Yunfeng Ye wrote: >> In realtime scenarios, the "nohz_full" parameter is configured. Tick >> interference is not expected when there is only one realtime thread. >> But when the idle thread is switched to the realtime thread, the tick >> timer is restarted always. >> >> So on the nohz full mode, it is unnecessary to restart the tick timer >> when there is only one realtime thread. Adding can_stop_full_tick() >> before restarting the tick, if it return true, keep tick stopped. >> >> Signed-off-by: Yunfeng Ye > > We can indeed stop the tick and avoid it to be re-armed needlessly at this > point. > > I'm taking your patch, I may just edit it a little and resend it. > Ok, thanks. > Thanks! > . >
Re: [PATCH] mm: fix some spelling mistakes in comments
On Fri, Nov 27, 2020 at 6:50 AM Haitao Shi wrote: > > Fix some spelling mistakes in comments: > udpate ==> update > succesful ==> successful > exmaple ==> example > unneccessary ==> unnecessary > stoping ==> stopping > uknown ==> unknown > > Signed-off-by: Haitao Shi Reviewed-by: Souptick Joarder > --- > mm/filemap.c | 2 +- > mm/huge_memory.c | 2 +- > mm/khugepaged.c | 2 +- > mm/memblock.c| 2 +- > mm/migrate.c | 2 +- > mm/page_ext.c| 2 +- > 6 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/mm/filemap.c b/mm/filemap.c > index 3ebbe64..8826c48 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -1359,7 +1359,7 @@ static int __wait_on_page_locked_async(struct page > *page, > else > ret = PageLocked(page); > /* > -* If we were succesful now, we know we're still on the > +* If we were successful now, we know we're still on the > * waitqueue as we're still under the lock. This means it's > * safe to remove and return success, we know the callback > * isn't going to trigger. > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index ec2bb93..0fea0c2 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2356,7 +2356,7 @@ static void __split_huge_page_tail(struct page *head, > int tail, > * Clone page flags before unfreezing refcount. > * > * After successful get_page_unless_zero() might follow flags change, > -* for exmaple lock_page() which set PG_waiters. > +* for example lock_page() which set PG_waiters. > */ > page_tail->flags &= ~PAGE_FLAGS_CHECK_AT_PREP; > page_tail->flags |= (head->flags & > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index 4e3dff1..d6f7ede 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -1273,7 +1273,7 @@ static int khugepaged_scan_pmd(struct mm_struct *mm, > * PTEs are armed with uffd write protection. > * Here we can also mark the new huge pmd as > * write protected if any of the small ones is > -* marked but that could bring uknown > +* marked but that could bring unknown > * userfault messages that falls outside of > * the registered range. So, just be simple. > */ > diff --git a/mm/memblock.c b/mm/memblock.c > index b68ee86..086662a 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -871,7 +871,7 @@ int __init_memblock memblock_physmem_add(phys_addr_t > base, phys_addr_t size) > * @base: base address of the region > * @size: size of the region > * @set: set or clear the flag > - * @flag: the flag to udpate > + * @flag: the flag to update > * > * This function isolates region [@base, @base + @size), and sets/clears flag > * > diff --git a/mm/migrate.c b/mm/migrate.c > index 5795cb8..8a3580c 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -2548,7 +2548,7 @@ static bool migrate_vma_check_page(struct page *page) > * will bump the page reference count. Sadly there is no way > to > * differentiate a regular pin from migration wait. Hence to > * avoid 2 racing thread trying to migrate back to CPU to > enter > -* infinite loop (one stoping migration because the other is > +* infinite loop (one stopping migration because the other is > * waiting on pte migration entry). We always return true > here. > * > * FIXME proper solution is to rework migration_entry_wait() > so > diff --git a/mm/page_ext.c b/mm/page_ext.c > index a3616f7..cf931eb 100644 > --- a/mm/page_ext.c > +++ b/mm/page_ext.c > @@ -34,7 +34,7 @@ > * > * The need callback is used to decide whether extended memory allocation is > * needed or not. Sometimes users want to deactivate some features in this > - * boot and extra memory would be unneccessary. In this case, to avoid > + * boot and extra memory would be unnecessary. In this case, to avoid > * allocating huge chunk of memory, each clients represent their need of > * extra memory through the need callback. If one of the need callbacks > * returns true, it means that someone needs extra memory so that > -- > 2.10.1 > >
Re: [PATCH v8] Add MediaTek MT6779 devapc driver
On 15/10/2020 05:20, Neal Liu wrote: These patch series introduce a MediaTek MT6779 devapc driver. MediaTek bus fabric provides TrustZone security support and data protection to prevent slaves from being accessed by unexpected masters. The security violation is logged and sent to the processor for further analysis or countermeasures. Any occurrence of security violation would raise an interrupt, and it will be handled by mtk-devapc driver. The violation information is printed in order to find the murderer. Now pushed to v5.10-next/soc Thanks a lot! changes since v7: - fix VIO_MOD_TO_REG_IND calculation wrong problem. - revise parameter type of ISR. changes since v6: - remove unnecessary mask/unmask module irq during ISR. changes since v5: - remove redundant write reg operation. - use static variable of vio_dbgs instead. - add stop_devapc() if driver is removed. changes since v4: - refactor data structure. - merge two simple functions into one. - refactor register setting to prevent too many function call overhead. changes since v3: - revise violation handling flow to make it more easily to understand hardware behavior. - add more comments to understand how hardware works. changes since v2: - pass platform info through DT data. - remove unnecessary function. - remove slave_type because it always equals to 1 in current support SoC. - use vio_idx_num instread of list all devices' index. - add more comments to describe hardware behavior. changes since v1: - move SoC specific part to DT data. - remove unnecessary boundary check. - remove unnecessary data type declaration. - use read_poll_timeout() instread of for loop polling. - revise coding style elegantly. *** BLURB HERE *** Neal Liu (2): dt-bindings: devapc: add bindings for mtk-devapc soc: mediatek: add mt6779 devapc driver .../bindings/soc/mediatek/devapc.yaml | 58 drivers/soc/mediatek/Kconfig | 9 + drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mtk-devapc.c | 308 ++ 4 files changed, 376 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/mediatek/devapc.yaml create mode 100644 drivers/soc/mediatek/mtk-devapc.c
drivers/staging/media/rkvdec/rkvdec.c:967:34: warning: unused variable 'of_rkvdec_match'
Hi Boris,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 99c710c46dfc413b9c8a1a40b463ae1eaca539e5
commit: cd33c830448baf7b1e94da72eca069e3e1d050c9 media: rkvdec: Add the rkvdec
driver
date: 7 months ago
config: x86_64-randconfig-r024-20201128 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
f095ac11a9550530a4a54298debb8b04b36422be)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cd33c830448baf7b1e94da72eca069e3e1d050c9
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout cd33c830448baf7b1e94da72eca069e3e1d050c9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/staging/media/rkvdec/rkvdec.c:967:34: warning: unused variable
>> 'of_rkvdec_match' [-Wunused-const-variable]
static const struct of_device_id of_rkvdec_match[] = {
^
1 warning generated.
vim +/of_rkvdec_match +967 drivers/staging/media/rkvdec/rkvdec.c
966
> 967 static const struct of_device_id of_rkvdec_match[] = {
968 { .compatible = "rockchip,rk3399-vdec" },
969 { /* sentinel */ }
970 };
971 MODULE_DEVICE_TABLE(of, of_rkvdec_match);
972
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v2 net-next 3/3] nfc: s3fwrn5: extract the common phy blocks
On Fri, 27 Nov 2020 20:22:18 +0900 bongsu.je...@gmail.com wrote: > From: Bongsu Jeon > > Extract the common phy blocks to reuse it. > The UART module will use the common blocks. > > Signed-off-by: Bongsu Jeon > --- > Changes in v2: > - remove the common function's definition in common header file. > - make the common phy_common.c file to define the common function. > - wrap the lines. > - change the Header guard. > - remove the unused common function. You need to repost the entire series. Please wait around 8 hours and rebase on top of net-next. At that point Krzysztof's fix which you were including as patch 1 should already be in net-next, so you should be able to post just the latter two patches.
Re: [GIT PULL] SCSI fixes for 5.10-rc5
The pull request you sent on Fri, 27 Nov 2020 13:56:30 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/80e1e1761d1a9eefda4d1545f8b6c0a2e46d4e3f Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Networking
Hello: This pull request was applied to netdev/net.git (refs/heads/master): On Fri, 27 Nov 2020 12:04:28 -0800 you wrote: > The following changes since commit 4d02da974ea85a62074efedf354e82778f910d82: > > Merge tag 'net-5.10-rc5' of > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2020-11-19 13:33:16 > -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git > tags/net-5.10-rc6 > > [...] Here is the summary with links: - [GIT,PULL] Networking https://git.kernel.org/netdev/net/c/79c0c1f0389d You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH 1/4] soc / drm: mediatek: Move DDP component defines into mtk-mmsys.h
On 06/10/2020 21:33, Enric Balletbo i Serra wrote:
From: Yongqiang Niu
MMSYS is the driver which controls the routing of these DDP components,
so the definition of the mtk_ddp_comp_id enum should be placed in mtk-mmsys.h
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
Signed-off-by: Enric Balletbo i Serra
---
This patch was previously part of another series, but has no
dependencies and can be applied independently. As the latest version
sent is from two months ago, I resent this patch because the next patches
of this series depends on it to apply cleanly.
Applied to v5.10-next/soc
Thanks
[1] https://patchwork.kernel.org/patch/11706243
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 34 +
drivers/soc/mediatek/mtk-mmsys.c| 4 +--
include/linux/soc/mediatek/mtk-mmsys.h | 33
3 files changed, 35 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index debe36395fe7..161201fe5179 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -7,6 +7,7 @@
#define MTK_DRM_DDP_COMP_H
#include
+#include
struct device;
struct device_node;
@@ -35,39 +36,6 @@ enum mtk_ddp_comp_type {
MTK_DDP_COMP_TYPE_MAX,
};
-enum mtk_ddp_comp_id {
- DDP_COMPONENT_AAL0,
- DDP_COMPONENT_AAL1,
- DDP_COMPONENT_BLS,
- DDP_COMPONENT_CCORR,
- DDP_COMPONENT_COLOR0,
- DDP_COMPONENT_COLOR1,
- DDP_COMPONENT_DITHER,
- DDP_COMPONENT_DPI0,
- DDP_COMPONENT_DPI1,
- DDP_COMPONENT_DSI0,
- DDP_COMPONENT_DSI1,
- DDP_COMPONENT_DSI2,
- DDP_COMPONENT_DSI3,
- DDP_COMPONENT_GAMMA,
- DDP_COMPONENT_OD0,
- DDP_COMPONENT_OD1,
- DDP_COMPONENT_OVL0,
- DDP_COMPONENT_OVL_2L0,
- DDP_COMPONENT_OVL_2L1,
- DDP_COMPONENT_OVL1,
- DDP_COMPONENT_PWM0,
- DDP_COMPONENT_PWM1,
- DDP_COMPONENT_PWM2,
- DDP_COMPONENT_RDMA0,
- DDP_COMPONENT_RDMA1,
- DDP_COMPONENT_RDMA2,
- DDP_COMPONENT_UFOE,
- DDP_COMPONENT_WDMA0,
- DDP_COMPONENT_WDMA1,
- DDP_COMPONENT_ID_MAX,
-};
-
struct mtk_ddp_comp;
struct cmdq_pkt;
struct mtk_ddp_comp_funcs {
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index a55f25511173..36ad66bb221b 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -5,13 +5,11 @@
*/
#include
+#include
#include
#include
#include
-#include "../../gpu/drm/mediatek/mtk_drm_ddp.h"
-#include "../../gpu/drm/mediatek/mtk_drm_ddp_comp.h"
-
#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040
#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044
#define DISP_REG_CONFIG_DISP_OD_MOUT_EN 0x048
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
b/include/linux/soc/mediatek/mtk-mmsys.h
index 7bab5d9a3d31..2228bf6133da 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -9,6 +9,39 @@
enum mtk_ddp_comp_id;
struct device;
+enum mtk_ddp_comp_id {
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_AAL1,
+ DDP_COMPONENT_BLS,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_COLOR1,
+ DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_DPI0,
+ DDP_COMPONENT_DPI1,
+ DDP_COMPONENT_DSI0,
+ DDP_COMPONENT_DSI1,
+ DDP_COMPONENT_DSI2,
+ DDP_COMPONENT_DSI3,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_OD0,
+ DDP_COMPONENT_OD1,
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_OVL_2L0,
+ DDP_COMPONENT_OVL_2L1,
+ DDP_COMPONENT_OVL1,
+ DDP_COMPONENT_PWM0,
+ DDP_COMPONENT_PWM1,
+ DDP_COMPONENT_PWM2,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_RDMA1,
+ DDP_COMPONENT_RDMA2,
+ DDP_COMPONENT_UFOE,
+ DDP_COMPONENT_WDMA0,
+ DDP_COMPONENT_WDMA1,
+ DDP_COMPONENT_ID_MAX,
+};
+
void mtk_mmsys_ddp_connect(struct device *dev,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next);
[PATCH] subpage_prot.2: SYNOPSIS: Fix return type: s/long/int/
The Linux kernel uses 'int' instead of 'long' for the return type. As glibc provides no wrapper, use the same type the kernel uses. .. $ grep -n wrapper man-pages/man2/subpage_prot.2 40:There is no glibc wrapper for this system call; see NOTES. 99:Glibc does not provide a wrapper for this system call; call it using $ grep -rn SYSCALL_DEFINE.*subpage_prot linux/; linux/arch/powerpc/mm/book3s64/subpage_prot.c:190: SYSCALL_DEFINE3(subpage_prot, unsigned long, addr, $ sed -n /SYSCALL.*subpage_prot/,/^}/p \ linux/arch/powerpc/mm/book3s64/subpage_prot.c \ |grep return; return -ENOENT; return -EINVAL; return -EINVAL; return 0; return -EFAULT; return -EFAULT; return err; $ sed -n /SYSCALL.*subpage_prot/,/^}/p \ linux/arch/powerpc/mm/book3s64/subpage_prot.c \ |grep '\'; int err; err = -ENOMEM; err = -ENOMEM; err = 0; return err; Signed-off-by: Alejandro Colomar --- man2/subpage_prot.2 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man2/subpage_prot.2 b/man2/subpage_prot.2 index b38ba718f..d6f016665 100644 --- a/man2/subpage_prot.2 +++ b/man2/subpage_prot.2 @@ -32,7 +32,7 @@ subpage_prot \- define a subpage protection for an address range .SH SYNOPSIS .nf -.BI "long subpage_prot(unsigned long " addr ", unsigned long " len , +.BI "int subpage_prot(unsigned long " addr ", unsigned long " len , .BI " uint32_t *" map ); .fi .PP -- 2.29.2
Re: [PATCH 2/4] soc: mediatek: mmsys: Use devm_platform_ioremap_resource()
On 06/10/2020 21:33, Enric Balletbo i Serra wrote:
For the common platform_get_resource()+devm_platform_ioremap() combination,
there is a helper, so use it and make the code a bit more compact.
Signed-off-by: Enric Balletbo i Serra
Applied to v5.10-next/soc
Thanks!
---
drivers/soc/mediatek/mtk-mmsys.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-mmsys.c b/drivers/soc/mediatek/mtk-mmsys.c
index 36ad66bb221b..18f93979e14a 100644
--- a/drivers/soc/mediatek/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mtk-mmsys.c
@@ -306,15 +306,12 @@ static int mtk_mmsys_probe(struct platform_device *pdev)
struct platform_device *clks;
struct platform_device *drm;
void __iomem *config_regs;
- struct resource *mem;
int ret;
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- config_regs = devm_ioremap_resource(dev, mem);
+ config_regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(config_regs)) {
ret = PTR_ERR(config_regs);
- dev_err(dev, "Failed to ioremap mmsys-config resource: %d\n",
- ret);
+ dev_err(dev, "Failed to ioremap mmsys registers: %d\n", ret);
return ret;
}
Re: [GIT PULL] asm-generic: add correct MAX_POSSIBLE_PHYSMEM_BITS setting
The pull request you sent on Fri, 27 Nov 2020 21:55:52 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git > tags/asm-generic-fixes-5.10-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/c84e1efae022071a4fcf9f1899bf71777c49943a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Networking
The pull request you sent on Fri, 27 Nov 2020 12:04:28 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-5.10-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/79c0c1f0389db60f3c83ec91585a39d16e036f21 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [git pull] drm fixes for 5.10-rc6
The pull request you sent on Fri, 27 Nov 2020 18:37:15 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-11-27-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/6910b676898934c2abe9f3ff3d60f4d4bc8afda8 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] SPI fixes for v5.10-rc5
The pull request you sent on Fri, 27 Nov 2020 13:48:29 +: > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git > tags/spi-fix-v5.10-rc5 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/87c301ca911a3bee68900ee475fe536eebd9bc41 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL for v5.10-rc6] vidtv driver fixes
The pull request you sent on Fri, 27 Nov 2020 13:41:00 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > tags/media/v5.10-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f594139d68ccdd64fe9c546b17189b298fa7ecd3 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] mtd: Fixes for v5.10-rc6
The pull request you sent on Fri, 27 Nov 2020 19:38:03 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git > tags/mtd/fixes-for-5.10-rc6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/76dc2bfc2e1b40573cd33eb1c2027ef6cb7fed6c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.10-4 tag
The pull request you sent on Fri, 27 Nov 2020 23:45:35 +1100: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.10-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/95e1c7b1dd4a91451040ff0f41c5b5173503a38e Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] net: cisco: remove trailing semicolon in macro definition
Hi Tom, On 27/11/2020 17:58, t...@redhat.com wrote: > From: Tom Rix > > The macro use will already have a semicolon. > > Signed-off-by: Tom Rix Seems to be the only occurrence in this file. Reviewed-by: Kieran Bingham > --- > drivers/net/wireless/cisco/airo.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/cisco/airo.c > b/drivers/net/wireless/cisco/airo.c > index 74acf9af2adb..ba62bb2995d9 100644 > --- a/drivers/net/wireless/cisco/airo.c > +++ b/drivers/net/wireless/cisco/airo.c > @@ -5785,7 +5785,7 @@ static int airo_get_quality (StatusRid *status_rid, > CapabilityRid *cap_rid) > } > > #define airo_get_max_quality(cap_rid) (memcmp((cap_rid)->prodName, "350", 3) > ? 0x20 : 0xa0) > -#define airo_get_avg_quality(cap_rid) (memcmp((cap_rid)->prodName, "350", 3) > ? 0x10 : 0x50); > +#define airo_get_avg_quality(cap_rid) (memcmp((cap_rid)->prodName, "350", 3) > ? 0x10 : 0x50) > > /*--*/ > /* >
Re: [PATCH] NFC:Fix Warning: Comparison to bool
On Thu, 26 Nov 2020 15:15:42 +0800 Runzhe Wang wrote:
> This patch uses the shdlc->rnr variable as a judgment condition of
> statement, rather than compares with bool.
>
> Signed-off-by: Runzhe Wang
> Reported-by: Abaci
"Fix Warning" sounds like you're addressing a real compiler warning,
please use a more suitable subject if the warning in question is from
your own tool. Like "nfc: refactor unnecessary comparison to bool".
> diff --git a/net/nfc/hci/llc_shdlc.c b/net/nfc/hci/llc_shdlc.c
> index 0eb4ddc..f178a42 100644
> --- a/net/nfc/hci/llc_shdlc.c
> +++ b/net/nfc/hci/llc_shdlc.c
> @@ -319,7 +319,7 @@ static void llc_shdlc_rcv_s_frame(struct llc_shdlc *shdlc,
> switch (s_frame_type) {
> case S_FRAME_RR:
> llc_shdlc_rcv_ack(shdlc, nr);
> - if (shdlc->rnr == true) { /* see SHDLC 10.7.7 */
> + if (shdlc->rnr) { /* see SHDLC 10.7.7 */
rnr is a bool, this is perfectly legal, there are also comparisons to
false which you don't fix, and nobody has touched this driver in 8
years so polishing this code is not exactly worth the effort.
I'm not applying this patch, sorry.
> shdlc->rnr = false;
> if (shdlc->send_q.qlen == 0) {
> skb = llc_shdlc_alloc_skb(shdlc, 0);
Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3
On Fri, Nov 27, 2020 at 12:51 PM Arnd Bergmann wrote: > > - Some DT patches for the Rockchip RK3399 platform, >in particular fixing the MMC device ordering that >recently became nondeterministic with async probe. Uhhuh. I didn't realize this MMC breakage happened. That's just an MMC bug. Other subsystems have been able to do async probing without making device ordering be random. So this really smells wrong, and I just never realized. Added Douglas Anderson to the cc - the whole PROBE_PREFER_ASYNCHRONOUS behavior appears broken. You basically should do the device numbering synchronously (or better yet - asynchronously, but single-threaded for the subsystem), and then asynchronously probe the actual device details after you've numbered them reliably. This is not something new - we do this for pretty much all the other block devices, and MMC is just doing things wrong. See SCSI probing for the traditional horrible cases (where just spinning up a disk could take tens of seconds). "Slow probing" is not an excuse of "random ordering". Behaving randomly is simply not acceptable. Linus
[PATCH v3 1/2] media: i2c: Add driver for the Sony Exmor-RS IMX300 camera sensor
From: AngeloGioacchino Del Regno This is a custom multi-aspect 25MegaPixels sensor from Sony, found in many Sony Xperia smartphones from various eras. The camera assembly for this sensor usually (at least in Xperia phones) has a lens that does not cover the entire sensor area, which means that the real corners are blind and that, in many lighting conditions, some more pixels in the corners are very getting obscured (as no decent amount of light can get in)... so, the maximum resolution that can produce a good image is: - In 4:3 aspect ratio, 5520x4160 (23.0MP) - In 16:9 aspect ratio, 5984x3392 (20.3MP). This sensor supports high frame rates (>=60FPS) when in binning mode and both RAW8 and RAW10 output modes. In this version of the driver, support has been provided for the following resolutions: W x H SZ MAX_FPS BINNING - 5520x4160 23.0MP 23 No - 5984x3392 20.3MP 26 No - 2992x1696 3.8MP 60 Yes - 1424x800 1.2MP 120 Yes Note 1: The "standard" camera assy for IMX300 also contains an actuator (to focus the image), but this driver only manages the actual image sensor. Note 2: The command tables for this sensor were reverse engineered from a downstream "userspace driver" that has been released in various versions on various Xperia smartphones. Register layout seems to be only vaguely similar to IMX219, which has a public datasheet from where some names for the figured out registers were taken and added to the driver: these names are probably not the right ones, but they surely represent the intended thing. Signed-off-by: AngeloGioacchino Del Regno --- drivers/media/i2c/Kconfig | 13 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/imx300.c | 3081 3 files changed, 3095 insertions(+) create mode 100644 drivers/media/i2c/imx300.c diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 878f66ef2719..032f45dfed16 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -801,6 +801,19 @@ config VIDEO_IMX290 To compile this driver as a module, choose M here: the module will be called imx290. +config VIDEO_IMX300 + tristate "Sony IMX300 Exmor RS sensor support" + depends on I2C && VIDEO_V4L2 + select MEDIA_CONTROLLER + select VIDEO_V4L2_SUBDEV_API + select V4L2_FWNODE + help + This is a Video4Linux2 sensor driver for the Sony + IMX300 Exmor RS multi-aspect sensor. + + To compile this driver as a module, choose M here: the + module will be called imx300. + config VIDEO_IMX319 tristate "Sony IMX319 sensor support" depends on I2C && VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index f0a77473979d..8a3e003dea45 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -117,6 +117,7 @@ obj-$(CONFIG_VIDEO_IMX219) += imx219.o obj-$(CONFIG_VIDEO_IMX258) += imx258.o obj-$(CONFIG_VIDEO_IMX274) += imx274.o obj-$(CONFIG_VIDEO_IMX290) += imx290.o +obj-$(CONFIG_VIDEO_IMX300) += imx300.o obj-$(CONFIG_VIDEO_IMX319) += imx319.o obj-$(CONFIG_VIDEO_IMX355) += imx355.o obj-$(CONFIG_VIDEO_MAX9286)+= max9286.o diff --git a/drivers/media/i2c/imx300.c b/drivers/media/i2c/imx300.c new file mode 100644 index ..ddf0540778ae --- /dev/null +++ b/drivers/media/i2c/imx300.c @@ -0,0 +1,3081 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * A V4L2 driver for Sony IMX300 Exmor RS multi-aspect image sensors. + * Copyright (C) 2020, AngeloGioacchino Del Regno + * + * Based on Sony imx219 camera driver + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define IMX300_REG_VALUE_08BIT 1 +#define IMX300_REG_VALUE_16BIT 2 + +/* + * Supported external clock frequency is from (around) 6 to 26MHz + * but there is no information about how to configure this sensor + * for anything else but 24MHz, since there is no datasheet... + */ +#define IMX300_XCLK_FREQ_24M 2400 + +/* Delay after XCLK/RESET during power up for sensor boot/stabilization */ +#define IMX300_XCLK_STABLE_DELAY_US1 +#define IMX300_XCLK_DELAY_RANGE_US 1000 +#define IMX300_XCLR_MIN_DELAY_US 25000 +#define IMX300_XCLR_DELAY_RANGE_US 1000 + +/* + * Pixel rates: max resolution + max FPS uses high bw; low resolution + * can use low bw in order to save power and limit sensor heating + */ +#define IMX300_HIGH_BW_PIXEL_RATE 62400 +#define IMX300_LOW_BW_PIXEL_RATE 38400 +#define IMX300_HIGH_BW_LINK_FREQ 78000 +#define IMX300_LOW_BW_LINK_FREQ48000 + +/* + * About the Chip ID: + * + * IMX300 seems to be sort of flawed... scanning the registers reveals + * that there's no reg having the expected 0x300 ChipID, like literally + * all of the other Sony IMX sensors. + * There seem
Re: [PATCH v2 3/5] memory: renesas-rpc-if: Fix a reference leak in rpcif_probe()
On Thu 2020-11-26 19:11:44, Lad Prabhakar wrote:
> Release the node reference by calling of_node_put(flash) in the probe.
>
> Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
> Reported-by: Pavel Machek
> Signed-off-by: Lad Prabhakar
> Cc: sta...@vger.kernel.org
> Reviewed-by: Sergei Shtylyov
Reviewed-by: Pavel Machek (CIP)<
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
signature.asc
Description: PGP signature
Re: [PATCH] MAINTAINERS add D: tag for subsystem commit prefix
On Fri, Nov 27, 2020 at 10:51 PM wrote: > > From > RFC MAINTAINERS tag for cleanup robot > https://lkml.org/lkml/2020/11/21/190 Please use lore.kernel.org for links. > The prefix used by subsystems in their commit log is arbitrary. > To elimitate the time and effort to manually find a reasonable Typo in "eliminate". > prefix, store the preferred prefix in the MAINTAINERS file. > > Populate with reasonable prefixes using this algorithm. > What did the maintainers use in their commits? > If there were no maintainers commits then what did everyone > else use in their commits. Why is this in the form of a question? I am not sure I understand -- is it rhetorical? > The results were manually reviewed and about 25% were rejected. What do you mean by rejected? > Add 'D' tag to checkpatch.pl > > Use 'D' tag by adding --subsystem_commit_prefix option > get_maintainer.pl This looks also out of place, as if it was squashed from other commits. I would suggest trying to reword the message in prose, explaining the rationale and why it was done like this. > AUXILIARY DISPLAY DRIVERS Missing entry for auxdisplay. Cheers, Miguel
Re: [PATCH v2 4/5] memory: renesas-rpc-if: Make rpcif_enable/disable_rpm() as static inline
On Thu 2020-11-26 19:11:45, Lad Prabhakar wrote: > Define rpcif_enable_rpm() and rpcif_disable_rpm() as static > inline in the header instead of exporting them. > > Suggested-by: Pavel Machek > Signed-off-by: Lad Prabhakar Reviewed-by: Pavel Machek (CIP)< -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany signature.asc Description: PGP signature
Re: [PATCH v2] soc / drm: mediatek: cmdq: Remove timeout handler in helper function
On 27/11/2020 15:42, Chun-Kuang Hu wrote:
Hi, Matthias:
Matthias Brugger 於 2020年11月27日 週五 下午8:40寫道：
Hi Chun-Kuang,
On 20/11/2020 00:46, Chun-Kuang Hu wrote:
Hi, Matthias:
I've provided the example for why of this patch. How do you think
about this patch?
Patch looks good to me. If you want to take it through your tree you can add my
Acked-by: Matthias Brugger
Beware that you might need a stable tag for it, so that I can merge it into my
soc branch, in case there are more changes to cmdq-helper.
I would like this patch to go into your tree because this patch mainly
modify cmdq helper. Even though this patch is one of the series
"Mediatek DRM driver detect CMDQ execution timeout by vblank IRQ" [1],
I would wait for this patch get into mainline then send the next
patch.
Applied to v5.10-next/soc
Thanks!
Regards,
Chun-Kuang.
Regards,
Matthias
Regards,
Chun-Kuang.
Chun-Kuang Hu 於 2020年11月2日 週一 上午8:04寫道：
For each client driver, its timeout handler need to dump hardware register
or its state machine information, and their way to detect timeout are
also different, so remove timeout handler in helper function and
let client driver implement its own timeout handler.
Signed-off-by: Chun-Kuang Hu
---
v1 is one patch in series "Mediatek DRM driver detect CMDQ execution
timeout by vblank IRQ", but according to Jassi's suggestion [1], send
each patch in different series.
[2] is an example that different client has different way to calculate
timeout. Some client driver care about each packet's execution time, but
some client driver care about the total execution time for all packets.
[1]
https://patchwork.kernel.org/project/linux-mediatek/cover/20200927230422.11610-1-chunkuang...@kernel.org/
[2]
https://patchwork.kernel.org/project/linux-mediatek/patch/20201022094152.17662-1-houlong@mediatek.com/
Changes in v2:
1. Rebase onto Linux 5.10-rc1
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +-
drivers/soc/mediatek/mtk-cmdq-helper.c | 41 +
include/linux/soc/mediatek/mtk-cmdq.h | 10 +-
3 files changed, 3 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index ac038572164d..4be5d1fccf2e 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -824,8 +824,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
#if IS_REACHABLE(CONFIG_MTK_CMDQ)
mtk_crtc->cmdq_client =
cmdq_mbox_create(mtk_crtc->mmsys_dev,
-drm_crtc_index(&mtk_crtc->base),
-2000);
+drm_crtc_index(&mtk_crtc->base));
if (IS_ERR(mtk_crtc->cmdq_client)) {
dev_dbg(dev, "mtk_crtc %d failed to create mailbox client, writing
register by CPU now\n",
drm_crtc_index(&mtk_crtc->base));
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 505651b0d715..280d3bd9f675 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -70,14 +70,7 @@ int cmdq_dev_get_client_reg(struct device *dev,
}
EXPORT_SYMBOL(cmdq_dev_get_client_reg);
-static void cmdq_client_timeout(struct timer_list *t)
-{
- struct cmdq_client *client = from_timer(client, t, timer);
-
- dev_err(client->client.dev, "cmdq timeout!\n");
-}
-
-struct cmdq_client *cmdq_mbox_create(struct device *dev, int index, u32
timeout)
+struct cmdq_client *cmdq_mbox_create(struct device *dev, int index)
{
struct cmdq_client *client;
@@ -85,12 +78,6 @@ struct cmdq_client *cmdq_mbox_create(struct device *dev, int
index, u32 timeout)
if (!client)
return (struct cmdq_client *)-ENOMEM;
- client->timeout_ms = timeout;
- if (timeout != CMDQ_NO_TIMEOUT) {
- spin_lock_init(&client->lock);
- timer_setup(&client->timer, cmdq_client_timeout, 0);
- }
- client->pkt_cnt = 0;
client->client.dev = dev;
client->client.tx_block = false;
client->client.knows_txdone = true;
@@ -112,11 +99,6 @@ EXPORT_SYMBOL(cmdq_mbox_create);
void cmdq_mbox_destroy(struct cmdq_client *client)
{
- if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
- spin_lock(&client->lock);
- del_timer_sync(&client->timer);
- spin_unlock(&client->lock);
- }
mbox_free_channel(client->chan);
kfree(client);
}
@@ -449,18 +431,6 @@ static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data
data)
struct cmdq_task_cb *cb = &pkt->cb;
struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
- if (client->timeout_ms != CMDQ_NO_TIMEOUT) {
- unsigned long flags = 0;
-
- spin_lock_irqsave(&client->lock, flags);
-
Re: [PATCH v2 1/5] memory: renesas-rpc-if: Return correct value to the caller of rpcif_manual_xfer()
On Thu 2020-11-26 19:11:42, Lad Prabhakar wrote:
> In the error path of rpcif_manual_xfer() the value of ret is overwritten
> by value returned by reset_control_reset() function and thus returning
> incorrect value to the caller.
>
> This patch makes sure the correct value is returned to the caller of
> rpcif_manual_xfer() by dropping the overwrite of ret in error path.
> Also now we ignore the value returned by reset_control_reset() in the
> error path and instead print a error message when it fails.
>
> Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
> Reported-by: Pavel Machek
> Signed-off-by: Lad Prabhakar
> Cc: sta...@vger.kernel.org
> Reviewed-by: Sergei Shtylyov
Reviewed-by: Pavel Machek (CIP)
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
signature.asc
Description: PGP signature
Re: [RFC PATCH v0 00/19] x86/insn: Add an insn_decode() API
On Fri, Nov 27, 2020 at 09:45:39AM -0800, Andy Lutomirski wrote: > Is -22 (-EINVAL) the same error it returns if you pass in garbage? Define garbage. Yes, if you have a sequence of bytes which you can unambiguously determine to be - an invalid instruction in some of the tables - REX prefix with the wrong bits set - a byte says that some insn part like ModRM or SIB is following but the buffer falls short - ... other error condition then maybe you can say, yes, I'm looking at garbage and can error out right then and there. But you need to have enough bytes of information to determine that. For example (those are random bytes): 11ff <.asm_start>: 11ff: 95 xchg %eax,%ebp 1200: 14 60 adc$0x60,%al 1202: 77 74 ja 1278 <__libc_csu_init+0x28> 1204: 82 (bad) 1205: 67 dc 55 35 fcoml 0x35(%ebp) The 0x82 is usually in opcode group 1 but that opcode is invalid in 64-bit mode. So if this is a 64-bit executable, you know that that is an invalid insn. Another example: 18: a0 .byte 0xa0 19: 17 (bad) 1a: 27 (bad) 1b: ea (bad) 1c: 90 nop 1d: 90 nop 1e: 90 nop 1f: 90 nop 0xa0 is the opcode for MOV AL, moffset8 where moffset8 is an address-sized memory offset, which in 64-bit mode is 64-bit. But we have only 7 bytes after the 0xa0 thus we know that the buffer is truncated. If it had one byte more, it would be a valid insn: 18: a0 17 27 ea 90 90 90movabs 0x9090909090ea2717,%al 20: 90 90 I'm sure you get the idea: if you have enough unambiguous bits which tell you that this cannot be a valid insn, then you can return early from the decoder and signal that fact. I'm not sure that you can do that for all possible byte combinations and also I'm not sure that it won't ever happen that it per chance misinterprets garbage data as valid instructions. > How hard would it be to teach it to return a different error code when > the buffer is too small? Yap, see above. Unambiguous cases are clear but I don't know it would work in all cases. For example, let's say you give it a zeroed out buffer of 8 bytes which doesn't contain anything - you've just zeroed it out and haven't put any insns in there yet. But those are perfectly valid insns: 0: 00 00 add %al,(%rax) 2: 00 00 add %al,(%rax) 4: 00 00 add %al,(%rax) 6: 00 00 add %al,(%rax) So now you go about your merry way working with those although they're not real instructions which some tool generated. See what I mean? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
[PATCH v3 2/2] media: dt-bindings: media: i2c: Add IMX300 CMOS sensor binding
From: AngeloGioacchino Del Regno
Add YAML device tree binding for IMX300 CMOS image sensor, and
the relevant MAINTAINERS entries.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/media/i2c/sony,imx300.yaml | 112 ++
MAINTAINERS | 7 ++
2 files changed, 119 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
b/Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
new file mode 100644
index ..388297fcc358
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/sony,imx300.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sony 1/2.3-Inch 25Mpixel Stacked CMOS Digital Image Sensor
+
+maintainers:
+ - AngeloGioacchino Del Regno
+
+description: |-
+ The Sony IMX300 is a 1/2.3-inch Stacked CMOS (Exmor-RS) digital image
+ sensor with a pixel size of 1.08um and an active array size of
+ 5948H x 4140V. It is programmable through I2C interface at address 0x10.
+ Image data is sent through MIPI CSI-2, which is configured as either 2 or
+ 4 data lanes.
+
+properties:
+ compatible:
+const: sony,imx300
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ vdig-supply:
+description:
+ Digital I/O voltage supply, 1.15-1.20 volts
+
+ vana-supply:
+description:
+ Analog voltage supply, 2.2 volts
+
+ vddl-supply:
+description:
+ Digital core voltage supply, 1.8 volts
+
+ reset-gpios:
+description: |-
+ Reference to the GPIO connected to the xclr pin, if any.
+ Must be released (set high) after all supplies are applied.
+
+ # See ../video-interfaces.txt for more details
+ port:
+type: object
+properties:
+ endpoint:
+type: object
+
+properties:
+ data-lanes:
+description: |-
+ The driver only supports four-lane operation.
+items:
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+
+ clock-noncontinuous: true
+
+ link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+description:
+ Allowed data bus frequencies. The driver currently needs
+ to switch between 78000 and 48000 Hz in order to
+ guarantee functionality of all modes.
+
+required:
+ - data-lanes
+ - link-frequencies
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - vana-supply
+ - vdig-supply
+ - vddl-supply
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+imx300: sensor@10 {
+compatible = "sony,imx300";
+reg = <0x10>;
+clocks = <&imx300_xclk>;
+vana-supply = <&imx300_vana>; /* 2.2v */
+vdig-supply = <&imx300_vdig>; /* 1.2v */
+vddl-supply = <&imx300_vddl>; /* 1.8v */
+
+port {
+imx300_0: endpoint {
+remote-endpoint = <&csi1_ep>;
+data-lanes = <0 1 2 3>;
+clock-noncontinuous;
+link-frequencies = /bits/ 64 <78000 48000>;
+};
+};
+};
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index c66710dd7e0a..21ba41db0063 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16279,6 +16279,13 @@ T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/imx290.txt
F: drivers/media/i2c/imx290.c
+SONY IMX300 SENSOR DRIVER
+M: AngeloGioacchino Del Regno
+L: linux-me...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml
+F: drivers/media/i2c/imx300.c
+
SONY IMX319 SENSOR DRIVER
M: Bingbu Cao
L: linux-me...@vger.kernel.org
--
2.29.2
[PATCH v3 0/2] Add support for the Sony Exmor-RS IMX300 camera sensor
From: AngeloGioacchino Del Regno This patch series adds support for the IMX300 camera sensor, (one of the) first Exmor-RS Stacked CMOS sensor(s), with support for both of the supported aspect ratios (4:3 and 16:9). This driver came out from reverse engineering of so called "userspace drivers" from Sony Xperia smartphones. I tried to document all of my findings and giving a sense to the registers as much as possible, but that was only partially possible and resembles some names from the IMX219 public datasheet, even though the addresses are basically completely different. This camera sensor driver was tested with all the resolutions declared in it on two phones: Sony Xperia XA2 and XA2 Ultra, on a SDM630 SoC (camss patches for this SoC will come in a later series) and is working great. - Changes in v3: - Removed unneeded fallthrough statements - Fixed double mode initialization at probe time - Fixed typo in the dt-binding description (8->25MPixels) - Fixed dt-binding data-lanes description, added to required properties - Changes in v2: - Changed dt-binding name and fixed a misconception about lane operation (sensor supports 2/4-Lane, driver supports 4-Lane only) - Now using lowercase names for regulator supplies - Fixed redefinition of clock-noncontinuous property - Added informations about constraints on data bus frequencies - Fixed MAINTAINERS: removed git tree AngeloGioacchino Del Regno (2): media: i2c: Add driver for the Sony Exmor-RS IMX300 camera sensor media: dt-bindings: media: i2c: Add IMX300 CMOS sensor binding .../bindings/media/i2c/sony,imx300.yaml | 112 + MAINTAINERS |7 + drivers/media/i2c/Kconfig | 13 + drivers/media/i2c/Makefile|1 + drivers/media/i2c/imx300.c| 3081 + 5 files changed, 3214 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/sony,imx300.yaml create mode 100644 drivers/media/i2c/imx300.c -- 2.29.2
[tip:master] BUILD SUCCESS 9b6205dd6a78acc4476ae51f992ce854e1bff941
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: 9b6205dd6a78acc4476ae51f992ce854e1bff941 Merge branch 'core/entry' elapsed time: 728m configs tested: 95 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig sh rsk7264_defconfig xtensaxip_kc705_defconfig sh microdev_defconfig armrealview_defconfig mipsmaltaup_xpa_defconfig c6xevmc6472_defconfig powerpc mpc834x_itxgp_defconfig mips rm200_defconfig arm milbeaut_m10v_defconfig mips pistachio_defconfig arm lpc18xx_defconfig m68km5407c3_defconfig mips cu1000-neo_defconfig x86_64 alldefconfig sh defconfig ia64 gensparse_defconfig arm collie_defconfig m68k m5208evb_defconfig arm h3600_defconfig shedosk7760_defconfig powerpcklondike_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201127 i386 randconfig-a003-20201127 i386 randconfig-a002-20201127 i386 randconfig-a005-20201127 i386 randconfig-a001-20201127 i386 randconfig-a006-20201127 x86_64 randconfig-a015-20201127 x86_64 randconfig-a011-20201127 x86_64 randconfig-a014-20201127 x86_64 randconfig-a016-20201127 x86_64 randconfig-a012-20201127 x86_64 randconfig-a013-20201127 i386 randconfig-a012-20201127 i386 randconfig-a013-20201127 i386 randconfig-a011-20201127 i386 randconfig-a016-20201127 i386 randconfig-a014-20201127 i386 randconfig-a015-20201127 riscvnommu_k210_defconfig riscvallyesconfig riscvnommu_virt_defconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec clang tested configs: x86_64 randconfig-a006-20201127 x86_64 randconfig-a003-20201127 x86_64 randconfig-a004-20201127 x86_64 randconfig-a005-20201127 x86_64 randconfig-a002-20201127 x86_64 randconfig-a001-20201127 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v2 0/1] arm64: defconfig: Enable Librem 5 hardware
Hi! > This series enables components found on Purism's Librem 5 > that are available in mainline. > > - changes from v1 > - As per review comments from Krzysztof Kozlowski > > https://lore.kernel.org/linux-arm-kernel/cajkoxpdewistg+cmes_wes5oz2f1qeexsus6ihenuls9sax...@mail.gmail.com/ > - Squash config changes into a single commit > - Add touch controller > > Patches are on top of Shawn's imx/defconfig Thanks for bringing support for your hardware to the mainline. Can I ask phone-de...@vger.kernel.org to be cc-ed for phone-related changes? How complete is the support? In particular, what interface do you use to configure audio routing for the modem? Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
Re: [PATCH net-next 5/7] net: hns3: add more info to hns3_dbg_bd_info()
On Fri, 27 Nov 2020 16:47:20 +0800 Huazhong Tan wrote: > Since TX hardware checksum and RX completion checksum have been > supported now, so add related information in hns3_dbg_bd_info(). > > Signed-off-by: Huazhong Tan drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:266:22: warning: incorrect type in assignment (different base types) drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:266:22:expected restricted __sum16 [usertype] csum drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:266:22:got unsigned int drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:268:22: warning: invalid assignment: |= drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:268:22:left side has type restricted __sum16 drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c:268:22:right side has type unsigned int
[tip:sched/core] BUILD SUCCESS a787bdaff83a085288b6fc607afb4bb648da3cc9
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core branch HEAD: a787bdaff83a085288b6fc607afb4bb648da3cc9 Merge branch 'linus' into sched/core, to resolve semantic conflict elapsed time: 723m configs tested: 107 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig powerpc tqm8541_defconfig arm lubbock_defconfig ia64 gensparse_defconfig mips ath79_defconfig powerpc mpc834x_mds_defconfig powerpc mpc834x_itxgp_defconfig mips rm200_defconfig arm milbeaut_m10v_defconfig mips pistachio_defconfig arm lpc18xx_defconfig m68km5407c3_defconfig mips cu1000-neo_defconfig x86_64 alldefconfig nds32 defconfig riscvnommu_virt_defconfig powerpc ppc40x_defconfig armdove_defconfig arm jornada720_defconfig powerpc mpc837x_rdb_defconfig mips malta_kvm_defconfig mips jazz_defconfig c6x dsk6455_defconfig arm h5000_defconfig powerpc ppa8548_defconfig powerpc mpc8315_rdb_defconfig powerpc tqm8xx_defconfig mips ip27_defconfig powerpc64 defconfig arm ep93xx_defconfig mips ath25_defconfig microblaze mmu_defconfig m68k m5208evb_defconfig arm h3600_defconfig shedosk7760_defconfig powerpcklondike_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20201127 i386 randconfig-a003-20201127 i386 randconfig-a002-20201127 i386 randconfig-a005-20201127 i386 randconfig-a001-20201127 i386 randconfig-a006-20201127 x86_64 randconfig-a015-20201127 x86_64 randconfig-a011-20201127 x86_64 randconfig-a014-20201127 x86_64 randconfig-a016-20201127 x86_64 randconfig-a012-20201127 x86_64 randconfig-a013-20201127 i386 randconfig-a012-20201127 i386 randconfig-a013-20201127 i386 randconfig-a011-20201127 i386 randconfig-a016-20201127 i386 randconfig-a014-20201127 i386 randconfig-a015-20201127 riscvnommu_k210_defconfig riscvallyesconfig riscv allnoconfig riscv defconfig riscv rv32_defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-
Re: [PATCH] MAINTAINERS add D: tag for subsystem commit prefix
On Fri, 2020-11-27 at 13:43 -0800, t...@redhat.com wrote:
> From: Tom Rix
>
> From
> RFC MAINTAINERS tag for cleanup robot
> https://lkml.org/lkml/2020/11/21/190
I think this should be RFC.
It looks as as if it's only for subsystems through A
> The prefix used by subsystems in their commit log is arbitrary.
> To elimitate the time and effort to manually find a reasonable
> prefix, store the preferred prefix in the MAINTAINERS file.
>
> Populate with reasonable prefixes using this algorithm.
> What did the maintainers use in their commits?
> If there were no maintainers commits then what did everyone
> else use in their commits.
The algorithm used to produce these prefixes should also be published.
> The results were manually reviewed and about 25% were rejected.
Because this isn't necessarily the best option.
I think an exception mechanism would be better than a specific
mechanism added to various entries.
> # check MAINTAINERS entries for the right ordering too
> - my $preferred_order = 'MRLSWQBCPTFXNK';
> + my $preferred_order = 'MRLSWQBCPTFXNKD';
> if ($rawline =~ /^\+[A-Z]:/ &&
> $prevrawline =~ /^[\+ ][A-Z]:/) {
> $rawline =~ /^\+([A-Z]):\s*(.*)/;
I'd prefer to keep the file and keyword list last.
[PATCH] mailmap: add two more addresses of Uwe Kleine-König
This fixes attribution for the commits (among others)
- d4097456cd1d ("video/framebuffer: move the probe func into .devinit.text in
Blackfin LCD driver")
- 0312e024d6cd ("mfd: mc13xxx: Add support for mc34708")
Signed-off-by: Uwe Kleine-König
---
Hello Andrew,
there is no explicit maintainer for .mailmap, but most of the last few
patches went in through you, so I'm addressing you. If that's wrong,
please advise who to bother instead.
Thanks
Uwe
.mailmap | 2 ++
1 file changed, 2 insertions(+)
diff --git a/.mailmap b/.mailmap
index d9fb83d67055..225546cc8028 100644
--- a/.mailmap
+++ b/.mailmap
@@ -322,6 +322,8 @@ TripleX Chung
Tsuneo Yoshioka
Tycho Andersen
Uwe Kleine-König
+Uwe Kleine-König
+Uwe Kleine-König
Uwe Kleine-König
Uwe Kleine-König
Valdis Kletnieks
base-commit: 9223e74f9960778bd3edd39e15edd5532708b7fb
--
2.29.2
Re: [GIT PULL 2/2] Kconfig updates for v5.10-rc1
On Fri, Nov 27, 2020 at 1:53 PM Linus Torvalds wrote: > > 33.68% cc1plus So a third of the time is the _single_ invocation of cc1plus, which happens from scrips/gcc-plugin.sh doing that $HOSTCC -c -x c++ -std=gnu++98 - -fsyntax-only thing. Which is purely to verify that plugins work. Ugh. Emese - I'm talking to myself while I'm looking at why "make allmodconfig" is so unbearably slow. This is part of it. Linus
[GIT PULL] ARM: at91: DT for 5.11
Arnd, Olof, Here are the DT changes for 5.11 which contains non urgent fixes. The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux tags/at91-dt-5.11 for you to fetch changes up to e1062fa7292f1e3744db0a487c4ac0109e09b03d: ARM: dts: at91: sama5d3_xplained: add pincontrol for USB Host (2020-11-24 12:11:27 +0100) AT91 DT for 5.11: - fix USB host pinctrl - fix DT schema warnings Alexander Dahl (2): ARM: dts: at91: smartkiz: Reference led node directly ARM: dts: at91: Fix schema warnings for pwm-leds Bartosz Golaszewski (1): ARM: dts: at91: at91-sama5d27_som1: fix EEPROM compatible Cristian Birsan (3): ARM: dts: at91: sam9x60: add pincontrol for USB Host ARM: dts: at91: sama5d4_xplained: add pincontrol for USB Host ARM: dts: at91: sama5d3_xplained: add pincontrol for USB Host arch/arm/boot/dts/at91-kizbox.dts | 10 +- arch/arm/boot/dts/at91-kizbox2-common.dtsi| 8 arch/arm/boot/dts/at91-kizbox3-hs.dts | 16 arch/arm/boot/dts/at91-kizbox3_common.dtsi| 10 +- arch/arm/boot/dts/at91-kizboxmini-common.dtsi | 8 arch/arm/boot/dts/at91-sam9x60ek.dts | 9 + arch/arm/boot/dts/at91-sama5d27_som1.dtsi | 2 +- arch/arm/boot/dts/at91-sama5d3_xplained.dts | 7 +++ arch/arm/boot/dts/at91-sama5d4_xplained.dts | 7 +++ arch/arm/boot/dts/at91-smartkiz.dts | 6 ++ arch/arm/boot/dts/at91sam9m10g45ek.dts| 10 +- arch/arm/boot/dts/at91sam9rlek.dts| 10 +- 12 files changed, 62 insertions(+), 41 deletions(-) -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[RFC PATCH] bpf: bpf_atomic_alu_string[] can be static
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
disasm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/bpf/disasm.c b/kernel/bpf/disasm.c
index f33acffdeed05..737e95b049574 100644
--- a/kernel/bpf/disasm.c
+++ b/kernel/bpf/disasm.c
@@ -80,7 +80,7 @@ const char *const bpf_alu_string[16] = {
[BPF_END >> 4] = "endian",
};
-const char *const bpf_atomic_alu_string[16] = {
+static const char *const bpf_atomic_alu_string[16] = {
[BPF_ADD >> 4] = "add",
[BPF_SUB >> 4] = "sub",
};
