Re: [PATCH V7 4/6] kbuild: Add support to build overlays (%.dtbo)
On Fri, Feb 05, 2021 at 02:55:07PM +0530, Viresh Kumar wrote: > On 05-02-21, 10:02, Geert Uytterhoeven wrote: > > Hi Viresh, > > > > Thanks for your patch > > (which I only noticed because it appeared in dt-rh/for-next ;-) > > > > On Fri, Jan 29, 2021 at 8:31 AM Viresh Kumar > > wrote: > > > Add support for building DT overlays (%.dtbo). The overlay's source file > > > will have the usual extension, i.e. .dts, though the blob will have > > > > Why use .dts and not .dtso for overlays? > > Because you originally (until v5) had a single rule for building .dtb > > and .dtbo files? > > I am fine with doing that as well if Rob and David agree to it. Rob > did suggest that at one point but we didn't do much about it later on > for some reason. > > FWIW, this will also require a change in the DTC compiler. Not really. It would need a change to automatically recognize that extension, but you can easily work around that by explicitly giving the -I option to specify the input type. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: BUG: KASAN: use-after-free in snd_complete_urb+0x109e/0x1740 [snd_usb_audio] (5.11-rc6)
On Sat, 06 Feb 2021 06:45:32 +0100,
Hillf Danton wrote:
>
> Due to the reconnecting key word mentioned, no fix to
> d0f09d1e4a88 ("ALSA: usb-audio: Refactoring endpoint URB deactivation")
> will be added.
>
> What is added is to capture EP_FLAG_STOPPING and remove the one
> second wait limit if the reconnecting acts may make it easier to
> repro the uaf. The diff is only for idea show.
If my understanding is right, this won't change. The problem is
rather the lack of this function call itself, i.e. the missing
synchronization for the stream stop.
It worked casually in the past because the endpoint resource is
released at a later point that is after all streams are really closed.
Now it's released earlier and hitting the UAF.
Takashi
>
> --- a/sound/usb/endpoint.c
> +++ b/sound/usb/endpoint.c
> @@ -832,24 +832,14 @@ void snd_usb_endpoint_suspend(struct snd
> */
> static int wait_clear_urbs(struct snd_usb_endpoint *ep)
> {
> - unsigned long end_time = jiffies + msecs_to_jiffies(1000);
> - int alive;
> -
> - if (!test_bit(EP_FLAG_STOPPING, >flags))
> - return 0;
> -
> + WARN_ON_ONCE(!test_bit(EP_FLAG_STOPPING, >flags));
> do {
> - alive = bitmap_weight(>active_mask, ep->nurbs);
> - if (!alive)
> + if (!bitmap_weight(>active_mask, ep->nurbs))
> break;
>
> schedule_timeout_uninterruptible(1);
> - } while (time_before(jiffies, end_time));
> + } while (1);
>
> - if (alive)
> - usb_audio_err(ep->chip,
> - "timeout: still %d active urbs on EP #%x\n",
> - alive, ep->ep_num);
> clear_bit(EP_FLAG_STOPPING, >flags);
>
> ep->sync_sink = NULL;
>
Re: [PATCH] usb: cdnsp: Removes some useless trace events
On 21-02-04 11:27:28, Greg KH wrote: > On Thu, Feb 04, 2021 at 10:20:35AM +0100, Pawel Laszczak wrote: > > Patch removes some useless trace events that can > > be replaced by ftrace. > > > > Reported-by: Dan Carpenter > > Signed-off-by: Pawel Laszczak > > --- > > drivers/usb/cdns3/cdnsp-ep0.c| 5 - > > drivers/usb/cdns3/cdnsp-gadget.c | 2 -- > > drivers/usb/cdns3/cdnsp-ring.c | 1 - > > drivers/usb/cdns3/cdnsp-trace.h | 10 -- > > 4 files changed, 18 deletions(-) > > Acked-by: Greg Kroah-Hartman Applied, thanks Pawel. -- Thanks, Peter Chen
回复: 回复: [PATCH v3] kvfree_rcu: Release page cache under memory pressure
发件人: Uladzislau Rezki
发送时间: 2021年2月4日 22:09
收件人: Zhang, Qiang
抄送: Uladzislau Rezki; paul...@kernel.org; j...@joelfernandes.org;
r...@vger.kernel.org; linux-kernel@vger.kernel.org
主题: Re: 回复: [PATCH v3] kvfree_rcu: Release page cache under memory pressure
[Please note: This e-mail is from an EXTERNAL e-mail address]
> 发件人: Uladzislau Rezki
> 发送时间: 2021年2月2日 3:57
> 收件人: Zhang, Qiang
> 抄送: ure...@gmail.com; paul...@kernel.org; j...@joelfernandes.org;
> r...@vger.kernel.org; linux-kernel@vger.kernel.org
> 主题: Re: [PATCH v3] kvfree_rcu: Release page cache under memory pressure
>
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> Hello, Zqiang.
>
> > From: Zqiang
> >
> > Add free per-cpu existing krcp's page cache operation, when
> > the system is under memory pressure.
> >
> > Signed-off-by: Zqiang
> > ---
> > kernel/rcu/tree.c | 26 ++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index c1ae1e52f638..644b0f3c7b9f 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -3571,17 +3571,41 @@ void kvfree_call_rcu(struct rcu_head *head,
> > rcu_callback_t func)
> > }
> > EXPORT_SYMBOL_GPL(kvfree_call_rcu);
> >
> > +static int free_krc_page_cache(struct kfree_rcu_cpu *krcp)
> > +{
> > + unsigned long flags;
> > + struct llist_node *page_list, *pos, *n;
> > + int freed = 0;
> > +
> > + raw_spin_lock_irqsave(>lock, flags);
> > + page_list = llist_del_all(>bkvcache);
> > + krcp->nr_bkv_objs = 0;
> > + raw_spin_unlock_irqrestore(>lock, flags);
> > +
> > + llist_for_each_safe(pos, n, page_list) {
> > + free_page((unsigned long)pos);
> > + freed++;
> > + }
> > +
> > + return freed;
> > +}
> > +
> > static unsigned long
> > kfree_rcu_shrink_count(struct shrinker *shrink, struct shrink_control *sc)
> > {
> > int cpu;
> > unsigned long count = 0;
> > + unsigned long flags;
> >
> > /* Snapshot count of all CPUs */
> > for_each_possible_cpu(cpu) {
> > struct kfree_rcu_cpu *krcp = per_cpu_ptr(, cpu);
> >
> > count += READ_ONCE(krcp->count);
> > +
> > + raw_spin_lock_irqsave(>lock, flags);
> > + count += krcp->nr_bkv_objs;
> > + raw_spin_unlock_irqrestore(>lock, flags);
> > }
> >
> > return count;
> > @@ -3598,6 +3622,8 @@ kfree_rcu_shrink_scan(struct shrinker *shrink, struct
> > shrink_control *sc)
> > struct kfree_rcu_cpu *krcp = per_cpu_ptr(, cpu);
> >
> > count = krcp->count;
> > + count += free_krc_page_cache(krcp);
> > +
> > raw_spin_lock_irqsave(>lock, flags);
> > if (krcp->monitor_todo)
> > kfree_rcu_drain_unlock(krcp, flags);
> > --
> > 2.17.1
> >>
> >Thank you for your patch!
> >
> >I spent some time to see how the patch behaves under low memory condition.
> >To simulate it, i used "rcuscale" tool with below parameters:
> >
> >../rcutorture/bin/kvm.sh --torture rcuscale --allcpus --duration 10
> >--kconfig >CONFIG_NR_CPUS=64 \
> >--bootargs "rcuscale.kfree_rcu_test=1 rcuscale.kfree_nthreads=16
> >>rcuscale.holdoff=20 rcuscale.kfree_loops=1 \
> >torture.disable_onoff_at_boot" --trust-make
> >
> >64 CPUs + 512 MB of memory. In general, my test system was running on edge
> >hitting an out of memory sometimes, but could be considered as stable in
> >regards to a test completion and taken time, so both were pretty solid.
> >
> >You can find a comparison on a plot, that can be downloaded following
> >a link: wget
> >>ftp://vps418301.ovh.net/incoming/release_page_cache_under_low_memory.png
> >
> >In short, i see that a patched version can lead to longer test completion,
> >whereas the default variant is stable on almost all runs. After some analysis
> >and further digging i came to conclusion that a shrinker
> >free_krc_page_cache()
> >concurs with run_page_cache_worker(krcp) running from kvfree_rcu() context.
> >
> >i.e. During the test a page shrinker is pretty active, because of low memory
> >condition. Our callback drains it whereas kvfree_rcu() part refill it right
> >away making kind of vicious circle.
> >
> >So, a run_page_cache_worker() should be backoff for some time when a system
> >runs into a low memory condition or high pressure:
> >
> >diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> >index 7077d73fcb53..446723b9646b 100644
> >--- a/kernel/rcu/tree.c
> >+++ b/kernel/rcu/tree.c
> >@@ -3163,7 +3163,7 @@ struct kfree_rcu_cpu {
> >bool initialized;
> >int count;
> >
> >- struct work_struct page_cache_work;
> >+ struct delayed_work page_cache_work;
> >atomic_t work_in_progress;
> >struct hrtimer hrtimer;
> >
> >@@ -3419,7 +3419,7 @@ schedule_page_work_fn(struct hrtimer *t)
> >struct kfree_rcu_cpu *krcp =
> >
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
>
>
>
> On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song escreveu:
> >> On 2/5/21 11:06 AM, Sedat Dilek wrote:
> >>> On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek wrote:
> >>> Grepping through linux.git/tools I guess some BTF tools/libs need to
> >>> know what BTF_INT_UNSIGNED is?
> >
> >> BTF_INT_UNSIGNED needs kernel support. Maybe to teach pahole to
> >> ignore this for now until kernel infrastructure is ready.
> >
> > Yeah, I thought about doing that.
> >
> >> Not sure whether this information will be useful or not
> >> for BTF. This needs to be discussed separately.
> >
> > Maybe search for the rationale for its introduction in DWARF.
>
> In LLVM, we have:
>uint8_t BTFEncoding;
>switch (Encoding) {
>case dwarf::DW_ATE_boolean:
> BTFEncoding = BTF::INT_BOOL;
> break;
>case dwarf::DW_ATE_signed:
>case dwarf::DW_ATE_signed_char:
> BTFEncoding = BTF::INT_SIGNED;
> break;
>case dwarf::DW_ATE_unsigned:
>case dwarf::DW_ATE_unsigned_char:
> BTFEncoding = 0;
> break;
>
> I think DW_ATE_unsigned can be ignored in pahole since
> the default encoding = 0. A simple comment is enough.
>
For the followers (here: LLVM v12.0.0-rc1):
[ llvm/lib/Target/BPF/BTFDebug.cpp ]
BTFTypeInt::BTFTypeInt(uint32_t Encoding, uint32_t SizeInBits,
uint32_t OffsetInBits, StringRef TypeName)
: Name(TypeName) {
// Translate IR int encoding to BTF int encoding.
uint8_t BTFEncoding;
switch (Encoding) {
case dwarf::DW_ATE_boolean:
BTFEncoding = BTF::INT_BOOL;
break;
case dwarf::DW_ATE_signed:
case dwarf::DW_ATE_signed_char:
BTFEncoding = BTF::INT_SIGNED;
break;
case dwarf::DW_ATE_unsigned:
case dwarf::DW_ATE_unsigned_char:
BTFEncoding = 0;
break;
default:
llvm_unreachable("Unknown BTFTypeInt Encoding");
}
- Sedat -
Re: Kernel version numbers after 4.9.255 and 4.4.255
On Fri, Feb 05, 2021 at 07:44:12PM +0100, Pavel Machek wrote: > Hi! > > > > > Ugh, I thought this was an internal representation, not an external one > > > > :( > > > > > > > > > It might work somewhere, but there are a lot of (X * 65536 + Y * 256 > > > > > + Z) > > > > > assumptions all around the world. So this doesn't look like a good > > > > > idea. > > > > > > > > Ok, so what happens if we "wrap"? What will break with that? At first > > > > glance, I can't see anything as we keep the padding the same, and our > > > > build scripts seem to pick the number up from the Makefile and treat it > > > > like a string. > > > > > > > > It's only the crazy out-of-tree kernel stuff that wants to do minor > > > > version checks that might go boom. And frankly, I'm not all that > > > > concerned if they have problems :) > > > > > > > > So, let's leave it alone and just see what happens! > > > > > > Yeah, stable is a great place to do the experiments. Not that this is > > > the first time :-(. > > > > How else can we "test this out"? > > > > Should I do an "empty" release of 4.4.256 and see if anyone complains? > > It seems that would be bad idea, as it would cause problems when stuff > is compiled on 4.4.256, not simply by running it. > > Sasha's patch seems like one option that could work. > > Even safer option is to switch to 4.4.255-st1, 4.4.255-st2 ... scheme. Using EXTRAVERSION would work, but it is effectivly the same thing as nothing exports that to userspace through the LINUX_VERSION macro. So clamping the version like Sasha's patches seems to be the best solution. thanks, greg k-h
Re: [PATCH v19 2/3] scsi: ufs: L2P map management for HPB read
On 2021-01-29 13:30, Daejun Park wrote:
This is a patch for managing L2P map in HPB module.
The HPB divides logical addresses into several regions. A region
consists
of several sub-regions. The sub-region is a basic unit where L2P
mapping is
managed. The driver loads L2P mapping data of each sub-region. The
loaded
sub-region is called active-state. The HPB driver unloads L2P mapping
data
as region unit. The unloaded region is called inactive-state.
Sub-region/region candidates to be loaded and unloaded are delivered
from
the UFS device. The UFS device delivers the recommended active
sub-region
and inactivate region to the driver using sensedata.
The HPB module performs L2P mapping management on the host through the
delivered information.
A pinned region is a pre-set regions on the UFS device that is always
activate-state.
The data structure for map data request and L2P map uses mempool API,
minimizing allocation overhead while avoiding static allocation.
The mininum size of the memory pool used in the HPB is implemented
as a module parameter, so that it can be configurable by the user.
To gurantee a minimum memory pool size of 4MB:
ufshpb_host_map_kbytes=4096
The map_work manages active/inactive by 2 "to-do" lists.
Each hpb lun maintains 2 "to-do" lists:
hpb->lh_inact_rgn - regions to be inactivated, and
hpb->lh_act_srgn - subregions to be activated
Those lists are maintained on IO completion.
Reviewed-by: Bart Van Assche
Reviewed-by: Can Guo
Acked-by: Avri Altman
Tested-by: Bean Huo
Signed-off-by: Daejun Park
---
drivers/scsi/ufs/ufs.h| 36 ++
drivers/scsi/ufs/ufshcd.c | 4 +
drivers/scsi/ufs/ufshpb.c | 993 +-
drivers/scsi/ufs/ufshpb.h | 65 +++
4 files changed, 1083 insertions(+), 15 deletions(-)
diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 65563635e20e..075c12e7de7e 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -472,6 +472,41 @@ struct utp_cmd_rsp {
u8 sense_data[UFS_SENSE_SIZE];
};
+struct ufshpb_active_field {
+ __be16 active_rgn;
+ __be16 active_srgn;
+};
+#define HPB_ACT_FIELD_SIZE 4
+
+/**
+ * struct utp_hpb_rsp - Response UPIU structure
+ * @residual_transfer_count: Residual transfer count DW-3
+ * @reserved1: Reserved double words DW-4 to DW-7
+ * @sense_data_len: Sense data length DW-8 U16
+ * @desc_type: Descriptor type of sense data
+ * @additional_len: Additional length of sense data
+ * @hpb_op: HPB operation type
+ * @reserved2: Reserved field
+ * @active_rgn_cnt: Active region count
+ * @inactive_rgn_cnt: Inactive region count
+ * @hpb_active_field: Recommended to read HPB region and subregion
+ * @hpb_inactive_field: To be inactivated HPB region and subregion
+ */
+struct utp_hpb_rsp {
+ __be32 residual_transfer_count;
+ __be32 reserved1[4];
+ __be16 sense_data_len;
+ u8 desc_type;
+ u8 additional_len;
+ u8 hpb_op;
+ u8 reserved2;
+ u8 active_rgn_cnt;
+ u8 inactive_rgn_cnt;
+ struct ufshpb_active_field hpb_active_field[2];
+ __be16 hpb_inactive_field[2];
+};
+#define UTP_HPB_RSP_SIZE 40
+
/**
* struct utp_upiu_rsp - general upiu response structure
* @header: UPIU header structure DW-0 to DW-2
@@ -482,6 +517,7 @@ struct utp_upiu_rsp {
struct utp_upiu_header header;
union {
struct utp_cmd_rsp sr;
+ struct utp_hpb_rsp hr;
struct utp_upiu_query qr;
};
};
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b8d6a52f5603..52e48de8d27c 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5018,6 +5018,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba,
struct ufshcd_lrb *lrbp)
*/
pm_runtime_get_noresume(hba->dev);
}
+
+ if (scsi_status == SAM_STAT_GOOD)
+ ufshpb_rsp_upiu(hba, lrbp);
break;
case UPIU_TRANSACTION_REJECT_UPIU:
/* TODO: handle Reject UPIU Response */
@@ -9228,6 +9231,7 @@ EXPORT_SYMBOL(ufshcd_shutdown);
void ufshcd_remove(struct ufs_hba *hba)
{
ufs_bsg_remove(hba);
+ ufshpb_remove(hba);
ufs_sysfs_remove_nodes(hba->dev);
blk_cleanup_queue(hba->tmf_queue);
blk_mq_free_tag_set(>tmf_tag_set);
diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
index 1f84141ed384..48edfdd0f606 100644
--- a/drivers/scsi/ufs/ufshpb.c
+++ b/drivers/scsi/ufs/ufshpb.c
@@ -16,11 +16,73 @@
#include "ufshpb.h"
#include "../sd.h"
+/* memory management */
+static struct kmem_cache *ufshpb_mctx_cache;
+static mempool_t *ufshpb_mctx_pool;
+static mempool_t *ufshpb_page_pool;
+/* A cache size of 2MB can cache ppn in the 1GB range. */
+static unsigned int ufshpb_host_map_kbytes = 2048;
+static int tot_active_srgn_pages;
+
+static struct
Re: Kernel version numbers after 4.9.255 and 4.4.255
On Fri, Feb 05, 2021 at 12:31:05PM -0500, Tony Battersby wrote: > On 2/4/21 6:00 AM, Jiri Slaby wrote: > > Agreed. But currently, sublevel won't "wrap", it will "overflow" to > > patchlevel. And that might be a problem. So we might need to update the > > header generation using e.g. "sublevel & 0xff" (wrap around) or > > "sublevel > 255 : 255 : sublevel" (be monotonic and get stuck at 255). > > > > In both LINUX_VERSION_CODE generation and KERNEL_VERSION proper. > > My preference would be to be monotonic and get stuck at 255 to avoid > breaking out-of-tree modules. I really do not care about out-of-tree modules sorry, as there's nothing we can do about them. And internal kernel apis are always changing, even in stable/lts releases, so changing this type of thing for them should not be a big deal as maintainers of this type of code always have to do that. thanks, greg k-h
Re: Kernel version numbers after 4.9.255 and 4.4.255
On Fri, Feb 05, 2021 at 07:11:05PM +0100, Mauro Carvalho Chehab wrote: > Em Fri, 5 Feb 2021 12:31:05 -0500 > Tony Battersby escreveu: > > > On 2/4/21 6:00 AM, Jiri Slaby wrote: > > > Agreed. But currently, sublevel won't "wrap", it will "overflow" to > > > patchlevel. And that might be a problem. So we might need to update the > > > header generation using e.g. "sublevel & 0xff" (wrap around) or > > > "sublevel > 255 : 255 : sublevel" (be monotonic and get stuck at 255). > > > > > > In both LINUX_VERSION_CODE generation and KERNEL_VERSION proper. > > > > My preference would be to be monotonic and get stuck at 255 to avoid > > breaking out-of-tree modules. If needed, add another macro that > > increases the number of bits that can be used to check for sublevels > > > 255, while keeping the old macros for compatibility reasons. Since > > sublevels > 255 have never existed before, any such checks must be > > newly-added, so they can be required to use the new macros. > > > > I do not run the 4.4/4.9 kernels usually, but I do sometimes test a wide > > range of kernels from 3.18 (gasp!) up to the latest when bisecting, > > benchmarking, or debugging problems. And I use a number of out-of-tree > > modules that rely on the KERNEL_VERSION to make everything work. Some > > out-of-tree modules like an updated igb network driver might be needed > > to make it possible to test the old kernel on particular hardware. > > > > In the worst case, I can patch LINUX_VERSION_CODE and KERNEL_VERSION > > locally to make out-of-tree modules work. Or else just not test kernels > > with sublevel > 255. > > Overflowing LINUX_VERSION_CODE breaks media applications. Several media > APIs have an ioctl that returns the Kernel version: > > drivers/media/cec/core/cec-api.c: caps.version = > LINUX_VERSION_CODE; > drivers/media/mc/mc-device.c: info->media_version = > LINUX_VERSION_CODE; > drivers/media/v4l2-core/v4l2-ioctl.c: cap->version = > LINUX_VERSION_CODE; > drivers/media/v4l2-core/v4l2-subdev.c: cap->version = > LINUX_VERSION_CODE; This always struck me as odd, because why can't they just use the uname(2) syscall instead? > Those can be used by applications in order to enable some features that > are available only after certain Kernel versions. > > This is somewhat deprecated, in favor of the usage of some other > capability fields, but for instance, the v4l2-compliance userspace tool > have two such checks: > > utils/v4l2-compliance/v4l2-compliance.cpp > 640:fail_on_test((vcap.version >> 16) < 3); > 641:if (vcap.version >= 0x050900) // Present from 5.9.0 onwards > > As far as I remember, all such checks are against major.minor. So, > something like: > > sublevel = (sublevel > 0xff) ? 0xff : sublevel; > > inside KERNEL_VERSION macro should fix such regression at -stable. I think if we clamp KERNEL_VERSION at 255 we should be fine for anyone checking this type of thing. Sasha has posted patches to do this. thanks, greg k-h
[PATCH] nbd: Convert to DEFINE_SHOW_ATTRIBUTE
From: Liao Pingfang
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: Liao Pingfang
---
drivers/block/nbd.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index e6ea5d3..8b9622e 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -1529,17 +1529,7 @@ static int nbd_dbg_tasks_show(struct seq_file *s, void
*unused)
return 0;
}
-static int nbd_dbg_tasks_open(struct inode *inode, struct file *file)
-{
- return single_open(file, nbd_dbg_tasks_show, inode->i_private);
-}
-
-static const struct file_operations nbd_dbg_tasks_ops = {
- .open = nbd_dbg_tasks_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(nbd_dbg_tasks);
static int nbd_dbg_flags_show(struct seq_file *s, void *unused)
{
@@ -1564,17 +1554,7 @@ static int nbd_dbg_flags_show(struct seq_file *s, void
*unused)
return 0;
}
-static int nbd_dbg_flags_open(struct inode *inode, struct file *file)
-{
- return single_open(file, nbd_dbg_flags_show, inode->i_private);
-}
-
-static const struct file_operations nbd_dbg_flags_ops = {
- .open = nbd_dbg_flags_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(nbd_dbg_flags);
static int nbd_dev_dbg_init(struct nbd_device *nbd)
{
@@ -1592,11 +1572,11 @@ static int nbd_dev_dbg_init(struct nbd_device *nbd)
}
config->dbg_dir = dir;
- debugfs_create_file("tasks", 0444, dir, nbd, _dbg_tasks_ops);
+ debugfs_create_file("tasks", 0444, dir, nbd, _dbg_tasks_fops);
debugfs_create_u64("size_bytes", 0444, dir, >bytesize);
debugfs_create_u32("timeout", 0444, dir, >tag_set.timeout);
debugfs_create_u64("blocksize", 0444, dir, >blksize);
- debugfs_create_file("flags", 0444, dir, nbd, _dbg_flags_ops);
+ debugfs_create_file("flags", 0444, dir, nbd, _dbg_flags_fops);
return 0;
}
--
1.8.3.1
Re: [PATCH net-next] xfrm: Return the correct errno code
On Thu, Feb 04, 2021 at 03:42:54PM +0800, Zheng Yongjun wrote: > When kalloc or kmemdup failed, should return ENOMEM rather than ENOBUF. > > Signed-off-by: Zheng Yongjun Applied to ipsec-next, thanks!
Re: [PATCH] printk: Userspace format enumeration support
On Fri, Feb 05, 2021 at 10:45:19PM +, Chris Down wrote: > Hi Steven, > > Steven Rostedt writes: > > Interesting, because when I was looking at the original patch (looked at > > the lore link before reading your reply), I thought to myself "this looks > > exactly like what I did for trace_printk formats", which the above file is > > where it is shown. I'm curious if this work was inspired by that? > > The double __builtin_constant_p() trick was suggested by Johannes based on > prior art in trace_puts() just prior to patch submission. Other than that, > it seems we came up with basically the same solution independently. :-) > > > > Anyway, there is something wrong at the moment. The output looks fine > > > with cat. But "less" says that it is a binary format and the output > > > is a bit messy: > > > > Hmm, that's usually the case when lseek gets messed up. Not sure how that > > happened. > > It looks as intended to me -- none of the newlines, nulls, or other control > sequences are escaped currently, since I didn't immediately see a reason to > do that. If that's a blocker though, I'm happy to change it. > > > > $> less /proc/printk_formats > > > "/proc/printk_formats" may be a binary file. See it anyway? > > > vmlinux,^A3Warning: unable to open an initial console. > > > ^@vmlinux,^A3Failed to execute %s (error %d) > > > ^@vmlinux,^A6Kernel memory protection disabled. > > > ^@vmlinux,^A3Starting init: %s exists but couldn't execute it (error %d) > > > > > > > > > That is for now. I still have to think about it. And I am also curious > > > about what others thing about this idea. > > > > > > > I'm not against the idea. I don't think it belongs in /proc. Perhaps > > debugfs is a better place to put it. > > Any location is fine with me, as long as it gets to userspace. How does > /printk/formats or /printk/formats/ sound to you? That's fine with me, but I'd like to see the patch with this in it first before approving it :) thanks, greg k-h
Re: [PATCH] esp: Simplify the calculation of variables
On Wed, Feb 03, 2021 at 10:44:30AM +0800, Jiapeng Chong wrote: > Fix the following coccicheck warnings: > > ./net/ipv6/esp6.c:791:16-18: WARNING !A || A && B is equivalent > to !A || B. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong Applied to ipsec-next, thanks!
Hi Dear
Hi Dear , How are you doing hope you are fine and OK? I was just going through the Internet search when I found your email address, I want to make a new and special friend, so I decided to contact you to see how we can make it work out if we can. Please I wish you will have the desire with me so that we can get to know each other better and see what happens in future. My name is Lisa Williams, I am an American, but presently I live in the UK, I will be glad to see your reply for us to know each other better to exchange pictures and details about us. Yours Lisa.
Re: [PATCH] MAINTAINERS/.mailmap: Use my @kernel.org address
On Wed, Jan 27, 2021 at 7:48 AM Sedat Dilek wrote: > > On Wed, Jan 27, 2021 at 6:07 AM Lukas Bulwahn wrote: > > > > On Tue, Jan 26, 2021 at 10:27 PM Nathan Chancellor > > wrote: > > > > > > Use my @kernel.org for all points of contact so that I am always > > > accessible. > > > > > > Signed-off-by: Nathan Chancellor > > > > Congrats, Nathan. You deserve it for all the warning fixes, reports, > > maintenance, CI, reviews and much more stuff you are doing. > > > > +1 > > Congrats Nathan. > ministerial: https://git.kernel.org/linus/654eb3f2a009af1fc64b10442e559e0d1e50904a - sed@ -
Re: [PATCH v2] tracepoints: Do not punish non static call users
Hi Steven, I love your patch! Perhaps something to improve: [auto build test WARNING on tip/perf/core] [also build test WARNING on linux/master linus/master v5.11-rc6 next-20210125] [cannot apply to hnaz-linux-mm/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Steven-Rostedt/tracepoints-Do-not-punish-non-static-call-users/20210206-112501 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 32451614da2a9cf4296f90d3606ac77814fb519d config: arm64-randconfig-r033-20210206 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project c9439ca36342fb6013187d0a69aef92736951476) 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 arm64 cross compiling tool for clang build # apt-get install binutils-aarch64-linux-gnu # https://github.com/0day-ci/linux/commit/3fc399c60e990487bf5d0cd91406052c0db853df git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Steven-Rostedt/tracepoints-Do-not-punish-non-static-call-users/20210206-112501 git checkout 3fc399c60e990487bf5d0cd91406052c0db853df # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from block/blk-wbt.c:32: >> include/trace/events/wbt.h:15:1: warning: variable '__data' is uninitialized >> when used here [-Wuninitialized] TRACE_EVENT(wbt_stat, ^ include/linux/tracepoint.h:550:2: note: expanded from macro 'TRACE_EVENT' DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) ^~~~ include/linux/tracepoint.h:417:11: note: expanded from macro 'DECLARE_TRACE' PARAMS(__data, args)) ^~ include/linux/tracepoint.h:97:25: note: expanded from macro 'PARAMS' #define PARAMS(args...) args ^~~~ note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) include/linux/tracepoint.h:201:33: note: expanded from macro '__DO_TRACE' __DO_TRACE_CALL(name, TP_ARGS(args)); \ ^~~~ include/linux/tracepoint.h:138:26: note: expanded from macro 'TP_ARGS' #define TP_ARGS(args...)args ^~~~ include/linux/tracepoint.h:166:56: note: expanded from macro '__DO_TRACE_CALL' #define __DO_TRACE_CALL(name, args) __traceiter_##name(args) ^~~~ include/trace/events/wbt.h:15:1: note: variable '__data' is declared here include/linux/tracepoint.h:550:2: note: expanded from macro 'TRACE_EVENT' DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) ^ include/linux/tracepoint.h:414:2: note: expanded from macro 'DECLARE_TRACE' __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \ ^ include/linux/tracepoint.h:244:4: note: expanded from macro '__DECLARE_TRACE' __DO_TRACE(name,\ ^ include/linux/tracepoint.h:181:3: note: expanded from macro '__DO_TRACE' void __maybe_unused *__data;\ ^ In file included from block/blk-wbt.c:32: >> include/trace/events/wbt.h:15:1: warning: variable '__data' is uninitialized >> when used here [-Wuninitialized] TRACE_EVENT(wbt_stat, ^ include/linux/tracepoint.h:550:2: note: expanded from macro 'TRACE_EVENT' DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) ^~~~ include/linux/tracepoint.h:417:11: note: expanded from macro 'DECLARE_TRACE' PARAMS(__data, args)) ^~ include/linux/tracepoint.h:97:25: note: expanded from macro 'PARAMS' #define PARAMS(args...) args ^~~~ note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) include/linux/tracepoint.h:201:33: note: expanded from macro '__DO_TRACE' __DO_TRACE_CALL(name, TP_ARGS(args)); \ ^~~~ include/linux/tracepoint.h:138:26: note: expanded from macro 'TP_ARGS' #define TP_ARGS(args...)args
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 7:26 AM Sedat Dilek wrote:
>
> On Sat, Feb 6, 2021 at 6:53 AM Sedat Dilek wrote:
> >
> > On Sat, Feb 6, 2021 at 6:44 AM Sedat Dilek wrote:
> > >
> > > On Sat, Feb 6, 2021 at 4:34 AM Sedat Dilek wrote:
> > > >
> > > > On Fri, Feb 5, 2021 at 10:54 PM Yonghong Song wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 2/5/21 12:31 PM, Sedat Dilek wrote:
> > > > > > On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
> > > > > >>> Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song escreveu:
> > > > > On 2/5/21 11:06 AM, Sedat Dilek wrote:
> > > > > > On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek
> > > > > > wrote:
> > > > > > Grepping through linux.git/tools I guess some BTF tools/libs
> > > > > > need to
> > > > > > know what BTF_INT_UNSIGNED is?
> > > > > >>>
> > > > > BTF_INT_UNSIGNED needs kernel support. Maybe to teach pahole to
> > > > > ignore this for now until kernel infrastructure is ready.
> > > > > >>>
> > > > > >>> Yeah, I thought about doing that.
> > > > > >>>
> > > > > Not sure whether this information will be useful or not
> > > > > for BTF. This needs to be discussed separately.
> > > > > >>>
> > > > > >>> Maybe search for the rationale for its introduction in DWARF.
> > > > > >>
> > > > > >> In LLVM, we have:
> > > > > >> uint8_t BTFEncoding;
> > > > > >> switch (Encoding) {
> > > > > >> case dwarf::DW_ATE_boolean:
> > > > > >> BTFEncoding = BTF::INT_BOOL;
> > > > > >> break;
> > > > > >> case dwarf::DW_ATE_signed:
> > > > > >> case dwarf::DW_ATE_signed_char:
> > > > > >> BTFEncoding = BTF::INT_SIGNED;
> > > > > >> break;
> > > > > >> case dwarf::DW_ATE_unsigned:
> > > > > >> case dwarf::DW_ATE_unsigned_char:
> > > > > >> BTFEncoding = 0;
> > > > > >> break;
> > > > > >>
> > > > > >> I think DW_ATE_unsigned can be ignored in pahole since
> > > > > >> the default encoding = 0. A simple comment is enough.
> > > > > >>
> > > > > >
> > > > > > Yonghong Son, do you have a patch/diff for me?
> > > > >
> > > > > Looking at error message from log:
> > > > >
> > > > > LLVM_OBJCOPY=/opt/binutils/bin/objcopy /opt/pahole/bin/pahole -J
> > > > > .tmp_vmlinux.btf
> > > > > [115] INT DW_ATE_unsigned_1 Error emitting BTF type
> > > > > Encountered error while encoding BTF.
> > > > >
> > > > > Not exactly what is the root cause. Maybe bt->bit_size is not
> > > > > encoded correctly. Could you put vmlinux (in the above it is
> > > > > .tmp_vmlinux.btf) somewhere, I or somebody else can investigate
> > > > > and provide a proper fix.
> > > > >
> > > >
> > > > [ TO: Masahiro ]
> > > >
> > > > Thanks for taking care Yonghong - hope this is your first name, if not
> > > > I am sorry.
> > > > In case of mixing my first and last name you will make me female -
> > > > Dilek is a Turkish female first name :-).
> > > > So, in some cultures you need to be careful.
> > > >
> > > > Anyway... back to business and facts.
> > > >
> > > > Out of frustration I killed my last build via `make distclean`.
> > > > The whole day I tested diverse combination of GCC-10 and LLVM-12
> > > > together with BTF Kconfigs, selfmade pahole, etc.
> > > >
> > > > I will do ne run with some little changes:
> > > >
> > > > #1: Pass LLVM_IAS=1 to make (means use Clang's Integrated ASsembler -
> > > > as per Nick this leads to the same error - should be unrelated)
> > > > #2: I did: DEBUG_INFO_COMPRESSED y -> n
> > > >
> > > > #2 I did in case you need vmlinux and I have to upload - I will
> > > > compress the resulting vmlinux with ZSTD.
> > > > You need vmlinux or .tmp_vmlinux.btf file?
> > > > Nick was not allowed from his company to download from a Dropbox link.
> > > > So, as an alternative I can offer GoogleDrive...
> > > > ...or bomb into your INBOX :-).
> > > >
> > > > Now, why I CCed Masahiro:
> > > >
> > > > In case of ERRORs when running `scripts/link-vmlinux.sh` above files
> > > > will be removed.
> > > >
> > > > Last, I found a hack to bypass this - means to keep these files (I
> > > > need to check old emails).
> > > >
> > > > Masahiro, you see a possibility to have a way to keep these files in
> > > > case of ERRORs without doing hackery?
> > > >
> > > > From a previous post in this thread:
> > > >
> > > > + info BTF .btf.vmlinux.bin.o
> > > > + [ != silent_ ]
> > > > + printf %-7s %s\n BTF .btf.vmlinux.bin.o
> > > > BTF .btf.vmlinux.bin.o
> > > > + LLVM_OBJCOPY=llvm-objcopy /opt/pahole/bin/pahole -J .tmp_vmlinux.btf
> > > > [2] INT long unsigned int Error emitting BTF type
> > > > Encountered error while encoding BTF.
> > > > + llvm-objcopy --only-section=.BTF --set-section-flags
> > > > .BTF=alloc,readonly --strip-all .tmp_vmlinux.btf .btf.vmlinux.bin.o
> > > > ...
> > > > + info BTFIDS vmlinux
> > > > + [ != silent_ ]
> > > > + printf %-7s %s\n BTFIDS vmlinux
> > > > BTFIDS
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 6:53 AM Sedat Dilek wrote:
>
> On Sat, Feb 6, 2021 at 6:44 AM Sedat Dilek wrote:
> >
> > On Sat, Feb 6, 2021 at 4:34 AM Sedat Dilek wrote:
> > >
> > > On Fri, Feb 5, 2021 at 10:54 PM Yonghong Song wrote:
> > > >
> > > >
> > > >
> > > > On 2/5/21 12:31 PM, Sedat Dilek wrote:
> > > > > On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
> > > > >>
> > > > >>
> > > > >>
> > > > >> On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
> > > > >>> Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song escreveu:
> > > > On 2/5/21 11:06 AM, Sedat Dilek wrote:
> > > > > On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek
> > > > > wrote:
> > > > > Grepping through linux.git/tools I guess some BTF tools/libs need
> > > > > to
> > > > > know what BTF_INT_UNSIGNED is?
> > > > >>>
> > > > BTF_INT_UNSIGNED needs kernel support. Maybe to teach pahole to
> > > > ignore this for now until kernel infrastructure is ready.
> > > > >>>
> > > > >>> Yeah, I thought about doing that.
> > > > >>>
> > > > Not sure whether this information will be useful or not
> > > > for BTF. This needs to be discussed separately.
> > > > >>>
> > > > >>> Maybe search for the rationale for its introduction in DWARF.
> > > > >>
> > > > >> In LLVM, we have:
> > > > >> uint8_t BTFEncoding;
> > > > >> switch (Encoding) {
> > > > >> case dwarf::DW_ATE_boolean:
> > > > >> BTFEncoding = BTF::INT_BOOL;
> > > > >> break;
> > > > >> case dwarf::DW_ATE_signed:
> > > > >> case dwarf::DW_ATE_signed_char:
> > > > >> BTFEncoding = BTF::INT_SIGNED;
> > > > >> break;
> > > > >> case dwarf::DW_ATE_unsigned:
> > > > >> case dwarf::DW_ATE_unsigned_char:
> > > > >> BTFEncoding = 0;
> > > > >> break;
> > > > >>
> > > > >> I think DW_ATE_unsigned can be ignored in pahole since
> > > > >> the default encoding = 0. A simple comment is enough.
> > > > >>
> > > > >
> > > > > Yonghong Son, do you have a patch/diff for me?
> > > >
> > > > Looking at error message from log:
> > > >
> > > > LLVM_OBJCOPY=/opt/binutils/bin/objcopy /opt/pahole/bin/pahole -J
> > > > .tmp_vmlinux.btf
> > > > [115] INT DW_ATE_unsigned_1 Error emitting BTF type
> > > > Encountered error while encoding BTF.
> > > >
> > > > Not exactly what is the root cause. Maybe bt->bit_size is not
> > > > encoded correctly. Could you put vmlinux (in the above it is
> > > > .tmp_vmlinux.btf) somewhere, I or somebody else can investigate
> > > > and provide a proper fix.
> > > >
> > >
> > > [ TO: Masahiro ]
> > >
> > > Thanks for taking care Yonghong - hope this is your first name, if not
> > > I am sorry.
> > > In case of mixing my first and last name you will make me female -
> > > Dilek is a Turkish female first name :-).
> > > So, in some cultures you need to be careful.
> > >
> > > Anyway... back to business and facts.
> > >
> > > Out of frustration I killed my last build via `make distclean`.
> > > The whole day I tested diverse combination of GCC-10 and LLVM-12
> > > together with BTF Kconfigs, selfmade pahole, etc.
> > >
> > > I will do ne run with some little changes:
> > >
> > > #1: Pass LLVM_IAS=1 to make (means use Clang's Integrated ASsembler -
> > > as per Nick this leads to the same error - should be unrelated)
> > > #2: I did: DEBUG_INFO_COMPRESSED y -> n
> > >
> > > #2 I did in case you need vmlinux and I have to upload - I will
> > > compress the resulting vmlinux with ZSTD.
> > > You need vmlinux or .tmp_vmlinux.btf file?
> > > Nick was not allowed from his company to download from a Dropbox link.
> > > So, as an alternative I can offer GoogleDrive...
> > > ...or bomb into your INBOX :-).
> > >
> > > Now, why I CCed Masahiro:
> > >
> > > In case of ERRORs when running `scripts/link-vmlinux.sh` above files
> > > will be removed.
> > >
> > > Last, I found a hack to bypass this - means to keep these files (I
> > > need to check old emails).
> > >
> > > Masahiro, you see a possibility to have a way to keep these files in
> > > case of ERRORs without doing hackery?
> > >
> > > From a previous post in this thread:
> > >
> > > + info BTF .btf.vmlinux.bin.o
> > > + [ != silent_ ]
> > > + printf %-7s %s\n BTF .btf.vmlinux.bin.o
> > > BTF .btf.vmlinux.bin.o
> > > + LLVM_OBJCOPY=llvm-objcopy /opt/pahole/bin/pahole -J .tmp_vmlinux.btf
> > > [2] INT long unsigned int Error emitting BTF type
> > > Encountered error while encoding BTF.
> > > + llvm-objcopy --only-section=.BTF --set-section-flags
> > > .BTF=alloc,readonly --strip-all .tmp_vmlinux.btf .btf.vmlinux.bin.o
> > > ...
> > > + info BTFIDS vmlinux
> > > + [ != silent_ ]
> > > + printf %-7s %s\n BTFIDS vmlinux
> > > BTFIDS vmlinux
> > > + ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
> > > FAILED: load BTF from vmlinux: Invalid argument
> > > + on_exit
> > > + [ 255 -ne 0 ]
> > > + cleanup
> > > + rm -f .btf.vmlinux.bin.o
> > > + rm -f .tmp_System.map
> > > + rm -f .tmp_vmlinux.btf .tmp_vmlinux.kallsyms1
> > >
Re: Conflict with Mickaël Salaün's blacklist patches [was [PATCH v5 0/4] Add EFI_CERT_X509_GUID support for dbx/mokx entries]
> On Feb 5, 2021, at 3:27 AM, Mickaël Salaün wrote: > > > On 05/02/2021 01:24, Eric Snowberg wrote: >> >>> On Feb 4, 2021, at 1:26 AM, Mickaël Salaün wrote: >>> >>> >>> On 04/02/2021 04:53, Eric Snowberg wrote: > On Feb 3, 2021, at 11:49 AM, Mickaël Salaün wrote: > > This looks good to me, and it still works for my use case. Eric's > patchset only looks for asymmetric keys in the blacklist keyring, so > even if we use the same keyring we don't look for the same key types. My > patchset only allows blacklist keys (i.e. hashes, not asymmetric keys) > to be added by user space (if authenticated), but because Eric's > asymmetric keys are loaded with KEY_ALLOC_BYPASS_RESTRICTION, it should > be OK for his use case. There should be no interference between the two > new features, but I find it a bit confusing to have such distinct use of > keys from the same keyring depending on their type. I agree, it is a bit confusing. What is the thought of having a dbx keyring, similar to how the platform keyring works? https://www.spinics.net/lists/linux-security-module/msg40262.html > On 03/02/2021 17:26, David Howells wrote: >> >> Eric Snowberg wrote: >> >>> This is the fifth patch series for adding support for >>> EFI_CERT_X509_GUID entries [1]. It has been expanded to not only >>> include >>> dbx entries but also entries in the mokx. Additionally my series to >>> preload these certificate [2] has also been included. >> >> Okay, I've tentatively applied this to my keys-next branch. However, it >> conflicts minorly with Mickaël Salaün's patches that I've previously >> merged on >> the same branch. Can you have a look at the merge commit >> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=keys-next=fdbbe7ceeb95090d09c33ce0497e0394c82aa33d >> >> (the top patch of my keys-next branch) >> >> to see if that is okay by both of you? If so, can you give it a whirl? I’m seeing a build error within blacklist_hashes_checked with one of my configs. The config is as follows: $ grep CONFIG_SYSTEM_BLACKLIST_HASH_LIST .config CONFIG_SYSTEM_BLACKLIST_HASH_LIST=“revocation_list" $ cat certs/revocation_list "tbs:1e125ea4f38acb7b29b0c495fd8e7602c2c3353b913811a9da3a2fb505c08a32” make[1]: *** No rule to make target 'revocation_list', needed by 'certs/blacklist_hashes_checked'. Stop. >>> >>> It requires an absolute path. >> >> Ok, if I use an absolute path now with CONFIG_SYSTEM_BLACKLIST_HASH_LIST >> it works. >> >>> This is to align with other variables >>> using the config_filename macro: CONFIG_SYSTEM_TRUSTED_KEYS, >>> CONFIG_MODULE_SIG_KEY and now CONFIG_SYSTEM_REVOCATION_KEYS. >> >> I just did a quick test with CONFIG_SYSTEM_TRUSTED_KEYS. It looks like we >> can use either a relative or absolute path with CONFIG_SYSTEM_TRUSTED_KEYS. >> Shouldn’t this be consistent? > > CONFIG_SYSTEM_TRUSTED_KEYS (and similar config) works with relative path > to $(srctree) not $(srctree)/certs as in your example. Correct, I had "certs" in my relative path. > We can make CONFIG_SYSTEM_BLACKLIST_HASH_LIST works with $(srctree) with > this patch: > > diff --git a/certs/Makefile b/certs/Makefile > index eb45407ff282..92a233eaa926 100644 > --- a/certs/Makefile > +++ b/certs/Makefile > @@ -14,6 +14,8 @@ $(eval $(call config_filename,SYSTEM_BLACKLIST_HASH_LIST)) > > $(obj)/blacklist_hashes.o: $(obj)/blacklist_hashes_checked > > +CFLAGS_blacklist_hashes.o += -I$(srctree) > + > targets += blacklist_hashes_checked After applying this patch, CONFIG_SYSTEM_BLACKLIST_HASH_LIST now works like the other filename macros. It seems like this would be a good addition. I have done some additional testing, I am seeing a regression. The blacklist keyring is no longer picking up any of the hashes from the dbx during boot. I backed out the merge with my changes (fdbbe7ceeb95090d09c33ce0497e0394c82aa33d) and still see the regression. I then backed out Mickaël merge (5bf1adccf5c41dbdd51d1f4de220d335d9548598) and it fixes the regression. On a x86 with the updated dbx from uefi.org, I’d expect to see 234 bin hash entries in the blacklist keyring. With the current merged code, there is none.
Re: [PATCH v2] tracepoints: Do not punish non static call users
Hi Steven, I love your patch! Yet something to improve: [auto build test ERROR on tip/perf/core] [also build test ERROR on linux/master linus/master v5.11-rc6 next-20210125] [cannot apply to hnaz-linux-mm/master] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Steven-Rostedt/tracepoints-Do-not-punish-non-static-call-users/20210206-112501 base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 32451614da2a9cf4296f90d3606ac77814fb519d config: powerpc-randconfig-r002-20210206 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project c9439ca36342fb6013187d0a69aef92736951476) 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 powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://github.com/0day-ci/linux/commit/3fc399c60e990487bf5d0cd91406052c0db853df git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Steven-Rostedt/tracepoints-Do-not-punish-non-static-call-users/20210206-112501 git checkout 3fc399c60e990487bf5d0cd91406052c0db853df # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All error/warnings (new ones prefixed by >>): In file included from arch/powerpc/kernel/ptrace/ptrace.c:29: >> include/trace/events/syscalls.h:18:1: error: variable '__data' is >> uninitialized when used here [-Werror,-Wuninitialized] TRACE_EVENT_FN(sys_enter, ^ include/linux/tracepoint.h:553:2: note: expanded from macro 'TRACE_EVENT_FN' DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) ^~~~ include/linux/tracepoint.h:417:11: note: expanded from macro 'DECLARE_TRACE' PARAMS(__data, args)) ^~ include/linux/tracepoint.h:97:25: note: expanded from macro 'PARAMS' #define PARAMS(args...) args ^~~~ note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) include/linux/tracepoint.h:201:33: note: expanded from macro '__DO_TRACE' __DO_TRACE_CALL(name, TP_ARGS(args)); \ ^~~~ include/linux/tracepoint.h:138:26: note: expanded from macro 'TP_ARGS' #define TP_ARGS(args...)args ^~~~ include/linux/tracepoint.h:166:56: note: expanded from macro '__DO_TRACE_CALL' #define __DO_TRACE_CALL(name, args) __traceiter_##name(args) ^~~~ include/trace/events/syscalls.h:18:1: note: variable '__data' is declared here include/linux/tracepoint.h:553:2: note: expanded from macro 'TRACE_EVENT_FN' DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) ^ include/linux/tracepoint.h:414:2: note: expanded from macro 'DECLARE_TRACE' __DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \ ^ include/linux/tracepoint.h:244:4: note: expanded from macro '__DECLARE_TRACE' __DO_TRACE(name,\ ^ include/linux/tracepoint.h:181:3: note: expanded from macro '__DO_TRACE' void __maybe_unused *__data;\ ^ In file included from arch/powerpc/kernel/ptrace/ptrace.c:29: >> include/trace/events/syscalls.h:18:1: error: variable '__data' is >> uninitialized when used here [-Werror,-Wuninitialized] TRACE_EVENT_FN(sys_enter, ^ include/linux/tracepoint.h:553:2: note: expanded from macro 'TRACE_EVENT_FN' DECLARE_TRACE(name, PARAMS(proto), PARAMS(args)) ^~~~ include/linux/tracepoint.h:417:11: note: expanded from macro 'DECLARE_TRACE' PARAMS(__data, args)) ^~ include/linux/tracepoint.h:97:25: note: expanded from macro 'PARAMS' #define PARAMS(args...) args ^~~~ note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all) include/linux/tracepoint.h:201:33: note: expanded from macro '__DO_TRACE' __DO_TRACE_CALL(name, TP_ARGS(args)); \ ^~~~
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 6:44 AM Sedat Dilek wrote:
>
> On Sat, Feb 6, 2021 at 4:34 AM Sedat Dilek wrote:
> >
> > On Fri, Feb 5, 2021 at 10:54 PM Yonghong Song wrote:
> > >
> > >
> > >
> > > On 2/5/21 12:31 PM, Sedat Dilek wrote:
> > > > On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
> > > >>
> > > >>
> > > >>
> > > >> On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
> > > >>> Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song escreveu:
> > > On 2/5/21 11:06 AM, Sedat Dilek wrote:
> > > > On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek
> > > > wrote:
> > > > Grepping through linux.git/tools I guess some BTF tools/libs need to
> > > > know what BTF_INT_UNSIGNED is?
> > > >>>
> > > BTF_INT_UNSIGNED needs kernel support. Maybe to teach pahole to
> > > ignore this for now until kernel infrastructure is ready.
> > > >>>
> > > >>> Yeah, I thought about doing that.
> > > >>>
> > > Not sure whether this information will be useful or not
> > > for BTF. This needs to be discussed separately.
> > > >>>
> > > >>> Maybe search for the rationale for its introduction in DWARF.
> > > >>
> > > >> In LLVM, we have:
> > > >> uint8_t BTFEncoding;
> > > >> switch (Encoding) {
> > > >> case dwarf::DW_ATE_boolean:
> > > >> BTFEncoding = BTF::INT_BOOL;
> > > >> break;
> > > >> case dwarf::DW_ATE_signed:
> > > >> case dwarf::DW_ATE_signed_char:
> > > >> BTFEncoding = BTF::INT_SIGNED;
> > > >> break;
> > > >> case dwarf::DW_ATE_unsigned:
> > > >> case dwarf::DW_ATE_unsigned_char:
> > > >> BTFEncoding = 0;
> > > >> break;
> > > >>
> > > >> I think DW_ATE_unsigned can be ignored in pahole since
> > > >> the default encoding = 0. A simple comment is enough.
> > > >>
> > > >
> > > > Yonghong Son, do you have a patch/diff for me?
> > >
> > > Looking at error message from log:
> > >
> > > LLVM_OBJCOPY=/opt/binutils/bin/objcopy /opt/pahole/bin/pahole -J
> > > .tmp_vmlinux.btf
> > > [115] INT DW_ATE_unsigned_1 Error emitting BTF type
> > > Encountered error while encoding BTF.
> > >
> > > Not exactly what is the root cause. Maybe bt->bit_size is not
> > > encoded correctly. Could you put vmlinux (in the above it is
> > > .tmp_vmlinux.btf) somewhere, I or somebody else can investigate
> > > and provide a proper fix.
> > >
> >
> > [ TO: Masahiro ]
> >
> > Thanks for taking care Yonghong - hope this is your first name, if not
> > I am sorry.
> > In case of mixing my first and last name you will make me female -
> > Dilek is a Turkish female first name :-).
> > So, in some cultures you need to be careful.
> >
> > Anyway... back to business and facts.
> >
> > Out of frustration I killed my last build via `make distclean`.
> > The whole day I tested diverse combination of GCC-10 and LLVM-12
> > together with BTF Kconfigs, selfmade pahole, etc.
> >
> > I will do ne run with some little changes:
> >
> > #1: Pass LLVM_IAS=1 to make (means use Clang's Integrated ASsembler -
> > as per Nick this leads to the same error - should be unrelated)
> > #2: I did: DEBUG_INFO_COMPRESSED y -> n
> >
> > #2 I did in case you need vmlinux and I have to upload - I will
> > compress the resulting vmlinux with ZSTD.
> > You need vmlinux or .tmp_vmlinux.btf file?
> > Nick was not allowed from his company to download from a Dropbox link.
> > So, as an alternative I can offer GoogleDrive...
> > ...or bomb into your INBOX :-).
> >
> > Now, why I CCed Masahiro:
> >
> > In case of ERRORs when running `scripts/link-vmlinux.sh` above files
> > will be removed.
> >
> > Last, I found a hack to bypass this - means to keep these files (I
> > need to check old emails).
> >
> > Masahiro, you see a possibility to have a way to keep these files in
> > case of ERRORs without doing hackery?
> >
> > From a previous post in this thread:
> >
> > + info BTF .btf.vmlinux.bin.o
> > + [ != silent_ ]
> > + printf %-7s %s\n BTF .btf.vmlinux.bin.o
> > BTF .btf.vmlinux.bin.o
> > + LLVM_OBJCOPY=llvm-objcopy /opt/pahole/bin/pahole -J .tmp_vmlinux.btf
> > [2] INT long unsigned int Error emitting BTF type
> > Encountered error while encoding BTF.
> > + llvm-objcopy --only-section=.BTF --set-section-flags
> > .BTF=alloc,readonly --strip-all .tmp_vmlinux.btf .btf.vmlinux.bin.o
> > ...
> > + info BTFIDS vmlinux
> > + [ != silent_ ]
> > + printf %-7s %s\n BTFIDS vmlinux
> > BTFIDS vmlinux
> > + ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
> > FAILED: load BTF from vmlinux: Invalid argument
> > + on_exit
> > + [ 255 -ne 0 ]
> > + cleanup
> > + rm -f .btf.vmlinux.bin.o
> > + rm -f .tmp_System.map
> > + rm -f .tmp_vmlinux.btf .tmp_vmlinux.kallsyms1
> > .tmp_vmlinux.kallsyms1.S .tmp_vmlinux.kallsyms1.o
> > .tmp_vmlinux.kallsyms2 .tmp_vmlinux.kallsyms2.S .tmp_vmlinux.kallsyms
> > 2.o
> > + rm -f System.map
> > + rm -f vmlinux
> > + rm -f vmlinux.o
> > make[3]: *** [Makefile:1166: vmlinux] Error 255
> >
> > ^^^ Look here.
> >
>
> With this diff:
>
> $ git diff
[RFC][PATCH 1/2] dma-buf: dma-heap: Provide accessor to get heap name
It can be useful to access the name for the heap,
so provide an accessor to do so.
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Chris Goldsworthy
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: Ezequiel Garcia
Cc: Simon Ser
Cc: James Jones
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: John Stultz
---
drivers/dma-buf/dma-heap.c | 13 +
include/linux/dma-heap.h | 9 +
2 files changed, 22 insertions(+)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index afd22c9dbdcf..6c746ea67676 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -190,6 +190,19 @@ void *dma_heap_get_drvdata(struct dma_heap *heap)
return heap->priv;
}
+
+/**
+ * dma_heap_get_name() - get heap name
+ * @heap: DMA-Heap to retrieve private data for
+ *
+ * Returns:
+ * The char* for the heap name.
+ */
+char *dma_heap_get_name(struct dma_heap *heap)
+{
+ return heap->name;
+}
+
struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
{
struct dma_heap *heap, *h, *err_ret;
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 454e354d1ffb..b91778291fb1 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -50,6 +50,15 @@ struct dma_heap_export_info {
*/
void *dma_heap_get_drvdata(struct dma_heap *heap);
+/**
+ * dma_heap_get_name() - get heap name
+ * @heap: DMA-Heap to retrieve private data for
+ *
+ * Returns:
+ * The char* for the heap name.
+ */
+char *dma_heap_get_name(struct dma_heap *heap);
+
/**
* dma_heap_add - adds a heap to dmabuf heaps
* @exp_info: information needed to register this heap
--
2.25.1
[RFC][PATCH 2/2] dma-buf: heaps: Fix the name used when exporting dmabufs to be the actual heap name
By default dma_buf_export() sets the exporter name to be KBUILD_MODNAME. Unfortunately this may not be identical to the string used as the heap name (ie: "system" vs "system_heap"). This can cause some minor confusion with tooling, and there is the future potential where multiple heap types may be exported by the same module (but would all have the same name). So to avoid all this, set the exporter exp_name to the heap name. Cc: Daniel Vetter Cc: Sumit Semwal Cc: Liam Mark Cc: Chris Goldsworthy Cc: Laura Abbott Cc: Brian Starkey Cc: Hridya Valsaraju Cc: Suren Baghdasaryan Cc: Sandeep Patil Cc: Daniel Mentz Cc: Ørjan Eide Cc: Robin Murphy Cc: Ezequiel Garcia Cc: Simon Ser Cc: James Jones Cc: linux-me...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Signed-off-by: John Stultz --- drivers/dma-buf/heaps/cma_heap.c| 1 + drivers/dma-buf/heaps/system_heap.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 364fc2f3e499..62465d61ccc7 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -339,6 +339,7 @@ static int cma_heap_allocate(struct dma_heap *heap, buffer->pagecount = pagecount; /* create the dmabuf */ + exp_info.exp_name = dma_heap_get_name(heap); exp_info.ops = _heap_buf_ops; exp_info.size = buffer->len; exp_info.flags = fd_flags; diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 17e0e9a68baf..2d4afc79c700 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -388,6 +388,7 @@ static int system_heap_allocate(struct dma_heap *heap, } /* create the dmabuf */ + exp_info.exp_name = dma_heap_get_name(heap); exp_info.ops = _heap_buf_ops; exp_info.size = buffer->len; exp_info.flags = fd_flags; -- 2.25.1
Re: [PATCH v10 12/16] KVM: x86: Introduce new KVM_FEATURE_SEV_LIVE_MIGRATION feature & Custom MSR.
Hello Steve,
Continued response to your queries, especially related to userspace
control of SEV live migration feature :
On Fri, Feb 05, 2021 at 06:54:21PM -0800, Steve Rutherford wrote:
> On Thu, Feb 4, 2021 at 7:08 PM Ashish Kalra wrote:
> >
> > Hello Steve,
> >
> > On Thu, Feb 04, 2021 at 04:56:35PM -0800, Steve Rutherford wrote:
> > > On Wed, Feb 3, 2021 at 4:39 PM Ashish Kalra wrote:
> > > >
> > > > From: Ashish Kalra
> > > >
> > > > Add new KVM_FEATURE_SEV_LIVE_MIGRATION feature for guest to check
> > > > for host-side support for SEV live migration. Also add a new custom
> > > > MSR_KVM_SEV_LIVE_MIGRATION for guest to enable the SEV live migration
> > > > feature.
> > > >
> > > > Signed-off-by: Ashish Kalra
> > > > ---
> > > > Documentation/virt/kvm/cpuid.rst | 5 +
> > > > Documentation/virt/kvm/msr.rst | 12
> > > > arch/x86/include/uapi/asm/kvm_para.h | 4
> > > > arch/x86/kvm/svm/sev.c | 13 +
> > > > arch/x86/kvm/svm/svm.c | 16
> > > > arch/x86/kvm/svm/svm.h | 2 ++
> > > > 6 files changed, 52 insertions(+)
> > > >
> > > > diff --git a/Documentation/virt/kvm/cpuid.rst
> > > > b/Documentation/virt/kvm/cpuid.rst
> > > > index cf62162d4be2..0bdb6cdb12d3 100644
> > > > --- a/Documentation/virt/kvm/cpuid.rst
> > > > +++ b/Documentation/virt/kvm/cpuid.rst
> > > > @@ -96,6 +96,11 @@ KVM_FEATURE_MSI_EXT_DEST_ID15 guest
> > > > checks this feature bit
> > > > before using extended
> > > > destination
> > > > ID bits in MSI address
> > > > bits 11-5.
> > > >
> > > > +KVM_FEATURE_SEV_LIVE_MIGRATION 16 guest checks this
> > > > feature bit before
> > > > + using the page
> > > > encryption state
> > > > + hypercall to notify the
> > > > page state
> > > > + change
> > > > +
> > > > KVM_FEATURE_CLOCKSOURCE_STABLE_BIT 24 host will warn if no
> > > > guest-side
> > > > per-cpu warps are
> > > > expected in
> > > > kvmclock
> > > > diff --git a/Documentation/virt/kvm/msr.rst
> > > > b/Documentation/virt/kvm/msr.rst
> > > > index e37a14c323d2..020245d16087 100644
> > > > --- a/Documentation/virt/kvm/msr.rst
> > > > +++ b/Documentation/virt/kvm/msr.rst
> > > > @@ -376,3 +376,15 @@ data:
> > > > write '1' to bit 0 of the MSR, this causes the host to re-scan
> > > > its queue
> > > > and check if there are more notifications pending. The MSR is
> > > > available
> > > > if KVM_FEATURE_ASYNC_PF_INT is present in CPUID.
> > > > +
> > > > +MSR_KVM_SEV_LIVE_MIGRATION:
> > > > +0x4b564d08
> > > > +
> > > > + Control SEV Live Migration features.
> > > > +
> > > > +data:
> > > > +Bit 0 enables (1) or disables (0) host-side SEV Live Migration
> > > > feature,
> > > > +in other words, this is guest->host communication that it's
> > > > properly
> > > > +handling the shared pages list.
> > > > +
> > > > +All other bits are reserved.
> > > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h
> > > > b/arch/x86/include/uapi/asm/kvm_para.h
> > > > index 950afebfba88..f6bfa138874f 100644
> > > > --- a/arch/x86/include/uapi/asm/kvm_para.h
> > > > +++ b/arch/x86/include/uapi/asm/kvm_para.h
> > > > @@ -33,6 +33,7 @@
> > > > #define KVM_FEATURE_PV_SCHED_YIELD 13
> > > > #define KVM_FEATURE_ASYNC_PF_INT 14
> > > > #define KVM_FEATURE_MSI_EXT_DEST_ID15
> > > > +#define KVM_FEATURE_SEV_LIVE_MIGRATION 16
> > > >
> > > > #define KVM_HINTS_REALTIME 0
> > > >
> > > > @@ -54,6 +55,7 @@
> > > > #define MSR_KVM_POLL_CONTROL 0x4b564d05
> > > > #define MSR_KVM_ASYNC_PF_INT 0x4b564d06
> > > > #define MSR_KVM_ASYNC_PF_ACK 0x4b564d07
> > > > +#define MSR_KVM_SEV_LIVE_MIGRATION 0x4b564d08
> > > >
> > > > struct kvm_steal_time {
> > > > __u64 steal;
> > > > @@ -136,4 +138,6 @@ struct kvm_vcpu_pv_apf_data {
> > > > #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
> > > > #define KVM_PV_EOI_DISABLED 0x0
> > > >
> > > > +#define KVM_SEV_LIVE_MIGRATION_ENABLED BIT_ULL(0)
> > > > +
> > > > #endif /* _UAPI_ASM_X86_KVM_PARA_H */
> > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > > > index b0d324aed515..93f42b3d3e33 100644
> > > > --- a/arch/x86/kvm/svm/sev.c
> > > > +++ b/arch/x86/kvm/svm/sev.c
> > > > @@ -1627,6 +1627,16 @@ int svm_page_enc_status_hc(struct kvm *kvm,
> > > > unsigned long gpa,
> > > > return ret;
> > > > }
> > > >
> > > > +void sev_update_migration_flags(struct kvm *kvm, u64 data)
> > > > +{
> > > > + struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
> > > > +
> > > > + if (!sev_guest(kvm))
>
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Sat, Feb 6, 2021 at 4:34 AM Sedat Dilek wrote:
>
> On Fri, Feb 5, 2021 at 10:54 PM Yonghong Song wrote:
> >
> >
> >
> > On 2/5/21 12:31 PM, Sedat Dilek wrote:
> > > On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
> > >>
> > >>
> > >>
> > >> On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
> > >>> Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song escreveu:
> > On 2/5/21 11:06 AM, Sedat Dilek wrote:
> > > On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek
> > > wrote:
> > > Grepping through linux.git/tools I guess some BTF tools/libs need to
> > > know what BTF_INT_UNSIGNED is?
> > >>>
> > BTF_INT_UNSIGNED needs kernel support. Maybe to teach pahole to
> > ignore this for now until kernel infrastructure is ready.
> > >>>
> > >>> Yeah, I thought about doing that.
> > >>>
> > Not sure whether this information will be useful or not
> > for BTF. This needs to be discussed separately.
> > >>>
> > >>> Maybe search for the rationale for its introduction in DWARF.
> > >>
> > >> In LLVM, we have:
> > >> uint8_t BTFEncoding;
> > >> switch (Encoding) {
> > >> case dwarf::DW_ATE_boolean:
> > >> BTFEncoding = BTF::INT_BOOL;
> > >> break;
> > >> case dwarf::DW_ATE_signed:
> > >> case dwarf::DW_ATE_signed_char:
> > >> BTFEncoding = BTF::INT_SIGNED;
> > >> break;
> > >> case dwarf::DW_ATE_unsigned:
> > >> case dwarf::DW_ATE_unsigned_char:
> > >> BTFEncoding = 0;
> > >> break;
> > >>
> > >> I think DW_ATE_unsigned can be ignored in pahole since
> > >> the default encoding = 0. A simple comment is enough.
> > >>
> > >
> > > Yonghong Son, do you have a patch/diff for me?
> >
> > Looking at error message from log:
> >
> > LLVM_OBJCOPY=/opt/binutils/bin/objcopy /opt/pahole/bin/pahole -J
> > .tmp_vmlinux.btf
> > [115] INT DW_ATE_unsigned_1 Error emitting BTF type
> > Encountered error while encoding BTF.
> >
> > Not exactly what is the root cause. Maybe bt->bit_size is not
> > encoded correctly. Could you put vmlinux (in the above it is
> > .tmp_vmlinux.btf) somewhere, I or somebody else can investigate
> > and provide a proper fix.
> >
>
> [ TO: Masahiro ]
>
> Thanks for taking care Yonghong - hope this is your first name, if not
> I am sorry.
> In case of mixing my first and last name you will make me female -
> Dilek is a Turkish female first name :-).
> So, in some cultures you need to be careful.
>
> Anyway... back to business and facts.
>
> Out of frustration I killed my last build via `make distclean`.
> The whole day I tested diverse combination of GCC-10 and LLVM-12
> together with BTF Kconfigs, selfmade pahole, etc.
>
> I will do ne run with some little changes:
>
> #1: Pass LLVM_IAS=1 to make (means use Clang's Integrated ASsembler -
> as per Nick this leads to the same error - should be unrelated)
> #2: I did: DEBUG_INFO_COMPRESSED y -> n
>
> #2 I did in case you need vmlinux and I have to upload - I will
> compress the resulting vmlinux with ZSTD.
> You need vmlinux or .tmp_vmlinux.btf file?
> Nick was not allowed from his company to download from a Dropbox link.
> So, as an alternative I can offer GoogleDrive...
> ...or bomb into your INBOX :-).
>
> Now, why I CCed Masahiro:
>
> In case of ERRORs when running `scripts/link-vmlinux.sh` above files
> will be removed.
>
> Last, I found a hack to bypass this - means to keep these files (I
> need to check old emails).
>
> Masahiro, you see a possibility to have a way to keep these files in
> case of ERRORs without doing hackery?
>
> From a previous post in this thread:
>
> + info BTF .btf.vmlinux.bin.o
> + [ != silent_ ]
> + printf %-7s %s\n BTF .btf.vmlinux.bin.o
> BTF .btf.vmlinux.bin.o
> + LLVM_OBJCOPY=llvm-objcopy /opt/pahole/bin/pahole -J .tmp_vmlinux.btf
> [2] INT long unsigned int Error emitting BTF type
> Encountered error while encoding BTF.
> + llvm-objcopy --only-section=.BTF --set-section-flags
> .BTF=alloc,readonly --strip-all .tmp_vmlinux.btf .btf.vmlinux.bin.o
> ...
> + info BTFIDS vmlinux
> + [ != silent_ ]
> + printf %-7s %s\n BTFIDS vmlinux
> BTFIDS vmlinux
> + ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
> FAILED: load BTF from vmlinux: Invalid argument
> + on_exit
> + [ 255 -ne 0 ]
> + cleanup
> + rm -f .btf.vmlinux.bin.o
> + rm -f .tmp_System.map
> + rm -f .tmp_vmlinux.btf .tmp_vmlinux.kallsyms1
> .tmp_vmlinux.kallsyms1.S .tmp_vmlinux.kallsyms1.o
> .tmp_vmlinux.kallsyms2 .tmp_vmlinux.kallsyms2.S .tmp_vmlinux.kallsyms
> 2.o
> + rm -f System.map
> + rm -f vmlinux
> + rm -f vmlinux.o
> make[3]: *** [Makefile:1166: vmlinux] Error 255
>
> ^^^ Look here.
>
With this diff:
$ git diff scripts/link-vmlinux.sh
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index eef40fa9485d..40f1b6aae553 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -330,7 +330,7 @@ vmlinux_link vmlinux "${kallsymso}" ${btf_vmlinux_bin_o}
# fill in BTF IDs
if [ -n "${CONFIG_DEBUG_INFO_BTF}" -a -n "${CONFIG_BPF}" ];
[PATCH v2] printk: fix deadlock when kernel panic
We found a deadlock bug on our server when the kernel panic. It can be
described in the following diagram.
CPU0: CPU1:
panic rcu_dump_cpu_stacks
kdump_nmi_shootdown_cpus nmi_trigger_cpumask_backtrace
register_nmi_handler(crash_nmi_callback) printk_safe_flush
__printk_safe_flush
raw_spin_lock_irqsave(_lock)
// send NMI to other processors
apic_send_IPI_allbutself(NMI_VECTOR)
// NMI interrupt, dead
loop
crash_nmi_callback
printk_safe_flush_on_panic
printk_safe_flush
__printk_safe_flush
// deadlock
raw_spin_lock_irqsave(_lock)
The register_nmi_handler() can be called in the __crash_kexec() or the
crash_smp_send_stop() on the x86-64. Because CPU1 is interrupted by the
NMI with holding the read_lock and crash_nmi_callback() never returns,
CPU0 can deadlock when printk_safe_flush_on_panic() is called.
When we hold the read_lock and then interrupted by the NMI, if the NMI
handler call nmi_panic(), it is also can lead to deadlock.
In order to fix it, we make read_lock global and rename it to
safe_read_lock. And we handle safe_read_lock the same way in
printk_safe_flush_on_panic() as we handle logbuf_lock there.
Fixes: cf9b1106c81c ("printk/nmi: flush NMI messages on the system panic")
Signed-off-by: Muchun Song
---
v2:
- handle read_lock the same way as we handle logbuf_lock there.
Thanks Petr.
kernel/printk/printk_safe.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index a0e6f746de6c..2e9e3ed7d63e 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -45,6 +45,8 @@ struct printk_safe_seq_buf {
static DEFINE_PER_CPU(struct printk_safe_seq_buf, safe_print_seq);
static DEFINE_PER_CPU(int, printk_context);
+static DEFINE_RAW_SPINLOCK(safe_read_lock);
+
#ifdef CONFIG_PRINTK_NMI
static DEFINE_PER_CPU(struct printk_safe_seq_buf, nmi_print_seq);
#endif
@@ -180,8 +182,6 @@ static void report_message_lost(struct printk_safe_seq_buf
*s)
*/
static void __printk_safe_flush(struct irq_work *work)
{
- static raw_spinlock_t read_lock =
- __RAW_SPIN_LOCK_INITIALIZER(read_lock);
struct printk_safe_seq_buf *s =
container_of(work, struct printk_safe_seq_buf, work);
unsigned long flags;
@@ -195,7 +195,7 @@ static void __printk_safe_flush(struct irq_work *work)
* different CPUs. This is especially important when printing
* a backtrace.
*/
- raw_spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_read_lock, flags);
i = 0;
more:
@@ -232,7 +232,7 @@ static void __printk_safe_flush(struct irq_work *work)
out:
report_message_lost(s);
- raw_spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_read_lock, flags);
}
/**
@@ -278,6 +278,14 @@ void printk_safe_flush_on_panic(void)
raw_spin_lock_init(_lock);
}
+ if (raw_spin_is_locked(_read_lock)) {
+ if (num_online_cpus() > 1)
+ return;
+
+ debug_locks_off();
+ raw_spin_lock_init(_read_lock);
+ }
+
printk_safe_flush();
}
--
2.11.0
[PATCH] drivers/misc/vmw_vmci: restrict too big queue size in qp_host_alloc_queue
syzbot found WARNING in qp_broker_alloc[1] in qp_host_alloc_queue()
when num_pages is 0x11, giving queue_size + queue_page_size
bigger than KMALLOC_MAX_SIZE for kzalloc(), resulting order >= MAX_ORDER
condition.
queue_size + queue_page_size=0x8000d8, where KMALLOC_MAX_SIZE=0x40.
FYI, I've also noticed in vmci_queue_pair.c other SLAB allocations with no
length check that might exceed KMALLOC_MAX_SIZE as well,
but syzbot doesn't have reproduces for them.
in qp_alloc_ppn_set():
produce_ppns =
kmalloc_array(num_produce_pages, sizeof(*produce_ppns),
GFP_KERNEL);
[..]
consume_ppns =
kmalloc_array(num_consume_pages, sizeof(*consume_ppns),
GFP_KERNEL);
[..]
in qp_alloc_hypercall():
msg_size = sizeof(*alloc_msg) +
(size_t) entry->num_ppns * ppn_size;
alloc_msg = kmalloc(msg_size, GFP_KERNEL);
[..]
in qp_broker_create():
entry->local_mem = kcalloc(QPE_NUM_PAGES(entry->qp),
PAGE_SIZE, GFP_KERNEL);
[1]
Call Trace:
alloc_pages include/linux/gfp.h:547 [inline]
kmalloc_order+0x40/0x130 mm/slab_common.c:837
kmalloc_order_trace+0x15/0x70 mm/slab_common.c:853
kmalloc_large include/linux/slab.h:481 [inline]
__kmalloc+0x257/0x330 mm/slub.c:3959
kmalloc include/linux/slab.h:557 [inline]
kzalloc include/linux/slab.h:682 [inline]
qp_host_alloc_queue drivers/misc/vmw_vmci/vmci_queue_pair.c:540 [inline]
qp_broker_create drivers/misc/vmw_vmci/vmci_queue_pair.c:1351 [inline]
qp_broker_alloc+0x936/0x2740 drivers/misc/vmw_vmci/vmci_queue_pair.c:1739
Reported-by: syzbot+15ec7391f3d6a1a7c...@syzkaller.appspotmail.com
Signed-off-by: Sabyrzhan Tasbolatov
---
drivers/misc/vmw_vmci/vmci_queue_pair.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index c49065887e8f..f6af406fda80 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -537,6 +537,11 @@ static struct vmci_queue *qp_host_alloc_queue(u64 size)
queue_page_size = num_pages * sizeof(*queue->kernel_if->u.h.page);
+ if (queue_size + queue_page_size > KMALLOC_MAX_SIZE) {
+ pr_warn("too big queue to allocate\n");
+ return NULL;
+ }
+
queue = kzalloc(queue_size + queue_page_size, GFP_KERNEL);
if (queue) {
queue->q_header = NULL;
--
2.25.1
[PATCH net-next] net: socket: use BIT_MASK for MSG_*
From: Menglong Dong
The bit mask for MSG_* seems a little confused here. Replace it
with BIT_MASK to make it clear to understand.
Signed-off-by: Menglong Dong
---
include/linux/socket.h | 71 ++
1 file changed, 37 insertions(+), 34 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 385894b4a8bb..671d31c41582 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -283,42 +283,45 @@ struct ucred {
Added those for 1003.1g not all are supported yet
*/
-#define MSG_OOB1
-#define MSG_PEEK 2
-#define MSG_DONTROUTE 4
-#define MSG_TRYHARD 4 /* Synonym for MSG_DONTROUTE for DECnet */
-#define MSG_CTRUNC 8
-#define MSG_PROBE 0x10/* Do not send. Only probe path f.e. for MTU */
-#define MSG_TRUNC 0x20
-#define MSG_DONTWAIT 0x40/* Nonblocking io*/
-#define MSG_EOR 0x80 /* End of record */
-#define MSG_WAITALL0x100 /* Wait for a full request */
-#define MSG_FIN 0x200
-#define MSG_SYN0x400
-#define MSG_CONFIRM0x800 /* Confirm path validity */
-#define MSG_RST0x1000
-#define MSG_ERRQUEUE 0x2000 /* Fetch message from error queue */
-#define MSG_NOSIGNAL 0x4000 /* Do not generate SIGPIPE */
-#define MSG_MORE 0x8000 /* Sender will send more */
-#define MSG_WAITFORONE 0x1 /* recvmmsg(): block until 1+ packets avail */
-#define MSG_SENDPAGE_NOPOLICY 0x1 /* sendpage() internal : do no apply
policy */
-#define MSG_SENDPAGE_NOTLAST 0x2 /* sendpage() internal : not the last
page */
-#define MSG_BATCH 0x4 /* sendmmsg(): more messages coming */
-#define MSG_EOF MSG_FIN
-#define MSG_NO_SHARED_FRAGS 0x8 /* sendpage() internal : page frags are
not shared */
-#define MSG_SENDPAGE_DECRYPTED 0x10 /* sendpage() internal : page may carry
- * plain text and require encryption
- */
-
-#define MSG_ZEROCOPY 0x400 /* Use user data in kernel path */
-#define MSG_FASTOPEN 0x2000 /* Send data in TCP SYN */
-#define MSG_CMSG_CLOEXEC 0x4000/* Set close_on_exec for file
- descriptor received through
- SCM_RIGHTS */
+#define MSG_OOBBIT_MASK(0)
+#define MSG_PEEK BIT_MASK(1)
+#define MSG_DONTROUTE BIT_MASK(2)
+#define MSG_TRYHARDBIT_MASK(2) /* Synonym for MSG_DONTROUTE for DECnet
*/
+#define MSG_CTRUNC BIT_MASK(3)
+#define MSG_PROBE BIT_MASK(4) /* Do not send. Only probe path f.e.
for MTU*/
+#define MSG_TRUNC BIT_MASK(5)
+#define MSG_DONTWAIT BIT_MASK(6) /* Nonblocking io */
+#define MSG_EORBIT_MASK(7) /* End of record
*/
+#define MSG_WAITALLBIT_MASK(8) /* Wait for a full request */
+#define MSG_FINBIT_MASK(9)
+#define MSG_SYNBIT_MASK(10)
+#define MSG_CONFIRMBIT_MASK(11)/* Confirm path validity*/
+#define MSG_RSTBIT_MASK(12)
+#define MSG_ERRQUEUE BIT_MASK(13)/* Fetch message from error queue */
+#define MSG_NOSIGNAL BIT_MASK(14)/* Do not generate SIGPIPE */
+#define MSG_MORE BIT_MASK(15)/* Sender will send more*/
+#define MSG_WAITFORONE BIT_MASK(16)/* recvmmsg(): block until 1+ packets
avail */
+#define MSG_SENDPAGE_NOPOLICY BIT_MASK(16)/* sendpage() internal : do no
apply policy */
+#define MSG_SENDPAGE_NOTLAST BIT_MASK(17)/* sendpage() internal : not
the last page */
+#define MSG_BATCH BIT_MASK(18)/* sendmmsg(): more messages
coming */
+#define MSG_EOFMSG_FIN
+#define MSG_NO_SHARED_FRAGSBIT_MASK(19)/* sendpage() internal : page
frags
+* are not shared
+*/
+#define MSG_SENDPAGE_DECRYPTED BIT_MASK(20)/* sendpage() internal : page
may carry
+* plain text and require
encryption
+*/
+
+#define MSG_ZEROCOPY BIT_MASK(26)/* Use user data in kernel path */
+#define MSG_FASTOPEN BIT_MASK(29)/* Send data in TCP SYN */
+#define MSG_CMSG_CLOEXEC BIT_MASK(30)/* Set close_on_exec for file
+* descriptor received through
+* SCM_RIGHTS
+*/
#if defined(CONFIG_COMPAT)
-#define MSG_CMSG_COMPAT0x8000 /* This message needs 32 bit
fixups */
+#define MSG_CMSG_COMPATBIT_MASK(31)/* This message needs 32 bit
fixups */
#else
-#define MSG_CMSG_COMPAT0 /* We never have 32 bit fixups
*/
+#define MSG_CMSG_COMPAT
Re: [PATCH v10 12/16] KVM: x86: Introduce new KVM_FEATURE_SEV_LIVE_MIGRATION feature & Custom MSR.
Hello Steve,
Let me first answer those queries which i can do immediately ...
On Fri, Feb 05, 2021 at 06:54:21PM -0800, Steve Rutherford wrote:
> On Thu, Feb 4, 2021 at 7:08 PM Ashish Kalra wrote:
> >
> > Hello Steve,
> >
> > On Thu, Feb 04, 2021 at 04:56:35PM -0800, Steve Rutherford wrote:
> > > On Wed, Feb 3, 2021 at 4:39 PM Ashish Kalra wrote:
> > > >
> > > > From: Ashish Kalra
> > > >
> > > > Add new KVM_FEATURE_SEV_LIVE_MIGRATION feature for guest to check
> > > > for host-side support for SEV live migration. Also add a new custom
> > > > MSR_KVM_SEV_LIVE_MIGRATION for guest to enable the SEV live migration
> > > > feature.
> > > >
> > > > Signed-off-by: Ashish Kalra
> > > > ---
> > > > Documentation/virt/kvm/cpuid.rst | 5 +
> > > > Documentation/virt/kvm/msr.rst | 12
> > > > arch/x86/include/uapi/asm/kvm_para.h | 4
> > > > arch/x86/kvm/svm/sev.c | 13 +
> > > > arch/x86/kvm/svm/svm.c | 16
> > > > arch/x86/kvm/svm/svm.h | 2 ++
> > > > 6 files changed, 52 insertions(+)
> > > >
> > > > diff --git a/Documentation/virt/kvm/cpuid.rst
> > > > b/Documentation/virt/kvm/cpuid.rst
> > > > index cf62162d4be2..0bdb6cdb12d3 100644
> > > > --- a/Documentation/virt/kvm/cpuid.rst
> > > > +++ b/Documentation/virt/kvm/cpuid.rst
> > > > @@ -96,6 +96,11 @@ KVM_FEATURE_MSI_EXT_DEST_ID15 guest
> > > > checks this feature bit
> > > > before using extended
> > > > destination
> > > > ID bits in MSI address
> > > > bits 11-5.
> > > >
> > > > +KVM_FEATURE_SEV_LIVE_MIGRATION 16 guest checks this
> > > > feature bit before
> > > > + using the page
> > > > encryption state
> > > > + hypercall to notify the
> > > > page state
> > > > + change
> > > > +
> > > > KVM_FEATURE_CLOCKSOURCE_STABLE_BIT 24 host will warn if no
> > > > guest-side
> > > > per-cpu warps are
> > > > expected in
> > > > kvmclock
> > > > diff --git a/Documentation/virt/kvm/msr.rst
> > > > b/Documentation/virt/kvm/msr.rst
> > > > index e37a14c323d2..020245d16087 100644
> > > > --- a/Documentation/virt/kvm/msr.rst
> > > > +++ b/Documentation/virt/kvm/msr.rst
> > > > @@ -376,3 +376,15 @@ data:
> > > > write '1' to bit 0 of the MSR, this causes the host to re-scan
> > > > its queue
> > > > and check if there are more notifications pending. The MSR is
> > > > available
> > > > if KVM_FEATURE_ASYNC_PF_INT is present in CPUID.
> > > > +
> > > > +MSR_KVM_SEV_LIVE_MIGRATION:
> > > > +0x4b564d08
> > > > +
> > > > + Control SEV Live Migration features.
> > > > +
> > > > +data:
> > > > +Bit 0 enables (1) or disables (0) host-side SEV Live Migration
> > > > feature,
> > > > +in other words, this is guest->host communication that it's
> > > > properly
> > > > +handling the shared pages list.
> > > > +
> > > > +All other bits are reserved.
> > > > diff --git a/arch/x86/include/uapi/asm/kvm_para.h
> > > > b/arch/x86/include/uapi/asm/kvm_para.h
> > > > index 950afebfba88..f6bfa138874f 100644
> > > > --- a/arch/x86/include/uapi/asm/kvm_para.h
> > > > +++ b/arch/x86/include/uapi/asm/kvm_para.h
> > > > @@ -33,6 +33,7 @@
> > > > #define KVM_FEATURE_PV_SCHED_YIELD 13
> > > > #define KVM_FEATURE_ASYNC_PF_INT 14
> > > > #define KVM_FEATURE_MSI_EXT_DEST_ID15
> > > > +#define KVM_FEATURE_SEV_LIVE_MIGRATION 16
> > > >
> > > > #define KVM_HINTS_REALTIME 0
> > > >
> > > > @@ -54,6 +55,7 @@
> > > > #define MSR_KVM_POLL_CONTROL 0x4b564d05
> > > > #define MSR_KVM_ASYNC_PF_INT 0x4b564d06
> > > > #define MSR_KVM_ASYNC_PF_ACK 0x4b564d07
> > > > +#define MSR_KVM_SEV_LIVE_MIGRATION 0x4b564d08
> > > >
> > > > struct kvm_steal_time {
> > > > __u64 steal;
> > > > @@ -136,4 +138,6 @@ struct kvm_vcpu_pv_apf_data {
> > > > #define KVM_PV_EOI_ENABLED KVM_PV_EOI_MASK
> > > > #define KVM_PV_EOI_DISABLED 0x0
> > > >
> > > > +#define KVM_SEV_LIVE_MIGRATION_ENABLED BIT_ULL(0)
> > > > +
> > > > #endif /* _UAPI_ASM_X86_KVM_PARA_H */
> > > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> > > > index b0d324aed515..93f42b3d3e33 100644
> > > > --- a/arch/x86/kvm/svm/sev.c
> > > > +++ b/arch/x86/kvm/svm/sev.c
> > > > @@ -1627,6 +1627,16 @@ int svm_page_enc_status_hc(struct kvm *kvm,
> > > > unsigned long gpa,
> > > > return ret;
> > > > }
> > > >
> > > > +void sev_update_migration_flags(struct kvm *kvm, u64 data)
> > > > +{
> > > > + struct kvm_sev_info *sev = _kvm_svm(kvm)->sev_info;
> > > > +
> > > > + if (!sev_guest(kvm))
> > > > + return;
> > >
> > >
Re: [PATCH v4 03/22] media: camss: Replace trace_printk() with dev_dbg()
On Fri, Feb 5, 2021 at 6:44 PM Robert Foss wrote:
>
> trace_printk() should not be used in production code,
> since extra memory is used for special buffers whenever
> trace_puts() is used.
>
> Replace it with dev_dbg() which provides all of the desired
> debugging functionality.
>
> Signed-off-by: Robert Foss
> Suggested-by: Nicolas Boichat
Thanks!
Reviewed-by: Nicolas Boichat
> ---
>
> Changes since v3:
> - Nicolas: Create this patch
>
>
> drivers/media/platform/qcom/camss/camss-vfe-4-1.c | 5 +++--
> drivers/media/platform/qcom/camss/camss-vfe-4-7.c | 5 +++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
> b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
> index a1b56b89130d..85b9bcbc7321 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
> @@ -12,6 +12,7 @@
> #include
> #include
>
> +#include "camss.h"
> #include "camss-vfe.h"
>
> #define VFE_0_HW_VERSION 0x000
> @@ -936,8 +937,8 @@ static irqreturn_t vfe_isr(int irq, void *dev)
>
> vfe->ops->isr_read(vfe, , );
>
> - trace_printk("VFE: status0 = 0x%08x, status1 = 0x%08x\n",
> -value0, value1);
> + dev_dbg(vfe->camss->dev, "VFE: status0 = 0x%08x, status1 = 0x%08x\n",
> + value0, value1);
>
> if (value0 & VFE_0_IRQ_STATUS_0_RESET_ACK)
> vfe->isr_ops.reset_ack(vfe);
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
> b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
> index 84c33b8f9fe3..f7e00a2de393 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
> @@ -12,6 +12,7 @@
> #include
> #include
>
> +#include "camss.h"
> #include "camss-vfe.h"
>
> #define VFE_0_HW_VERSION 0x000
> @@ -1069,8 +1070,8 @@ static irqreturn_t vfe_isr(int irq, void *dev)
>
> vfe->ops->isr_read(vfe, , );
>
> - trace_printk("VFE: status0 = 0x%08x, status1 = 0x%08x\n",
> -value0, value1);
> + dev_dbg(vfe->camss->dev, "VFE: status0 = 0x%08x, status1 = 0x%08x\n",
> + value0, value1);
>
> if (value0 & VFE_0_IRQ_STATUS_0_RESET_ACK)
> vfe->isr_ops.reset_ack(vfe);
> --
> 2.27.0
>
Re: [External] Re: [PATCH] mm: memcontrol: remove rcu_read_lock from get_mem_cgroup_from_page
On Sat, Feb 6, 2021 at 2:15 AM Johannes Weiner wrote:
>
> On Fri, Feb 05, 2021 at 11:32:24AM +0100, Michal Hocko wrote:
> > On Fri 05-02-21 17:14:30, Muchun Song wrote:
> > > On Fri, Feb 5, 2021 at 4:36 PM Michal Hocko wrote:
> > > >
> > > > On Fri 05-02-21 14:27:19, Muchun Song wrote:
> > > > > The get_mem_cgroup_from_page() is called under page lock, so the page
> > > > > memcg cannot be changed under us.
> > > >
> > > > Where is the page lock enforced?
> > >
> > > Because it is called from alloc_page_buffers(). This path is under
> > > page lock.
> >
> > I do not see any page lock enforecement there. There is not even a
> > comment requiring that. Can we grow more users where this is not the
> > case? There is no actual relation between alloc_page_buffers and
> > get_mem_cgroup_from_page except that the former is the only _current_
> > existing user. I would be careful to dictate locking based solely on
> > that.
>
> Since alloc_page_buffers() holds the page lock throughout the entire
> time it uses the memcg, there is no actual reason for it to use RCU or
> even acquire an additional reference on the css. We know it's pinned,
> the charge pins it, and the page lock pins the charge. It can neither
> move to a different cgroup nor be uncharged.
Thanks for your patient explanation.
>
> So what do you say we switch alloc_page_buffers() to page_memcg()?
It's better than mine.
>
> And because that removes the last user of get_mem_cgroup_from_page(),
> we can kill it off and worry about a good interface once a consumer
> materializes for it.
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 96c7604f69b3..12a10f461b81 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -847,7 +847,7 @@ struct buffer_head *alloc_page_buffers(struct page *page,
> unsigned long size,
> if (retry)
> gfp |= __GFP_NOFAIL;
>
> - memcg = get_mem_cgroup_from_page(page);
> + memcg = page_memcg(page);
> old_memcg = set_active_memcg(memcg);
>
> head = NULL;
> @@ -868,7 +868,6 @@ struct buffer_head *alloc_page_buffers(struct page *page,
> unsigned long size,
> }
> out:
> set_active_memcg(old_memcg);
> - mem_cgroup_put(memcg);
> return head;
> /*
> * In case anything failed, we just free everything we got.
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index a8c7a0ccc759..a44b2d51aecc 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -687,8 +687,6 @@ struct mem_cgroup *mem_cgroup_from_task(struct
> task_struct *p);
>
> struct mem_cgroup *get_mem_cgroup_from_mm(struct mm_struct *mm);
>
> -struct mem_cgroup *get_mem_cgroup_from_page(struct page *page);
> -
> struct lruvec *lock_page_lruvec(struct page *page);
> struct lruvec *lock_page_lruvec_irq(struct page *page);
> struct lruvec *lock_page_lruvec_irqsave(struct page *page,
> @@ -1169,11 +1167,6 @@ static inline struct mem_cgroup
> *get_mem_cgroup_from_mm(struct mm_struct *mm)
> return NULL;
> }
>
> -static inline struct mem_cgroup *get_mem_cgroup_from_page(struct page *page)
> -{
> - return NULL;
> -}
> -
> static inline void mem_cgroup_put(struct mem_cgroup *memcg)
> {
> }
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 490357945f2c..ff52550d2f65 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1048,29 +1048,6 @@ struct mem_cgroup *get_mem_cgroup_from_mm(struct
> mm_struct *mm)
> }
> EXPORT_SYMBOL(get_mem_cgroup_from_mm);
>
> -/**
> - * get_mem_cgroup_from_page: Obtain a reference on given page's memcg.
> - * @page: page from which memcg should be extracted.
> - *
> - * Obtain a reference on page->memcg and returns it if successful. Otherwise
> - * root_mem_cgroup is returned.
> - */
> -struct mem_cgroup *get_mem_cgroup_from_page(struct page *page)
> -{
> - struct mem_cgroup *memcg = page_memcg(page);
> -
> - if (mem_cgroup_disabled())
> - return NULL;
> -
> - rcu_read_lock();
> - /* Page should not get uncharged and freed memcg under us. */
> - if (!memcg || WARN_ON_ONCE(!css_tryget(>css)))
> - memcg = root_mem_cgroup;
> - rcu_read_unlock();
> - return memcg;
> -}
> -EXPORT_SYMBOL(get_mem_cgroup_from_page);
> -
> static __always_inline struct mem_cgroup *active_memcg(void)
> {
> if (in_interrupt())
Re: [PATCH v2 2/2] of: property: Add fw_devlink support for interrupts
On Fri, Feb 5, 2021 at 9:55 AM Saravana Kannan wrote:
>
> On Fri, Feb 5, 2021 at 9:52 AM Geert Uytterhoeven
> wrote:
> >
> > Hi Saravana,
> >
> > On Fri, Feb 5, 2021 at 6:20 PM Saravana Kannan wrote:
> > > On Fri, Feb 5, 2021 at 2:20 AM Geert Uytterhoeven
> > > wrote:
> > > > On Fri, Feb 5, 2021 at 11:06 AM Saravana Kannan
> > > > wrote:
> > > > > On Fri, Feb 5, 2021 at 12:06 AM Geert Uytterhoeven
> > > > > wrote:
> > > > > > On Fri, Feb 5, 2021 at 8:38 AM Marek Szyprowski
> > > > > > wrote:
> > > > > > > On 04.02.2021 22:31, Saravana Kannan wrote:
> > > > > > > > On Thu, Feb 4, 2021 at 3:52 AM Marek Szyprowski
> > > > > > > > wrote:
> > > > > > > >> On 21.01.2021 23:57, Saravana Kannan wrote:
> > > > > > > >>> This allows fw_devlink to create device links between
> > > > > > > >>> consumers of an
> > > > > > > >>> interrupt and the supplier of the interrupt.
> > > > > > > >>>
> > > > > > > >>> Cc: Marc Zyngier
> > > > > > > >>> Cc: Kevin Hilman
> > > > > > > >>> Cc: Greg Kroah-Hartman
> > > > > > > >>> Reviewed-by: Rob Herring
> > > > > > > >>> Reviewed-by: Thierry Reding
> > > > > > > >>> Reviewed-by: Linus Walleij
> > > > > > > >>> Signed-off-by: Saravana Kannan
> > > > > > > >> This patch landed some time ago in linux-next as commit
> > > > > > > >> 4104ca776ba3
> > > > > > > >> ("of: property: Add fw_devlink support for interrupts"). It
> > > > > > > >> breaks MMC
> > > > > > > >> host controller operation on ARM Juno R1 board (the mmci@5
> > > > > > > >> device
> > > > > > > >> defined in arch/arm64/boot/dts/arm/juno-motherboard.dtsi). I
> > > > > > > >> didn't
> > > > > > > > I grepped around and it looks like the final board file is this
> > > > > > > > or
> > > > > > > > whatever includes it?
> > > > > > > > arch/arm64/boot/dts/arm/juno-base.dtsi
> > > > > > > The final board file is arch/arm64/boot/dts/arm/juno-r1.dts
> > > > > > > > This patch just finds the interrupt-parent and then tries to
> > > > > > > > use that
> > > > > > > > as a supplier if "interrupts" property is listed. But the only
> > > > > > > > interrupt parent I can see is:
> > > > > > > > gic: interrupt-controller@2c01 {
> > > > > > > > compatible = "arm,gic-400",
> > > > > > > > "arm,cortex-a15-gic";
> > > > > > > >
> > > > > > > > And the driver uses IRQCHIP_DECLARE() and hence should be
> > > > > > > > pretty much
> > > > > > > > a NOP since those suppliers are never devices and are ignored.
> > > > > > > > $ git grep "arm,gic-400" -- drivers/
> > > > > > > > drivers/irqchip/irq-gic.c:IRQCHIP_DECLARE(gic_400,
> > > > > > > > "arm,gic-400", gic_of_init);
> > > > > > > >
> > > > > > > > This doesn't make any sense. Am I looking at the right files?
> > > > > > > > Am I
> > > > > > > > missing something?
> > > > > > >
> > > > > > > Okay, I've added displaying a list of deferred devices when
> > > > > > > mounting
> > > > > > > rootfs fails and got following items:
> > > > > > >
> > > > > > > Deferred devices:
> > > > > > > 1800.ethernetplatform: probe deferral - supplier
> > > > > > > bus@800:motherboard-bus not ready
> > > > > > > 1c05.mmciamba: probe deferral - supplier
> > > > > > > bus@800:motherboard-bus not ready
> > > > > > > 1c1d.gpioamba: probe deferral - supplier
> > > > > > > bus@800:motherboard-bus not ready
> > > > > > > 2b60.iommu platform: probe deferral - wait for supplier
> > > > > > > scpi-power-domains
> > > > > > > 7ff5.hdlcd platform: probe deferral - wait for supplier
> > > > > > > scpi-clk
> > > > > > > 7ff6.hdlcd platform: probe deferral - wait for supplier
> > > > > > > scpi-clk
> > > > > > > 1c06.kmi amba: probe deferral - supplier
> > > > > > > bus@800:motherboard-bus not ready
> > > > > > > 1c07.kmi amba: probe deferral - supplier
> > > > > > > bus@800:motherboard-bus not ready
> > > > > > > 1c17.rtc amba: probe deferral - supplier
> > > > > > > bus@800:motherboard-bus not ready
> > > > > > > 1c0f.wdt amba: probe deferral - supplier
> > > > > > > bus@800:motherboard-bus not ready
> > > > > > > gpio-keys
> > > > > > > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > > > > > > unknown-block(0,0)
> > > > > > >
> > > > > > > I don't see the 'bus@800:motherboard-bus' on the deferred
> > > > > > > devices
> > > > > > > list, so it looks that device core added a link to something that
> > > > > > > is not
> > > > > > > a platform device...
> > > > >
> > > > > Probe deferred devices (even platform devices) not showing up in that
> > > > > list is not unusual. That's because devices end up on that list only
> > > > > after a driver for them is matched and then it fails.
> > > > >
> > > > > > Lemme guess: bus@800 is a simple bus, but it has an
> > > > > > interrupt-map, and the devlink code doesn't follow the mapping?
> > > > > >
> > > > >
> > > > > No, what's happening is that (and this is something I just learned)
Re: [PATCH 0/3] drivers/net/ethernet/amd: Follow style guide
On Fri, Feb 5, 2021 at 7:16 PM Randy Dunlap wrote: > > On 2/5/21 4:01 PM, Amy Parker wrote: > > This patchset updates atarilance.c and sun3lance.c to follow the kernel > > style guide. Each patch tackles a different issue in the style guide. > > > >-Amy IP > > > > Amy Parker (3): > > drivers/net/ethernet/amd: Correct spacing around C keywords > > drivers/net/ethernet/amd: Fix bracket matching and line levels > > drivers/net/ethernet/amd: Break apart one-lined expressions > > > > drivers/net/ethernet/amd/atarilance.c | 64 ++- > > drivers/net/ethernet/amd/sun3lance.c | 64 +++ > > 2 files changed, 69 insertions(+), 59 deletions(-) > > > > Hi Amy, > > For each patch, can you confirm that the before & after binary files > are the same? or if they are not the same, explain why not? > > Just something that I have done in the past... > > thanks. At least when I tried - yes. These are just stylistic changes. Currently using gcc version 10.2.1. -Amy IP
Re: [PATCH net 1/1] net: stmmac: set TxQ mode back to DCB after disabling CBS
Hello: This patch was applied to netdev/net.git (refs/heads/master): On Thu, 4 Feb 2021 22:03:16 +0800 you wrote: > From: Mohammad Athari Bin Ismail > > When disable CBS, mode_to_use parameter is not updated even the operation > mode of Tx Queue is changed to Data Centre Bridging (DCB). Therefore, > when tc_setup_cbs() function is called to re-enable CBS, the operation > mode of Tx Queue remains at DCB, which causing CBS fails to work. > > [...] Here is the summary with links: - [net,1/1] net: stmmac: set TxQ mode back to DCB after disabling CBS https://git.kernel.org/netdev/net/c/f317e2ea8c88 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Re: [PATCH] drivers: scsi: Describe and replace a word with better one in the file qlogicpti.h
Hi Bhaskar, On Sat, Feb 6, 2021 at 9:55 AM Bhaskar Chowdhury wrote: > > > > s/fucking/awful/ > > Signed-off-by: Bhaskar Chowdhury > --- > drivers/scsi/qlogicpti.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/qlogicpti.h b/drivers/scsi/qlogicpti.h > index 2b6374e08a7d..4a47631b22ea 100644 > --- a/drivers/scsi/qlogicpti.h > +++ b/drivers/scsi/qlogicpti.h > @@ -62,7 +62,7 @@ > #define REQUEST_QUEUE_WAKEUP 0x8005 > #define EXECUTION_TIMEOUT_RESET0x8006 > > -/* Am I fucking pedantic or what? */ > +/* Am I awful pedantic or what? */ You're right that this needs to go, but "awfully" is a better replacement than "awful". However it's likely that the entire comment can either be removed or replaced with something more descriptive. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/
Re: [Freedreno] [PATCH] drm/msm/dp: remove unneeded semicolon
On 2021-02-02 19:08, Yang Li wrote:
Eliminate the following coccicheck warning:
./drivers/gpu/drm/msm/dp/dp_ctrl.c:1161:2-3: Unneeded semicolon
Reported-by: Abaci Robot
Signed-off-by: Yang Li
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index e3462f5..61ed67b 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1158,7 +1158,7 @@ static int dp_ctrl_link_rate_down_shift(struct
dp_ctrl_private *ctrl)
default:
ret = -EINVAL;
break;
- };
+ }
if (!ret)
DRM_DEBUG_DP("new rate=0x%x\n", ctrl->link->link_params.rate);
Re: [PATCH 3/3] kbuild: introduce KERNEL_VERSION2 and LINUX_VERSION_CODE2
On Fri, Feb 05, 2021 at 10:50:33PM -0500, Sasha Levin wrote: SUBLEVEL only has 8 bits of space, which means that we'll overflow it once it reaches 256. Few of the stable branches will imminently overflow SUBLEVEL while there's no risk of overflowing VERSION. Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this should create a better balance between the different version numbers we use. We can't however use the original KERNEL_VERSION and LINUX_VERSION_CODE as userspace has created ABI dependency on their structure, and we risk breaking this userspace by modifying the layout of the version integers. Cc: sta...@kernel.org Signed-off-by: Sasha Levin Reviewed-by: Greg Kroah-Hartman Signed-off-by: Masahiro Yamada I wanted to re-use an older commit but forgot to drop the two tags above. The tags from Masahiro and Greg shouldn't be here, sorry about that. -- Thanks, Sasha
Re: [PATCH 0/8] mm: memcontrol: switch to rstat v2
On Fri, Feb 05, 2021 at 01:27:58PM -0500, Johannes Weiner wrote: > This is version 2 of the memcg rstat patches. Updates since v1: > > - added cgroup selftest output (see test section below) (thanks Roman) > - updated cgroup selftest to match new kernel implementation > - added Fixes: tag to 'mm: memcontrol: fix cpuhotplug statistics flushing' > (Shakeel) > - collected review & ack tags > - added rstat overview to 'mm: memcontrol: switch to rstat' changelog (Michal) > - simplified memcg_flush_lruvec_page_state() and removed cpu==-1 case (Michal) The whole series looks good to me. Please feel free to route the rstat patches with the rest of the series. Thanks. -- tejun
[PATCH 3/3] kbuild: introduce KERNEL_VERSION2 and LINUX_VERSION_CODE2
SUBLEVEL only has 8 bits of space, which means that we'll overflow it
once it reaches 256.
Few of the stable branches will imminently overflow SUBLEVEL while
there's no risk of overflowing VERSION.
Thus, give SUBLEVEL 8 more bits which will be stolen from VERSION, this
should create a better balance between the different version numbers we
use.
We can't however use the original KERNEL_VERSION and LINUX_VERSION_CODE
as userspace has created ABI dependency on their structure, and we risk
breaking this userspace by modifying the layout of the version integers.
Cc: sta...@kernel.org
Signed-off-by: Sasha Levin
Reviewed-by: Greg Kroah-Hartman
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin
---
Makefile | 8 +++-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ++--
drivers/usb/core/hcd.c | 4 ++--
drivers/usb/gadget/udc/aspeed-vhub/hub.c | 4 ++--
include/linux/usb/composite.h | 4 ++--
kernel/sys.c | 2 +-
tools/perf/tests/bpf-script-example.c | 2 +-
tools/perf/tests/bpf-script-test-kbuild.c | 2 +-
tools/perf/tests/bpf-script-test-prologue.c| 2 +-
9 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/Makefile b/Makefile
index 157be50c691e5..2177c548e4c24 100644
--- a/Makefile
+++ b/Makefile
@@ -1266,7 +1266,13 @@ define filechk_version.h
expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 +
$(SUBLEVEL)); \
fi; \
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + \
- ((c) > 255 ? 255 : (c)))'
+ ((c) > 255 ? 255 : (c)))'; \
+ echo \#define LINUX_VERSION_CODE2 $(shell\
+ expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
+ echo \#define LINUX_VERSION_MAJOR $(VERSION);\
+ echo \#define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL);\
+ echo \#define LINUX_VERSION_SUBLEVEL $(SUBLEVEL);\
+ echo '#define KERNEL_VERSION2(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
endef
$(version_h): FORCE
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index e4c9627485aa5..989f15d9aa7d4 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -237,8 +237,8 @@ static void mlx5_set_driver_version(struct mlx5_core_dev
*dev)
remaining_size = max_t(int, 0, driver_ver_sz - strlen(string));
snprintf(string + strlen(string), remaining_size, "%u.%u.%u",
-(u8)((LINUX_VERSION_CODE >> 16) & 0xff),
(u8)((LINUX_VERSION_CODE >> 8) & 0xff),
-(u16)(LINUX_VERSION_CODE & 0x));
+ (u8)(LINUX_VERSION_MAJOR), (u8)(LINUX_VERSION_PATCHLEVEL),
+ (u16)(LINUX_VERSION_SUBLEVEL));
/*Send the command*/
MLX5_SET(set_driver_version_in, in, opcode,
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index ad5a0f405a75c..3f0381344221e 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -111,8 +111,8 @@ DECLARE_WAIT_QUEUE_HEAD(usb_kill_urb_queue);
*/
/*-*/
-#define KERNEL_REL bin2bcd(((LINUX_VERSION_CODE >> 16) & 0x0ff))
-#define KERNEL_VER bin2bcd(((LINUX_VERSION_CODE >> 8) & 0x0ff))
+#define KERNEL_REL bin2bcd(LINUX_VERSION_MAJOR)
+#define KERNEL_VER bin2bcd(LINUX_VERSION_PATCHLEVEL)
/* usb 3.1 root hub device descriptor */
static const u8 usb31_rh_dev_descriptor[18] = {
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/hub.c
b/drivers/usb/gadget/udc/aspeed-vhub/hub.c
index bfd8e77788e29..5c7dea5e0ff16 100644
--- a/drivers/usb/gadget/udc/aspeed-vhub/hub.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/hub.c
@@ -46,8 +46,8 @@
*- Make vid/did overridable
*- make it look like usb1 if usb1 mode forced
*/
-#define KERNEL_REL bin2bcd(((LINUX_VERSION_CODE >> 16) & 0x0ff))
-#define KERNEL_VER bin2bcd(((LINUX_VERSION_CODE >> 8) & 0x0ff))
+#define KERNEL_REL bin2bcd(LINUX_VERSION_MAJOR)
+#define KERNEL_VER bin2bcd(LINUX_VERSION_PATCHLEVEL)
enum {
AST_VHUB_STR_INDEX_MAX = 4,
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 5646dad886e61..c71150f2c6390 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -575,8 +575,8 @@ static inline u16 get_default_bcdDevice(void)
{
u16 bcdDevice;
- bcdDevice = bin2bcd((LINUX_VERSION_CODE >> 16 & 0xff)) << 8;
- bcdDevice |= bin2bcd((LINUX_VERSION_CODE >> 8 & 0xff));
+ bcdDevice = bin2bcd(LINUX_VERSION_MAJOR) << 8;
+ bcdDevice |= bin2bcd(LINUX_VERSION_PATCHLEVEL);
return bcdDevice;
}
diff --git a/kernel/sys.c
Re: [PATCH 1/5] clk: rockchip: add clock ids for PCLK_DPHYRX and PCLK_DPHYTX0 on rk3368
On Fri, 5 Feb 2021 12:04:58 +0100, Heiko Stuebner wrote: > Needed by the mipi dphys. > The naming follows the clock names in the manual. Applied, thanks! [1/5] clk: rockchip: add clock ids for PCLK_DPHYRX and PCLK_DPHYTX0 on rk3368 commit: 0be10b6f68b217876665031f643e571a5661fc9c [2/5] clk: rockchip: use clock ids for PCLK_DPHYRX and PCLK_DPHYTX0 on rk3368 commit: fabb841c5b16721298cfe649b569a4fa40af28a6 [3/5] clk: rockchip: add clock id for SCLK_VIP_OUT on rk3368 commit: 686458aa752362f86d881d7fa4576c9f175b2d9b [4/5] clk: rockchip: use clock id for SCLK_VIP_OUT on rk3368 commit: ed2243e0038b8afdd7726d117da34ee4577e11ad [5/5] clk: rockchip: fix DPHY gate locations on rk3368 commit: 4bc23b3c83c9a3fc0a7dd8f2f11f451aa92c85cd Best regards, -- Heiko Stuebner
[PATCH 1/3] Revert "kbuild: give the SUBLEVEL more room in KERNEL_VERSION"
This reverts commit 537896fabed11f8d976d1aacdb977213c7b3.
This turns out to be a bad idea: userspace has coded the structure of
KERNEL_VERSION on it's own and assumes the 2-1-1 byte split, making it
userspace ABI we can't break.
The reverted patch didn't make it past linux-next, so no userspace was
hurt in the process.
Signed-off-by: Sasha Levin
---
Makefile | 7 ++-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ++--
drivers/usb/core/hcd.c | 4 ++--
drivers/usb/gadget/udc/aspeed-vhub/hub.c | 4 ++--
include/linux/usb/composite.h | 4 ++--
kernel/sys.c | 2 +-
tools/perf/tests/bpf-script-example.c | 2 +-
tools/perf/tests/bpf-script-test-kbuild.c | 2 +-
tools/perf/tests/bpf-script-test-prologue.c| 2 +-
9 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/Makefile b/Makefile
index 28019532e55ac..49ac1b7fe8e99 100644
--- a/Makefile
+++ b/Makefile
@@ -1259,11 +1259,8 @@ endef
define filechk_version.h
echo \#define LINUX_VERSION_CODE $(shell \
- expr $(VERSION) \* 16777216 + 0$(PATCHLEVEL) \* 65536 + 0$(SUBLEVEL)); \
- echo \#define LINUX_VERSION_MAJOR $(VERSION); \
- echo \#define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL); \
- echo \#define LINUX_VERSION_SUBLEVEL $(SUBLEVEL); \
- echo '#define KERNEL_VERSION(a,b,c) (((a) << 24) + ((b) << 16) + (c))'
+ expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
+ echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
endef
$(version_h): FORCE
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 989f15d9aa7d4..e4c9627485aa5 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -237,8 +237,8 @@ static void mlx5_set_driver_version(struct mlx5_core_dev
*dev)
remaining_size = max_t(int, 0, driver_ver_sz - strlen(string));
snprintf(string + strlen(string), remaining_size, "%u.%u.%u",
- (u8)(LINUX_VERSION_MAJOR), (u8)(LINUX_VERSION_PATCHLEVEL),
- (u16)(LINUX_VERSION_SUBLEVEL));
+(u8)((LINUX_VERSION_CODE >> 16) & 0xff),
(u8)((LINUX_VERSION_CODE >> 8) & 0xff),
+(u16)(LINUX_VERSION_CODE & 0x));
/*Send the command*/
MLX5_SET(set_driver_version_in, in, opcode,
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 3f0381344221e..ad5a0f405a75c 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -111,8 +111,8 @@ DECLARE_WAIT_QUEUE_HEAD(usb_kill_urb_queue);
*/
/*-*/
-#define KERNEL_REL bin2bcd(LINUX_VERSION_MAJOR)
-#define KERNEL_VER bin2bcd(LINUX_VERSION_PATCHLEVEL)
+#define KERNEL_REL bin2bcd(((LINUX_VERSION_CODE >> 16) & 0x0ff))
+#define KERNEL_VER bin2bcd(((LINUX_VERSION_CODE >> 8) & 0x0ff))
/* usb 3.1 root hub device descriptor */
static const u8 usb31_rh_dev_descriptor[18] = {
diff --git a/drivers/usb/gadget/udc/aspeed-vhub/hub.c
b/drivers/usb/gadget/udc/aspeed-vhub/hub.c
index 5c7dea5e0ff16..bfd8e77788e29 100644
--- a/drivers/usb/gadget/udc/aspeed-vhub/hub.c
+++ b/drivers/usb/gadget/udc/aspeed-vhub/hub.c
@@ -46,8 +46,8 @@
*- Make vid/did overridable
*- make it look like usb1 if usb1 mode forced
*/
-#define KERNEL_REL bin2bcd(LINUX_VERSION_MAJOR)
-#define KERNEL_VER bin2bcd(LINUX_VERSION_PATCHLEVEL)
+#define KERNEL_REL bin2bcd(((LINUX_VERSION_CODE >> 16) & 0x0ff))
+#define KERNEL_VER bin2bcd(((LINUX_VERSION_CODE >> 8) & 0x0ff))
enum {
AST_VHUB_STR_INDEX_MAX = 4,
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index c71150f2c6390..5646dad886e61 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -575,8 +575,8 @@ static inline u16 get_default_bcdDevice(void)
{
u16 bcdDevice;
- bcdDevice = bin2bcd(LINUX_VERSION_MAJOR) << 8;
- bcdDevice |= bin2bcd(LINUX_VERSION_PATCHLEVEL);
+ bcdDevice = bin2bcd((LINUX_VERSION_CODE >> 16 & 0xff)) << 8;
+ bcdDevice |= bin2bcd((LINUX_VERSION_CODE >> 8 & 0xff));
return bcdDevice;
}
diff --git a/kernel/sys.c b/kernel/sys.c
index b09fe21e88ff5..8bb46e50f02d4 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1242,7 +1242,7 @@ static int override_release(char __user *release, size_t
len)
break;
rest++;
}
- v = LINUX_VERSION_PATCHLEVEL + 60;
+ v = ((LINUX_VERSION_CODE >> 8) & 0xff) + 60;
copy = clamp_t(size_t, len, 1, sizeof(buf));
copy = scnprintf(buf, copy, "2.6.%u%s", v, rest);
ret = copy_to_user(release, buf, copy + 1);
diff --git
[PATCH 2/3] kbuild: clamp SUBLEVEL to 255
Right now if SUBLEVEL becomes larger than 255 it will overflow into the territory of PATCHLEVEL, causing havoc in userspace that tests for specific kernel version. While userspace code tests for MAJOR and PATCHLEVEL, it doesn't test SUBLEVEL at any point as ABI changes don't happen in the context of stable tree. Thus, to avoid overflows, simply clamp SUBLEVEL to it's maximum value in the context of LINUX_VERSION_CODE. This does not affect "make kernelversion" and such. Signed-off-by: Sasha Levin --- Makefile | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 49ac1b7fe8e99..157be50c691e5 100644 --- a/Makefile +++ b/Makefile @@ -1258,9 +1258,15 @@ define filechk_utsrelease.h endef define filechk_version.h - echo \#define LINUX_VERSION_CODE $(shell \ - expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \ - echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))' + if [ $(SUBLEVEL) -gt 255 ]; then \ + echo \#define LINUX_VERSION_CODE $(shell \ + expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 255); \ + else \ + echo \#define LINUX_VERSION_CODE $(shell \ + expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + $(SUBLEVEL)); \ + fi; \ + echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + \ + ((c) > 255 ? 255 : (c)))' endef $(version_h): FORCE -- 2.27.0
Re: [PATCH v4 5/5] phy: phy-hi3670-usb3: move driver from staging into phy
On Tue, 19 Jan 2021 11:44:43 +0100, Mauro Carvalho Chehab wrote: > The phy USB3 driver for Hisilicon 970 (hi3670) is ready > for mainstream. Mode it from staging into the main driver's > phy/ directory. > > Signed-off-by: Mauro Carvalho Chehab > --- > .../bindings/phy/hisilicon,hi3670-usb3.yaml | 73 ++ > MAINTAINERS | 9 +- > drivers/phy/hisilicon/Kconfig | 10 + > drivers/phy/hisilicon/Makefile| 1 + > drivers/phy/hisilicon/phy-hi3670-usb3.c | 668 ++ > drivers/staging/hikey9xx/Kconfig | 11 - > drivers/staging/hikey9xx/Makefile | 2 - > drivers/staging/hikey9xx/phy-hi3670-usb3.c| 668 -- > drivers/staging/hikey9xx/phy-hi3670-usb3.yaml | 73 -- > 9 files changed, 760 insertions(+), 755 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml > create mode 100644 drivers/phy/hisilicon/phy-hi3670-usb3.c > delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.c > delete mode 100644 drivers/staging/hikey9xx/phy-hi3670-usb3.yaml > Acked-by: Rob Herring
general protection fault in ieee80211_assign_vif_chanctx
Hello, syzbot found the following issue on: HEAD commit:3aaf0a27 Merge tag 'clang-format-for-linux-v5.11-rc7' of g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11dde95f50 kernel config: https://syzkaller.appspot.com/x/.config?x=266a5362c89c8127 dashboard link: https://syzkaller.appspot.com/bug?extid=bbf402b783eeb6d908db compiler: Debian clang version 11.0.1-2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11fea674d0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1054d88cd0 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+bbf402b783eeb6d90...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xfbd59c20: [#1] PREEMPT SMP KASAN KASAN: maybe wild-memory-access in range [0xdead0100-0xdead0107] CPU: 0 PID: 10022 Comm: syz-executor445 Not tainted 5.11.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:ieee80211_chanctx_num_assigned net/mac80211/chan.c:22 [inline] RIP: 0010:ieee80211_assign_vif_chanctx+0x6a7/0xa80 net/mac80211/chan.c:746 Code: 08 00 0f 85 96 00 00 00 e9 f7 00 00 00 e8 a1 ce 8a f8 49 83 c6 20 31 db 4c 89 f5 0f 1f 84 00 00 00 00 00 48 89 e8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 ef e8 fa 34 ce f8 48 8b 6d 00 4c 39 f5 RSP: 0018:c90007fef670 EFLAGS: 00010a02 RAX: 1bd5a020 RBX: 0002 RCX: 8880156c1bc0 RDX: RSI: 0001 RDI: RBP: dead0100 R08: 88ecf9e5 R09: fbfff1b672de R10: fbfff1b672de R11: R12: R13: dc00 R14: 888013e2b020 R15: 88801bff0bc0 FS: 7f5557b86700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f5557b85288 CR3: 24a0d000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __ieee80211_vif_release_channel+0x279/0x540 net/mac80211/chan.c:1619 ieee80211_vif_release_channel+0x13e/0x1a0 net/mac80211/chan.c:1833 ieee80211_ibss_disconnect+0x6ea/0x870 net/mac80211/ibss.c:735 ieee80211_ibss_leave+0x26/0xf0 net/mac80211/ibss.c:1871 rdev_leave_ibss net/wireless/rdev-ops.h:545 [inline] __cfg80211_leave_ibss+0x11c/0x200 net/wireless/ibss.c:212 cfg80211_leave_ibss+0x5c/0x70 net/wireless/ibss.c:230 cfg80211_change_iface+0x428/0xaa0 net/wireless/util.c:1047 nl80211_set_interface+0x497/0x7f0 net/wireless/nl80211.c:3839 genl_family_rcv_msg_doit net/netlink/genetlink.c:739 [inline] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0xe4e/0x1280 net/netlink/genetlink.c:800 netlink_rcv_skb+0x190/0x3a0 net/netlink/af_netlink.c:2494 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x786/0x940 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x9ae/0xd50 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] sys_sendmsg+0x519/0x800 net/socket.c:2345 ___sys_sendmsg net/socket.c:2399 [inline] __sys_sendmsg+0x2bf/0x370 net/socket.c:2432 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x446889 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:7f5557b862f8 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 004cb440 RCX: 00446889 RDX: RSI: 2340 RDI: 0003 RBP: 004cb44c R08: 0003 R09: R10: 0008 R11: 0246 R12: 0049b254 R13: 0031313230386c6e R14: R15: 004cb448 Modules linked in: ---[ end trace 986da0a98b3932dc ]--- RIP: 0010:ieee80211_chanctx_num_assigned net/mac80211/chan.c:22 [inline] RIP: 0010:ieee80211_assign_vif_chanctx+0x6a7/0xa80 net/mac80211/chan.c:746 Code: 08 00 0f 85 96 00 00 00 e9 f7 00 00 00 e8 a1 ce 8a f8 49 83 c6 20 31 db 4c 89 f5 0f 1f 84 00 00 00 00 00 48 89 e8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 ef e8 fa 34 ce f8 48 8b 6d 00 4c 39 f5 RSP: 0018:c90007fef670 EFLAGS: 00010a02 RAX: 1bd5a020 RBX: 0002 RCX: 8880156c1bc0 RDX: RSI: 0001 RDI: RBP: dead0100 R08: 88ecf9e5 R09: fbfff1b672de R10: fbfff1b672de R11: R12: R13: dc00 R14: 888013e2b020 R15: 88801bff0bc0 FS: 7f5557b86700() GS:8880b9c0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2:
Re: [PATCH] Makefile: reuse CC_VERSION_TEXT
On Sat, Feb 6, 2021 at 2:49 AM Masahiro Yamada wrote:
>
> On Sat, Feb 6, 2021 at 7:01 AM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > I noticed we're invoking $(CC) via $(shell) more than once to check the
> > version. Let's reuse the first string captured in $CC_VERSION_TEXT.
> >
> > Fixes: 315bab4e972d ("kbuild: fix endless syncconfig in case arch Makefile
> > sets CROSS_COMPILE")
>
>
> I did not touch this hunk because I have a plan
> for different refactoring, but I have never got
> around to do it.
>
> Anyway, you beat me, and I will pick this up.
> But, the Fixes tag is questionable because
> this is code refactoring.
>
When I see this... and hear refactoring... As a suggestion/improvement...
Can we have LD_VERSION_TEXT analogue to CC_VERSION_TEXT?
Both are shown when doing a `cat /proc/version` (and IIRC in file
include/generated/compile.h).
Thanks.
- Sedat -
>
> > Signed-off-by: Nick Desaulniers
> > ---
> > Makefile | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index a85535eb6a7d..70034d7c1051 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -557,7 +557,13 @@ ifdef building_out_of_srctree
> > { echo "# this is build directory, ignore it"; echo "*"; } >
> > .gitignore
> > endif
> >
> > -ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
> > +# The expansion should be delayed until arch/$(SRCARCH)/Makefile is
> > included.
> > +# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
> > +# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
> > +# and from include/config/auto.conf.cmd to detect the compiler upgrade.
> > +CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1)
> > +
> > +ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
> > ifneq ($(CROSS_COMPILE),)
> > CLANG_FLAGS+= --target=$(notdir $(CROSS_COMPILE:%-=%))
> > GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
> > @@ -576,12 +582,6 @@ KBUILD_AFLAGS += $(CLANG_FLAGS)
> > export CLANG_FLAGS
> > endif
> >
> > -# The expansion should be delayed until arch/$(SRCARCH)/Makefile is
> > included.
> > -# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
> > -# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
> > -# and from include/config/auto.conf.cmd to detect the compiler upgrade.
> > -CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1)
> > -
> > ifdef config-build
> > #
> > ===
> > # *config targets only - make sure prerequisites are updated, and descend
> > --
> > 2.30.0.478.g8a0d178c01-goog
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Clang Built Linux" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clang-built-linux+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/clang-built-linux/20210205220125.2931504-1-ndesaulniers%40google.com.
>
>
>
> --
> Best Regards
> Masahiro Yamada
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/CAK7LNARKHvjTcnic%3DZKntH3NY5meehQbJuBr34y9_tn8b-Ym0w%40mail.gmail.com.
Re: [PATCH v4 1/2] dt-bindings: counter: add pulse-counter binding
On Thu, Jan 28, 2021 at 02:39:22PM +0100, Oleksij Rempel wrote:
> On Thu, Jan 28, 2021 at 09:17:23AM +0100, Linus Walleij wrote:
> > Hi Oleksij,
> >
> > thanks for your patch!
> >
> > On Tue, Jan 26, 2021 at 2:15 PM Oleksij Rempel
> > wrote:
> >
> > > Add binding for the pulse counter node
> > >
> > > Signed-off-by: Oleksij Rempel
> > (...)
> >
> > > +properties:
> > > + compatible:
> > > +const: virtual,pulse-counter
> >
> > What is so virtual about this? The device seems very real.
>
> Currently there are two ways:
> 1. use "virtual" or "linux" vendor. Same as "virtual,mdio-gpio"
virtual is used by exactly one case. linux for a few more, mostly
linux,spdif-dit and extcon (deprecated).
> 2. Extend the list of "not vendor" prefixes in the prefixes list:
>Documentation/devicetree/bindings/vendor-prefixes.yaml
Pretty sure that says 'DON'T ADD MORE'. Maybe I forgot to scream it.
>
> Since both ways seems to be valid, i personally prefer to use existing
> prefix instead of maintaining the vendor-prefixes.yaml
>
> @Rob, what do you prefer?
For vendorless bindings, no vendor prefix! 'gpio-counter' if only gpio
interfaced. No idea what other options would be.
>
> > However it is certainly a GPIO counter.
>
> This was my first implementation. @Jonathan you suggest to use GPIO-free
> way, can you and Linus please decide what is the way to go.
>
> I personally can imagine that this driver can be attached to any IRQ
> source, including drivers/iio/trigger/iio-trig-sysfs.c
>
> > I would call it "gpio-counter" simply.
> >
> > Define:
> > $nodename:
> > pattern: "^counter(@.*)?$"
> >
> > > +counter-0 {
> >
> > counter@0 {
> >
> > > +counter-1 {
> >
> > counter@1 {
>
> In this case the dtc compiler will say:
> /counter@0: node has a unit name, but no reg property
counter-0 then.
>
> Regards,
> Oleksij
> --
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | http://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v2 20/28] KVM: x86/mmu: Use atomic ops to set SPTEs in TDP MMU map
On Wed, Feb 03, 2021, Paolo Bonzini wrote: > On 02/02/21 19:57, Ben Gardon wrote: > > To prepare for handling page faults in parallel, change the TDP MMU > > page fault handler to use atomic operations to set SPTEs so that changes > > are not lost if multiple threads attempt to modify the same SPTE. > > > > Reviewed-by: Peter Feiner > > Signed-off-by: Ben Gardon > > > > --- > > > > v1 -> v2 > > - Rename "atomic" arg to "shared" in multiple functions > > - Merged the commit that protects the lists of TDP MMU pages with a new > >lock > > - Merged the commits to add an atomic option for setting SPTEs and to > >use that option in the TDP MMU page fault handler > > I'll look at the kernel test robot report if nobody beats me to it. It's just a vanilla i386 compilation issue, the xchg() is on an 8-byte value. We could fudge around it via #ifdef around the xchg(). Making all of tdp_mmu.c x86-64 only would be nice to avoid future annoyance, though the number of stubs required would be painful...
[PATCH v5 07/34] keembay-vpu-ipc: Add Keem Bay VPU IPC module
From: Paul Murphy Intel Keem Bay SoC contains a Vision Processing Unit (VPU) to enable machine vision and other applications. Enable Linux to control the VPU processor and provides an interface to the Keem Bay IPC for communicating with the VPU firmware. Specifically the driver provides the following functionality to other kernel components: - Starting (including loading the VPU firmware) / Stopping / Rebooting the VPU. - Getting notifications of VPU events (e.g., WDT events). - Communicating with the VPU via the Keem Bay IPC mechanism. In addition to the above, the driver also exposes SoC information (like stepping, device ID, etc.) to user-space via sysfs. Specifically, the following sysfs files are provided: - /sys/firmware/keembay-vpu-ipc/device_id - /sys/firmware/keembay-vpu-ipc/feature_exclusion - /sys/firmware/keembay-vpu-ipc/hardware_id - /sys/firmware/keembay-vpu-ipc/sku - /sys/firmware/keembay-vpu-ipc/stepping Co-developed-by: Daniele Alessandrelli Signed-off-by: Daniele Alessandrelli Signed-off-by: Mark Gross Signed-off-by: Paul Murphy --- MAINTAINERS |9 + drivers/soc/intel/Kconfig | 15 + drivers/soc/intel/Makefile|3 +- drivers/soc/intel/keembay-vpu-ipc.c | 2026 + include/linux/soc/intel/keembay-vpu-ipc.h | 62 + 5 files changed, 2114 insertions(+), 1 deletion(-) create mode 100644 drivers/soc/intel/keembay-vpu-ipc.c create mode 100644 include/linux/soc/intel/keembay-vpu-ipc.h diff --git a/MAINTAINERS b/MAINTAINERS index b409f87af522..797a1ff7057c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9066,6 +9066,15 @@ F: Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml F: drivers/soc/intel/keembay-ipc.c F: include/linux/soc/intel/keembay-ipc.h +INTEL KEEM BAY VPU IPC DRIVER +M: Paul J Murphy +M: Daniele Alessandrelli +M: Mark Gross +S: Supported +F: Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml +F: drivers/soc/intel/keembay-vpu-ipc.c +F: include/linux/soc/intel/keembay-vpu-ipc.h + INTEL MANAGEMENT ENGINE (mei) M: Tomas Winkler L: linux-kernel@vger.kernel.org diff --git a/drivers/soc/intel/Kconfig b/drivers/soc/intel/Kconfig index a575e31e47b4..ebd23ea57d04 100644 --- a/drivers/soc/intel/Kconfig +++ b/drivers/soc/intel/Kconfig @@ -15,4 +15,19 @@ config KEEMBAY_IPC Select this if you are compiling the Kernel for an Intel SoC that includes the Intel Vision Processing Unit (VPU) such as Keem Bay. + +config KEEMBAY_VPU_IPC + tristate "Intel Keem Bay VPU IPC Driver" + depends on KEEMBAY_IPC + depends on HAVE_ARM_SMCCC + help + This option enables support for loading and communicating with + the firmware on the Vision Processing Unit (VPU) of the Keem Bay + SoC. The driver depends on the Keem Bay IPC driver to do + communication, and it depends on secure world monitor software to + do the control of the VPU state. + + Select this if you are compiling the Kernel for an Intel SoC that + includes the Intel Vision Processing Unit (VPU) such as Keem Bay. + endmenu diff --git a/drivers/soc/intel/Makefile b/drivers/soc/intel/Makefile index ecf0246e7822..363a81848843 100644 --- a/drivers/soc/intel/Makefile +++ b/drivers/soc/intel/Makefile @@ -1,4 +1,5 @@ # # Makefile for Keem Bay IPC Linux driver # -obj-$(CONFIG_KEEMBAY_IPC) += keembay-ipc.o +obj-$(CONFIG_KEEMBAY_IPC) += keembay-ipc.o +obj-$(CONFIG_KEEMBAY_VPU_IPC) += keembay-vpu-ipc.o diff --git a/drivers/soc/intel/keembay-vpu-ipc.c b/drivers/soc/intel/keembay-vpu-ipc.c new file mode 100644 index ..8f3d6a466629 --- /dev/null +++ b/drivers/soc/intel/keembay-vpu-ipc.c @@ -0,0 +1,2026 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Keem Bay VPU IPC Driver. + * + * Copyright (c) 2018-2020 Intel Corporation. + * + * The purpose of this driver is to facilitate booting, control and + * communication with the VPU IP on the Keem Bay SoC. + * + * Specifically the driver provides the following functionality to other kernel + * components: + * - Loading the VPU firmware into DDR for the VPU to execute. + * - Starting / Stopping / Rebooting the VPU. + * - Getting notifications of VPU events (e.g., WDT events). + * - Communicating with the VPU using the Keem Bay IPC mechanism. + * + * In addition to the above, the driver also exposes SoC information (like + * stepping, device ID, etc.) to user-space via sysfs. + * + * + * VPU Firmware loading + * + * + * The VPU Firmware consists of both the RTOS and the application code meant to + * be run by the VPU. + * + * The VPU Firmware is loaded into DDR using the Linux Firmware API. The + * firmware is loaded into a specific reserved memory region in DDR and + * executed by the VPU directly from there. + * + * The VPU Firmware binary is expected to have the
Re: [PATCH 5/8] cgroup: rstat: punt root-level optimization to individual controllers
Hello,
On Fri, Feb 05, 2021 at 01:28:03PM -0500, Johannes Weiner wrote:
> Current users of the rstat code can source root-level statistics from
> the native counters of their respective subsystem, allowing them to
> forego aggregation at the root level. This optimization is currently
> implemented inside the generic rstat code, which doesn't track the
> root cgroup and doesn't invoke the subsystem flush callbacks on it.
>
> However, the memory controller cannot do this optimization, because
> cgroup1 breaks out memory specifically for the local level, including
> at the root level. In preparation for the memory controller switching
> to rstat, move the optimization from rstat core to the controllers.
>
> Afterwards, rstat will always track the root cgroup for changes and
> invoke the subsystem callbacks on it; and it's up to the subsystem to
> special-case and skip aggregation of the root cgroup if it can source
> this information through other, cheaper means.
>
> The extra cost of tracking the root cgroup is negligible: on stat
> changes, we actually remove a branch that checks for the root. The
> queueing for a flush touches only per-cpu data, and only the first
> stat change since a flush requires a (per-cpu) lock.
>
> Signed-off-by: Johannes Weiner
Generally looks good to me.
Acked-by: Tejun Heo
A couple nits below.
> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c
> index 02ce2058c14b..76725e1cad7f 100644
> --- a/block/blk-cgroup.c
> +++ b/block/blk-cgroup.c
> @@ -766,6 +766,10 @@ static void blkcg_rstat_flush(struct cgroup_subsys_state
> *css, int cpu)
> struct blkcg *blkcg = css_to_blkcg(css);
> struct blkcg_gq *blkg;
>
> + /* Root-level stats are sourced from system-wide IO stats */
> + if (!cgroup_parent(css->cgroup))
> + return;
> +
> rcu_read_lock();
>
> hlist_for_each_entry_rcu(blkg, >blkg_list, blkcg_node) {
> @@ -789,6 +793,7 @@ static void blkcg_rstat_flush(struct cgroup_subsys_state
> *css, int cpu)
> u64_stats_update_end(>iostat.sync);
>
> /* propagate global delta to parent */
> + /* XXX: could skip this if parent is root */
> if (parent) {
> u64_stats_update_begin(>iostat.sync);
> blkg_iostat_set(, >iostat.cur);
Might as well update this similar to cgroup_base_stat_flush()?
> @@ -58,8 +53,16 @@ void cgroup_rstat_updated(struct cgroup *cgrp, int cpu)
> if (rstatc->updated_next)
> break;
>
> + if (!parent) {
Maybe useful to note that the node is being marked busy but not added to the
non-existent parent.
> + rstatc->updated_next = cgrp;
> + break;
> + }
> +
> + prstatc = cgroup_rstat_cpu(parent, cpu);
> rstatc->updated_next = prstatc->updated_children;
> prstatc->updated_children = cgrp;
> +
> + cgrp = parent;
> }
>
> raw_spin_unlock_irqrestore(cpu_lock, flags);
...
> static void cgroup_base_stat_flush(struct cgroup *cgrp, int cpu)
> {
> - struct cgroup *parent = cgroup_parent(cgrp);
> struct cgroup_rstat_cpu *rstatc = cgroup_rstat_cpu(cgrp, cpu);
> + struct cgroup *parent = cgroup_parent(cgrp);
Is this chunk intentional?
> struct cgroup_base_stat cur, delta;
> unsigned seq;
>
> + /* Root-level stats are sourced from system-wide CPU stats */
> + if (!parent)
> + return;
> +
> /* fetch the current per-cpu values */
> do {
> seq = __u64_stats_fetch_begin(>bsync);
> @@ -326,8 +336,8 @@ static void cgroup_base_stat_flush(struct cgroup *cgrp,
> int cpu)
> cgroup_base_stat_add(>bstat, );
> cgroup_base_stat_add(>last_bstat, );
>
> - /* propagate global delta to parent */
> - if (parent) {
> + /* propagate global delta to parent (unless that's root) */
> + if (cgroup_parent(parent)) {
Yeah, this makes sense. Can you add a short while-at-it note in the patch
description?
Thanks.
--
tejun
Re: [PATCH v9 1/3] vmlinux.lds.h: add DWARF v5 sections
On Fri, 5 Feb 2021 12:22:18 -0800 Nick Desaulniers wrote: > We expect toolchains to produce these new debug info sections as part of > DWARF v5. Add explicit placements to prevent the linker warnings from > --orphan-section=warn. > > Compilers may produce such sections with explicit -gdwarf-5, or based on > the implicit default version of DWARF when -g is used via DEBUG_INFO. > This implicit default changes over time, and has changed to DWARF v5 > with GCC 11. > > .debug_sup was mentioned in review, but without compilers producing it > today, let's wait to add it until it becomes necessary. > There isn't anything in this changelog which explains why a -stable backport was requested? Or is there? Irritating linker warnings? More than that?
Re: [PATCH] printk: Userspace format enumeration support
On Fri, 5 Feb 2021 22:45:19 + Chris Down wrote: > >I'm not against the idea. I don't think it belongs in /proc. Perhaps > >debugfs is a better place to put it. > > Any location is fine with me, as long as it gets to userspace. How does > /printk/formats or /printk/formats/ sound to you? I'm fine with it, if others are. Something like this will probably need approval from others on the Cc list here. -- Steve
[PATCH v5 21/34] xlink-core: Enable xlink protocol over pcie
From: Seamus Kelly
Enable host system access to the VPU over the xlink protocol over PCIe by
enabling channel multiplexing and dispatching. This allows for remote host
communication channels across pcie links.
add dispatcher
update multiplexer to utilise dispatcher
xlink-core: Patch set 2
Add xlink-dispatcher
creates tx and rx threads
enables queueing of messages for transmission and on reception
Update multiplexer to utilise dispatcher:
handle multiplexing channels over single interface link e.g.
PCIe
process messages received by dispatcher
pass messages created by API calls to dispatcher for
transmission
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Seamus Kelly
---
drivers/misc/xlink-core/Makefile| 2 +-
drivers/misc/xlink-core/xlink-core.c| 35 +-
drivers/misc/xlink-core/xlink-dispatcher.c | 441 +
drivers/misc/xlink-core/xlink-dispatcher.h | 26 +
drivers/misc/xlink-core/xlink-multiplexer.c | 498 +++-
5 files changed, 999 insertions(+), 3 deletions(-)
create mode 100644 drivers/misc/xlink-core/xlink-dispatcher.c
create mode 100644 drivers/misc/xlink-core/xlink-dispatcher.h
diff --git a/drivers/misc/xlink-core/Makefile b/drivers/misc/xlink-core/Makefile
index e82b7c72b6b9..ee81f9d05f2b 100644
--- a/drivers/misc/xlink-core/Makefile
+++ b/drivers/misc/xlink-core/Makefile
@@ -2,4 +2,4 @@
# Makefile for Keem Bay xlink Linux driver
#
obj-$(CONFIG_XLINK_CORE) += xlink.o
-xlink-objs += xlink-core.o xlink-multiplexer.o xlink-platform.o xlink-ioctl.o
+xlink-objs += xlink-core.o xlink-multiplexer.o xlink-dispatcher.o
xlink-platform.o xlink-ioctl.o
diff --git a/drivers/misc/xlink-core/xlink-core.c
b/drivers/misc/xlink-core/xlink-core.c
index dd8db834c184..bdbf8c6a99ca 100644
--- a/drivers/misc/xlink-core/xlink-core.c
+++ b/drivers/misc/xlink-core/xlink-core.c
@@ -21,6 +21,7 @@
#include "xlink-core.h"
#include "xlink-defs.h"
+#include "xlink-dispatcher.h"
#include "xlink-ioctl.h"
#include "xlink-multiplexer.h"
#include "xlink-platform.h"
@@ -151,6 +152,12 @@ static int kmb_xlink_probe(struct platform_device *pdev)
goto r_multiplexer;
}
+ // initialize dispatcher
+ rc = xlink_dispatcher_init(xlink_dev->pdev);
+ if (rc != X_LINK_SUCCESS) {
+ pr_err("Dispatcher initialization failed\n");
+ goto r_dispatcher;
+ }
// initialize xlink data structure
xlink_dev->nmb_connected_links = 0;
mutex_init(_dev->lock);
@@ -168,7 +175,7 @@ static int kmb_xlink_probe(struct platform_device *pdev)
/*Allocating Major number*/
if ((alloc_chrdev_region(, 0, 1, "xlinkdev")) < 0) {
dev_info(>dev, "Cannot allocate major number\n");
- goto r_multiplexer;
+ goto r_dispatcher;
}
dev_info(>dev, "Major = %d Minor = %d\n", MAJOR(xdev),
MINOR(xdev));
@@ -205,6 +212,8 @@ static int kmb_xlink_probe(struct platform_device *pdev)
class_destroy(dev_class);
r_class:
unregister_chrdev_region(xdev, 1);
+r_dispatcher:
+ xlink_dispatcher_destroy();
r_multiplexer:
xlink_multiplexer_destroy();
return -1;
@@ -220,6 +229,10 @@ static int kmb_xlink_remove(struct platform_device *pdev)
rc = xlink_multiplexer_destroy();
if (rc != X_LINK_SUCCESS)
pr_err("Multiplexer destroy failed\n");
+ // stop dispatchers and destroy
+ rc = xlink_dispatcher_destroy();
+ if (rc != X_LINK_SUCCESS)
+ pr_err("Dispatcher destroy failed\n");
mutex_unlock(>lock);
mutex_destroy(>lock);
@@ -314,6 +327,14 @@ enum xlink_error xlink_connect(struct xlink_handle *handle)
link->handle = *handle;
xlink->nmb_connected_links++;
kref_init(>refcount);
+ if (interface != IPC_INTERFACE) {
+ // start dispatcher
+ rc = xlink_dispatcher_start(link->id, >handle);
+ if (rc) {
+ pr_err("dispatcher start failed\n");
+ goto r_cleanup;
+ }
+ }
// initialize multiplexer connection
rc = xlink_multiplexer_connect(link->id);
if (rc) {
@@ -649,6 +670,7 @@ EXPORT_SYMBOL_GPL(xlink_release_data);
enum xlink_error xlink_disconnect(struct xlink_handle *handle)
{
struct xlink_link *link;
+ int interface = NULL_INTERFACE;
enum xlink_error rc = X_LINK_ERROR;
if (!xlink || !handle)
@@ -661,6 +683,17 @@ enum xlink_error xlink_disconnect(struct xlink_handle
*handle)
// decrement refcount, if count is 0 lock mutex and disconnect
if
[RFC v1 15/26] x86/boot: Add a trampoline for APs booting in 64-bit mode
From: Sean Christopherson
Add a trampoline for booting APs in 64-bit mode via a software handoff
with BIOS, and use the new trampoline for the ACPI MP wake protocol used
by TDX.
Extend the real mode IDT pointer by four bytes to support LIDT in 64-bit
mode. For the GDT pointer, create a new entry as the existing storage
for the pointer occupies the zero entry in the GDT itself.
Reported-by: Kai Huang
Signed-off-by: Sean Christopherson
Reviewed-by: Andi Kleen
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/include/asm/realmode.h | 1 +
arch/x86/kernel/smpboot.c| 5 +++
arch/x86/realmode/rm/header.S| 1 +
arch/x86/realmode/rm/trampoline_64.S | 49 +++-
arch/x86/realmode/rm/trampoline_common.S | 5 ++-
5 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/realmode.h b/arch/x86/include/asm/realmode.h
index 5db5d083c873..5066c8b35e7c 100644
--- a/arch/x86/include/asm/realmode.h
+++ b/arch/x86/include/asm/realmode.h
@@ -25,6 +25,7 @@ struct real_mode_header {
u32 sev_es_trampoline_start;
#endif
#ifdef CONFIG_X86_64
+ u32 trampoline_start64;
u32 trampoline_pgd;
#endif
/* ACPI S3 wakeup */
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 8ca66af96a54..11dd0deb4810 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1035,6 +1035,11 @@ static int do_boot_cpu(int apicid, int cpu, struct
task_struct *idle,
unsigned long boot_error = 0;
unsigned long timeout;
+#ifdef CONFIG_X86_64
+ if (is_tdx_guest())
+ start_ip = real_mode_header->trampoline_start64;
+#endif
+
idle->thread.sp = (unsigned long)task_pt_regs(idle);
early_gdt_descr.address = (unsigned long)get_cpu_gdt_rw(cpu);
initial_code = (unsigned long)start_secondary;
diff --git a/arch/x86/realmode/rm/header.S b/arch/x86/realmode/rm/header.S
index 8c1db5bf5d78..2eb62be6d256 100644
--- a/arch/x86/realmode/rm/header.S
+++ b/arch/x86/realmode/rm/header.S
@@ -24,6 +24,7 @@ SYM_DATA_START(real_mode_header)
.long pa_sev_es_trampoline_start
#endif
#ifdef CONFIG_X86_64
+ .long pa_trampoline_start64
.long pa_trampoline_pgd;
#endif
/* ACPI S3 wakeup */
diff --git a/arch/x86/realmode/rm/trampoline_64.S
b/arch/x86/realmode/rm/trampoline_64.S
index 84c5d1b33d10..12b734b1da8b 100644
--- a/arch/x86/realmode/rm/trampoline_64.S
+++ b/arch/x86/realmode/rm/trampoline_64.S
@@ -143,13 +143,20 @@ SYM_CODE_START(startup_32)
movl%eax, %cr3
# Set up EFER
+ movl$MSR_EFER, %ecx
+ rdmsr
+ cmp pa_tr_efer, %eax
+ jne .Lwrite_efer
+ cmp pa_tr_efer + 4, %edx
+ je .Ldone_efer
+.Lwrite_efer:
movlpa_tr_efer, %eax
movlpa_tr_efer + 4, %edx
- movl$MSR_EFER, %ecx
wrmsr
+.Ldone_efer:
# Enable paging and in turn activate Long Mode
- movl$(X86_CR0_PG | X86_CR0_WP | X86_CR0_PE), %eax
+ movl$(X86_CR0_PG | X86_CR0_WP | X86_CR0_NE | X86_CR0_PE), %eax
movl%eax, %cr0
/*
@@ -161,6 +168,19 @@ SYM_CODE_START(startup_32)
ljmpl $__KERNEL_CS, $pa_startup_64
SYM_CODE_END(startup_32)
+SYM_CODE_START(pa_trampoline_compat)
+ /*
+* In compatibility mode. Prep ESP and DX for startup_32, then disable
+* paging and complete the switch to legacy 32-bit mode.
+*/
+ movl$rm_stack_end, %esp
+ movw$__KERNEL_DS, %dx
+
+ movl$(X86_CR0_NE | X86_CR0_PE), %eax
+ movl%eax, %cr0
+ ljmpl $__KERNEL32_CS, $pa_startup_32
+SYM_CODE_END(pa_trampoline_compat)
+
.section ".text64","ax"
.code64
.balign 4
@@ -169,6 +189,20 @@ SYM_CODE_START(startup_64)
jmpq*tr_start(%rip)
SYM_CODE_END(startup_64)
+SYM_CODE_START(trampoline_start64)
+ /*
+* APs start here on a direct transfer from 64-bit BIOS with identity
+* mapped page tables. Load the kernel's GDT in order to gear down to
+* 32-bit mode (to handle 4-level vs. 5-level paging), and to (re)load
+* segment registers. Load the zero IDT so any fault triggers a
+* shutdown instead of jumping back into BIOS.
+*/
+ lidttr_idt(%rip)
+ lgdttr_gdt64(%rip)
+
+ ljmpl *tr_compat(%rip)
+SYM_CODE_END(trampoline_start64)
+
.section ".rodata","a"
# Duplicate the global descriptor table
# so the kernel can live anywhere
@@ -182,6 +216,17 @@ SYM_DATA_START(tr_gdt)
.quad 0x00cf9300 # __KERNEL_DS
SYM_DATA_END_LABEL(tr_gdt, SYM_L_LOCAL, tr_gdt_end)
+SYM_DATA_START(tr_gdt64)
+ .short tr_gdt_end - tr_gdt - 1 # gdt limit
+ .long pa_tr_gdt
+ .long 0
+SYM_DATA_END(tr_gdt64)
+
+SYM_DATA_START(tr_compat)
+ .long pa_trampoline_compat
+ .short __KERNEL32_CS
Re: [PATCH v5 1/2] dt-bindings: Add DT schema for Arm Mali Valhall GPU
On Thu, Jan 28, 2021 at 10:23:41AM +0800, Nick Fan wrote:
> Add devicetree schema for Arm Mali Valhall GPU
>
> Define a compatible string for the Mali Valhall GPU
> for Mediatek's SoC platform.
>
> Signed-off-by: Nick Fan
> ---
> .../bindings/gpu/arm,mali-valhall.yaml| 217 ++
> 1 file changed, 217 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
> new file mode 100644
> index ..275c14ad173a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall.yaml
> @@ -0,0 +1,217 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2020 MediaTek Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpu/arm,mali-valhall.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM Mali Valhall GPU
> +
> +maintainers:
> + - Rob Herring
> +
> +properties:
> + $nodename:
> +pattern: '^gpu@[a-f0-9]+$'
> +
> + compatible:
> +items:
> + - enum:
> + - mediatek,mt8192-mali
> + - const: arm,mali-valhall
> +
> + reg:
> +maxItems: 1
> +
> + interrupts:
> +items:
> + - description: GPU interrupt
> + - description: MMU interrupt
> + - description: Job interrupt
> +
> + interrupt-names:
> +items:
> + - const: gpu
> + - const: mmu
> + - const: job
Please use the same order as midgard and bifrost.
> +
> + clocks:
> +minItems: 1
> +
> + power-domains:
> +minItems: 1
> +maxItems: 5
> +
> + mali-supply: true
> + sram-supply: true
> +
> + operating-points-v2: true
> + opp_table: true
opp-table
> +
> + "#cooling-cells":
> +const: 2
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-names
> + - clocks
> +
> +additionalProperties: false
> +
> +allOf:
> + - if:
> + properties:
> +compatible:
> + contains:
> +const: mediatek,mt8192-mali
> +then:
> + properties:
> +power-domains:
> + minItems: 5
> + maxItems: 5
> +
> +power-domain-names:
> + items:
> +- const: core0
> +- const: core1
> +- const: core2
> +- const: core3
> +- const: core4
> +
> + required:
> +- sram-supply
> +- power-domains
> +
> +examples:
> + - |
> +#include
> +#include
> +
> +gpu@1300 {
> + compatible = "mediatek,mt8192-mali", "arm,mali-valhall";
Do 4 space indent.
> + reg = <0x1300 0x4000>;
> + interrupts =
> + ,
> + ,
> + ;
> + interrupt-names =
> + "gpu",
> + "mmu",
> + "job";
> +
> + clocks = < 0>;
> +
> + power-domains =
> + < 4>,
> + < 5>,
> + < 6>,
> + < 7>,
> + < 8>;
> +
> + operating-points-v2 = <_opp_table>;
> + mali-supply = <_7_vbuck1>;
> + sram-supply = <_vsram_others_ldo_reg>;
> + gpu_opp_table: opp_table {
> + compatible = "operating-points-v2";
And then the same here.
> + opp-shared;
> +
> + opp-35800 {
> + opp-hz = /bits/ 64 <35800>;
> + opp-microvolt = <606250>,
> + <75>;
Isn't this supposed to be either a single value or ?
> + };
> +
> + opp-39900 {
> + opp-hz = /bits/ 64 <39900>;
> + opp-microvolt = <618750>,
> + <75>;
> + };
> +
> + opp-44000 {
> + opp-hz = /bits/ 64 <44000>;
> + opp-microvolt = <631250>,
> + <75>;
> + };
> +
> + opp-48200 {
> + opp-hz = /bits/ 64 <48200>;
> + opp-microvolt = <643750>,
> + <75>;
> + };
> +
> + opp-52300 {
> + opp-hz = /bits/ 64 <52300>;
> + opp-microvolt = <656250>,
> + <75>;
> + };
> +
> + opp-56400 {
> + opp-hz = /bits/ 64 <56400>;
> + opp-microvolt = <668750>,
> + <75>;
> + };
> +
> + opp-60500 {
> + opp-hz = /bits/ 64 <60500>;
> + opp-microvolt = <681250>,
> + <75>;
> + };
> +
> + opp-64700 {
> + opp-hz =
Re: [PATCH v4 18/21] mfd: hi6421-spmi-pmic: move driver from staging
On Tue, Jan 19, 2021 at 05:10:44PM +0100, Mauro Carvalho Chehab wrote: > This driver is ready for mainstream. So, move it out of staging. > > Signed-off-by: Mauro Carvalho Chehab > --- > .../mfd/hisilicon,hi6421-spmi-pmic.yaml | 135 + > MAINTAINERS | 7 + > drivers/mfd/Kconfig | 15 + > drivers/mfd/Makefile | 1 + > drivers/mfd/hi6421-spmi-pmic.c| 281 ++ > drivers/staging/hikey9xx/Kconfig | 16 - > drivers/staging/hikey9xx/Makefile | 1 - > drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 281 -- > .../hikey9xx/hisilicon,hi6421-spmi-pmic.yaml | 135 - > 9 files changed, 439 insertions(+), 433 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml > create mode 100644 drivers/mfd/hi6421-spmi-pmic.c > delete mode 100644 drivers/staging/hikey9xx/hi6421-spmi-pmic.c > delete mode 100644 drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml > > diff --git > a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml > b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml > new file mode 100644 > index ..3b23ad56b31a > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml > @@ -0,0 +1,135 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mfd/hisilicon,hi6421-spmi-pmic.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: HiSilicon 6421v600 SPMI PMIC > + > +maintainers: > + - Mauro Carvalho Chehab > + > +description: | > + HiSilicon 6421v600 should be connected inside a MIPI System Power > Management > + (SPMI) bus. It provides interrupts and power supply. > + > + The GPIO and interrupt settings are represented as part of the top-level > PMIC > + node. > + > + The SPMI controller part is provided by > + drivers/staging/hikey9xx/hisilicon,hisi-spmi-controller.yaml. > + > +properties: > + $nodename: > +pattern: "pmic@[0-9a-f]" > + > + compatible: > +const: hisilicon,hi6421v600-spmi Also, use the compatible string as the filename.
Re: ERROR: INT DW_ATE_unsigned_1 Error emitting BTF type
On Fri, Feb 5, 2021 at 10:54 PM Yonghong Song wrote:
>
>
>
> On 2/5/21 12:31 PM, Sedat Dilek wrote:
> > On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
> >>
> >>
> >>
> >> On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
> >>> Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song escreveu:
> On 2/5/21 11:06 AM, Sedat Dilek wrote:
> > On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek
> > wrote:
> > Grepping through linux.git/tools I guess some BTF tools/libs need to
> > know what BTF_INT_UNSIGNED is?
> >>>
> BTF_INT_UNSIGNED needs kernel support. Maybe to teach pahole to
> ignore this for now until kernel infrastructure is ready.
> >>>
> >>> Yeah, I thought about doing that.
> >>>
> Not sure whether this information will be useful or not
> for BTF. This needs to be discussed separately.
> >>>
> >>> Maybe search for the rationale for its introduction in DWARF.
> >>
> >> In LLVM, we have:
> >> uint8_t BTFEncoding;
> >> switch (Encoding) {
> >> case dwarf::DW_ATE_boolean:
> >> BTFEncoding = BTF::INT_BOOL;
> >> break;
> >> case dwarf::DW_ATE_signed:
> >> case dwarf::DW_ATE_signed_char:
> >> BTFEncoding = BTF::INT_SIGNED;
> >> break;
> >> case dwarf::DW_ATE_unsigned:
> >> case dwarf::DW_ATE_unsigned_char:
> >> BTFEncoding = 0;
> >> break;
> >>
> >> I think DW_ATE_unsigned can be ignored in pahole since
> >> the default encoding = 0. A simple comment is enough.
> >>
> >
> > Yonghong Son, do you have a patch/diff for me?
>
> Looking at error message from log:
>
> LLVM_OBJCOPY=/opt/binutils/bin/objcopy /opt/pahole/bin/pahole -J
> .tmp_vmlinux.btf
> [115] INT DW_ATE_unsigned_1 Error emitting BTF type
> Encountered error while encoding BTF.
>
> Not exactly what is the root cause. Maybe bt->bit_size is not
> encoded correctly. Could you put vmlinux (in the above it is
> .tmp_vmlinux.btf) somewhere, I or somebody else can investigate
> and provide a proper fix.
>
[ TO: Masahiro ]
Thanks for taking care Yonghong - hope this is your first name, if not
I am sorry.
In case of mixing my first and last name you will make me female -
Dilek is a Turkish female first name :-).
So, in some cultures you need to be careful.
Anyway... back to business and facts.
Out of frustration I killed my last build via `make distclean`.
The whole day I tested diverse combination of GCC-10 and LLVM-12
together with BTF Kconfigs, selfmade pahole, etc.
I will do ne run with some little changes:
#1: Pass LLVM_IAS=1 to make (means use Clang's Integrated ASsembler -
as per Nick this leads to the same error - should be unrelated)
#2: I did: DEBUG_INFO_COMPRESSED y -> n
#2 I did in case you need vmlinux and I have to upload - I will
compress the resulting vmlinux with ZSTD.
You need vmlinux or .tmp_vmlinux.btf file?
Nick was not allowed from his company to download from a Dropbox link.
So, as an alternative I can offer GoogleDrive...
...or bomb into your INBOX :-).
Now, why I CCed Masahiro:
In case of ERRORs when running `scripts/link-vmlinux.sh` above files
will be removed.
Last, I found a hack to bypass this - means to keep these files (I
need to check old emails).
Masahiro, you see a possibility to have a way to keep these files in
case of ERRORs without doing hackery?
>From a previous post in this thread:
+ info BTF .btf.vmlinux.bin.o
+ [ != silent_ ]
+ printf %-7s %s\n BTF .btf.vmlinux.bin.o
BTF .btf.vmlinux.bin.o
+ LLVM_OBJCOPY=llvm-objcopy /opt/pahole/bin/pahole -J .tmp_vmlinux.btf
[2] INT long unsigned int Error emitting BTF type
Encountered error while encoding BTF.
+ llvm-objcopy --only-section=.BTF --set-section-flags
.BTF=alloc,readonly --strip-all .tmp_vmlinux.btf .btf.vmlinux.bin.o
...
+ info BTFIDS vmlinux
+ [ != silent_ ]
+ printf %-7s %s\n BTFIDS vmlinux
BTFIDS vmlinux
+ ./tools/bpf/resolve_btfids/resolve_btfids vmlinux
FAILED: load BTF from vmlinux: Invalid argument
+ on_exit
+ [ 255 -ne 0 ]
+ cleanup
+ rm -f .btf.vmlinux.bin.o
+ rm -f .tmp_System.map
+ rm -f .tmp_vmlinux.btf .tmp_vmlinux.kallsyms1
.tmp_vmlinux.kallsyms1.S .tmp_vmlinux.kallsyms1.o
.tmp_vmlinux.kallsyms2 .tmp_vmlinux.kallsyms2.S .tmp_vmlinux.kallsyms
2.o
+ rm -f System.map
+ rm -f vmlinux
+ rm -f vmlinux.o
make[3]: *** [Makefile:1166: vmlinux] Error 255
^^^ Look here.
Thanks.
Regards,
- Sedat -
Re: [PATCH RESEND v5 3/8] dt-bindings: mfd: Add compatible for the MediaTek MT6359 PMIC
On Fri, 29 Jan 2021 17:49:36 +0800, Hsin-Hsiung Wang wrote: > This adds compatible for the MediaTek MT6359 PMIC. > > Signed-off-by: Hsin-Hsiung Wang > --- > changes since v4: > - remove unused compatible name. > --- > Documentation/devicetree/bindings/mfd/mt6397.txt | 1 + > 1 file changed, 1 insertion(+) > Acked-by: Rob Herring
[RFC v1 14/26] ACPI: tables: Add multiprocessor wake-up support
As per Guest-Host Communication Interface (GHCI)
Specification for Intel TDX, sec 4.1, a new sub
structure – multiprocessor wake-up structure - is added to the
ACPI Multiple APIC Description Table (MADT) to describe the
information of the mailbox. If a platform firmware produces the
multiprocessor wake-up structure, then the BSP in OS may use this
new mailbox-based mechanism to wake up the APs.
Add ACPI MADT wake table parsing support and if MADT wake table is
present, update apic->wakeup_secondary_cpu with new API which
uses MADT wake mailbox to wake-up CPU.
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Signed-off-by: Kuppuswamy Sathyanarayanan
Reviewed-by: Andi Kleen
---
arch/x86/include/asm/apic.h | 3 ++
arch/x86/kernel/acpi/boot.c | 56 +
arch/x86/kernel/apic/probe_32.c | 8 +
arch/x86/kernel/apic/probe_64.c | 8 +
drivers/acpi/tables.c | 9 ++
include/acpi/actbl2.h | 21 -
6 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 34cb3c159481..63f970c61cbe 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -497,6 +497,9 @@ static inline unsigned int read_apic_id(void)
return apic->get_apic_id(reg);
}
+typedef int (*wakeup_cpu_handler)(int apicid, unsigned long start_eip);
+extern void acpi_wake_cpu_handler_update(wakeup_cpu_handler handler);
+
extern int default_apic_id_valid(u32 apicid);
extern int default_acpi_madt_oem_check(char *, char *);
extern void default_setup_apic_routing(void);
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 7bdc0239a943..37ada1908fb7 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -65,6 +65,9 @@ int acpi_fix_pin2_polarity __initdata;
static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;
#endif
+static struct acpi_madt_mp_wake_mailbox *acpi_mp_wake_mailbox;
+static u64 acpi_mp_wake_mailbox_paddr;
+
#ifdef CONFIG_X86_IO_APIC
/*
* Locks related to IOAPIC hotplug
@@ -329,6 +332,29 @@ acpi_parse_lapic_nmi(union acpi_subtable_headers * header,
const unsigned long e
return 0;
}
+static void acpi_mp_wake_mailbox_init(void)
+{
+ if (acpi_mp_wake_mailbox)
+ return;
+
+ acpi_mp_wake_mailbox = memremap(acpi_mp_wake_mailbox_paddr,
+ sizeof(*acpi_mp_wake_mailbox), MEMREMAP_WB);
+}
+
+static int acpi_wakeup_cpu(int apicid, unsigned long start_ip)
+{
+ acpi_mp_wake_mailbox_init();
+
+ if (!acpi_mp_wake_mailbox)
+ return -EINVAL;
+
+ WRITE_ONCE(acpi_mp_wake_mailbox->apic_id, apicid);
+ WRITE_ONCE(acpi_mp_wake_mailbox->wakeup_vector, start_ip);
+ WRITE_ONCE(acpi_mp_wake_mailbox->command, ACPI_MP_WAKE_COMMAND_WAKEUP);
+
+ return 0;
+}
+
#endif /*CONFIG_X86_LOCAL_APIC */
#ifdef CONFIG_X86_IO_APIC
@@ -1086,6 +1112,30 @@ static int __init acpi_parse_madt_lapic_entries(void)
}
return 0;
}
+
+static int __init acpi_parse_mp_wake(union acpi_subtable_headers *header,
+ const unsigned long end)
+{
+ struct acpi_madt_mp_wake *mp_wake = NULL;
+
+ if (!IS_ENABLED(CONFIG_SMP))
+ return -ENODEV;
+
+ mp_wake = (struct acpi_madt_mp_wake *)header;
+ if (BAD_MADT_ENTRY(mp_wake, end))
+ return -EINVAL;
+
+ if (acpi_mp_wake_mailbox)
+ return -EINVAL;
+
+ acpi_table_print_madt_entry(>common);
+
+ acpi_mp_wake_mailbox_paddr = mp_wake->mailbox_address;
+
+ acpi_wake_cpu_handler_update(acpi_wakeup_cpu);
+
+ return 0;
+}
#endif /* CONFIG_X86_LOCAL_APIC */
#ifdef CONFIG_X86_IO_APIC
@@ -1284,6 +1334,12 @@ static void __init acpi_process_madt(void)
smp_found_config = 1;
}
+
+ /*
+* Parse MADT MP Wake entry.
+*/
+ acpi_table_parse_madt(ACPI_MADT_TYPE_MP_WAKE,
+ acpi_parse_mp_wake, 1);
}
if (error == -EINVAL) {
/*
diff --git a/arch/x86/kernel/apic/probe_32.c b/arch/x86/kernel/apic/probe_32.c
index a61f642b1b90..d450014841b2 100644
--- a/arch/x86/kernel/apic/probe_32.c
+++ b/arch/x86/kernel/apic/probe_32.c
@@ -207,3 +207,11 @@ int __init default_acpi_madt_oem_check(char *oem_id, char
*oem_table_id)
}
return 0;
}
+
+void __init acpi_wake_cpu_handler_update(wakeup_cpu_handler handler)
+{
+ struct apic **drv;
+
+ for (drv = __apicdrivers; drv < __apicdrivers_end; drv++)
+ (*drv)->wakeup_secondary_cpu = handler;
+}
diff --git a/arch/x86/kernel/apic/probe_64.c b/arch/x86/kernel/apic/probe_64.c
index
Re: [PATCH v4 1/3] dt-bindings: input: atmel_mxt_ts: Document atmel,wakeup-method and WAKE line GPIO
On Fri, 22 Jan 2021 23:06:57 +0300, Dmitry Osipenko wrote: > Some Atmel touchscreen controllers have a WAKE line that needs to be > asserted low in order to wake up controller from a deep sleep. Document > the wakeup methods and the new GPIO properties. > > Reviewed-by: Linus Walleij > Signed-off-by: Dmitry Osipenko > --- > .../bindings/input/atmel,maxtouch.yaml| 29 +++ > include/dt-bindings/input/atmel-maxtouch.h| 10 +++ > 2 files changed, 39 insertions(+) > create mode 100644 include/dt-bindings/input/atmel-maxtouch.h > Reviewed-by: Rob Herring
[PATCH v5 08/34] misc: xlink-pcie: Add documentation for XLink PCIe driver
From: Srikanth Thokala
Provide overview of XLink PCIe driver implementation
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
Documentation/vpu/index.rst | 1 +
Documentation/vpu/xlink-pcie.rst | 90
2 files changed, 91 insertions(+)
create mode 100644 Documentation/vpu/xlink-pcie.rst
diff --git a/Documentation/vpu/index.rst b/Documentation/vpu/index.rst
index 7e290e048910..661cc700ee45 100644
--- a/Documentation/vpu/index.rst
+++ b/Documentation/vpu/index.rst
@@ -14,3 +14,4 @@ This documentation contains information for the Intel VPU
stack.
:maxdepth: 2
vpu-stack-overview
+ xlink-pcie
diff --git a/Documentation/vpu/xlink-pcie.rst b/Documentation/vpu/xlink-pcie.rst
new file mode 100644
index ..85a70990e9c9
--- /dev/null
+++ b/Documentation/vpu/xlink-pcie.rst
@@ -0,0 +1,90 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Kernel driver: Xlink-pcie driver
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+Suffix: Bay
+Slave address: 6240
+Datasheet: Publicly available at Intel
+
+Author: Srikanth Thokala srikanth.thok...@intel.com
+
+Introduction
+
+The Xlink-pcie driver provides transport layer implementation for
+the data transfers to support Xlink protocol subsystem communication with the
+peer device, i.e., between remote host system and Keem Bay device.
+
+The Keem Bay device is an ARM-based SOC that includes a vision processing
+unit (VPU) and deep learning, neural network core in the hardware.
+The Xlink-pcie driver exports a functional device endpoint to the Keem Bay
+device and supports two-way communication with the peer device.
+
+High-level architecture
+===
+Remote Host: IA CPU
+Local Host: ARM CPU (Keem Bay)::
+
+
++
+| Remote Host IA CPU | | Local Host ARM CPU (Keem Bay) |
|
+
+==+=+===+===+
+| User App| | User App |
|
+
+--+-+---+---+
+| XLink UAPI | | XLink UAPI|
|
+
+--+-+---+---+
+| XLink Core | | XLink Core|
|
+
+--+-+---+---+
+| XLink PCIe | | XLink PCIe|
|
+
+--+-+---+---+
+| XLink-PCIe Remote Host driver | | XLink-PCIe Local Host driver |
|
+
+--+-+---+---+
+
|-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:|:|:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:|
+
+--+-+---+---+
+| PCIe Host Controller | | PCIe Device Controller|
HW|
+
+--+-+---+---+
+ ^ ^
+ | |
+ |- PCIe x2 Link -|
+
+This XLink PCIe driver comprises of two variants:
+* Local Host driver
+
+ * Intended for ARM CPU
+ * It is based on PCI Endpoint Framework
+ * Driver path: {tree}/drivers/misc/Xlink-pcie/local_host
+
+* Remote Host driver
+
+ * Intended for IA CPU
+ * It is a PCIe endpoint driver
+ * Driver path: {tree}/drivers/misc/Xlink-pcie/remote_host
+
+XLink PCIe communication between local host and remote host is achieved through
+ring buffer management and MSI/Doorbell interrupts.
+
+The Xlink-pcie driver subsystem registers the Keem Bay device as an endpoint
+driver and provides standard Linux PCIe sysfs interface:
+'/sys/bus/pci/devices/:xx:xx.0/'
+
+
+XLink protocol subsystem
+
+Xlink is an abstracted control and communication subsystem based on channel
+identification. It is intended to support VPU technology both at SoC level as
+well as at IP level, over multiple interfaces.
+
+- The Xlink subsystem abstracts several types of communication channels
+ underneath, allowing the usage of different interfaces with the
+ same function call interface.
+- The Communication channels are full-duplex protocol channels allowing
+ concurrent bidirectional communication.
+- The Xlink subsystem also supports control operations to VPU either
+ from standalone local system or from remote system based on communication
+ interface underneath.
+- The Xlink
[RFC v1 13/26] x86/tdx: Handle MWAIT, MONITOR and WBINVD
In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions
are not supported. So handle #VE due to these instructions as no ops.
Signed-off-by: Kuppuswamy Sathyanarayanan
Reviewed-by: Andi Kleen
---
arch/x86/kernel/tdx.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index eff58329751e..8d1d7555fb56 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -451,6 +451,23 @@ int tdx_handle_virtualization_exception(struct pt_regs
*regs,
case EXIT_REASON_EPT_VIOLATION:
ve->instr_len = tdx_handle_mmio(regs, ve);
break;
+ /*
+* Per Guest-Host-Communication Interface (GHCI) for Intel Trust
+* Domain Extensions (Intel TDX) specification, sec 2.4,
+* some instructions that unconditionally cause #VE (such as WBINVD,
+* MONITOR, MWAIT) do not have corresponding TDCALL
+* [TDG.VP.VMCALL ] leaves, since the TD has been designed
+* with no deterministic way to confirm the result of those operations
+* performed by the host VMM. In those cases, the goal is for the TD
+* #VE handler to increment the RIP appropriately based on the VE
+* information provided via TDCALL.
+*/
+ case EXIT_REASON_WBINVD:
+ pr_warn_once("WBINVD #VE Exception\n");
+ case EXIT_REASON_MWAIT_INSTRUCTION:
+ case EXIT_REASON_MONITOR_INSTRUCTION:
+ /* Handle as nops. */
+ break;
default:
pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
return -EFAULT;
--
2.25.1
[RFC v1 12/26] x86/tdx: Handle in-kernel MMIO
From: "Kirill A. Shutemov"
Handle #VE due to MMIO operations. MMIO triggers #VE with EPT_VIOLATION
exit reason.
For now we only handle subset of instruction that kernel uses for MMIO
oerations. User-space access triggers SIGBUS.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/kernel/tdx.c | 120 ++
1 file changed, 120 insertions(+)
diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index 3846d2807a7a..eff58329751e 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -6,6 +6,8 @@
#include
#include
#include
+#include
+#include /* force_sig_fault() */
#ifdef CONFIG_KVM_GUEST
#include "tdx-kvm.c"
@@ -270,6 +272,121 @@ static void tdx_handle_io(struct pt_regs *regs, u32
exit_qual)
}
}
+static unsigned long tdx_mmio(int size, bool write, unsigned long addr,
+ unsigned long val)
+{
+ register long r10 asm("r10") = TDVMCALL_STANDARD;
+ register long r11 asm("r11") = EXIT_REASON_EPT_VIOLATION;
+ register long r12 asm("r12") = size;
+ register long r13 asm("r13") = write;
+ register long r14 asm("r14") = addr;
+ register long r15 asm("r15") = val;
+ register long rcx asm("rcx");
+ long ret;
+
+ /* Allow to pass R10, R11, R12, R13, R14 and R15 down to the VMM */
+ rcx = BIT(10) | BIT(11) | BIT(12) | BIT(13) | BIT(14) | BIT(15);
+
+ asm volatile(TDCALL
+ : "=a"(ret), "=r"(r10), "=r"(r11), "=r"(r12), "=r"(r13),
+ "=r"(r14), "=r"(r15)
+ : "a"(TDVMCALL), "r"(rcx), "r"(r10), "r"(r11), "r"(r12),
+ "r"(r13), "r"(r14), "r"(r15)
+ : );
+
+ WARN_ON(ret || r10);
+
+ return r11;
+}
+
+static inline void *get_reg_ptr(struct pt_regs *regs, struct insn *insn)
+{
+ static const int regoff[] = {
+ offsetof(struct pt_regs, ax),
+ offsetof(struct pt_regs, cx),
+ offsetof(struct pt_regs, dx),
+ offsetof(struct pt_regs, bx),
+ offsetof(struct pt_regs, sp),
+ offsetof(struct pt_regs, bp),
+ offsetof(struct pt_regs, si),
+ offsetof(struct pt_regs, di),
+ offsetof(struct pt_regs, r8),
+ offsetof(struct pt_regs, r9),
+ offsetof(struct pt_regs, r10),
+ offsetof(struct pt_regs, r11),
+ offsetof(struct pt_regs, r12),
+ offsetof(struct pt_regs, r13),
+ offsetof(struct pt_regs, r14),
+ offsetof(struct pt_regs, r15),
+ };
+ int regno;
+
+ regno = X86_MODRM_REG(insn->modrm.value);
+ if (X86_REX_R(insn->rex_prefix.value))
+ regno += 8;
+
+ return (void *)regs + regoff[regno];
+}
+
+static int tdx_handle_mmio(struct pt_regs *regs, struct ve_info *ve)
+{
+ int size;
+ bool write;
+ unsigned long *reg;
+ struct insn insn;
+ unsigned long val = 0;
+
+ /*
+* User mode would mean the kernel exposed a device directly
+* to ring3, which shouldn't happen except for things like
+* DPDK.
+*/
+ if (user_mode(regs)) {
+ pr_err("Unexpected user-mode MMIO access.\n");
+ force_sig_fault(SIGBUS, BUS_ADRERR, (void __user *) ve->gla);
+ return 0;
+ }
+
+ kernel_insn_init(, (void *) regs->ip, MAX_INSN_SIZE);
+ insn_get_length();
+ insn_get_opcode();
+
+ write = ve->exit_qual & 0x2;
+
+ size = insn.opnd_bytes;
+ switch (insn.opcode.bytes[0]) {
+ /* MOV r/m8 r8 */
+ case 0x88:
+ /* MOV r8 r/m8*/
+ case 0x8A:
+ /* MOV r/m8 imm8*/
+ case 0xC6:
+ size = 1;
+ break;
+ }
+
+ if (inat_has_immediate(insn.attr)) {
+ BUG_ON(!write);
+ val = insn.immediate.value;
+ tdx_mmio(size, write, ve->gpa, val);
+ return insn.length;
+ }
+
+ BUG_ON(!inat_has_modrm(insn.attr));
+
+ reg = get_reg_ptr(regs, );
+
+ if (write) {
+ memcpy(, reg, size);
+ tdx_mmio(size, write, ve->gpa, val);
+ } else {
+ val = tdx_mmio(size, write, ve->gpa, val);
+ memset(reg, 0, size);
+ memcpy(reg, , size);
+ }
+ return insn.length;
+}
+
void __init tdx_early_init(void)
{
if (!cpuid_has_tdx_guest())
@@ -331,6 +448,9 @@ int tdx_handle_virtualization_exception(struct pt_regs
*regs,
case EXIT_REASON_IO_INSTRUCTION:
tdx_handle_io(regs, ve->exit_qual);
break;
+ case EXIT_REASON_EPT_VIOLATION:
+ ve->instr_len = tdx_handle_mmio(regs, ve);
+ break;
default:
Re: [PATCH v5 15/20] dt-bindings: net: sun8i-emac: Add H616 compatible string
On Wed, 27 Jan 2021 17:24:55 +, Andre Przywara wrote: > Add the obvious compatible name to the existing EMAC binding, and pair > it with the existing A64 fallback compatible string, as the devices are > compatible. > > On the way use enums to group the compatible devices together. > > Signed-off-by: Andre Przywara > --- > .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml| 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > Acked-by: Rob Herring
[RFC v1 11/26] x86/tdx: Handle port I/O
From: "Kirill A. Shutemov"
Unroll string operations and handle port I/O through TDVMCALLs.
Also handle #VE due to I/O operations with the same TDVMCALLs.
Decompression code uses port IO for earlyprintk. We must use
paravirt calls there too if we want to allow earlyprintk.
Decompresion code cannot deal with alternatives: use branches
instead to implement inX() and outX() helpers.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/boot/compressed/Makefile | 1 +
arch/x86/boot/compressed/tdx_io.S | 9 ++
arch/x86/include/asm/asm-prototypes.h | 1 +
arch/x86/include/asm/io.h | 5 +-
arch/x86/include/asm/tdx.h| 62 +--
arch/x86/kernel/Makefile | 2 +-
arch/x86/kernel/tdx.c | 72 +
arch/x86/kernel/tdx_io.S | 143 ++
8 files changed, 284 insertions(+), 11 deletions(-)
create mode 100644 arch/x86/boot/compressed/tdx_io.S
create mode 100644 arch/x86/kernel/tdx_io.S
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index a2554621cefe..54da333adc4e 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -97,6 +97,7 @@ endif
vmlinux-objs-$(CONFIG_ACPI) += $(obj)/acpi.o
vmlinux-objs-$(CONFIG_INTEL_TDX_GUEST) += $(obj)/tdx.o
+vmlinux-objs-$(CONFIG_INTEL_TDX_GUEST) += $(obj)/tdx_io.o
vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_thunk_$(BITS).o
efi-obj-$(CONFIG_EFI_STUB) = $(objtree)/drivers/firmware/efi/libstub/lib.a
diff --git a/arch/x86/boot/compressed/tdx_io.S
b/arch/x86/boot/compressed/tdx_io.S
new file mode 100644
index ..67498f67cb18
--- /dev/null
+++ b/arch/x86/boot/compressed/tdx_io.S
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include
+
+/* Do not export symbols in decompression code */
+#undef EXPORT_SYMBOL
+#define EXPORT_SYMBOL(sym)
+
+#include "../../kernel/tdx_io.S"
diff --git a/arch/x86/include/asm/asm-prototypes.h
b/arch/x86/include/asm/asm-prototypes.h
index 51e2bf27cc9b..6bc97aa39a21 100644
--- a/arch/x86/include/asm/asm-prototypes.h
+++ b/arch/x86/include/asm/asm-prototypes.h
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index ef7a686a55a9..30a3b30395ad 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#define build_mmio_read(name, size, type, reg, barrier) \
static inline type name(const volatile void __iomem *addr) \
@@ -309,7 +310,7 @@ static inline unsigned type in##bwl##_p(int port)
\
\
static inline void outs##bwl(int port, const void *addr, unsigned long count) \
{ \
- if (sev_key_active()) { \
+ if (sev_key_active() || is_tdx_guest()) { \
unsigned type *value = (unsigned type *)addr; \
while (count) { \
out##bwl(*value, port); \
@@ -325,7 +326,7 @@ static inline void outs##bwl(int port, const void *addr,
unsigned long count) \
\
static inline void ins##bwl(int port, void *addr, unsigned long count) \
{ \
- if (sev_key_active()) { \
+ if (sev_key_active() || is_tdx_guest()) { \
unsigned type *value = (unsigned type *)addr; \
while (count) { \
*value = in##bwl(port); \
diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
index 8c3e5af88643..b46ae140e39b 100644
--- a/arch/x86/include/asm/tdx.h
+++ b/arch/x86/include/asm/tdx.h
@@ -5,7 +5,16 @@
#define TDX_CPUID_LEAF_ID 0x21
-#ifdef CONFIG_INTEL_TDX_GUEST
+#define TDVMCALL 0
+#define TDINFO 1
+#define TDGETVEINFO3
+
+/* TDVMCALL R10 Input */
+#define TDVMCALL_STANDARD 0
+#define TDVMCALL_VENDOR1
+
+#ifndef __ASSEMBLY__
+#include
/*
* TDCALL instruction is newly added in TDX architecture,
@@ -14,19 +23,55 @@
*/
#define TDCALL ".byte 0x66,0x0f,0x01,0xcc"
-#define TDVMCALL 0
-#define TDINFO 1
-#define TDGETVEINFO3
-
-/* TDVMCALL R10 Input */
-#define TDVMCALL_STANDARD 0
-#define TDVMCALL_VENDOR1
+#ifdef CONFIG_INTEL_TDX_GUEST
/* Common API to check TDX support in decompression and common kernel code. */
bool is_tdx_guest(void);
void __init
[PATCH v5 18/34] xlink-ipc: Add xlink ipc driver
From: Seamus Kelly Add xLink driver, which interfaces the xLink Core driver with the Keem Bay VPU IPC driver, thus enabling xLink to control and communicate with the VPU IP present on the Intel Keem Bay SoC. Specifically the driver enables xLink Core to: * Boot / Reset the VPU IP * Register to VPU IP event notifications (device connected, device disconnected, WDT event) * Query the status of the VPU IP (OFF, BUSY, READY, ERROR, RECOVERY) * Exchange data with the VPU IP, using the Keem Bay IPC mechanism - Including the ability to send 'volatile' data (i.e., small amount of data, up to 128-bytes that was not allocated in the CPU/VPU shared memory region) Cc: Jonathan Corbet Cc: Cc: Derek Kiernan Cc: Dragan Cvetic Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: linux-...@vger.kernel.org Reviewed-by: Mark Gross Signed-off-by: Mark Gross Signed-off-by: Seamus Kelly --- Documentation/vpu/index.rst| 1 + Documentation/vpu/xlink-ipc.rst| 51 ++ MAINTAINERS| 6 + drivers/misc/Kconfig | 1 + drivers/misc/Makefile | 1 + drivers/misc/xlink-ipc/Kconfig | 7 + drivers/misc/xlink-ipc/Makefile| 4 + drivers/misc/xlink-ipc/xlink-ipc.c | 878 + include/linux/xlink-ipc.h | 48 ++ 9 files changed, 997 insertions(+) create mode 100644 Documentation/vpu/xlink-ipc.rst create mode 100644 drivers/misc/xlink-ipc/Kconfig create mode 100644 drivers/misc/xlink-ipc/Makefile create mode 100644 drivers/misc/xlink-ipc/xlink-ipc.c create mode 100644 include/linux/xlink-ipc.h diff --git a/Documentation/vpu/index.rst b/Documentation/vpu/index.rst index 661cc700ee45..49c78bb65b83 100644 --- a/Documentation/vpu/index.rst +++ b/Documentation/vpu/index.rst @@ -15,3 +15,4 @@ This documentation contains information for the Intel VPU stack. vpu-stack-overview xlink-pcie + xlink-ipc diff --git a/Documentation/vpu/xlink-ipc.rst b/Documentation/vpu/xlink-ipc.rst new file mode 100644 index ..97ee62b10e93 --- /dev/null +++ b/Documentation/vpu/xlink-ipc.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +Kernel driver: xLink IPC driver +=== + +Supported chips: + +* | Intel Edge.AI Computer Vision platforms: Keem Bay + | Suffix: Bay + | Datasheet: (not yet publicly available) + +Introduction + + +The xLink IPC driver interfaces the xLink Core driver with the Keem Bay VPU IPC +driver, thus enabling xLink to control and communicate with the VPU IP present +on the Intel Keem Bay SoC. + +Specifically the driver enables xLink Core to: + +* Boot / Reset the VPU IP +* Register to VPU IP event notifications (device connected, device disconnected, + WDT event) +* Query the status of the VPU IP (OFF, BUSY, READY, ERROR, RECOVERY) +* Exchange data with the VPU IP, using the Keem Bay IPC mechanism + + * Including the ability to send 'volatile' data (i.e. small amounts of data, +up to 128-bytes that was not allocated in the CPU/VPU shared memory region) + +Sending / Receiving 'volatile' data +=== + +Data to be exchanged with Keem Bay IPC needs to be allocated in the portion of +DDR shared between the CPU and VPU. + +This can be impractical for small amounts of data that user code can allocate +on the stack. + +To reduce the burden on user code, xLink Core provides special send / receive +functions to send up to 128 bytes of 'volatile data', i.e., data that is not +allocated in the shared memory and that might also disappear after the xLink +API is called (e.g., because allocated on the stack). + +The xLink IPC driver implements support for transferring such 'volatile data' +to the VPU using Keem Bay IPC. To this end, the driver reserves some memory in +the shared memory region. + +When volatile data is to be sent, xLink IPC allocates a buffer from the +reserved memory region and copies the volatile data to the buffer. The buffer +is then transferred to the VPU using Keem Bay IPC. diff --git a/MAINTAINERS b/MAINTAINERS index 1d825e6c3c53..8c79b879db8b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1961,6 +1961,12 @@ F: Documentation/devicetree/bindings/arm/intel,keembay.yaml F: arch/arm64/boot/dts/intel/keembay-evm.dts F: arch/arm64/boot/dts/intel/keembay-soc.dtsi +ARM/INTEL XLINK IPC SUPPORT +M: Seamus Kelly +M: Mark Gross +S: Supported +F: drivers/misc/xlink-ipc/ + ARM/INTEL KEEM BAY XLINK PCIE SUPPORT M: Srikanth Thokala M: Mark Gross diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index dfb98e444c6e..1f81ea915b95 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -482,4 +482,5 @@ source "drivers/misc/cardreader/Kconfig" source "drivers/misc/habanalabs/Kconfig" source "drivers/misc/uacce/Kconfig" source "drivers/misc/xlink-pcie/Kconfig" +source "drivers/misc/xlink-ipc/Kconfig" endmenu diff --git
回复: [PATCH] uprobes: Fix kasan UAF reported by syzbot
Hello peterz
This ("rbtree, uprobes: Use rbtree helpers")modification misses the increase
in the reference count , syzbot have been reporting recently .
Thanks
Qiang
发件人: Zhang, Qiang
发送时间: 2021年2月2日 17:17
收件人: pet...@infradead.org; mi...@redhat.com;
syzbot+2f6d683983e3905ad...@syzkaller.appspotmail.com
抄送: o...@redhat.com; linux-kernel@vger.kernel.org
主题: [PATCH] uprobes: Fix kasan UAF reported by syzbot
From: Zqiang
Call Trace:
__dump_stack [inline]
dump_stack+0x107/0x163
print_address_description.constprop.0.cold+0x5b/0x2f8
__kasan_report [inline]
kasan_report.cold+0x7c/0xd8
uprobe_cmp [inline]
__uprobe_cmp [inline]
rb_find_add [inline]
__insert_uprobe [inline]
insert_uprobe [inline]
alloc_uprobe [inline]
__uprobe_register+0x70f/0x850
..
__do_sys_perf_event_open+0x647/0x2e60
do_syscall_64+0x2d/0x70
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Allocated by task 12710:
kzalloc [inline]
alloc_uprobe [inline]
__uprobe_register+0x19c/0x850
trace_uprobe_enable [inline]
trace_uprobe_register+0x443/0x880
...
__do_sys_perf_event_open+0x647/0x2e60
do_syscall_64+0x2d/0x70
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 12710:
kfree+0xe5/0x7b0
put_uprobe [inline]
put_uprobe+0x13b/0x190
uprobe_apply+0xfc/0x130
uprobe_perf_open [inline]
trace_uprobe_register+0x5c9/0x880
...
__do_sys_perf_event_open+0x647/0x2e60
do_syscall_64+0x2d/0x70
entry_SYSCALL_64_after_hwframe+0x44/0xa9
fix the count of references lost in __find_uprobe function
Fixes: c6bc9bd06dff ("rbtree, uprobes: Use rbtree helpers")
Reported-by: syzbot+1182ffb2063c5d087...@syzkaller.appspotmail.com
Signed-off-by: Zqiang
---
kernel/events/uprobes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 7e15b2efdd87..6addc9780319 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -661,7 +661,7 @@ static struct uprobe *__find_uprobe(struct inode *inode,
loff_t offset)
struct rb_node *node = rb_find(, _tree, __uprobe_cmp_key);
if (node)
- return __node_2_uprobe(node);
+ return get_uprobe(__node_2_uprobe(node));
return NULL;
}
--
2.17.1
[PATCH v3] kcmp: Support selection of SYS_kcmp without CHECKPOINT_RESTORE
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend upon it. In particular, Mesa uses SYS_kcmp for
os_same_file_description() in order to identify when two fd (e.g. device
or dmabuf) point to the same struct file. Since they depend on it for
core functionality, lift SYS_kcmp out of the non-default
CONFIG_CHECKPOINT_RESTORE into the selectable syscall category.
Rasmus Villemoes also pointed out that systemd uses SYS_kcmp to
deduplicate the per-service file descriptor store.
Note that some distributions such as Ubuntu are already enabling
CHECKPOINT_RESTORE in their configs and so, by extension, SYS_kcmp.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3046
Signed-off-by: Chris Wilson
Cc: Kees Cook
Cc: Andy Lutomirski
Cc: Will Drewry
Cc: Andrew Morton
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Lucas Stach
Cc: Rasmus Villemoes
Cc: Cyrill Gorcunov
Cc: sta...@vger.kernel.org
Acked-by: Daniel Vetter # DRM depends on kcmp
Acked-by: Rasmus Villemoes # systemd uses kcmp
---
v2:
- Default n.
- Borrrow help message from man kcmp.
- Export get_epoll_tfile_raw_ptr() for CONFIG_KCMP
v3:
- Select KCMP for CONFIG_DRM
---
drivers/gpu/drm/Kconfig | 3 +++
fs/eventpoll.c| 4 ++--
include/linux/eventpoll.h | 2 +-
init/Kconfig | 11 +++
kernel/Makefile | 2 +-
tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
6 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0973f408d75f..af6c6d214d91 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -15,6 +15,9 @@ menuconfig DRM
select I2C_ALGOBIT
select DMA_SHARED_BUFFER
select SYNC_FILE
+# gallium uses SYS_kcmp for os_same_file_description() to de-duplicate
+# device and dmabuf fd. Let's make sure that is available for our userspace.
+ select KCMP
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index a829af074eb5..3196474cbe24 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -979,7 +979,7 @@ static struct epitem *ep_find(struct eventpoll *ep, struct
file *file, int fd)
return epir;
}
-#ifdef CONFIG_CHECKPOINT_RESTORE
+#ifdef CONFIG_KCMP
static struct epitem *ep_find_tfd(struct eventpoll *ep, int tfd, unsigned long
toff)
{
struct rb_node *rbp;
@@ -1021,7 +1021,7 @@ struct file *get_epoll_tfile_raw_ptr(struct file *file,
int tfd,
return file_raw;
}
-#endif /* CONFIG_CHECKPOINT_RESTORE */
+#endif /* CONFIG_KCMP */
/**
* Adds a new entry to the tail of the list in a lockless way, i.e.
diff --git a/include/linux/eventpoll.h b/include/linux/eventpoll.h
index 0350393465d4..593322c946e6 100644
--- a/include/linux/eventpoll.h
+++ b/include/linux/eventpoll.h
@@ -18,7 +18,7 @@ struct file;
#ifdef CONFIG_EPOLL
-#ifdef CONFIG_CHECKPOINT_RESTORE
+#ifdef CONFIG_KCMP
struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, unsigned long
toff);
#endif
diff --git a/init/Kconfig b/init/Kconfig
index b77c60f8b963..9cc7436b2f73 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1194,6 +1194,7 @@ endif # NAMESPACES
config CHECKPOINT_RESTORE
bool "Checkpoint/restore support"
select PROC_CHILDREN
+ select KCMP
default n
help
Enables additional kernel features in a sake of checkpoint/restore.
@@ -1737,6 +1738,16 @@ config ARCH_HAS_MEMBARRIER_CALLBACKS
config ARCH_HAS_MEMBARRIER_SYNC_CORE
bool
+config KCMP
+ bool "Enable kcmp() system call" if EXPERT
+ help
+ Enable the kernel resource comparison system call. It provides
+ user-space with the ability to compare two processes to see if they
+ share a common resource, such as a file descriptor or even virtual
+ memory space.
+
+ If unsure, say N.
+
config RSEQ
bool "Enable rseq() system call" if EXPERT
default y
diff --git a/kernel/Makefile b/kernel/Makefile
index aa7368c7eabf..320f1f3941b7 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -51,7 +51,7 @@ obj-y += livepatch/
obj-y += dma/
obj-y += entry/
-obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o
+obj-$(CONFIG_KCMP) += kcmp.o
obj-$(CONFIG_FREEZER) += freezer.o
obj-$(CONFIG_PROFILING) += profile.o
obj-$(CONFIG_STACKTRACE) += stacktrace.o
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 26c72f2b61b1..1b6c7d33c4ff 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -315,7 +315,7 @@ TEST(kcmp)
ret = __filecmp(getpid(), getpid(), 1, 1);
EXPECT_EQ(ret, 0);
if (ret != 0 && errno ==
Re: [PATCH] mm: cma: support sysfs
On 2/5/21 1:28 PM, Minchan Kim wrote: On Fri, Feb 05, 2021 at 12:25:52PM -0800, John Hubbard wrote: On 2/5/21 8:15 AM, Minchan Kim wrote: ... OK. But...what *is* your goal, and why is this useless (that's what orthogonal really means here) for your goal? As I mentioned, the goal is to monitor the failure from each of CMA since they have each own purpose. Let's have an example. System has 5 CMA area and each CMA is associated with each user scenario. They have exclusive CMA area to avoid fragmentation problem. CMA-1 depends on bluetooh CMA-2 depends on WIFI CMA-3 depends on sensor-A CMA-4 depends on sensor-B CMA-5 depends on sensor-C aha, finally. I had no idea that sort of use case was happening. This would be good to put in the patch commit description. With this, we could catch which module was affected but with global failure, I couldn't find who was affected. Also, would you be willing to try out something simple first, such as providing indication that cma is active and it's overall success rate, like this: /proc/vmstat: cma_alloc_success 125 cma_alloc_failure 25 ...or is the only way to provide the more detailed items, complete with per-CMA details, in a non-debugfs location? ...and then, to see if more is needed, some questions: a) Do you know of an upper bound on how many cma areas there can be (I think Matthew also asked that)? There is no upper bound since it's configurable. OK, thanks,so that pretty much rules out putting per-cma details into anything other than a directory or something like it. b) Is tracking the cma area really as valuable as other possibilities? We can put "a few" to "several" items here, so really want to get your very favorite bits of information in. If, for example, there can be *lots* of cma areas, then maybe tracking At this moment, allocation/failure for each CMA area since they have particular own usecase, which makes me easy to keep which module will be affected. I think it is very useful per-CMA statistics as minimum code change so I want to enable it by default under CONFIG_CMA && CONFIG_SYSFS. by a range of allocation sizes is better... I takes your suggestion something like this. [alloc_range] could be order or range by interval /sys/kernel/mm/cma/cma-A/[alloc_range]/success /sys/kernel/mm/cma/cma-A/[alloc_range]/fail .. .. /sys/kernel/mm/cma/cma-Z/[alloc_range]/success /sys/kernel/mm/cma/cma-Z/[alloc_range]/fail Actually, I meant, "ranges instead of cma areas", like this: / Understand your point but it would make hard to find who was affected by the failure. That's why I suggested to have your suggestion under additional config since per-cma metric with simple sucess/failure are enough. I agree it would be also useful but I'd like to enable it under CONFIG_CMA_SYSFS_ALLOC_RANGE as separate patchset. I will stop harassing you very soon, just want to bottom out on understanding the real goals first. :) I hope my example makes the goal more clear for you. Yes it does. Based on the (rather surprising) use of cma-area-per-device, it seems clear that you will need this, so I'll drop my objections to putting it in sysfs. I still think the "number of allocation failures" needs refining, probably via a range-based thing, as we've discussed. But the number of pages failed per cma looks OK now. thanks, -- John Hubbard NVIDIA
[PATCH 05/15] ARM: dts: ls1021a-qds: Add node for QSPI flash
Add the missing node for qspi flash.
Signed-off-by: Li Yang
---
arch/arm/boot/dts/ls1021a-qds.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts
b/arch/arm/boot/dts/ls1021a-qds.dts
index 71bab93bc4cc..86d969d0ef68 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -286,6 +286,21 @@
};
};
+ {
+ num-cs = <2>;
+ status = "okay";
+
+ qflash0: flash@0 {
+ compatible = "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <2000>;
+ reg = <0>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ };
+};
+
{
status = "okay";
};
--
2.17.1
[PATCH 12/15] ARM: dts: ls1021a: add #dma-cells to qdma node
Add the #dma-cells to align with the dma schema. Signed-off-by: Li Yang --- arch/arm/boot/dts/ls1021a.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi index 715932b1df58..a6342d69b4ea 100644 --- a/arch/arm/boot/dts/ls1021a.dtsi +++ b/arch/arm/boot/dts/ls1021a.dtsi @@ -950,6 +950,7 @@ ; interrupt-names = "qdma-error", "qdma-queue0", "qdma-queue1"; + #dma-cells = <2>; dma-channels = <8>; block-number = <1>; block-offset = <0x1000>; -- 2.17.1
[PATCH 14/15] ARM: dts: ls1021a-qds: change fpga to simple-mfd device
The FPGA is not really a bus but more like an MFD device. Change the
compatible string from "simple-bus" to "simple-mfd". This also fix a
node name issue with simple-bus schema.
Signed-off-by: Li Yang
---
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts
b/arch/arm/boot/dts/ls1021a-qds.dts
index 01fe0e7665f4..d311f60170ce 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -205,7 +205,7 @@
fpga: board-control@3,0 {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "simple-bus";
+ compatible = "simple-mfd";
reg = <0x3 0x0 0x100>;
bank-width = <1>;
device-width = <1>;
--
2.17.1
[PATCH 02/15] dt-bindings: i2c: imx: update schema to align with original binding
Layerscape SoCs doesn't use ipg as clock name. Remove the clock name requirement in the schema. Also the original binding doesn't enforce the order of "tx" and "rx" in dma-names. Both orders are used extensively in existing dtses, update the schema to allow both. Signed-off-by: Li Yang --- Documentation/devicetree/bindings/i2c/i2c-imx.yaml | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml index f23966b0d6c6..57237b0b7d89 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml @@ -54,20 +54,19 @@ properties: maxItems: 1 clock-names: -const: ipg +maxItems: 1 clock-frequency: enum: [ 10, 40 ] dmas: -items: - - description: DMA controller phandle and request line for RX - - description: DMA controller phandle and request line for TX +minItems: 2 +maxItems: 2 dma-names: items: - - const: rx - - const: tx + - enum: [ "rx", "tx" ] + - enum: [ "tx", "rx" ] sda-gpios: maxItems: 1 -- 2.17.1
[PATCH 13/15] ARM: dts: ls1021a: add #power-domain-cells for power-controller node
Add the #power-domain-cells for power-controller node as required by the
schema.
Signed-off-by: Li Yang
---
arch/arm/boot/dts/ls1021a.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index a6342d69b4ea..cf2b5ad42a65 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -964,6 +964,7 @@
compatible = "fsl,ls1021a-rcpm", "fsl,qoriq-rcpm-2.1+";
reg = <0x0 0x1ee2140 0x0 0x8>;
#fsl,rcpm-wakeup-cells = <2>;
+ #power-domain-cells = <0>;
};
ftm_alarm0: timer0@29d {
--
2.17.1
[PATCH 15/15] ARM: dts: ls1021a-tsn: remove undocumented property "position" from mma8452 node
Property "postion" is not documented in the mma8452 binding. Remove it
to resolve the error in "make dtbs_check"
Signed-off-by: Li Yang
---
arch/arm/boot/dts/ls1021a-tsn.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/ls1021a-tsn.dts
b/arch/arm/boot/dts/ls1021a-tsn.dts
index ce470ebfb2c0..8005efc5c812 100644
--- a/arch/arm/boot/dts/ls1021a-tsn.dts
+++ b/arch/arm/boot/dts/ls1021a-tsn.dts
@@ -137,7 +137,6 @@
/* 3 axis accelerometer */
accelerometer@1e {
compatible = "fsl,fxls8471";
- position = <0>;
reg = <0x1e>;
};
--
2.17.1
[PATCH 03/15] dt-bindings: memory: fsl: convert ifc binding to yaml schema
Convert the txt binding to yaml format and add description. Also
updated the recommended node name to ifc-bus to align with the
simple-bus node name requirements.
Signed-off-by: Li Yang
---
.../bindings/memory-controllers/fsl/ifc.txt | 82 --
.../bindings/memory-controllers/fsl/ifc.yaml | 140 ++
2 files changed, 140 insertions(+), 82 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
create mode 100644
Documentation/devicetree/bindings/memory-controllers/fsl/ifc.yaml
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
deleted file mode 100644
index 89427b018ba7..
--- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
+++ /dev/null
@@ -1,82 +0,0 @@
-Integrated Flash Controller
-
-Properties:
-- name : Should be ifc
-- compatible : should contain "fsl,ifc". The version of the integrated
- flash controller can be found in the IFC_REV register at
- offset zero.
-
-- #address-cells : Should be either two or three. The first cell is the
- chipselect number, and the remaining cells are the
- offset into the chipselect.
-- #size-cells : Either one or two, depending on how large each chipselect
-can be.
-- reg : Offset and length of the register set for the device
-- interrupts: IFC may have one or two interrupts. If two interrupt
- specifiers are present, the first is the "common"
- interrupt (CM_EVTER_STAT), and the second is the NAND
- interrupt (NAND_EVTER_STAT). If there is only one,
- that interrupt reports both types of event.
-
-- little-endian : If this property is absent, the big-endian mode will
- be in use as default for registers.
-
-- ranges : Each range corresponds to a single chipselect, and covers
- the entire access window as configured.
-
-Child device nodes describe the devices connected to IFC such as NOR (e.g.
-cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices
-like FPGAs, CPLDs, etc.
-
-Example:
-
- ifc@ffe1e000 {
- compatible = "fsl,ifc", "simple-bus";
- #address-cells = <2>;
- #size-cells = <1>;
- reg = <0x0 0xffe1e000 0 0x2000>;
- interrupts = <16 2 19 2>;
- little-endian;
-
- /* NOR, NAND Flashes and CPLD on board */
- ranges = <0x0 0x0 0x0 0xee00 0x0200
- 0x1 0x0 0x0 0xffa0 0x0001
- 0x3 0x0 0x0 0xffb0 0x0002>;
-
- flash@0,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "cfi-flash";
- reg = <0x0 0x0 0x200>;
- bank-width = <2>;
- device-width = <1>;
-
- partition@0 {
- /* 32MB for user data */
- reg = <0x0 0x0200>;
- label = "NOR Data";
- };
- };
-
- flash@1,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,ifc-nand";
- reg = <0x1 0x0 0x1>;
-
- partition@0 {
- /* This location must not be altered */
- /* 1MB for u-boot Bootloader Image */
- reg = <0x0 0x0010>;
- label = "NAND U-Boot Image";
- read-only;
- };
- };
-
- cpld@3,0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "fsl,p1010rdb-cpld";
- reg = <0x3 0x0 0x01f>;
- };
- };
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.yaml
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.yaml
new file mode 100644
index ..d37cae66b027
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/memory-controllers/fsl/ifc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FSL/NXP Integrated Flash Controller
+
+maintainers:
+ - Li Yang
+
+description: |
+ NXP's integrated flash controller (IFC) is an advanced version of the
+ enhanced local bus controller which includes similar programming and signal
+ interfaces with an extended feature set. The IFC provides access to
[PATCH 08/15] ARM: dts: ls1021a: breakup long values in thermal node
Breakup long values to pass the schema check. Signed-off-by: Li Yang --- arch/arm/boot/dts/ls1021a.dtsi | 72 +- 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi index 215a3d928ec9..88e7248fc5f0 100644 --- a/arch/arm/boot/dts/ls1021a.dtsi +++ b/arch/arm/boot/dts/ls1021a.dtsi @@ -247,42 +247,42 @@ reg = <0x0 0x1f0 0x0 0x1>; interrupts = ; fsl,tmu-range = <0xb 0x9002c 0x6004e 0x30066>; - fsl,tmu-calibration = <0x 0x0020 - 0x0001 0x0024 - 0x0002 0x002a - 0x0003 0x0032 - 0x0004 0x0038 - 0x0005 0x003e - 0x0006 0x0043 - 0x0007 0x004a - 0x0008 0x0050 - 0x0009 0x0059 - 0x000a 0x005f - 0x000b 0x0066 - - 0x0001 0x0023 - 0x00010001 0x002b - 0x00010002 0x0033 - 0x00010003 0x003a - 0x00010004 0x0042 - 0x00010005 0x004a - 0x00010006 0x0054 - 0x00010007 0x005c - 0x00010008 0x0065 - 0x00010009 0x006f - - 0x0002 0x0029 - 0x00020001 0x0033 - 0x00020002 0x003d - 0x00020003 0x0048 - 0x00020004 0x0054 - 0x00020005 0x0060 - 0x00020006 0x006c - - 0x0003 0x0025 - 0x00030001 0x0033 - 0x00030002 0x0043 - 0x00030003 0x0055>; + fsl,tmu-calibration = <0x 0x0020>, + <0x0001 0x0024>, + <0x0002 0x002a>, + <0x0003 0x0032>, + <0x0004 0x0038>, + <0x0005 0x003e>, + <0x0006 0x0043>, + <0x0007 0x004a>, + <0x0008 0x0050>, + <0x0009 0x0059>, + <0x000a 0x005f>, + <0x000b 0x0066>, + + <0x0001 0x0023>, + <0x00010001 0x002b>, + <0x00010002 0x0033>, + <0x00010003 0x003a>, + <0x00010004 0x0042>, + <0x00010005 0x004a>, + <0x00010006 0x0054>, + <0x00010007 0x005c>, + <0x00010008 0x0065>, + <0x00010009 0x006f>, + + <0x0002 0x0029>, + <0x00020001 0x0033>, + <0x00020002 0x003d>, + <0x00020003 0x0048>, + <0x00020004 0x0054>, + <0x00020005 0x0060>, + <0x00020006 0x006c>, + + <0x0003
[RFC v1 10/26] x86/io: Allow to override inX() and outX() implementation
From: "Kirill A. Shutemov"
The patch allows to override the implementation of the port IO
helpers. TDX code will provide an implementation that redirect the
helpers to paravirt calls.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/include/asm/io.h | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index d726459d08e5..ef7a686a55a9 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -271,18 +271,26 @@ static inline bool sev_key_active(void) { return false; }
#endif /* CONFIG_AMD_MEM_ENCRYPT */
+#ifndef __out
+#define __out(bwl, bw) \
+ asm volatile("out" #bwl " %" #bw "0, %w1" : : "a"(value), "Nd"(port))
+#endif
+
+#ifndef __in
+#define __in(bwl, bw) \
+ asm volatile("in" #bwl " %w1, %" #bw "0" : "=a"(value) : "Nd"(port))
+#endif
+
#define BUILDIO(bwl, bw, type) \
static inline void out##bwl(unsigned type value, int port) \
{ \
- asm volatile("out" #bwl " %" #bw "0, %w1" \
-: : "a"(value), "Nd"(port)); \
+ __out(bwl, bw); \
} \
\
static inline unsigned type in##bwl(int port) \
{ \
unsigned type value;\
- asm volatile("in" #bwl " %w1, %" #bw "0"\
-: "=a"(value) : "Nd"(port)); \
+ __in(bwl, bw); \
return value; \
} \
\
--
2.25.1
[PATCH v5 32/34] dt-bindings: misc: hddl_dev: Add hddl device management documentation
From: "C, Udhayakumar"
Add hddl device management documentation
The HDDL client driver acts as an software RTC to sync with network time.
It abstracts xlink protocol to communicate with remote IA host.
This driver exports the details about sensors available in the platform
to remote IA host as xlink packets.
This driver also handles device connect/disconnect events and identifies
board id and soc id using gpio's based on platform configuration.
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
.../bindings/misc/intel,hddl-client.yaml | 117 ++
1 file changed, 117 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/intel,hddl-client.yaml
diff --git a/Documentation/devicetree/bindings/misc/intel,hddl-client.yaml
b/Documentation/devicetree/bindings/misc/intel,hddl-client.yaml
new file mode 100644
index ..522b461663b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/intel,hddl-client.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/misc/intel,hddl-client.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Intel hddl client device to handle platform management in Bay series
+
+maintainers:
+ - Udhayakumar C
+
+description: |
+ The HDDL client driver acts as an software RTC to sync with network time.
+ It abstracts xlink protocol to communicate with remote host. This driver
+ exports the details about sensors available in the platform to remote
+ host as xlink packets.
+ This driver also handles device connect/disconnect events and identifies
+ board id and soc id using gpio's based on platform configuration.
+
+select: false
+
+properties:
+ compatible:
+items:
+ - const: intel,hddl-client
+
+ reg:
+minItems: 4
+maxItems: 4
+
+ xlink_chan:
+minItems: 1
+maxItems: 1
+description: xlink channel number used for communication
+ with remote host for time sync and sharing sensor
+ details available in platform.
+
+ i2c_xlink_chan:
+minItems: 1
+maxItems: 1
+description: xlink channel number used for communication
+ with remote host for xlink i2c smbus.
+
+ sensor_name:
+type: object
+description:
+ Details about sensors and its configuration on local host and remote
+ host.
+
+properties:
+ compatible:
+items:
+ - const: intel_tsens
+
+ reg:
+description: i2c slave address for sensor.
+
+ local-host:
+minItems: 1
+maxItems: 1
+description: enable bit 0 to register sensor as i2c slave
+ in local host (normal i2c client)
+ enable bit 1 to mimic sensor as i2c slave
+ in local host (onchip sensors as i2c slave)
+ enable bit 2 to register i2c slave as xlink smbus slave
+ in local host.
+ remote-host:
+minItems: 1
+maxItems: 1
+description: enable bit 0 to register sensor as i2c slave
+ in remote host (normal i2c client)
+ enable bit 1 to mimic sensor as i2c slave
+ in remote host (onchip sensors as i2c slave)
+ enable bit 2 to register i2c slave as xlink smbus slave
+ in remote host.
+
+ bus:
+minItems: 1
+maxItems: 1
+description: i2c bus number for the i2c client device.
+
+required:
+ - compatible
+ - reg
+ - local-host
+ - remote-host
+ - bus
+
+required:
+ - compatible
+ - reg
+ - xlink_chan
+ - i2c_xlink_chan
+
+additionalProperties: false
+
+examples:
+ - |
+hddl_dev{
+#address-cells = <2>;
+#size-cells = <2>;
+
+hddl@2032 {
+compatible = "intel,hddl-client";
+status = "disabled";
+reg = <0x0 0x2032 0x0 0x800>;
+xlink_chan = <1080>;
+i2c_xlink_chan = <1081>;
+kmb_xlink_tj {
+ status = "okay";
+ compatible = "intel_tsens";
+ local-host = <0x3>;
+ remote-host = <0x3>;
+ bus = <0x1>;
+};
+};
+};
--
2.17.1
[PATCH v5 33/34] misc: Hddl device management for local host
From: "C, Udhayakumar"
Add local host hddl device management for Intel Edge.AI Computer Vision
platforms.
About Intel Edge.AI Computer Vision platforms:
-
The Intel Edge.AI Computer Vision platforms are vision processing systems
targeting machine vision applications for connected devices.
They are based on ARM A53 CPU running Linux and acts as a PCIe
endpoint device.
High-level architecture:
Remote Host IA CPU Local Host ARM CPU
---
| * Send time as xlink packet | |* Sync time with IA host |
| * receive sensor details| |* Prepare and share sensor|
| and register as i2c or| | details to IA host as |
| xlink smbus slaves| | xlink packets |
---
| hddl server | <=> | hddl client |
--- xlink
hddl device module:
---
The HDDL client driver acts as an software RTC to sync with network
time. It abstracts xlink protocol to communicate with remote host.
This driver exports the details about sensors available in the
platform to remote host as xlink packets.
This driver also handles device connect/disconnect events and
identifies board id and soc id using gpio's, based on platform
configuration.
- Local Host driver
* Intended for ARM CPU
* It is based on xlink Framework
* Driver path:
{tree}/drivers/misc/hddl_device/hddl_device_client.c
Local arm host and Remote IA host drivers communicates using
XLINK protocol.
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
.../misc-devices/hddl_device_client.rst | 212 +
Documentation/misc-devices/index.rst | 1 +
Documentation/vpu/index.rst | 1 +
MAINTAINERS | 1 +
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/hddl_device/Kconfig | 14 +
drivers/misc/hddl_device/Makefile | 5 +
drivers/misc/hddl_device/hddl_device.c| 565 +
drivers/misc/hddl_device/hddl_device_lh.c | 764 ++
drivers/misc/hddl_device/hddl_device_util.h | 52 ++
11 files changed, 1617 insertions(+)
create mode 100644 Documentation/misc-devices/hddl_device_client.rst
create mode 100644 drivers/misc/hddl_device/Kconfig
create mode 100644 drivers/misc/hddl_device/Makefile
create mode 100644 drivers/misc/hddl_device/hddl_device.c
create mode 100644 drivers/misc/hddl_device/hddl_device_lh.c
create mode 100644 drivers/misc/hddl_device/hddl_device_util.h
diff --git a/Documentation/misc-devices/hddl_device_client.rst
b/Documentation/misc-devices/hddl_device_client.rst
new file mode 100644
index ..413643b6b500
--- /dev/null
+++ b/Documentation/misc-devices/hddl_device_client.rst
@@ -0,0 +1,212 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Kernel driver: hddl_device_client
+=
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+
+Authors:
+- Thalaiappan, Rathina
+- Udhayakumar C
+
+
+Overview
+
+
+This driver supports hddl device management for Intel Edge.AI Computer Vision
+platforms.
+
+This driver supports the following features:
+
+ - Exports deatils of temperature sensor, current sensor and fan controller
+present in Intel Edge.AI Computer Vision platforms to IA host.
+ - Enable Time sync of Intel Edge.AI Computer Vision platform with IA host.
+ - Handles device connect and disconnect events.
+ - Receives slave address from the IA host for memory mapped thermal sensors
+present in SoC (Documentation/hwmon/intel_tsens_sensors.rst).
+ - Registers i2c slave device for slaves present in Intel Edge.AI Computer
+Vision platform
+
+Keem Bay platform has
+Onchip sensors:
+
+ - Media Subsystem (mss) temperature sensor
+ - NN subsystem (nce) temperature sensor
+ - Compute subsystem (cse) temperature sensor
+ - SOC(Maximum of mss, nce and cse).
+
+Onboard sensors:
+
+ - two lm75 temperature sensors
+ - emc2103 fan controller
+ - ina3221 current sensor
+
+High-level architecture
+===
+::
+
+Remote Host IA CPU Local Host ARM CPU
+---
+| * Send time as xlink packet | |* Sync time with IA host |
+| * receive sensor details| |* Prepare and share sensor|
+| and register as i2c or| | details to IA host as |
+| xlink smbus slaves| | xlink packets |
+---
+
[RFC v1 09/26] x86/tdx: Handle CPUID via #VE
From: "Kirill A. Shutemov"
TDX has three classes of CPUID leaves: some CPUID leaves
are always handled by the CPU, others are handled by the TDX module,
and some others are handled by the VMM. Since the VMM cannot directly
intercept the instruction these are reflected with a #VE exception
to the guest, which then converts it into a TDCALL to the VMM,
or handled directly.
The TDX module EAS has a full list of CPUID leaves which are handled
natively or by the TDX module in 16.2. Only unknown CPUIDs are handled by
the #VE method. In practice this typically only applies to the
hypervisor specific CPUIDs unknown to the native CPU.
Therefore there is no risk of causing this in early CPUID code which
runs before the #VE handler is set up because it will never access
those exotic CPUID leaves.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/kernel/tdx.c | 32
1 file changed, 32 insertions(+)
diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index 5d961263601e..e98058c048b5 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -172,6 +172,35 @@ static int tdx_write_msr_safe(unsigned int msr, unsigned
int low,
return ret || r10 ? -EIO : 0;
}
+static void tdx_handle_cpuid(struct pt_regs *regs)
+{
+ register long r10 asm("r10") = TDVMCALL_STANDARD;
+ register long r11 asm("r11") = EXIT_REASON_CPUID;
+ register long r12 asm("r12") = regs->ax;
+ register long r13 asm("r13") = regs->cx;
+ register long r14 asm("r14");
+ register long r15 asm("r15");
+ register long rcx asm("rcx");
+ long ret;
+
+ /* Allow to pass R10, R11, R12, R13, R14 and R15 down to the VMM */
+ rcx = BIT(10) | BIT(11) | BIT(12) | BIT(13) | BIT(14) | BIT(15);
+
+ asm volatile(TDCALL
+ : "=a"(ret), "=r"(r10), "=r"(r11), "=r"(r12), "=r"(r13),
+ "=r"(r14), "=r"(r15)
+ : "a"(TDVMCALL), "r"(rcx), "r"(r10), "r"(r11), "r"(r12),
+ "r"(r13)
+ : );
+
+ regs->ax = r12;
+ regs->bx = r13;
+ regs->cx = r14;
+ regs->dx = r15;
+
+ WARN_ON(ret || r10);
+}
+
void __init tdx_early_init(void)
{
if (!cpuid_has_tdx_guest())
@@ -227,6 +256,9 @@ int tdx_handle_virtualization_exception(struct pt_regs
*regs,
case EXIT_REASON_MSR_WRITE:
ret = tdx_write_msr_safe(regs->cx, regs->ax, regs->dx);
break;
+ case EXIT_REASON_CPUID:
+ tdx_handle_cpuid(regs);
+ break;
default:
pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
return -EFAULT;
--
2.25.1
[PATCH v5 19/34] xlink-core: Add xlink core device tree bindings
From: Seamus Kelly
Add device tree bindings for keembay-xlink.
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Seamus Kelly
---
.../bindings/misc/intel,keembay-xlink.yaml| 29 +++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/intel,keembay-xlink.yaml
diff --git a/Documentation/devicetree/bindings/misc/intel,keembay-xlink.yaml
b/Documentation/devicetree/bindings/misc/intel,keembay-xlink.yaml
new file mode 100644
index ..5ac2e7fa5b5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/intel,keembay-xlink.yaml
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) Intel Corporation. All rights reserved.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/misc/intel,keembay-xlink.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Intel Keem Bay xlink
+
+maintainers:
+ - Seamus Kelly
+
+description: |
+ The Keem Bay xlink driver enables the communication/control sub-system
+ for internal and external communications to the Intel Keem Bay SoC.
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: intel,keembay-xlink
+
+additionalProperties: False
+
+examples:
+ - |
+xlink {
+compatible = "intel,keembay-xlink";
+};
--
2.17.1
Re: [PATCH] checkpatch: Don't warn about colon termination in linker scripts
On Thu, 2021-02-04 at 16:32 +, Chris Down wrote:
> This check erroneously flags cases like the one in my recent printk
> enumeration patch[0], where the spaces are syntactic, and `section:' vs.
> `section :' is syntactically important:
>
> ERROR: space prohibited before that ':' (ctx:WxW)
> #258: FILE: include/asm-generic/vmlinux.lds.h:314:
> + .printk_fmts : AT(ADDR(.printk_fmts) - LOAD_OFFSET) {
>
> 0: https://lore.kernel.org/patchwork/patch/1375749/
Remember to cc the checkpatch maintainers.
> Signed-off-by: Chris Down
> Cc: Andrew Morton
> ---
> scripts/checkpatch.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 4f8494527139..3bcffc5574ae 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -5046,7 +5046,7 @@ sub process {
> # A colon needs no spaces before when it is
> # terminating a case value or a label.
> } elsif ($opv eq ':C' || $opv eq ':L') {
> - if ($ctx =~ /Wx./) {
> + if ($ctx =~ /Wx./ and $realfile !~
> m@.*\.lds\.h$@) {
> if (ERROR("SPACING",
> "space prohibited
> before that '$op' $at\n" . $hereptr)) {
> $good =
> rtrim($fix_elements[$n]) . trim($fix_elements[$n + 1]);
[PATCH v5 28/34] misc: Intel tsens IA host driver.
From: "C, Udhayakumar"
Add Intel tsens IA host driver for Intel Edge.AI Computer Vision
platforms.
About Intel Edge.AI Computer Vision platforms:
-
The Intel Edge.AI Computer Vision platforms are vision processing systems
targeting machine vision applications for connected devices.
They are based on ARM A53 CPU running Linux and acts as a PCIe
endpoint device.
High-level architecture:
Remote Host IA CPU Local Host ARM CPU
--
| Platform| | Thermal Daemon|
| Management SW| ||
--
| Intel tsens | | intel tsens i2c slave |
| i2c client | | and thermal driver|
--
| XLINK I2C | | XLINK I2C Slave |
| controller | <=> | controller |
xlink smbus --
intel tsens module:
---
The tsens module enables reading of on chip sensors present
in the Intel Edge.AI Computer Vision platforms.In the tsens module
various junction and SoC temperatures are reported using thermal
subsystem and i2c subsystem.
Temperature data reported using thermal subsystem will be used for
various cooling agents such as DVFS, fan control and shutdown the
system in case of critical temperature.
Temperature data reported using i2c subsystem will be used by
platform manageability software running in IA host.
- Remote Host driver
* Intended for IA CPU
* It is a I2C client driver
* Driver path:
{tree}/drivers/misc/intel_tsens/intel_tsens_host.c
Local host and Remote host drivers communicates using
I2C SMBUS protocol.
Acked-by: Mark Mross
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/intel_tsens_host.rst| 71
drivers/misc/intel_tsens/Kconfig| 13 +
drivers/misc/intel_tsens/Makefile | 1 +
drivers/misc/intel_tsens/intel_tsens_host.c | 352
include/linux/intel_tsens_host.h| 34 ++
6 files changed, 472 insertions(+)
create mode 100644 Documentation/hwmon/intel_tsens_host.rst
create mode 100644 drivers/misc/intel_tsens/intel_tsens_host.c
create mode 100644 include/linux/intel_tsens_host.h
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index fc29100bef73..7a9eaddd1ab3 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -81,6 +81,7 @@ Hardware Monitoring Kernel Drivers
isl68137
it87
intel_tsens_sensor.rst
+ intel_tsens_host.rst
jc42
k10temp
k8temp
diff --git a/Documentation/hwmon/intel_tsens_host.rst
b/Documentation/hwmon/intel_tsens_host.rst
new file mode 100644
index ..012c593f969f
--- /dev/null
+++ b/Documentation/hwmon/intel_tsens_host.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Kernel driver: intel_tsens
+==
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+
+Slave address: The address is assigned by the hddl device management
+ driver.
+
+Datasheet:
+ Documentation/hwmon/intel_tsens_sensor.rst#Remote Thermal Interface
+
+Authors:
+- Thalaiappan, Rathina
+
+Description
+===
+The intel_tsens is a temperature sensor driver receiving the junction
temperature
+from different heating points inside the SOC. The driver will receive the
+temperature on SMBUS connection. The reported temperature is in degrees
Celsius.
+
+In Keem Bay, the four thermal junction temperature points are,
+Media Subsystem (mss), NN subsystem (nce), Compute subsystem (cse) and
+SOC(Maximum of mss, nce and cse).
+
+Example
+===
+Temperature reported by a Keem Bay on the Linux Thermal sysfs interface.
+
+# cat /sys/class/thermal/thermal_zone*/type
+mss
+css
+nce
+soc
+
+# cat /sys/class/thermal/thermal_zone*/temp
+0
+29210
+28478
+29210
+
++---+-+
+| offset| Sensor|
++---+-+
+| 0 | mss |
++---+-+
+| 1 | css |
++---+-+
+| 2 | nce |
++---+-+
+| 3 | soc |
++---+-+
+
+#sudo i2cdetect -l
+i2c-8 smbus SMBus I801 adapter at efa0 SMBus adapte
r
+
+To read mss junction temperature:
+#i2cget -y 8 0x0 w
+
+To read cse junction temperature:
+#i2cget -y 8 0x1 w
+
+To read nce junction temperature:
+#i2cget -y 8 0x2 w
+
+To read overall SoC temperature:
+#i2cget -y 8 0x3 w
diff --git a/drivers/misc/intel_tsens/Kconfig
[RFC v1 08/26] x86/tdx: Add MSR support for TDX guest
From: "Kirill A. Shutemov"
Operations on context-switched MSRs can be run natively. The rest of
MSRs should be handled through TDVMCALLs.
TDVMCALL[Instruction.RDMSR] and TDVMCALL[Instruction.WRMSR] provide
MSR oprations.
You can find RDMSR and WRMSR details in Guest-Host-Communication
Interface (GHCI) for Intel Trust Domain Extensions (Intel TDX)
specification, sec 3.10, 3.11.
Also, since CSTAR MSR is not used on Intel CPUs as SYSCALL
instruction, ignore accesses to CSTAR MSR. Ignore accesses to
the MSR for compatibility: no need in wrap callers in
!is_tdx_guest().
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/kernel/tdx.c | 94 ++-
1 file changed, 93 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index bbefe639a2ed..5d961263601e 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -94,6 +94,84 @@ static __cpuidle void tdx_safe_halt(void)
BUG_ON(ret || r10);
}
+static bool tdx_is_context_switched_msr(unsigned int msr)
+{
+ /* XXX: Update the list of context-switched MSRs */
+
+ switch (msr) {
+ case MSR_EFER:
+ case MSR_IA32_CR_PAT:
+ case MSR_FS_BASE:
+ case MSR_GS_BASE:
+ case MSR_KERNEL_GS_BASE:
+ case MSR_IA32_SYSENTER_CS:
+ case MSR_IA32_SYSENTER_EIP:
+ case MSR_IA32_SYSENTER_ESP:
+ case MSR_STAR:
+ case MSR_LSTAR:
+ case MSR_SYSCALL_MASK:
+ case MSR_IA32_XSS:
+ case MSR_TSC_AUX:
+ case MSR_IA32_BNDCFGS:
+ return true;
+ }
+ return false;
+}
+
+static u64 tdx_read_msr_safe(unsigned int msr, int *err)
+{
+ register long r10 asm("r10") = TDVMCALL_STANDARD;
+ register long r11 asm("r11") = EXIT_REASON_MSR_READ;
+ register long r12 asm("r12") = msr;
+ register long rcx asm("rcx");
+ long ret;
+
+ WARN_ON_ONCE(tdx_is_context_switched_msr(msr));
+
+ if (msr == MSR_CSTAR)
+ return 0;
+
+ /* Allow to pass R10, R11 and R12 down to the VMM */
+ rcx = BIT(10) | BIT(11) | BIT(12);
+
+ asm volatile(TDCALL
+ : "=a"(ret), "=r"(r10), "=r"(r11), "=r"(r12)
+ : "a"(TDVMCALL), "r"(rcx), "r"(r10), "r"(r11), "r"(r12)
+ : );
+
+ /* XXX: Better error handling needed? */
+ *err = (ret || r10) ? -EIO : 0;
+
+ return r11;
+}
+
+static int tdx_write_msr_safe(unsigned int msr, unsigned int low,
+ unsigned int high)
+{
+ register long r10 asm("r10") = TDVMCALL_STANDARD;
+ register long r11 asm("r11") = EXIT_REASON_MSR_WRITE;
+ register long r12 asm("r12") = msr;
+ register long r13 asm("r13") = (u64)high << 32 | low;
+ register long rcx asm("rcx");
+ long ret;
+
+ WARN_ON_ONCE(tdx_is_context_switched_msr(msr));
+
+ if (msr == MSR_CSTAR)
+ return 0;
+
+ /* Allow to pass R10, R11, R12 and R13 down to the VMM */
+ rcx = BIT(10) | BIT(11) | BIT(12) | BIT(13);
+
+ asm volatile(TDCALL
+ : "=a"(ret), "=r"(r10), "=r"(r11), "=r"(r12), "=r"(r13)
+ : "a"(TDVMCALL), "r"(rcx), "r"(r10), "r"(r11), "r"(r12),
+ "r"(r13)
+ : );
+
+ return ret || r10 ? -EIO : 0;
+}
+
void __init tdx_early_init(void)
{
if (!cpuid_has_tdx_guest())
@@ -132,17 +210,31 @@ unsigned long tdx_get_ve_info(struct ve_info *ve)
int tdx_handle_virtualization_exception(struct pt_regs *regs,
struct ve_info *ve)
{
+ unsigned long val;
+ int ret = 0;
+
switch (ve->exit_reason) {
case EXIT_REASON_HLT:
tdx_halt();
break;
+ case EXIT_REASON_MSR_READ:
+ val = tdx_read_msr_safe(regs->cx, (unsigned int *));
+ if (!ret) {
+ regs->ax = val & UINT_MAX;
+ regs->dx = val >> 32;
+ }
+ break;
+ case EXIT_REASON_MSR_WRITE:
+ ret = tdx_write_msr_safe(regs->cx, regs->ax, regs->dx);
+ break;
default:
pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
return -EFAULT;
}
/* After successful #VE handling, move the IP */
- regs->ip += ve->instr_len;
+ if (!ret)
+ regs->ip += ve->instr_len;
return ret;
}
--
2.25.1
[PATCH v5 25/34] misc: Add Keem Bay VPU manager
From: "Li, Tingqian"
VPU IP on Keem Bay SOC is a vision acceleration IP complex
under the control of a RTOS-based firmware (running on RISC
MCU inside the VPU IP) serving user-space application
running on CPU side for HW accelerated computer vision tasks.
This module is kernel counterpart of the VPUAL(VPU abstraction
layer) which bridges firmware on VPU side and applications on
CPU user-space, it assists firmware on VPU side serving multiple
user space application processes on CPU side concurrently while
also performing necessary data buffer management on behave of
VPU IP.
objmgr provides basic infrastructure for create/destroy VPU side
software object concurrently on demand of user-space application
and also automatically release leaked objects during handling of
application termination. Note this module only cares about the
life-cycle of such objects, it's up to the application and firmware
to define the behavior/operations of each object.
objmgr does it's job by communicating with firmware through a fixed
reserved xlink channel, using a very simple message protocol.
smm provides DMABuf allocation/import facilities to allow user-space
app pass data to/from VPU in zero-copy fashion. it also provided a
convenient ioctl function for converting virtual pointer of a mem-mapped
and imported DMABuf into it's corresponding dma address, to allow
user-space app to specify the sub-regions of a bigger DMABuf to be
processed by VPU.
Signed-off-by: Li Tingqian
Signed-off-by: Zhou Luwei
Signed-off-by: Wang jue
Signed-off-by: Mark Gross
---
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile| 1 +
drivers/misc/vpumgr/Kconfig | 9 +
drivers/misc/vpumgr/Makefile | 3 +
drivers/misc/vpumgr/vpu_common.h | 31 ++
drivers/misc/vpumgr/vpu_mgr.c| 370
drivers/misc/vpumgr/vpu_smm.c| 554 +
drivers/misc/vpumgr/vpu_smm.h| 30 ++
drivers/misc/vpumgr/vpu_vcm.c| 584 +++
drivers/misc/vpumgr/vpu_vcm.h| 84 +
include/uapi/misc/vpumgr.h | 64
11 files changed, 1731 insertions(+)
create mode 100644 drivers/misc/vpumgr/Kconfig
create mode 100644 drivers/misc/vpumgr/Makefile
create mode 100644 drivers/misc/vpumgr/vpu_common.h
create mode 100644 drivers/misc/vpumgr/vpu_mgr.c
create mode 100644 drivers/misc/vpumgr/vpu_smm.c
create mode 100644 drivers/misc/vpumgr/vpu_smm.h
create mode 100644 drivers/misc/vpumgr/vpu_vcm.c
create mode 100644 drivers/misc/vpumgr/vpu_vcm.h
create mode 100644 include/uapi/misc/vpumgr.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 09ae65e98681..2d1f7b165cc8 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -484,4 +484,5 @@ source "drivers/misc/uacce/Kconfig"
source "drivers/misc/xlink-pcie/Kconfig"
source "drivers/misc/xlink-ipc/Kconfig"
source "drivers/misc/xlink-core/Kconfig"
+source "drivers/misc/vpumgr/Kconfig"
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f3a6eb03bae9..2936930f3edc 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_HISI_HIKEY_USB) += hisi_hikey_usb.o
obj-y += xlink-pcie/
obj-$(CONFIG_XLINK_IPC)+= xlink-ipc/
obj-$(CONFIG_XLINK_CORE) += xlink-core/
+obj-$(CONFIG_VPUMGR) += vpumgr/
diff --git a/drivers/misc/vpumgr/Kconfig b/drivers/misc/vpumgr/Kconfig
new file mode 100644
index ..bb82ff83afd3
--- /dev/null
+++ b/drivers/misc/vpumgr/Kconfig
@@ -0,0 +1,9 @@
+config VPUMGR
+ tristate "VPU Manager"
+ depends on ARM64 && XLINK_CORE
+ help
+ VPUMGR manages life-cycle of VPU related resources which were
+ dynamically allocated on demands of user-space application
+
+ Select y or m if you have a processor including the Intel
+ Vision Processor (VPU) on it.
diff --git a/drivers/misc/vpumgr/Makefile b/drivers/misc/vpumgr/Makefile
new file mode 100644
index ..51441dc8a930
--- /dev/null
+++ b/drivers/misc/vpumgr/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_VPUMGR) += vpumgr.o
+vpumgr-objs := vpu_mgr.o vpu_smm.o vpu_vcm.o
diff --git a/drivers/misc/vpumgr/vpu_common.h b/drivers/misc/vpumgr/vpu_common.h
new file mode 100644
index ..cd474ffc05f3
--- /dev/null
+++ b/drivers/misc/vpumgr/vpu_common.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0-only
+ * VPUMGR Kernel module - common definition
+ * Copyright (C) 2020-2021 Intel Corporation
+ */
+#ifndef _VPU_COMMON_H
+#define _VPU_COMMON_H
+#include
+#include
+
+#include
+
+#include "vpu_vcm.h"
+
+/* there will be one such device for each HW instance */
+struct vpumgr_device {
+ struct device *sdev;
+ struct device *dev;
+ dev_t devnum;
+ struct cdev cdev;
+ struct platform_device *pdev;
+
+ struct vcm_dev vcm;
+ struct dentry *debugfs_root;
+
+
[RFC v1 07/26] x86/tdx: Wire up KVM hypercalls
From: "Kirill A. Shutemov"
KVM hypercalls have to be wrapped into vendor-specific TDVMCALLs.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/include/asm/kvm_para.h | 21 ++
arch/x86/include/asm/tdx.h | 8 +++
arch/x86/kernel/tdx-kvm.c | 116
arch/x86/kernel/tdx.c | 4 ++
4 files changed, 149 insertions(+)
create mode 100644 arch/x86/kernel/tdx-kvm.c
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index 338119852512..2fa85481520b 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
extern void kvmclock_init(void);
@@ -34,6 +35,10 @@ static inline bool kvm_check_and_clear_guest_paused(void)
static inline long kvm_hypercall0(unsigned int nr)
{
long ret;
+
+ if (is_tdx_guest())
+ return tdx_kvm_hypercall0(nr);
+
asm volatile(KVM_HYPERCALL
: "=a"(ret)
: "a"(nr)
@@ -44,6 +49,10 @@ static inline long kvm_hypercall0(unsigned int nr)
static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
{
long ret;
+
+ if (is_tdx_guest())
+ return tdx_kvm_hypercall1(nr, p1);
+
asm volatile(KVM_HYPERCALL
: "=a"(ret)
: "a"(nr), "b"(p1)
@@ -55,6 +64,10 @@ static inline long kvm_hypercall2(unsigned int nr, unsigned
long p1,
unsigned long p2)
{
long ret;
+
+ if (is_tdx_guest())
+ return tdx_kvm_hypercall2(nr, p1, p2);
+
asm volatile(KVM_HYPERCALL
: "=a"(ret)
: "a"(nr), "b"(p1), "c"(p2)
@@ -66,6 +79,10 @@ static inline long kvm_hypercall3(unsigned int nr, unsigned
long p1,
unsigned long p2, unsigned long p3)
{
long ret;
+
+ if (is_tdx_guest())
+ return tdx_kvm_hypercall3(nr, p1, p2, p3);
+
asm volatile(KVM_HYPERCALL
: "=a"(ret)
: "a"(nr), "b"(p1), "c"(p2), "d"(p3)
@@ -78,6 +95,10 @@ static inline long kvm_hypercall4(unsigned int nr, unsigned
long p1,
unsigned long p4)
{
long ret;
+
+ if (is_tdx_guest())
+ return tdx_kvm_hypercall4(nr, p1, p2, p3, p4);
+
asm volatile(KVM_HYPERCALL
: "=a"(ret)
: "a"(nr), "b"(p1), "c"(p2), "d"(p3), "S"(p4)
diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
index b98de067257b..8c3e5af88643 100644
--- a/arch/x86/include/asm/tdx.h
+++ b/arch/x86/include/asm/tdx.h
@@ -51,4 +51,12 @@ unsigned long tdx_get_ve_info(struct ve_info *ve);
int tdx_handle_virtualization_exception(struct pt_regs *regs,
struct ve_info *ve);
+long tdx_kvm_hypercall0(unsigned int nr);
+long tdx_kvm_hypercall1(unsigned int nr, unsigned long p1);
+long tdx_kvm_hypercall2(unsigned int nr, unsigned long p1, unsigned long p2);
+long tdx_kvm_hypercall3(unsigned int nr, unsigned long p1, unsigned long p2,
+ unsigned long p3);
+long tdx_kvm_hypercall4(unsigned int nr, unsigned long p1, unsigned long p2,
+ unsigned long p3, unsigned long p4);
+
#endif /* _ASM_X86_TDX_H */
diff --git a/arch/x86/kernel/tdx-kvm.c b/arch/x86/kernel/tdx-kvm.c
new file mode 100644
index ..323d43fcb338
--- /dev/null
+++ b/arch/x86/kernel/tdx-kvm.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+long tdx_kvm_hypercall0(unsigned int nr)
+{
+ register long r10 asm("r10") = TDVMCALL_VENDOR;
+ register long r11 asm("r11") = nr;
+ register long rcx asm("rcx");
+ long ret;
+
+ /* Allow to pass R10 and R11 down to the VMM */
+ rcx = BIT(10) | BIT(11);
+
+ asm volatile(TDCALL
+ : "=a"(ret), "=r"(r10)
+ : "a"(TDVMCALL), "r"(rcx), "r"(r10), "r"(r11)
+ : "memory");
+
+ BUG_ON(ret);
+ return r10;
+}
+EXPORT_SYMBOL_GPL(tdx_kvm_hypercall0);
+
+long tdx_kvm_hypercall1(unsigned int nr, unsigned long p1)
+{
+ register long r10 asm("r10") = TDVMCALL_VENDOR;
+ register long r11 asm("r11") = nr;
+ register long r12 asm("r12") = p1;
+ register long rcx asm("rcx");
+ long ret;
+
+ /* Allow to pass R10, R11 and R12 down to the VMM */
+ rcx = BIT(10) | BIT(11) | BIT(12);
+
+ asm volatile(TDCALL
+ : "=a"(ret), "=r"(r10)
+ : "a"(TDVMCALL), "r"(rcx), "r"(r10), "r"(r11), "r"(r12)
+ : "memory");
+
+ BUG_ON(ret);
+ return r10;
+}
+EXPORT_SYMBOL_GPL(tdx_kvm_hypercall1);
+
+long tdx_kvm_hypercall2(unsigned int nr, unsigned long p1, unsigned long p2)
+{
+ register long r10 asm("r10") =
Re: [PATCH] mm: cma: support sysfs
On 2/5/21 1:52 PM, Suren Baghdasaryan wrote: I takes your suggestion something like this. [alloc_range] could be order or range by interval /sys/kernel/mm/cma/cma-A/[alloc_range]/success /sys/kernel/mm/cma/cma-A/[alloc_range]/fail .. .. /sys/kernel/mm/cma/cma-Z/[alloc_range]/success /sys/kernel/mm/cma/cma-Z/[alloc_range]/fail The interface above seems to me the most useful actually, if by [alloc_range] you mean the different allocation orders. This would cover Minchan's per-CMA failure tracking and would also allow us to understand what kind of allocations are failing and therefore if the problem is caused by pinning/fragmentation or by over-utilization. I agree. That seems about right, now that we've established that cma areas are a must-have. thanks, -- John Hubbard NVIDIA
[PATCH v5 06/34] dt-bindings: Add bindings for Keem Bay VPU IPC driver
From: Paul Murphy
Add DT bindings documentation for the Keem Bay VPU IPC driver.
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Reviewed-by: Mark Gross
Co-developed-by: Daniele Alessandrelli
Signed-off-by: Paul Murphy
Signed-off-by: Daniele Alessandrelli
Signed-off-by: Mark Gross
---
.../soc/intel/intel,keembay-vpu-ipc.yaml | 143 ++
1 file changed, 143 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml
diff --git
a/Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml
b/Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml
new file mode 100644
index ..9dae8ab4c723
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/intel/intel,keembay-vpu-ipc.yaml
@@ -0,0 +1,143 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) Intel Corporation. All rights reserved.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/soc/intel/intel,keembay-vpu-ipc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Intel Keem Bay VPU IPC
+
+maintainers:
+ - Paul Murphy
+ - Daniele Alessandrelli
+
+description:
+ This binding provides support for the Vision Processing Unit (VPU) found on
+ the Intel Keem Bay SoC.
+
+ The VPU is started and controlled by SoC CPU, which is in charge of loading
+ the VPU firmware. The SoC CPU can communicate with the VPU firmware using an
+ Inter-Processor Communication (IPC) mechanism.
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: intel,keembay-vpu-ipc
+
+ reg:
+items:
+ - description: NCE WDT registers
+ - description: NCE TIM_GEN_CONFIG registers
+ - description: MSS WDT registers
+ - description: MSS TIM_GEN_CONFIG registers
+
+ reg-names:
+items:
+ - const: nce_wdt
+ - const: nce_tim_cfg
+ - const: mss_wdt
+ - const: mss_tim_cfg
+
+ memory-region:
+items:
+ - description: reference to the VPU reserved memory region
+ - description: reference to the X509 reserved memory region
+ - description: reference to the MSS IPC area
+
+ clocks:
+items:
+ - description: cpu clock
+ - description: pll 0 out 0 rate
+ - description: pll 0 out 1 rate
+ - description: pll 0 out 2 rate
+ - description: pll 0 out 3 rate
+ - description: pll 1 out 0 rate
+ - description: pll 1 out 1 rate
+ - description: pll 1 out 2 rate
+ - description: pll 1 out 3 rate
+ - description: pll 2 out 0 rate
+ - description: pll 2 out 1 rate
+ - description: pll 2 out 2 rate
+ - description: pll 2 out 3 rate
+
+ clock-names:
+items:
+ - const: cpu_clock
+ - const: pll_0_out_0
+ - const: pll_0_out_1
+ - const: pll_0_out_2
+ - const: pll_0_out_3
+ - const: pll_1_out_0
+ - const: pll_1_out_1
+ - const: pll_1_out_2
+ - const: pll_1_out_3
+ - const: pll_2_out_0
+ - const: pll_2_out_1
+ - const: pll_2_out_2
+ - const: pll_2_out_3
+
+ interrupts:
+items:
+ - description: number of NCE sub-system WDT timeout IRQ
+ - description: number of MSS sub-system WDT timeout IRQ
+
+ interrupt-names:
+items:
+ - const: nce_wdt
+ - const: mss_wdt
+
+ intel,keembay-vpu-ipc-imr:
+$ref: "/schemas/types.yaml#/definitions/uint32"
+description:
+ Isolated Memory Region (IMR) number that the runtime service must use to
+ protect the VPU memory region before authentication.
+
+ intel,keembay-vpu-ipc-id:
+$ref: "/schemas/types.yaml#/definitions/uint32"
+description: The VPU ID to be passed to the VPU firmware.
+
+additionalProperties: False
+
+examples:
+ - |
+#include
+vpu-ipc@3f00209c {
+compatible = "intel,keembay-vpu-ipc";
+reg = <0x3f00209c 0x10>,
+ <0x3f003008 0x4>,
+ <0x2082009c 0x10>,
+ <0x20821008 0x4>;
+reg-names = "nce_wdt",
+"nce_tim_cfg",
+"mss_wdt",
+"mss_tim_cfg";
+memory-region = <_reserved>,
+<_x509_reserved>,
+<_ipc_reserved>;
+clocks = <_clk 0>,
+ <_clk 0>,
+ <_clk 1>,
+ <_clk 2>,
+ <_clk 3>,
+ <_clk 4>,
+ <_clk 5>,
+ <_clk 6>,
+ <_clk 7>,
+ <_clk 8>,
+ <_clk 9>,
+ <_clk 10>,
+ <_clk 11>;
+clock-names = "cpu_clock",
+ "pll_0_out_0", "pll_0_out_1",
+ "pll_0_out_2", "pll_0_out_3",
+ "pll_1_out_0", "pll_1_out_1",
+ "pll_1_out_2", "pll_1_out_3",
+ "pll_2_out_0", "pll_2_out_1",
+ "pll_2_out_2", "pll_2_out_3";
+interrupts = ,
+
[PATCH v5 09/34] misc: xlink-pcie: lh: Add PCIe EPF driver for Local Host
From: Srikanth Thokala
Add PCIe EPF driver for local host (lh) to configure BAR's and other
HW resources. Underlying PCIe HW controller is a Synopsys DWC PCIe core.
Cc: Derek Kiernan
Cc: Dragan Cvetic
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
MAINTAINERS | 6 +
drivers/misc/Kconfig| 1 +
drivers/misc/Makefile | 1 +
drivers/misc/xlink-pcie/Kconfig | 9 +
drivers/misc/xlink-pcie/Makefile| 1 +
drivers/misc/xlink-pcie/local_host/Makefile | 2 +
drivers/misc/xlink-pcie/local_host/epf.c| 373
drivers/misc/xlink-pcie/local_host/epf.h| 37 ++
drivers/misc/xlink-pcie/local_host/xpcie.h | 38 ++
9 files changed, 468 insertions(+)
create mode 100644 drivers/misc/xlink-pcie/Kconfig
create mode 100644 drivers/misc/xlink-pcie/Makefile
create mode 100644 drivers/misc/xlink-pcie/local_host/Makefile
create mode 100644 drivers/misc/xlink-pcie/local_host/epf.c
create mode 100644 drivers/misc/xlink-pcie/local_host/epf.h
create mode 100644 drivers/misc/xlink-pcie/local_host/xpcie.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 797a1ff7057c..1154d3e6b359 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1961,6 +1961,12 @@ F:
Documentation/devicetree/bindings/arm/intel,keembay.yaml
F: arch/arm64/boot/dts/intel/keembay-evm.dts
F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
+ARM KEEM BAY XLINK PCIE SUPPORT
+M: Srikanth Thokala
+M: Mark Gross
+S: Supported
+F: drivers/misc/xlink-pcie/
+
ARM/INTEL RESEARCH IMOTE/STARGATE 2 MACHINE SUPPORT
M: Jonathan Cameron
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fafa8b0d8099..dfb98e444c6e 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -481,4 +481,5 @@ source "drivers/misc/ocxl/Kconfig"
source "drivers/misc/cardreader/Kconfig"
source "drivers/misc/habanalabs/Kconfig"
source "drivers/misc/uacce/Kconfig"
+source "drivers/misc/xlink-pcie/Kconfig"
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d23231e73330..d17621fc43d5 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_HABANA_AI) += habanalabs/
obj-$(CONFIG_UACCE)+= uacce/
obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
obj-$(CONFIG_HISI_HIKEY_USB) += hisi_hikey_usb.o
+obj-y += xlink-pcie/
diff --git a/drivers/misc/xlink-pcie/Kconfig b/drivers/misc/xlink-pcie/Kconfig
new file mode 100644
index ..46aa401d79b7
--- /dev/null
+++ b/drivers/misc/xlink-pcie/Kconfig
@@ -0,0 +1,9 @@
+config XLINK_PCIE_LH_DRIVER
+ tristate "XLink PCIe Local Host driver"
+ depends on PCI_ENDPOINT && ARCH_KEEMBAY
+ help
+ This option enables XLink PCIe Local Host driver.
+
+ Choose M here to compile this driver as a module, name is mxlk_ep.
+ This driver is used for XLink communication over PCIe and is to be
+ loaded on the Intel Keem Bay platform.
diff --git a/drivers/misc/xlink-pcie/Makefile b/drivers/misc/xlink-pcie/Makefile
new file mode 100644
index ..d693d382e9c6
--- /dev/null
+++ b/drivers/misc/xlink-pcie/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += local_host/
diff --git a/drivers/misc/xlink-pcie/local_host/Makefile
b/drivers/misc/xlink-pcie/local_host/Makefile
new file mode 100644
index ..514d3f0c91bc
--- /dev/null
+++ b/drivers/misc/xlink-pcie/local_host/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_XLINK_PCIE_LH_DRIVER) += mxlk_ep.o
+mxlk_ep-objs := epf.o
diff --git a/drivers/misc/xlink-pcie/local_host/epf.c
b/drivers/misc/xlink-pcie/local_host/epf.c
new file mode 100644
index ..0234756e89ae
--- /dev/null
+++ b/drivers/misc/xlink-pcie/local_host/epf.c
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay XLink PCIe Driver
+ *
+ * Copyright (C) 2021 Intel Corporation
+ */
+
+#include
+#include
+
+#include "epf.h"
+
+#define BAR2_MIN_SIZE SZ_16K
+#define BAR4_MIN_SIZE SZ_16K
+
+#define PCIE_REGS_PCIE_INTR_ENABLE 0x18
+#define PCIE_REGS_PCIE_INTR_FLAGS 0x1C
+#define LBC_CII_EVENT_FLAG BIT(18)
+#define PCIE_REGS_PCIE_ERR_INTR_FLAGS 0x24
+#define LINK_REQ_RST_FLG BIT(15)
+
+static struct pci_epf_header xpcie_header = {
+ .vendorid = PCI_VENDOR_ID_INTEL,
+ .deviceid = PCI_DEVICE_ID_INTEL_KEEMBAY,
+ .baseclass_code = PCI_BASE_CLASS_MULTIMEDIA,
+ .subclass_code = 0x0,
+ .subsys_vendor_id = 0x0,
+ .subsys_id = 0x0,
+};
+
+static const struct pci_epf_device_id xpcie_epf_ids[] = {
+ {
+ .name = "mxlk_pcie_epf",
+ },
+ {},
+};
+
+static irqreturn_t intel_xpcie_err_interrupt(int
[PATCH v5 17/34] xlink-ipc: Add xlink ipc device tree bindings
From: Seamus Kelly
Add device tree bindings for the xLink IPC driver which enables xLink to
control and communicate with the VPU IP present on the Intel Keem Bay
SoC.
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Seamus Kelly
---
.../misc/intel,keembay-xlink-ipc.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/intel,keembay-xlink-ipc.yaml
diff --git
a/Documentation/devicetree/bindings/misc/intel,keembay-xlink-ipc.yaml
b/Documentation/devicetree/bindings/misc/intel,keembay-xlink-ipc.yaml
new file mode 100644
index ..70a3061d024d
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/intel,keembay-xlink-ipc.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) Intel Corporation. All rights reserved.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/misc/intel,keembay-xlink-ipc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Intel Keem Bay xlink IPC
+
+maintainers:
+ - Kelly Seamus
+
+description: |
+ The Keem Bay xlink IPC driver enables the communication/control sub-system
+ for internal IPC communications within the Intel Keem Bay SoC.
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - const: intel,keembay-xlink-ipc
+
+ memory-region:
+items:
+ - description: reference to the CSS xlink IPC reserved memory region.
+ - description: reference to the MSS xlink IPC reserved memory region.
+
+ intel,keembay-vpu-ipc-id:
+$ref: "/schemas/types.yaml#/definitions/uint32"
+description: The numeric ID identifying the VPU within the xLink stack.
+
+ intel,keembay-vpu-ipc-name:
+$ref: "/schemas/types.yaml#/definitions/string"
+description: User-friendly name for the VPU within the xLink stack.
+
+ intel,keembay-vpu-ipc:
+$ref: "/schemas/types.yaml#/definitions/phandle"
+description: reference to the corresponding intel,keembay-vpu-ipc node.
+
+additionalProperties: False
+
+examples:
+ - |
+xlink-ipc {
+compatible = "intel,keembay-xlink-ipc";
+memory-region = <_xlink_reserved>,
+<_xlink_reserved>;
+intel,keembay-vpu-ipc-id = <0x0>;
+intel,keembay-vpu-ipc-name = "vpu-slice-0";
+intel,keembay-vpu-ipc = <>;
+};
--
2.17.1
Re: [RFC v1 13/26] x86/tdx: Handle MWAIT, MONITOR and WBINVD
On Fri, Feb 5, 2021 at 3:39 PM Kuppuswamy Sathyanarayanan wrote: > > In non-root TDX guest mode, MWAIT, MONITOR and WBINVD instructions > are not supported. So handle #VE due to these instructions as no ops. > MWAIT turning into NOP is no good. How about suppressing X86_FEATURE_MWAIT instead? --Andy
[PATCH v5 24/34] dt-bindings: misc: Add Keem Bay vpumgr
From: "Li, Tingqian"
Add DT binding schema for VPU on Keem Bay ASoC platform
Cc: Rob Herring
Cc: devicet...@vger.kernel.org
Signed-off-by: Li Tingqian
Signed-off-by: Mark Gross
---
.../bindings/misc/intel,keembay-vpu-mgr.yaml | 48 +++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/intel,keembay-vpu-mgr.yaml
diff --git a/Documentation/devicetree/bindings/misc/intel,keembay-vpu-mgr.yaml
b/Documentation/devicetree/bindings/misc/intel,keembay-vpu-mgr.yaml
new file mode 100644
index ..a44f492277ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/intel,keembay-vpu-mgr.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+# Copyright (C) 2020 Intel
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/intel,keembay-vpu-mgr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel VPU manager bindings
+
+maintainers:
+ - Li, Tingqian
+ - Zhou, Luwei
+
+description: |
+ The Intel VPU manager provides shared memory and process
+ depedent context management for Intel VPU hardware IP.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - intel,keembay-vpu-mgr
+ - intel,keembay-vpusmm
+
+ memory-region:
+description:
+ phandle to a node describing reserved memory (System RAM memory)
+ used by VPU (see bindings/reserved-memory/reserved-memory.txt)
+maxItems: 1
+
+ intel,keembay-vpu-ipc-id:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+ the index of the VPU slice to be managed. Default is 0.
+
+required:
+ - compatible
+ - memory-region
+
+additionalProperties: false
+
+examples:
+ - |
+vpumgr0 {
+compatible = "intel,keembay-vpu-mgr";
+memory-region = <_reserved>;
+intel,keembay-vpu-ipc-id = <0x0>;
+};
--
2.17.1
Re: [PATCH 1/3] dt-bindings: Fix undocumented compatible strings in examples
On Tue, Feb 02, 2021 at 02:55:42PM -0600, Rob Herring wrote: > Running 'dt-validate -m' will flag any compatible strings missing a schema. > Fix all the errors found in DT binding examples. Most of these are just > typos. > > Cc: Stephen Boyd > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Linus Walleij > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Daniel Palmer > Cc: Bartosz Golaszewski > Cc: Avi Fishman > Cc: Tomer Maimon > Cc: Tali Perry > Cc: Joerg Roedel > Cc: Will Deacon > Cc: Andrew Jeffery > Cc: Joel Stanley > Cc: Wim Van Sebroeck > Cc: Guenter Roeck > Cc: Yoshihiro Shimoda > Cc: Vincent Cheng > Cc: linux-...@vger.kernel.org > Cc: linux-cry...@vger.kernel.org > Cc: linux-g...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: io...@lists.linux-foundation.org > Cc: linux-watch...@vger.kernel.org > Signed-off-by: Rob Herring Acked-by: Wolfram Sang # for I2C signature.asc Description: PGP signature
[PATCH v5 27/34] misc: Tsens ARM host thermal driver.
From: "C, Udhayakumar"
Add tsens ARM host thermal driver for Intel Edge.AI Computer Vision
platforms.
About Intel Edge.AI Computer Vision platforms:
-
The Intel Edge.AI Computer Vision platforms are vision processing systems
targeting machine vision applications for connected devices.
They are based on ARM A53 CPU running Linux and acts as a PCIe
endpoint device.
High-level architecture:
Remote Host IA CPULocal Host ARM CPU
--
| Platform| | Thermal Daemon|
| Management SW| ||
--
| Intel tsens | | intel tsens i2c slave |
| i2c client | | and thermal driver|
--
| XLINK I2C | | XLINK I2C Slave |
| controller | <=> | controller |
smbus--
intel tsens module:
---
The tsens module enables reading of on chip sensors present
in the Intel Edge.AI Computer Vision platforms. In the tsens module
various junction and SoC temperatures are reported using thermal
subsystem and i2c subsystem.
Temperature data reported using thermal subsystem will be used for
various cooling agents such as DVFS, fan control and shutdown the
system in case of critical temperature.
Temperature data reported using i2c subsystem will be used by
platform manageability software running in IA host.
- Local Host driver
* Intended for ARM CPU
* It is based on Thermal and I2C slave Framework
* Driver path:
{tree}/drivers/misc/intel_tsens/intel_tsens_thermal.c
Local host and Remote host drivers communicates using
XLINK I2C SMBUS protocol.
Acked-by: Mark Gross
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/intel_tsens_sensor.rst| 67 ++
MAINTAINERS | 5 +
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/intel_tsens/Kconfig | 15 +
drivers/misc/intel_tsens/Makefile | 7 +
.../misc/intel_tsens/intel_tsens_thermal.c| 651 ++
.../misc/intel_tsens/intel_tsens_thermal.h| 38 +
include/linux/hddl_device.h | 153
10 files changed, 939 insertions(+)
create mode 100644 Documentation/hwmon/intel_tsens_sensor.rst
create mode 100644 drivers/misc/intel_tsens/Kconfig
create mode 100644 drivers/misc/intel_tsens/Makefile
create mode 100644 drivers/misc/intel_tsens/intel_tsens_thermal.c
create mode 100644 drivers/misc/intel_tsens/intel_tsens_thermal.h
create mode 100644 include/linux/hddl_device.h
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index fcb870ce6286..fc29100bef73 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -80,6 +80,7 @@ Hardware Monitoring Kernel Drivers
ir38064
isl68137
it87
+ intel_tsens_sensor.rst
jc42
k10temp
k8temp
diff --git a/Documentation/hwmon/intel_tsens_sensor.rst
b/Documentation/hwmon/intel_tsens_sensor.rst
new file mode 100644
index ..0f53dfca477e
--- /dev/null
+++ b/Documentation/hwmon/intel_tsens_sensor.rst
@@ -0,0 +1,67 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Kernel driver: intel_tsens_thermal
+==
+
+Supported chips:
+ * Intel Edge.AI Computer Vision platforms: Keem Bay
+
+Slave address: The address is assigned by the hddl device management
+ driver.
+
+Authors:
+- Thalaiappan, Rathina
+- Udhayakumar C
+
+Description
+===
+The Intel Edge.AI Computer Vision platforms have memory mapped thermal sensors
+which are accessible locally. The intel_tsens_thermal driver handles these
+thermal sensor and exposes the temperature to
+
+* the external host similar to the standard SMBUS based thermal sensor
+(like LM73) to the host by registering to the I2C subsystem as
+slave interface (Documentation/i2c/slave-interface.rst).
+* the local CPU as a standard thermal device.
+
+In Keem Bay, the four thermal junction temperature points are,
+Media Subsystem (mss), NN subsystem (nce), Compute subsystem (cse) and
+SOC(Maximum of mss, nce and cse).
+
+Similarity: /drivers/thermal/qcom
+
+Example
+===
+Local Thermal Interface:
+
+Temperature reported in Keem Bay on the Linux Thermal sysfs interface.
+
+# cat /sys/class/thermal/thermal_zone*/type
+mss
+css
+nce
+soc
+
+# cat /sys/class/thermal/thermal_zone*/temp
+0
+29210
+28478
+29210
+
+Remote Thermal Interface:
+
+tsens i2c slave driver reports temperature of
[RFC v1 06/26] x86/tdx: Add HLT support for TDX guest
From: "Kirill A. Shutemov"
Per Guest-Host-Communication Interface (GHCI) for Intel Trust
Domain Extensions (Intel TDX) specification, sec 3.8,
TDVMCALL[Instruction.HLT] provides HLT operation. Use it to implement
halt() and safe_halt() paravirtualization calls.
The same TDVMCALL is used to handle #VE exception due to
EXIT_REASON_HLT.
Signed-off-by: Kirill A. Shutemov
Reviewed-by: Andi Kleen
Signed-off-by: Kuppuswamy Sathyanarayanan
---
arch/x86/include/asm/tdx.h | 5
arch/x86/kernel/tdx.c | 61 ++
2 files changed, 60 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
index 90eb61b07d1f..b98de067257b 100644
--- a/arch/x86/include/asm/tdx.h
+++ b/arch/x86/include/asm/tdx.h
@@ -14,9 +14,14 @@
*/
#define TDCALL ".byte 0x66,0x0f,0x01,0xcc"
+#define TDVMCALL 0
#define TDINFO 1
#define TDGETVEINFO3
+/* TDVMCALL R10 Input */
+#define TDVMCALL_STANDARD 0
+#define TDVMCALL_VENDOR1
+
/* Common API to check TDX support in decompression and common kernel code. */
bool is_tdx_guest(void);
diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index ae2d5c847700..25dd33bc2e49 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -51,6 +51,45 @@ static void tdx_get_info(void)
td_info.attributes = rdx;
}
+static __cpuidle void tdx_halt(void)
+{
+ register long r10 asm("r10") = TDVMCALL_STANDARD;
+ register long r11 asm("r11") = EXIT_REASON_HLT;
+ register long rcx asm("rcx");
+ long ret;
+
+ /* Allow to pass R10 and R11 down to the VMM */
+ rcx = BIT(10) | BIT(11);
+
+ asm volatile(TDCALL
+ : "=a"(ret), "=r"(r10), "=r"(r11)
+ : "a"(TDVMCALL), "r"(rcx), "r"(r10), "r"(r11)
+ : );
+
+ /* It should never fail */
+ BUG_ON(ret || r10);
+}
+
+static __cpuidle void tdx_safe_halt(void)
+{
+ register long r10 asm("r10") = TDVMCALL_STANDARD;
+ register long r11 asm("r11") = EXIT_REASON_HLT;
+ register long rcx asm("rcx");
+ long ret;
+
+ /* Allow to pass R10 and R11 down to the VMM */
+ rcx = BIT(10) | BIT(11);
+
+ /* Enable interrupts next to the TDVMCALL to avoid performance
degradation */
+ asm volatile("sti\n\t" TDCALL
+ : "=a"(ret), "=r"(r10), "=r"(r11)
+ : "a"(TDVMCALL), "r"(rcx), "r"(r10), "r"(r11)
+ : );
+
+ /* It should never fail */
+ BUG_ON(ret || r10);
+}
+
void __init tdx_early_init(void)
{
if (!cpuid_has_tdx_guest())
@@ -60,6 +99,9 @@ void __init tdx_early_init(void)
tdx_get_info();
+ pv_ops.irq.safe_halt = tdx_safe_halt;
+ pv_ops.irq.halt = tdx_halt;
+
pr_info("TDX guest is initialized\n");
}
@@ -86,10 +128,17 @@ unsigned long tdx_get_ve_info(struct ve_info *ve)
int tdx_handle_virtualization_exception(struct pt_regs *regs,
struct ve_info *ve)
{
- /*
-* TODO: Add handler support for various #VE exit
-* reasons
-*/
- pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
- return -EFAULT;
+ switch (ve->exit_reason) {
+ case EXIT_REASON_HLT:
+ tdx_halt();
+ break;
+ default:
+ pr_warn("Unexpected #VE: %d\n", ve->exit_reason);
+ return -EFAULT;
+ }
+
+ /* After successful #VE handling, move the IP */
+ regs->ip += ve->instr_len;
+
+ return ret;
}
--
2.25.1
Re: [PATCH v4 3/3] arm64: dts: reset: add microchip sparx5 switch reset driver
On Wed, Jan 20, 2021 at 09:19:21AM +0100, Steen Hegelund wrote:
> This provides reset driver support for the Microchip Sparx5 PCB134 and
> PCB135 reference boards.
This isn't a compatible change. You need an explanation why that's okay
if that's intended.
>
> Signed-off-by: Steen Hegelund
> ---
> arch/arm64/boot/dts/microchip/sparx5.dtsi | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> index 380281f312d8..4edbb9fcdce0 100644
> --- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> @@ -132,9 +132,17 @@ mux: mux-controller {
> };
> };
>
> - reset@611010008 {
> - compatible = "microchip,sparx5-chip-reset";
> - reg = <0x6 0x11010008 0x4>;
> + gcb_ctrl: syscon@61101 {
> + compatible = "microchip,sparx5-gcb-syscon", "syscon";
> + reg = <0x6 0x1101 0x1>;
> + };
> +
> + reset: reset-controller@0 {
> + compatible = "microchip,sparx5-switch-reset";
> + reg = <0x6 0x0 0x0>;
Your register length is 0?
> + #reset-cells = <1>;
> + cpu-syscon = <_ctrl>;
Can't you accomplish the same thing adding these to
"microchip,sparx5-chip-reset"? Or possibly as a child node.
Define nodes based on h/w blocks, not as containers of things you happen
to want for some driver.
> + gcb-syscon = <_ctrl>;
> };
>
> uart0: serial@60010 {
> --
> 2.29.2
>
[PATCH v2] kunit: don't show `1 == 1` in failed assertion messages
Currently, given something (fairly dystopian) like
> KUNIT_EXPECT_EQ(test, 2 + 2, 5)
KUnit will prints a failure message like this.
> Expected 2 + 2 == 5, but
> 2 + 2 == 4
> 5 == 5
With this patch, the output just becomes
> Expected 2 + 2 == 5, but
> 2 + 2 == 4
This patch is slightly hacky, but it's quite common* to compare an
expression to a literal integer value, so this can make KUnit less
chatty in many cases. (This patch also fixes variants like
KUNIT_EXPECT_GT, LE, et al.).
It also allocates an additional string briefly, but given this only
happens on test failures, it doesn't seem too bad a tradeoff.
Also, in most cases it'll realize the lengths are unequal and bail out
before the allocation.
We could save the result of the formatted string to avoid wasting this
extra work, but it felt cleaner to leave it as-is.
Edge case: for something silly and unrealistic like
> KUNIT_EXPECT_EQ(test, 4, 5);
It'll generate this message with a trailing "but"
> Expected 4 == 5, but
>
It didn't feel worth adding a check up-front to see if both sides are
literals to handle this better.
*A quick grep suggests 100+ comparisons to an integer literal as the
right hand side.
Signed-off-by: Daniel Latypov
Tested-by: David Gow
Reviewed-by: Brendan Higgins
---
lib/kunit/assert.c | 39 +--
1 file changed, 33 insertions(+), 6 deletions(-)
diff --git a/lib/kunit/assert.c b/lib/kunit/assert.c
index 33acdaa28a7d..e0ec7d6fed6f 100644
--- a/lib/kunit/assert.c
+++ b/lib/kunit/assert.c
@@ -85,6 +85,29 @@ void kunit_ptr_not_err_assert_format(const struct
kunit_assert *assert,
}
EXPORT_SYMBOL_GPL(kunit_ptr_not_err_assert_format);
+/* Checks if `text` is a literal representing `value`, e.g. "5" and 5 */
+static bool is_literal(struct kunit *test, const char *text, long long value,
+ gfp_t gfp)
+{
+ char *buffer;
+ int len;
+ bool ret;
+
+ len = snprintf(NULL, 0, "%lld", value);
+ if (strlen(text) != len)
+ return false;
+
+ buffer = kunit_kmalloc(test, len+1, gfp);
+ if (!buffer)
+ return false;
+
+ snprintf(buffer, len+1, "%lld", value);
+ ret = strncmp(buffer, text, len) == 0;
+
+ kunit_kfree(test, buffer);
+ return ret;
+}
+
void kunit_binary_assert_format(const struct kunit_assert *assert,
struct string_stream *stream)
{
@@ -97,12 +120,16 @@ void kunit_binary_assert_format(const struct kunit_assert
*assert,
binary_assert->left_text,
binary_assert->operation,
binary_assert->right_text);
- string_stream_add(stream, KUNIT_SUBSUBTEST_INDENT "%s == %lld\n",
- binary_assert->left_text,
- binary_assert->left_value);
- string_stream_add(stream, KUNIT_SUBSUBTEST_INDENT "%s == %lld",
- binary_assert->right_text,
- binary_assert->right_value);
+ if (!is_literal(stream->test, binary_assert->left_text,
+ binary_assert->left_value, stream->gfp))
+ string_stream_add(stream, KUNIT_SUBSUBTEST_INDENT "%s ==
%lld\n",
+ binary_assert->left_text,
+ binary_assert->left_value);
+ if (!is_literal(stream->test, binary_assert->right_text,
+ binary_assert->right_value, stream->gfp))
+ string_stream_add(stream, KUNIT_SUBSUBTEST_INDENT "%s == %lld",
+ binary_assert->right_text,
+ binary_assert->right_value);
kunit_assert_print_msg(assert, stream);
}
EXPORT_SYMBOL_GPL(kunit_binary_assert_format);
base-commit: 1e0d27fce010b0a4a9e595506b6ede75934c31be
--
2.30.0.478.g8a0d178c01-goog
[PATCH v5 26/34] dt-bindings: misc: intel_tsens: Add tsens thermal bindings documentation
From: "C, Udhayakumar"
Add device tree bindings for local host thermal sensors
Intel Edge.AI Computer Vision platforms.
The tsens module enables reading of on chip sensors present
in the Intel Bay series SoC. In the tsens module various junction
temperature and SoC temperature are reported using thermal subsystem
and i2c subsystem.
Temperature data reported using thermal subsystem will be used for
various cooling agents such as DVFS, fan control and shutdown the
system in case of critical temperature.
Temperature data reported using i2c subsytem will be used by
platform manageability software running in remote host.
Acked-by: mark gross
Signed-off-by: C Udhayakumar
Signed-off-by: Mark Gross
---
.../bindings/misc/intel,intel-tsens.yaml | 122 ++
1 file changed, 122 insertions(+)
create mode 100644
Documentation/devicetree/bindings/misc/intel,intel-tsens.yaml
diff --git a/Documentation/devicetree/bindings/misc/intel,intel-tsens.yaml
b/Documentation/devicetree/bindings/misc/intel,intel-tsens.yaml
new file mode 100644
index ..f307dc6d2012
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/intel,intel-tsens.yaml
@@ -0,0 +1,122 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/misc/intel,intel-tsens.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Intel Temperature sensors in Bay series
+
+maintainers:
+ - Udhayakumar C
+
+description: |
+ The tsens driver enables reading of onchip sensors present
+ in the Intel Bay SoC.
+ Each subnode of the tsens represents sensors available
+ on the soc.
+
+select: false
+
+properties:
+ compatible:
+items:
+ - const: intel,intel-tsens
+
+ plat_name:
+contains:
+ enum:
+- intel,keembay_thermal
+
+ reg:
+minItems: 1
+maxItems: 2
+
+ clocks:
+items:
+ - description: thermal sensor clock
+
+ clk-rate:
+items:
+ - description: thermal sensor clock freq
+
+ sensor_name:
+type: object
+description:
+ Details to configure sensor trip points and its types.
+
+properties:
+ passive_delay:
+minItems: 1
+maxItems: 1
+description: number of milliseconds to wait between polls when
+ performing passive cooling
+
+ polling_delay:
+minItems: 1
+maxItems: 1
+description: number of milliseconds to wait between polls when checking
+ whether trip points have been crossed (0 for interrupt
+ driven systems)
+
+ trip_temp:
+minItems: 1
+description: temperature for trip points
+
+ trip_type:
+minItems: 1
+description: trip type list for trip points
+
+required:
+ - passive_delay
+ - polling_delay
+ - trip_temp
+ - trip_type
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+tsens {
+#address-cells = <2>;
+#size-cells = <2>;
+
+tsens@2026 {
+compatible = "intel,intel-tsens";
+status = "disabled";
+plat_name = "intel,keembay_thermal";
+reg = <0x0 0x2026 0x0 0x100>;
+clocks = <_clk>;
+clk-rate = <125>;
+
+mss {
+passive_delay = <1000>;
+polling_delay = <2000>;
+trip_temp = <4 8 100>;
+trip_type = "passive", "passive", "critical";
+};
+
+css {
+passive_delay = <1000>;
+polling_delay = <2000>;
+trip_temp = <4 8 100>;
+trip_type = "passive", "passive", "critical";
+};
+
+nce {
+passive_delay = <1000>;
+polling_delay = <2000>;
+trip_temp = <4 8 100>;
+trip_type = "passive", "passive", "critical";
+};
+
+soc {
+passive_delay = <1000>;
+polling_delay = <2000>;
+trip_temp = <4 8 100>;
+trip_type = "passive", "passive", "critical";
+};
+};
+};
--
2.17.1
[PATCH v4 2/3] kunit: tool: add support for filtering suites by glob
This allows running different subsets of tests, e.g.
$ ./tools/testing/kunit/kunit.py build
$ ./tools/testing/kunit/kunit.py exec 'list*'
$ ./tools/testing/kunit/kunit.py exec 'kunit*'
This passes the "kunit_filter.glob" commandline option to the UML
kernel, which currently only supports filtering by suite name.
Signed-off-by: Daniel Latypov
Reviewed-by: Brendan Higgins
---
tools/testing/kunit/kunit.py | 21 -
tools/testing/kunit/kunit_kernel.py| 4 +++-
tools/testing/kunit/kunit_tool_test.py | 15 +--
3 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index 02871a363f76..d5144fcb03ac 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -28,12 +28,12 @@ KunitBuildRequest = namedtuple('KunitBuildRequest',
['jobs', 'build_dir', 'alltests',
'make_options'])
KunitExecRequest = namedtuple('KunitExecRequest',
- ['timeout', 'build_dir', 'alltests'])
+ ['timeout', 'build_dir', 'alltests',
'filter_glob'])
KunitParseRequest = namedtuple('KunitParseRequest',
['raw_output', 'input_data', 'build_dir',
'json'])
KunitRequest = namedtuple('KunitRequest', ['raw_output','timeout', 'jobs',
- 'build_dir', 'alltests', 'json',
- 'make_options'])
+ 'build_dir', 'alltests',
'filter_glob',
+ 'json', 'make_options'])
KernelDirectoryPath = sys.argv[0].split('tools/testing/kunit/')[0]
@@ -93,6 +93,7 @@ def exec_tests(linux: kunit_kernel.LinuxSourceTree,
test_start = time.time()
result = linux.run_kernel(
timeout=None if request.alltests else request.timeout,
+filter_glob=request.filter_glob,
build_dir=request.build_dir)
test_end = time.time()
@@ -149,7 +150,7 @@ def run_tests(linux: kunit_kernel.LinuxSourceTree,
return build_result
exec_request = KunitExecRequest(request.timeout, request.build_dir,
- request.alltests)
+ request.alltests, request.filter_glob)
exec_result = exec_tests(linux, exec_request)
if exec_result.status != KunitStatus.SUCCESS:
return exec_result
@@ -200,6 +201,14 @@ def add_exec_opts(parser) -> None:
type=int,
default=300,
metavar='timeout')
+ parser.add_argument('filter_glob',
+ help='maximum number of seconds to allow for all
tests '
+ 'to run. This does not include time taken to build
the '
+ 'tests.',
+ type=str,
+ nargs='?',
+ default='',
+ metavar='filter_glob')
def add_parse_opts(parser) -> None:
parser.add_argument('--raw_output', help='don\'t format output from
kernel',
@@ -266,6 +275,7 @@ def main(argv, linux=None):
cli_args.jobs,
cli_args.build_dir,
cli_args.alltests,
+ cli_args.filter_glob,
cli_args.json,
cli_args.make_options)
result = run_tests(linux, request)
@@ -307,7 +317,8 @@ def main(argv, linux=None):
exec_request = KunitExecRequest(cli_args.timeout,
cli_args.build_dir,
- cli_args.alltests)
+ cli_args.alltests,
+ cli_args.filter_glob)
exec_result = exec_tests(linux, exec_request)
parse_request = KunitParseRequest(cli_args.raw_output,
exec_result.result,
diff --git a/tools/testing/kunit/kunit_kernel.py
b/tools/testing/kunit/kunit_kernel.py
index 0b461663e7d9..71a5f5c1750b 100644
--- a/tools/testing/kunit/kunit_kernel.py
+++ b/tools/testing/kunit/kunit_kernel.py
@@ -203,8 +203,10 @@ class LinuxSourceTree(object):
return False
return self.validate_config(build_dir)
- def run_kernel(self, args=[], build_dir='', timeout=None) ->
Iterator[str]:
+ def run_kernel(self, args=[], build_dir='', filter_glob='',
timeout=None) -> Iterator[str]:
args.extend(['mem=1G', 'console=tty'])
+ if filter_glob:
+
[PATCH] ia64: Fix style guide breakage
Some statements do not have proper spacing between their C
keywords (commonly if and for) throughout files in the ia64 tree.
This patch corrects this to follow the kernel code style guide.
Signed-off-by: Amy Parker
---
arch/ia64/hp/common/sba_iommu.c | 6 +++---
arch/ia64/kernel/machine_kexec.c | 2 +-
arch/ia64/kernel/palinfo.c | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 9148ddbf02e5..84a410f3e68f 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -139,7 +139,7 @@
#ifdef ASSERT_PDIR_SANITY
#define ASSERT(expr) \
-if(!(expr)) { \
+if (!(expr)) { \
printk( "\n" __FILE__ ":%d: Assertion " #expr "
failed!\n",__LINE__); \
panic(#expr); \
}
@@ -510,7 +510,7 @@ sba_search_bitmap(struct ioc *ioc, struct device *dev,
if (likely(bits_wanted == 1)) {
unsigned int bitshiftcnt;
- for(; res_ptr < res_end ; res_ptr++) {
+ for (; res_ptr < res_end ; res_ptr++) {
if (likely(*res_ptr != ~0UL)) {
bitshiftcnt = ffz(*res_ptr);
*res_ptr |= (1UL << bitshiftcnt);
@@ -538,7 +538,7 @@ sba_search_bitmap(struct ioc *ioc, struct device *dev,
mask = base_mask << bitshiftcnt;
DBG_RES("%s() o %ld %p", __func__, o, res_ptr);
- for(; res_ptr < res_end ; res_ptr++)
+ for (; res_ptr < res_end ; res_ptr++)
{
DBG_RES("%p %lx %lx\n", res_ptr, mask, *res_ptr);
ASSERT(0 != mask);
diff --git a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
index efc9b568401c..8de286450578 100644
--- a/arch/ia64/kernel/machine_kexec.c
+++ b/arch/ia64/kernel/machine_kexec.c
@@ -137,7 +137,7 @@ void machine_kexec(struct kimage *image)
{
BUG_ON(!image);
unw_init_running(ia64_machine_kexec, image);
- for(;;);
+ for (;;);
}
void arch_crash_save_vmcoreinfo(void)
diff --git a/arch/ia64/kernel/palinfo.c b/arch/ia64/kernel/palinfo.c
index 78fa6579c9ea..ec2ff3e510c0 100644
--- a/arch/ia64/kernel/palinfo.c
+++ b/arch/ia64/kernel/palinfo.c
@@ -155,7 +155,7 @@ static void bitregister_process(struct seq_file *m, u64
*reg_info, int max)
value >>= i = begin = ffs(value) - 1;
- for(; i < max; i++ ) {
+ for (; i < max; i++ ) {
if (i != 0 && (i%64) == 0) value = *++reg_info;
@@ -523,7 +523,7 @@ static void feature_set_info(struct seq_file *m, u64 avail,
u64 status, u64 cont
int i;
vf = v = proc_features[set];
- for(i=0; i < 64; i++, avail >>=1, status >>=1, control >>=1) {
+ for (i=0; i < 64; i++, avail >>=1, status >>=1, control >>=1) {
if (!(control)) /* No remaining bits set */
break;
@@ -613,7 +613,7 @@ static int bus_info(struct seq_file *m)
status = st.pal_bus_features_val;
control = ct.pal_bus_features_val;
- for(i=0; i < 64; i++, v++, avail >>=1, status >>=1, control >>=1) {
+ for (i=0; i < 64; i++, v++, avail >>=1, status >>=1, control >>=1) {
if ( ! *v )
continue;
seq_printf(m, "%-48s : %s%s %s\n", *v,
--
2.29.2
