Re: [PATCH v6] gpio: pca953x: Add Maxim MAX7313 PWM support

[Miquel Raynal]

Hi Uwe,

Uwe Kleine-König  wrote on Mon, 29 Jun
2020 21:50:44 +0200:

> On Mon, Jun 29, 2020 at 04:08:44PM +0200, Miquel Raynal wrote:
> > Hello Uwe, Thierry,
> > 
> > Miquel Raynal  wrote on Sun,  3 May 2020
> > 12:54:53 +0200:
> >   
> > > The MAX7313 chip is fully compatible with the PCA9535 on its basic
> > > functions but can also manage the intensity on each of its ports with
> > > PWM. Each output is independent and may be tuned with 16 values (4
> > > bits per output). The period is always 32kHz, only the duty-cycle may
> > > be changed. One can use any output as GPIO or PWM.
> > > 
> > > Signed-off-by: Miquel Raynal 
> > > ---  
> > 
> > Can I have a status on this patch please?
> > 
> > If it was forgotten, I would be good to have it queued now, otherwise,
> > may I know the reason?  
> 
> You could reply to my feedback ... If you could say there: "What you
> want isn't possible" I'd count this as a strong indication to not ask to
> implement Andy's suggestion. (Even if this would be possible, I'm not
> sure this is a good idea, but still ...)

Sorry for the misunderstanding, but I already replied twice to Andy
about this. Once in October, again in November, then I gave a shot to
the idea of splitting the drivers (GPIO vs. PWM) in January. So I
thought you were sharing your thoughts out loud but was not expecting
any specific feedback on it.

So, no, even if the idea might make sense, it is not doable in a
reasonable amount of time. I am not saying it is impossible, but someone
has to think about it deeper and propose a core structure to handle it
in a generic and clean way so that other drivers sharing the same
properties can rely on it. I am not qualified enough to do it the proper
way in a reasonable time frame.

Thanks,
Miquèl

Re: [PATCH v4 12/23] ASoC: simple-card: Support DPCM DAI link with multiple Codecs

[Kuninori Morimoto]

Hi Sameer

Thank you for explaining detail at off-list mail.

Your issue happen on (C) case, and you are tring to solve it.
It is easy to understand if it was indicated at log area.
I have imagined other system from "multiple CPU/Codec support".

(A)(B)
FE <-> BE

(C)(D)
BE <-> BE

> > I'm not sure, this is just my guess.
> > I'm happy if we can support it more easily :)
> Right now I am trying re-use simple-card driver as much as possible
> and still make it work for flexible sound cards. I will be happy to
> discuss and improve the patch wherever necessary. Please help me
> understand which part you think looks to be hacky.

> > But, if it was difficult to keep compatibility on simple-card,
> > we/you need to have new one.
> Patch 17/23 and 18/23 introduce new compatible
> 'simple-cc-audio-card'. Idea was to use component chaining which
> allows connection of FE<->BE and multiple BE<->BE components along the
> DAPM path (patch 16/23). Do you think it would be fine?

This seems very complex system for current simple-card.
"concept" of simple-card is simple (but "code" is not so simple...)
Because of it, it doesn't assume flexible connection.

Maybe your patch works for you, but might breaks other systems.
Or, makes code or DT settings more complex/ununderstandable.
Not sure, but my guess.

Using cpu@0 node for BE is the 1st confusable point for me.
Using fe/be instead of cpu/codec is easy to understand.

Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [RFC PATCH v1 1/2] Bluetooth: queue ACL packets if no handle is found

[Marcel Holtmann]

Hi Archie,

>>> There is a possibility that an ACL packet is received before we
>>> receive the HCI connect event for the corresponding handle. If this
>>> happens, we discard the ACL packet.
>>> 
>>> Rather than just ignoring them, this patch provides a queue for
>>> incoming ACL packet without a handle. The queue is processed when
>>> receiving a HCI connection event. If 2 seconds elapsed without
>>> receiving the HCI connection event, assume something bad happened
>>> and discard the queued packet.
>>> 
>>> Signed-off-by: Archie Pusaka 
>>> Reviewed-by: Abhishek Pandit-Subedi 
>> 
>> so two things up front. I want to hide this behind a 
>> HCI_QUIRK_OUT_OF_ORDER_ACL that a transport driver has to set first. Frankly 
>> if this kind of out-of-order happens on UART or SDIO transports, then 
>> something is obviously going wrong. I have no plan to fix up after a fully 
>> serialized transport.
>> 
>> Secondly, if a transport sets HCI_QUIRK_OUT_OF_ORDER_ACL, then I want this 
>> off by default. You can enable it via an experimental setting. The reason 
>> here is that we have to make it really hard and fail as often as possible so 
>> that hardware manufactures and spec writers realize that something is 
>> fundamentally broken here.
>> 
>> I have no problem in running the code and complaining loudly in case the 
>> quirk has been set. Just injecting the packets can only happen if bluetoothd 
>> explicitly enabled it.
> 
> Got it.
> 
>> 
>> 
>>> 
>>> ---
>>> 
>>> include/net/bluetooth/hci_core.h |  8 +++
>>> net/bluetooth/hci_core.c | 84 +---
>>> net/bluetooth/hci_event.c|  2 +
>>> 3 files changed, 88 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/include/net/bluetooth/hci_core.h 
>>> b/include/net/bluetooth/hci_core.h
>>> index 836dc997ff94..b69ecdd0d15a 100644
>>> --- a/include/net/bluetooth/hci_core.h
>>> +++ b/include/net/bluetooth/hci_core.h
>>> @@ -270,6 +270,9 @@ struct adv_monitor {
>>> /* Default authenticated payload timeout 30s */
>>> #define DEFAULT_AUTH_PAYLOAD_TIMEOUT   0x0bb8
>>> 
>>> +/* Time to keep ACL packets without a corresponding handle queued (2s) */
>>> +#define PENDING_ACL_TIMEOUT  msecs_to_jiffies(2000)
>>> +
>> 
>> Do we have some btmon traces with timestamps. Isn’t a second enough? 
>> Actually 2 seconds is an awful long time.
> 
> When this happens in the test lab, the HCI connect event is about
> 0.002 second behind the first ACL packet. We can change this if
> required.
> 
>> 
>>> struct amp_assoc {
>>>  __u16   len;
>>>  __u16   offset;
>>> @@ -538,6 +541,9 @@ struct hci_dev {
>>>  struct delayed_work rpa_expired;
>>>  bdaddr_trpa;
>>> 
>>> + struct delayed_work remove_pending_acl;
>>> + struct sk_buff_head pending_acl_q;
>>> +
>> 
>> can we name this ooo_q and move it to the other queues in this struct. 
>> Unless we want to add a Kconfig option around it, we don’t need to keep it 
>> here.
> 
> Ack.
> 
>> 
>>> #if IS_ENABLED(CONFIG_BT_LEDS)
>>>  struct led_trigger  *power_led;
>>> #endif
>>> @@ -1773,6 +1779,8 @@ void hci_le_start_enc(struct hci_conn *conn, __le16 
>>> ediv, __le64 rand,
>>> void hci_copy_identity_address(struct hci_dev *hdev, bdaddr_t *bdaddr,
>>> u8 *bdaddr_type);
>>> 
>>> +void hci_process_pending_acl(struct hci_dev *hdev, struct hci_conn *conn);
>>> +
>>> #define SCO_AIRMODE_MASK   0x0003
>>> #define SCO_AIRMODE_CVSD   0x
>>> #define SCO_AIRMODE_TRANSP 0x0003
>>> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
>>> index 7959b851cc63..30780242c267 100644
>>> --- a/net/bluetooth/hci_core.c
>>> +++ b/net/bluetooth/hci_core.c
>>> @@ -1786,6 +1786,7 @@ int hci_dev_do_close(struct hci_dev *hdev)
>>>  skb_queue_purge(&hdev->rx_q);
>>>  skb_queue_purge(&hdev->cmd_q);
>>>  skb_queue_purge(&hdev->raw_q);
>>> + skb_queue_purge(&hdev->pending_acl_q);
>>> 
>>>  /* Drop last sent command */
>>>  if (hdev->sent_cmd) {
>>> @@ -3518,6 +3519,78 @@ static int hci_suspend_notifier(struct 
>>> notifier_block *nb, unsigned long action,
>>>  return NOTIFY_STOP;
>>> }
>>> 
>>> +static void hci_add_pending_acl(struct hci_dev *hdev, struct sk_buff *skb)
>>> +{
>>> + skb_queue_tail(&hdev->pending_acl_q, skb);
>>> +
>>> + queue_delayed_work(hdev->workqueue, &hdev->remove_pending_acl,
>>> +PENDING_ACL_TIMEOUT);
>>> +}
>>> +
>>> +void hci_process_pending_acl(struct hci_dev *hdev, struct hci_conn *conn)
>>> +{
>>> + struct sk_buff *skb, *tmp;
>>> + struct hci_acl_hdr *hdr;
>>> + u16 handle, flags;
>>> + bool reset_timer = false;
>>> +
>>> + skb_queue_walk_safe(&hdev->pending_acl_q, skb, tmp) {
>>> + hdr = (struct hci_acl_hdr *)skb->data;
>>> + handle = __le16_to_cpu(hdr->handle);
>>> + flags  = hci_flags(handle);
>>> + handle = hci_handle(handle);
>>> +
>>> + if (handle !

[PATCH v2] net: qrtr: free flow in __qrtr_node_release

[Carl Huang]

The flow is allocated in qrtr_tx_wait, but not freed when qrtr node
is released. (*slot) becomes NULL after radix_tree_iter_delete is
called in __qrtr_node_release. The fix is to save (*slot) to a
vairable and then free it.

This memory leak is catched when kmemleak is enabled in kernel,
the report looks like below:

unreferenced object 0xa0de69e08420 (size 32):
  comm "kworker/u16:3", pid 176, jiffies 4294918275 (age 82858.876s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 28 84 e0 69 de a0 ff ff  (..i
28 84 e0 69 de a0 ff ff 03 00 00 00 00 00 00 00  (..i
  backtrace:
[] qrtr_node_enqueue+0x38e/0x400 [qrtr]
[<9cea437f>] qrtr_sendmsg+0x1e0/0x2a0 [qrtr]
[<8bddbba4>] sock_sendmsg+0x5b/0x60
[<03beb43a>] qmi_send_message.isra.3+0xbe/0x110 [qmi_helpers]
[<9c9ae7de>] qmi_send_request+0x1c/0x20 [qmi_helpers]

Signed-off-by: Carl Huang 
---
 net/qrtr/qrtr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
index 2d8d613..0598813 100644
--- a/net/qrtr/qrtr.c
+++ b/net/qrtr/qrtr.c
@@ -166,6 +166,7 @@ static void __qrtr_node_release(struct kref *kref)
 {
struct qrtr_node *node = container_of(kref, struct qrtr_node, ref);
struct radix_tree_iter iter;
+   struct qrtr_tx_flow *flow;
unsigned long flags;
void __rcu **slot;
 
@@ -181,8 +182,9 @@ static void __qrtr_node_release(struct kref *kref)
 
/* Free tx flow counters */
radix_tree_for_each_slot(slot, &node->qrtr_tx_flow, &iter, 0) {
+   flow = *slot;
radix_tree_iter_delete(&node->qrtr_tx_flow, &iter, slot);
-   kfree(*slot);
+   kfree(flow);
}
kfree(node);
 }
-- 
2.7.4

Re: [PATCH v3 00/15] HWPOISON: soft offline rework

[堀口 直也]

On Mon, Jun 29, 2020 at 12:29:25PM +0200, Oscar Salvador wrote:
> On Wed, 2020-06-24 at 15:01 +, nao.horigu...@gmail.com wrote:
> > I rebased soft-offline rework patchset [1][2] onto the latest
> > mmotm.  The
> > rebasing required some non-trivial changes to adjust, but mainly that
> > was
> > straightforward.  I confirmed that the reported problem doesn't
> > reproduce on
> > compaction after soft offline.  For more precise description of the
> > problem
> > and the motivation of this patchset, please see [2].
> 
> Hi Naoya,
> 
> Thanks for dusting this off.
> To be honest, I got stuck with the hard offline mode so this delayed
> the resubmission, along other problems.
> 
> > I think that the following two patches in v2 are better to be done
> > with
> > separate work of hard-offline rework, so it's not included in this
> > series.
> > 
> >   - mm,hwpoison: Take pages off the buddy when hard-offlining
> >   - mm/hwpoison-inject: Rip off duplicated checks
> > 
> > These two are not directly related to the reported problem, so they
> > seems
> > not urgent.  And the first one breaks num_poisoned_pages counting in
> > some
> > testcases, and The second patch needs more consideration about
> > commented point.
> 
> I fully agree.
> 
> > Any comment/suggestion/help would be appreciated.
> 
> My "new" version included a patch to make sure we give a chance to
> pages that possibly are in a pcplist.
> Current behavior is that if someone tries to soft-offline such a page,
> we return an error because page count is 0 but page is not in the buddy
> system.
> 
> Since this patchset already landed in the mm tree, I could send it as a
> standalone patch on top if you agree with it.
> 
> My patch looked something like:
> 
> From: Oscar Salvador 
> Date: Mon, 29 Jun 2020 12:25:11 +0200
> Subject: [PATCH] mm,hwpoison: Drain pcplists before bailing out for
> non-buddy
>  zero-refcount page
> 
> A page with 0-refcount and !PageBuddy could perfectly be a pcppage.
> Currently, we bail out with an error if we encounter such a page,
> meaning that we do not give a chance to handle pcppages.
> 
> Fix this by draining pcplists whenever we find this kind of page
> and retry the check again.
> It might be that pcplists have been spilled into the buddy allocator
> and so we can handle it.
>
> Signed-off-by: Oscar Salvador 

I'm fine with this patch, so this will be with the next version with
some minor change like moving function comment block together.

Actually I feel we could refactor get_hwpoison_page() with get_any_page()
to handle this kind of pcplist related issues in one place. But this could
be more important in hard-offline reworking, and we don't have to do it
in this series.

Thanks,
Naoya Horiguchi

Re: [PATCH v1] Bluetooth: Fix kernel oops triggered by hci_adv_monitors_clear()

[Marcel Holtmann]

Hi Miao-chen,

> This fixes the kernel oops by removing unnecessary background scan
> update from hci_adv_monitors_clear() which shouldn't invoke any work
> queue.
> 
> The following test was performed.
> - Run "rmmod btusb" and verify that no kernel oops is triggered.
> 
> Signed-off-by: Miao-chen Chou 
> Reviewed-by: Abhishek Pandit-Subedi 
> Reviewed-by: Alain Michaud 
> ---
> 
> net/bluetooth/hci_core.c | 2 --
> 1 file changed, 2 deletions(-)
> 
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 5577cf9e2c7cd..77615161c7d72 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -3005,8 +3005,6 @@ void hci_adv_monitors_clear(struct hci_dev *hdev)
>   hci_free_adv_monitor(monitor);
> 
>   idr_destroy(&hdev->adv_monitors_idr);
> -
> - hci_update_background_scan(hdev);
> }

I am happy to apply this as well, but I also applied another patch re-arranging 
the workqueue destroy handling. Can you check which prefer or if we should 
include both patches.

Regards

Marcel

Re: [RFC PATCH v1 2/2] Bluetooth: queue L2CAP conn req if encryption is needed

[Marcel Holtmann]

Hi Luiz,

> It is possible to receive an L2CAP conn req for an encrypted
> connection, before actually receiving the HCI change encryption
> event. If this happened, the received L2CAP packet will be ignored.
>>> 
>>> How is this possible? Or you are referring to a race between the ACL
>>> and Event endpoint where the Encryption Change is actually pending to
>>> be processed but we end up processing the ACL data first.
>> 
>> you get the ACL packet with the L2CAP_Connect_Req in it and then the HCI 
>> Encryption Change event. However over the air they go in the different 
>> order. It is specific to the USB transport and nothing is going to fix this. 
>> The USB transport design is borked. You can only do bandaids.
>> 
> This patch queues the L2CAP packet and process them after the
> expected HCI event is received. If after 2 seconds we still don't
> receive it, then we assume something bad happened and discard the
> queued packets.
 
 as with the other patch, this should be behind the same quirk and 
 experimental setting for exactly the same reasons.
 
> 
> Signed-off-by: Archie Pusaka 
> Reviewed-by: Abhishek Pandit-Subedi 
> 
> ---
> 
> include/net/bluetooth/bluetooth.h |  6 +++
> include/net/bluetooth/l2cap.h |  6 +++
> net/bluetooth/hci_event.c |  3 ++
> net/bluetooth/l2cap_core.c| 87 +++
> 4 files changed, 91 insertions(+), 11 deletions(-)
> 
> diff --git a/include/net/bluetooth/bluetooth.h 
> b/include/net/bluetooth/bluetooth.h
> index 7ee8041af803..e64278401084 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -335,7 +335,11 @@ struct l2cap_ctrl {
> u16 reqseq;
> u16 txseq;
> u8  retries;
> + u8  rsp_code;
> + u8  amp_id;
> + __u8ident;
> __le16  psm;
> + __le16  scid;
> bdaddr_t bdaddr;
> struct l2cap_chan *chan;
> };
 
 I would not bother trying to make this work with CREATE_CHAN_REQ. That is 
 if you want to setup a L2CAP channel that can be moved between BR/EDR and 
 AMP controllers and in that case you have to read the L2CAP information 
 and features first. Meaning there will have been unencrypted ACL packets. 
 This problem only exists if the remote side doesn’t request any version 
 information first.
 
> @@ -374,6 +378,8 @@ struct bt_skb_cb {
> struct hci_ctrl hci;
> };
> };
> +static_assert(sizeof(struct bt_skb_cb) <= sizeof(((struct sk_buff 
> *)0)->cb));
> +
> #define bt_cb(skb) ((struct bt_skb_cb *)((skb)->cb))
> 
> #define hci_skb_pkt_type(skb) bt_cb((skb))->pkt_type
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index 8f1e6a7a2df8..f8f6dec96f12 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -58,6 +58,7 @@
> #define L2CAP_MOVE_ERTX_TIMEOUT   msecs_to_jiffies(6)
> #define L2CAP_WAIT_ACK_POLL_PERIODmsecs_to_jiffies(200)
> #define L2CAP_WAIT_ACK_TIMEOUTmsecs_to_jiffies(1)
> +#define L2CAP_PEND_ENC_CONN_TIMEOUT  msecs_to_jiffies(2000)
> 
> #define L2CAP_A2MP_DEFAULT_MTU670
> 
> @@ -700,6 +701,9 @@ struct l2cap_conn {
> struct mutexchan_lock;
> struct kref ref;
> struct list_headusers;
> +
> + struct delayed_work remove_pending_encrypt_conn;
> + struct sk_buff_head pending_conn_q;
> };
> 
> struct l2cap_user {
> @@ -1001,4 +1005,6 @@ void l2cap_conn_put(struct l2cap_conn *conn);
> int l2cap_register_user(struct l2cap_conn *conn, struct l2cap_user *user);
> void l2cap_unregister_user(struct l2cap_conn *conn, struct l2cap_user 
> *user);
> 
> +void l2cap_process_pending_encrypt_conn(struct hci_conn *hcon);
> +
> #endif /* __L2CAP_H */
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 108c6c102a6a..8cefc51a5ca4 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -3136,6 +3136,9 @@ static void hci_encrypt_change_evt(struct hci_dev 
> *hdev, struct sk_buff *skb)
> 
> unlock:
> hci_dev_unlock(hdev);
> +
> + if (conn && !ev->status && ev->encrypt)
> + l2cap_process_pending_encrypt_conn(conn);
> }
> 
> static void hci_change_link_key_complete_evt(struct hci_dev *hdev,
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 35d2bc569a2d..fc6fe2c80c46 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -62,6 +62,10 @@ static void l2cap_send_disconn_req(struct l2cap_chan 
> *chan, int err);

[PATCH v3.1 7/7] kconfig: qconf: navigate menus on hyperlinks

[Mauro Carvalho Chehab]

Instead of just changing the helper window to show a
dependency, also navigate to it at the config and menu
widgets.

Signed-off-by: Mauro Carvalho Chehab 


---

I ended re-sending the same version as on patch series 2. Please
consider this patch instead.

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 6a327b69ff5f..fd721c6c4c94 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1233,7 +1233,6 @@ void ConfigInfoView::clicked(const QUrl &url)
char *data = new char[count + 1];
struct symbol **result;
struct menu *m = NULL;
-   char type;
 
if (count < 1) {
qInfo() << "Clicked link is empty";
@@ -1243,7 +1242,6 @@ void ConfigInfoView::clicked(const QUrl &url)
 
memcpy(data, str.constData(), count);
data[count] = '\0';
-   type = data[0];
 
/* Seek for exact match */
data[0] = '^';
@@ -1256,15 +1254,8 @@ void ConfigInfoView::clicked(const QUrl &url)
}
 
sym = *result;
-   if (type == 's') {
-   symbolInfo();
-   emit showDebugChanged(true);
-   free(result);
-   delete data;
-   return;
-   }
 
-   /* URL is a menu */
+   /* Seek for the menu which holds the symbol */
for (struct property *prop = sym->prop; prop; prop = prop->next) {
if (prop->type != P_PROMPT && prop->type != P_MENU)
continue;
@@ -1273,16 +1264,13 @@ void ConfigInfoView::clicked(const QUrl &url)
}
 
if (!m) {
-   qInfo() << "Clicked menu is invalid:" << data;
-   free(result);
-   delete data;
-   return;
+   /* Symbol is not visible as a menu */
+   symbolInfo();
+   emit showDebugChanged(true);
+   } else {
+   emit menuSelected(m);
}
 
-   _menu = m;
-   menuInfo();
-
-   emit showDebugChanged(true);
free(result);
delete data;
 }
@@ -1731,6 +1719,7 @@ void ConfigMainWindow::setMenuLink(struct menu *menu)
list->setSelected(item, true);
list->scrollToItem(item);
list->setFocus();
+   helpText->setInfo(menu);
}
}
 }

Re: [RFC PATCH v1 1/2] Bluetooth: queue ACL packets if no handle is found

[Archie Pusaka]

Hi Marcel,

On Mon, 29 Jun 2020 at 14:40, Marcel Holtmann  wrote:
>
> Hi Archie,
>
> > There is a possibility that an ACL packet is received before we
> > receive the HCI connect event for the corresponding handle. If this
> > happens, we discard the ACL packet.
> >
> > Rather than just ignoring them, this patch provides a queue for
> > incoming ACL packet without a handle. The queue is processed when
> > receiving a HCI connection event. If 2 seconds elapsed without
> > receiving the HCI connection event, assume something bad happened
> > and discard the queued packet.
> >
> > Signed-off-by: Archie Pusaka 
> > Reviewed-by: Abhishek Pandit-Subedi 
>
> so two things up front. I want to hide this behind a 
> HCI_QUIRK_OUT_OF_ORDER_ACL that a transport driver has to set first. Frankly 
> if this kind of out-of-order happens on UART or SDIO transports, then 
> something is obviously going wrong. I have no plan to fix up after a fully 
> serialized transport.
>
> Secondly, if a transport sets HCI_QUIRK_OUT_OF_ORDER_ACL, then I want this 
> off by default. You can enable it via an experimental setting. The reason 
> here is that we have to make it really hard and fail as often as possible so 
> that hardware manufactures and spec writers realize that something is 
> fundamentally broken here.
>
> I have no problem in running the code and complaining loudly in case the 
> quirk has been set. Just injecting the packets can only happen if bluetoothd 
> explicitly enabled it.

Got it.

>
>
> >
> > ---
> >
> > include/net/bluetooth/hci_core.h |  8 +++
> > net/bluetooth/hci_core.c | 84 +---
> > net/bluetooth/hci_event.c|  2 +
> > 3 files changed, 88 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/net/bluetooth/hci_core.h 
> > b/include/net/bluetooth/hci_core.h
> > index 836dc997ff94..b69ecdd0d15a 100644
> > --- a/include/net/bluetooth/hci_core.h
> > +++ b/include/net/bluetooth/hci_core.h
> > @@ -270,6 +270,9 @@ struct adv_monitor {
> > /* Default authenticated payload timeout 30s */
> > #define DEFAULT_AUTH_PAYLOAD_TIMEOUT   0x0bb8
> >
> > +/* Time to keep ACL packets without a corresponding handle queued (2s) */
> > +#define PENDING_ACL_TIMEOUT  msecs_to_jiffies(2000)
> > +
>
> Do we have some btmon traces with timestamps. Isn’t a second enough? Actually 
> 2 seconds is an awful long time.

When this happens in the test lab, the HCI connect event is about
0.002 second behind the first ACL packet. We can change this if
required.

>
> > struct amp_assoc {
> >   __u16   len;
> >   __u16   offset;
> > @@ -538,6 +541,9 @@ struct hci_dev {
> >   struct delayed_work rpa_expired;
> >   bdaddr_trpa;
> >
> > + struct delayed_work remove_pending_acl;
> > + struct sk_buff_head pending_acl_q;
> > +
>
> can we name this ooo_q and move it to the other queues in this struct. Unless 
> we want to add a Kconfig option around it, we don’t need to keep it here.

Ack.

>
> > #if IS_ENABLED(CONFIG_BT_LEDS)
> >   struct led_trigger  *power_led;
> > #endif
> > @@ -1773,6 +1779,8 @@ void hci_le_start_enc(struct hci_conn *conn, __le16 
> > ediv, __le64 rand,
> > void hci_copy_identity_address(struct hci_dev *hdev, bdaddr_t *bdaddr,
> >  u8 *bdaddr_type);
> >
> > +void hci_process_pending_acl(struct hci_dev *hdev, struct hci_conn *conn);
> > +
> > #define SCO_AIRMODE_MASK   0x0003
> > #define SCO_AIRMODE_CVSD   0x
> > #define SCO_AIRMODE_TRANSP 0x0003
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index 7959b851cc63..30780242c267 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -1786,6 +1786,7 @@ int hci_dev_do_close(struct hci_dev *hdev)
> >   skb_queue_purge(&hdev->rx_q);
> >   skb_queue_purge(&hdev->cmd_q);
> >   skb_queue_purge(&hdev->raw_q);
> > + skb_queue_purge(&hdev->pending_acl_q);
> >
> >   /* Drop last sent command */
> >   if (hdev->sent_cmd) {
> > @@ -3518,6 +3519,78 @@ static int hci_suspend_notifier(struct 
> > notifier_block *nb, unsigned long action,
> >   return NOTIFY_STOP;
> > }
> >
> > +static void hci_add_pending_acl(struct hci_dev *hdev, struct sk_buff *skb)
> > +{
> > + skb_queue_tail(&hdev->pending_acl_q, skb);
> > +
> > + queue_delayed_work(hdev->workqueue, &hdev->remove_pending_acl,
> > +PENDING_ACL_TIMEOUT);
> > +}
> > +
> > +void hci_process_pending_acl(struct hci_dev *hdev, struct hci_conn *conn)
> > +{
> > + struct sk_buff *skb, *tmp;
> > + struct hci_acl_hdr *hdr;
> > + u16 handle, flags;
> > + bool reset_timer = false;
> > +
> > + skb_queue_walk_safe(&hdev->pending_acl_q, skb, tmp) {
> > + hdr = (struct hci_acl_hdr *)skb->data;
> > + handle = __le16_to_cpu(hdr->handle);
> > + flags  = hci_flags(handle);
> > + handle = hci_handle(handle);
> > +
> > + 

[PATCH] kconfig: qconf: parse newer types at debug info

[Mauro Carvalho Chehab]

There are 3 types that are not parsed by the debug info logic.
Add support for them.

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kconfig/qconf.cc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index fd721c6c4c94..4a616128a154 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1154,6 +1154,9 @@ QString ConfigInfoView::debug_info(struct symbol *sym)
case P_DEFAULT:
case P_SELECT:
case P_RANGE:
+   case P_COMMENT:
+   case P_IMPLY:
+   case P_SYMBOL:
debug += prop_get_type_name(prop->type);
debug += ": ";
expr_print(prop->expr, expr_print_help, &debug, E_NONE);
-- 
2.26.2

Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone support

[Amit Kucheria]

On Tue, Jun 30, 2020 at 12:07 PM Andy Tang  wrote:
>
>
>
> > -Original Message-
> > From: Amit Kucheria 
> > Sent: 2020年6月30日 13:37
> > To: Andy Tang 
> > Cc: Shawn Guo ; Leo Li ; Rob
> > Herring ; lakml ;
> > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > ; LKML 
> > Subject: Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal
> > zone support
> >
> > Caution: EXT Email
> >
> > On Tue, Jun 30, 2020 at 10:58 AM Andy Tang  wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Amit Kucheria 
> > > > Sent: 2020年6月30日 13:12
> > > > To: Andy Tang 
> > > > Cc: Shawn Guo ; Leo Li ;
> > > > Rob Herring ; lakml
> > > > ;
> > > > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > > > ; LKML 
> > > > Subject: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal
> > > > zone support
> > > >
> > > > Caution: EXT Email
> > > >
> > > > On Tue, Jun 30, 2020 at 8:56 AM  wrote:
> > > > >
> > > > > From: Yuantian Tang 
> > > > >
> > > > > There are 2 thermal zones in ls1088a soc. Add the other thermal
> > > > > zone node to enable it.
> > > > > Also update the values in calibration table to make the
> > > > > temperatures monitored more precise.
> > > > >
> > > > > Signed-off-by: Yuantian Tang 
> > > > > ---
> > > > >  .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 100
> > > > > +++---
> > > > >  1 file changed, 62 insertions(+), 38 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > index 36a799554620..ccbbc23e6c85 100644
> > > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > > @@ -129,19 +129,19 @@
> > > > > };
> > > > >
> > > > > thermal-zones {
> > > > > -   cpu_thermal: cpu-thermal {
> > > > > +   core-cluster {
> > > > > polling-delay-passive = <1000>;
> > > > > polling-delay = <5000>;
> > > > > thermal-sensors = <&tmu 0>;
> > > > >
> > > > > trips {
> > > > > -   cpu_alert: cpu-alert {
> > > > > +   core_cluster_alert:
> > > > core-cluster-alert
> > > > > + {
> > > > > temperature =
> > <85000>;
> > > > > hysteresis = <2000>;
> > > > > type = "passive";
> > > > > };
> > > > >
> > > > > -   cpu_crit: cpu-crit {
> > > > > +   core_cluster_crit:
> > > > > + core-cluster-crit {
> > > > > temperature =
> > <95000>;
> > > > > hysteresis = <2000>;
> > > > > type = "critical"; @@
> > > > -150,7
> > > > > +150,7 @@
> > > > >
> > > > > cooling-maps {
> > > > > map0 {
> > > > > -   trip = <&cpu_alert>;
> > > > > +   trip =
> > > > <&core_cluster_alert>;
> > > > > cooling-device =
> > > > > <&cpu0
> > > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > > > <&cpu1
> > > > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, @@ -163,6 +163,26 @@
> > > > > };
> > > > > };
> > > > > };
> > > > > +
> > > > > +   soc {
> > > > > +   polling-delay-passive = <1000>;
> > > > > +   polling-delay = <5000>;
> > > > > +   thermal-sensors = <&tmu 1>;
> > > > > +
> > > > > +   trips {
> > > > > +   soc-alert {
> > > > > +   temperature =
> > <85000>;
> > > > > +   hysteresis = <2000>;
> > > > > +   type = "passive";
> > > > > +   };
> > > > > +
> > > > > +   soc-crit {
> > > > > +   temperature =
> > <95000>;
> > > > > +   hysteresis = <2000>;
> > > > > +   type = "critical";
> > > > > +   };
> > > > > +   };
> > > > > +   };
> > > >
> > > > You should also add a cooling-maps section for this thermal zone
> > > > given that it has a passive trip type. Otherwise there is no use for a
> > passive trip type.
> > > It is better to have a cooling device. But there is only one cooling
> > > device on this platform wh

RE: [PATCH] ASoC: Intel: bxt-da7219-max98357a: support MAX98390 speaker amp

[Lu, Brent]

> 
> Support MAX98390 speaker amplifier on cometlake platform. Driver now
> detects amplifier type in the probe function and installs corresponding
> controls and DAPM widgets/routes in the late_probe function.
> 
> Signed-off-by: Brent Lu 

This patch is from Chrome-v4.19 branch to support the combination of DA7219
and MAX98390 on a CML Chromebook. It reuses the topology file
sof-cml-da7219-max98357a.tplg


> ---
>  sound/soc/intel/boards/Kconfig|  20 
>  sound/soc/intel/boards/bxt_da7219_max98357a.c | 129
> --
>  sound/soc/intel/common/soc-acpi-intel-cml-match.c |   4 +-
>  3 files changed, 139 insertions(+), 14 deletions(-)
> 
> diff --git a/sound/soc/intel/boards/Kconfig
> b/sound/soc/intel/boards/Kconfig index 3d820e1..b3b863e 100644
> --- a/sound/soc/intel/boards/Kconfig
> +++ b/sound/soc/intel/boards/Kconfig
> @@ -291,9 +291,17 @@ config
> SND_SOC_INTEL_DA7219_MAX98357A_GENERIC
>   select SND_SOC_DMIC
>   select SND_SOC_HDAC_HDMI
> 
> +config SND_SOC_INTEL_DA7219_MAX98390_GENERIC
> + tristate
> + select SND_SOC_DA7219
> + select SND_SOC_MAX98390
> + select SND_SOC_DMIC
> + select SND_SOC_HDAC_HDMI
> +
>  config SND_SOC_INTEL_BXT_DA7219_MAX98357A_COMMON
>   tristate
>   select SND_SOC_INTEL_DA7219_MAX98357A_GENERIC
> + select SND_SOC_INTEL_DA7219_MAX98390_GENERIC
> 
>  if SND_SOC_INTEL_APL
> 
> @@ -309,6 +317,18 @@ config
> SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH
>  Say Y or m if you have such a device. This is a recommended option.
>  If unsure select "N".
> 
> +config SND_SOC_INTEL_BXT_DA7219_MAX98390_MACH
> + tristate "Broxton with DA7219 and MAX98390 in I2S Mode"
> + depends on I2C && ACPI && GPIOLIB
> + depends on MFD_INTEL_LPSS || COMPILE_TEST
> + depends on SND_HDA_CODEC_HDMI
> + select SND_SOC_INTEL_BXT_DA7219_MAX98357A_COMMON
> + help
> +This adds support for ASoC machine driver for Broxton-P platforms
> +with DA7219 + MAX98390 I2S audio codec.
> +Say Y or m if you have such a device. This is a recommended option.
> +If unsure select "N".
> +
>  config SND_SOC_INTEL_BXT_RT298_MACH
>   tristate "Broxton with RT298 I2S mode"
>   depends on I2C && ACPI && GPIOLIB
> diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c
> b/sound/soc/intel/boards/bxt_da7219_max98357a.c
> index 44016c1..12f07e1 100644
> --- a/sound/soc/intel/boards/bxt_da7219_max98357a.c
> +++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c
> @@ -25,9 +25,14 @@
> 
>  #define BXT_DIALOG_CODEC_DAI "da7219-hifi"
>  #define BXT_MAXIM_CODEC_DAI  "HiFi"
> +#define MAX98390_DEV0_NAME   "i2c-MX98390:00"
> +#define MAX98390_DEV1_NAME   "i2c-MX98390:01"
>  #define DUAL_CHANNEL 2
>  #define QUAD_CHANNEL 4
> 
> +#define SPKAMP_MAX98357A 1
> +#define SPKAMP_MAX98390  2
> +
>  static struct snd_soc_jack broxton_headset;  static struct snd_soc_jack
> broxton_hdmi[3];
> 
> @@ -40,6 +45,7 @@ struct bxt_hdmi_pcm {
>  struct bxt_card_private {
>   struct list_head hdmi_pcm_list;
>   bool common_hdmi_codec_drv;
> + int spkamp;
>  };
> 
>  enum {
> @@ -85,13 +91,20 @@ static int platform_clock_control(struct
> snd_soc_dapm_widget *w,  static const struct snd_kcontrol_new
> broxton_controls[] = {
>   SOC_DAPM_PIN_SWITCH("Headphone Jack"),
>   SOC_DAPM_PIN_SWITCH("Headset Mic"),
> +};
> +
> +static const struct snd_kcontrol_new max98357a_controls[] = {
>   SOC_DAPM_PIN_SWITCH("Spk"),
>  };
> 
> +static const struct snd_kcontrol_new max98390_controls[] = {
> + SOC_DAPM_PIN_SWITCH("Left Spk"),
> + SOC_DAPM_PIN_SWITCH("Right Spk"),
> +};
> +
>  static const struct snd_soc_dapm_widget broxton_widgets[] = {
>   SND_SOC_DAPM_HP("Headphone Jack", NULL),
>   SND_SOC_DAPM_MIC("Headset Mic", NULL),
> - SND_SOC_DAPM_SPK("Spk", NULL),
>   SND_SOC_DAPM_MIC("SoC DMIC", NULL),
>   SND_SOC_DAPM_SPK("HDMI1", NULL),
>   SND_SOC_DAPM_SPK("HDMI2", NULL),
> @@ -100,14 +113,20 @@ static const struct snd_soc_dapm_widget
> broxton_widgets[] = {
>   platform_clock_control,
>   SND_SOC_DAPM_POST_PMD|SND_SOC_DAPM_PRE_PMU),
>  };
> 
> +static const struct snd_soc_dapm_widget max98357a_widgets[] = {
> + SND_SOC_DAPM_SPK("Spk", NULL),
> +};
> +
> +static const struct snd_soc_dapm_widget max98390_widgets[] = {
> + SND_SOC_DAPM_SPK("Left Spk", NULL),
> + SND_SOC_DAPM_SPK("Right Spk", NULL),
> +};
> +
>  static const struct snd_soc_dapm_route audio_map[] = {
>   /* HP jack connectors - unknown if we have jack detection */
>   {"Headphone Jack", NULL, "HPL"},
>   {"Headphone Jack", NULL, "HPR"},
> 
> - /* speaker */
> - {"Spk", NULL, "Speaker"},
> -
>   /* other jacks */
>   {"MIC", NULL, "Headset Mic"},
> 
> @@ -134,6 +153,17 @@ static const struct snd_soc_dapm_route audio_map[]
> = {
>   { "Headset Mic", NULL, "Platform Clock" },  };
> 
> +static const struct snd_soc_da

Re: [PATCH v3 4/8] mm/hugetlb: make hugetlb migration callback CMA aware

[Michal Hocko]

On Tue 30-06-20 15:30:04, Joonsoo Kim wrote:
> 2020년 6월 29일 (월) 오후 4:55, Michal Hocko 님이 작성:
[...]
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 57ece74e3aae..c1595b1d36f3 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -1092,10 +1092,14 @@ static struct page 
> > *dequeue_huge_page_nodemask(struct hstate *h, gfp_t gfp_mask,
> >  /* Movability of hugepages depends on migration support. */
> >  static inline gfp_t htlb_alloc_mask(struct hstate *h)
> >  {
> > +   gfp_t gfp;
> > +
> > if (hugepage_movable_supported(h))
> > -   return GFP_HIGHUSER_MOVABLE;
> > +   gfp = GFP_HIGHUSER_MOVABLE;
> > else
> > -   return GFP_HIGHUSER;
> > +   gfp = GFP_HIGHUSER;
> > +
> > +   return current_gfp_context(gfp);
> >  }
> >
> >  static struct page *dequeue_huge_page_vma(struct hstate *h,
> >
> > If we even fix this general issue for other allocations and allow a
> > better CMA exclusion then it would be implemented consistently for
> > everybody.
> 
> Yes, I have reviewed the memalloc_nocma_{} APIs and found the better way
> for CMA exclusion. I will do it after this patch is finished.
> 
> > Does this make more sense to you are we still not on the same page wrt
> > to the actual problem?
> 
> Yes, but we have different opinions about it. As said above, I will make
> a patch for better CMA exclusion after this patchset. It will make
> code consistent.
> I'd really appreciate it if you wait until then.

As I've said I would _prefer_ simplicity over "correctness" if it is only
partial and hard to reason about from the userspace experience but this
is not something I would _insist_ on. If Mike as a maintainer of the
code is ok with that then I will not stand in the way.

But please note that a missing current_gfp_context inside
htlb_alloc_mask is a subtle bug. I do not think it matters right now but
with a growing use of scoped apis this might actually hit some day so I
believe we want to have it in place.

Thanks!

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 4/4] i2c: stm32f7: Add SMBus-specific protocols support

[Wolfram Sang]

Hi Alain,

> > So, as mentioned in the other review, I'd like to evaluate other
> > possibilities for the above:
> > 
> > - One option is to enable it globally in probe(). Then you lose the
> >   possibility to have a device at address 0x08.
> 
> I'd prefer avoid this solution to not lose the address 0x08.

Understandably.

> > - Enable it in probe() only if there is a generic binding "host-notify".
> 
> Do you mean having the adapter walk through childs node and see if at least
> one of them have the host-notify property ? This mean that such solution
> wouldn't work for device relying on platform data rather than DT nodes.

I meant a generic binding for the host-controller. It could be seen as a
HW description if we need HostNotify on that bus or not.

Maybe it becomes more clear with the R-Car I2C controller as an example.
It only supports one slave address. If I want HostNotify there, I can't
use another slave backend. Now, it could be that I need the slave EEPROM
backend, although there is a HostNotify capable device on the bus. So, I
am leaning to have a generic "host-notify" binding for the host.

I consider platform_data legacy. If we use device_property, we should be
safe regarding all current and future HW descriptions, or?

> > - Let the core scan for a device with HOST_NOTIFY when registering an
> >   adapter and then call back into the driver somehow?
> 
> You mean at adapter registration time only ? Not device probing time ?
> At probing time, we could have the core (i2c_device_probe) check for the flag
> HOST_NOTIFY and if setted call a dedicated host-notify reg callback ?

As said above, I am leaning to the generic property. In addition, it
doesn't feel right to me to add/remove the HostNotify feature at runtime
depending on the client devices. Imagine someone changes another slave
backend to address 0x08 and the HostNotify device comes later. Then, it
won't work all of a sudden.

It feels much safer to me to declare HostNotify as a feature of the IP
core which it either has or it has not, configurable at boot-time.

Makes sense?

Kind regards,

   Wolfram



signature.asc
Description: PGP signature

Re: [RFC PATCH 00/10] Netronix embedded controller driver for Kobo and Tolino ebook readers

[Andreas Kemnade]

Hi,

On Sun, 21 Jun 2020 00:39:04 +0200
Jonathan Neuschäfer  wrote:

> Hi,
> 
> This patchset adds basic support for the embedded controller found on
> older ebook reader boards designed by/with the ODM Netronix Inc.[1] and
> sold by Kobo or Tolino, for example the Kobo Aura and the Tolino Shine.
> These drivers are based on the vendor kernel sources, but in order to
> all information in a single place, I documented the register interface
> of the EC on GitHub[4].
> 
> A few things still needs to be ironed out, hence the RFC tag:
>  - The reboot/reset handler in patch 3/10 calls into I2C code, which may
>sleep, but reboot handlers are apparently not allowed to sleep.
>  - I'm not sure I got the YAML DT bindings right. I have also included
>the plain text DT bindings for reference.
> 
> 
got a chance to test it on a Tolino Shine 2 HD.
It uses the RTC from the RC5T619 but backlight seems to go via MSP430
EC.

I got this.

[1.453603] ntxec 0-0043: Netronix embedded controller version f110 detected.
[   10.723638] ntxec-rtc 21a.i2c:embedded-controller@43:rtc: registered as 
rtc0
[   10.775276] ntxec-pwm: probe of 21a.i2c:embedded-controller@43:pwm 
failed with error -5
[   10.850597] ntxec-rtc 21a.i2c:embedded-controller@43:rtc: hctosys: 
unable to read the hardware clock

version number matchess with what the vendor kernel reports. Maybe we
should document which version is running on which devices?

&i2c1 {
pinctrl-names = "default","sleep";
pinctrl-0 = <&pinctrl_i2c1>;
pinctrl-1 = <&pinctrl_i2c1_sleep>;
status = "okay";

embedded-controller@43 {
//  pinctrl-names = "default";
//  pinctrl-0 = <&pinctrl_ec>;
compatible = "netronix,ntxec";
reg = <0x43>;
interrupts-extended = <&gpio5 11 IRQ_TYPE_EDGE_FALLING>;
interrupt-controller;
#interrupt-cells = <1>;

ec_pwm: pwm {
compatible = "netronix,ntxec-pwm";
#pwm-cells = <2>;
};

rtc {
compatible = "netronix,ntxec-rtc";
};
};
};

Regards,
Andreas

RE: [RFC PATCH v3 0/5] scsi: ufs: Add Host Performance Booster Support

[Avri Altman]

Hi,
 
> 
> Hi Bean,
> > On Mon, 2020-06-29 at 15:15 +0900, Daejun Park wrote:
> > > > Seems you intentionally ignored to give you comments on my
> > > > suggestion.
> > > > let me provide the reason.
> > >
> > > Sorry! I replied to your comment (
> > > https://protect2.fireeye.com/url?k=be575021-e3854728-be56db6e-
> 0cc47a31cdf8-
> 6c7d0e1e42762b92&q=1&u=https%3A%2F%2Flkml.org%2Flkml%2F2020%2F6%
> 2F15%2F1492),
> > > but you didn't reply on that. I thought you agreed because you didn't
> > > send
> > > any more comments.
> > >
> > >
> > > > Before submitting your next version patch, please check your L2P
> > > > mapping HPB reqeust submission logical algorithem. I have did
> > >
> > > We are also reviewing the code that you submitted before.
> > > It seems to be a performance improvement as it sends a map request
> > > directly.
> > >
> > > > performance comparison testing on 4KB, there are about 13%
> > > > performance
> > > > drop. Also the hit count is lower. I don't know if this is related
> > > > to
> > >
> > > It is interesting that there is actually a performance improvement.
> > > Could you share the test environment, please? However, I think
> > > stability is
> > > important to HPB driver. We have tested our method with the real
> > > products and
> > > the HPB 1.0 driver is based on that.
> >
> > I just run fio benchmark tool with --rw=randread, --bs=4kb, --
> > size=8G/10G/64G/100G. and see what performance diff with the direct
> > submission approach.
> 
> Thanks!
> 
> > > After this patch, your approach can be done as an incremental patch?
> > > I would
> > > like to test the patch that you submitted and verify it.
> > >
> > > > your current work queue scheduling, since you didn't add the timer
> > > > for
> > > > each HPB request.
> > >
> >
> > Taking into consideration of the HPB 2.0, can we submit the HPB write
> > request to the SCSI layer? if not, it will be a direct submission way.
> > why not directly use direct way? or maybe you have a more advisable
> > approach to work around this. would you please share with us.
> > appreciate.
> 
> I am considering a direct submission way for the next version.
> We will implement the write buffer command of HPB 2.0, after patching HPB
> 1.0.
> 
> As for the direct submission of HPB releated command including HPB write
> buffer, I think we'd better discuss the right approach in depth before
> moving on to the next step.
I vote to stay with the current implementation because:
1) Bean is probably right about 2.0, but it's out of scope for now - 
there is a long way to go before we'll need to worry about it
2) For now, we should focus on the functional flows. 
Performance issues, should such issues indeed exists, can be dealt with  
later.  And,
3) The current code base is running in production for more than 3 years now.
 I am not so eager to dump a robust, well debugged code unless it 
absolutely necessary.

Thanks,
Avri

[PATCH] ASoC: Intel: bxt-da7219-max98357a: support MAX98390 speaker amp

[Brent Lu]

Support MAX98390 speaker amplifier on cometlake platform. Driver now
detects amplifier type in the probe function and installs corresponding
controls and DAPM widgets/routes in the late_probe function.

Signed-off-by: Brent Lu 
---
 sound/soc/intel/boards/Kconfig|  20 
 sound/soc/intel/boards/bxt_da7219_max98357a.c | 129 --
 sound/soc/intel/common/soc-acpi-intel-cml-match.c |   4 +-
 3 files changed, 139 insertions(+), 14 deletions(-)

diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig
index 3d820e1..b3b863e 100644
--- a/sound/soc/intel/boards/Kconfig
+++ b/sound/soc/intel/boards/Kconfig
@@ -291,9 +291,17 @@ config SND_SOC_INTEL_DA7219_MAX98357A_GENERIC
select SND_SOC_DMIC
select SND_SOC_HDAC_HDMI
 
+config SND_SOC_INTEL_DA7219_MAX98390_GENERIC
+   tristate
+   select SND_SOC_DA7219
+   select SND_SOC_MAX98390
+   select SND_SOC_DMIC
+   select SND_SOC_HDAC_HDMI
+
 config SND_SOC_INTEL_BXT_DA7219_MAX98357A_COMMON
tristate
select SND_SOC_INTEL_DA7219_MAX98357A_GENERIC
+   select SND_SOC_INTEL_DA7219_MAX98390_GENERIC
 
 if SND_SOC_INTEL_APL
 
@@ -309,6 +317,18 @@ config SND_SOC_INTEL_BXT_DA7219_MAX98357A_MACH
   Say Y or m if you have such a device. This is a recommended option.
   If unsure select "N".
 
+config SND_SOC_INTEL_BXT_DA7219_MAX98390_MACH
+   tristate "Broxton with DA7219 and MAX98390 in I2S Mode"
+   depends on I2C && ACPI && GPIOLIB
+   depends on MFD_INTEL_LPSS || COMPILE_TEST
+   depends on SND_HDA_CODEC_HDMI
+   select SND_SOC_INTEL_BXT_DA7219_MAX98357A_COMMON
+   help
+  This adds support for ASoC machine driver for Broxton-P platforms
+  with DA7219 + MAX98390 I2S audio codec.
+  Say Y or m if you have such a device. This is a recommended option.
+  If unsure select "N".
+
 config SND_SOC_INTEL_BXT_RT298_MACH
tristate "Broxton with RT298 I2S mode"
depends on I2C && ACPI && GPIOLIB
diff --git a/sound/soc/intel/boards/bxt_da7219_max98357a.c 
b/sound/soc/intel/boards/bxt_da7219_max98357a.c
index 44016c1..12f07e1 100644
--- a/sound/soc/intel/boards/bxt_da7219_max98357a.c
+++ b/sound/soc/intel/boards/bxt_da7219_max98357a.c
@@ -25,9 +25,14 @@
 
 #define BXT_DIALOG_CODEC_DAI   "da7219-hifi"
 #define BXT_MAXIM_CODEC_DAI"HiFi"
+#define MAX98390_DEV0_NAME "i2c-MX98390:00"
+#define MAX98390_DEV1_NAME "i2c-MX98390:01"
 #define DUAL_CHANNEL   2
 #define QUAD_CHANNEL   4
 
+#define SPKAMP_MAX98357A   1
+#define SPKAMP_MAX983902
+
 static struct snd_soc_jack broxton_headset;
 static struct snd_soc_jack broxton_hdmi[3];
 
@@ -40,6 +45,7 @@ struct bxt_hdmi_pcm {
 struct bxt_card_private {
struct list_head hdmi_pcm_list;
bool common_hdmi_codec_drv;
+   int spkamp;
 };
 
 enum {
@@ -85,13 +91,20 @@ static int platform_clock_control(struct 
snd_soc_dapm_widget *w,
 static const struct snd_kcontrol_new broxton_controls[] = {
SOC_DAPM_PIN_SWITCH("Headphone Jack"),
SOC_DAPM_PIN_SWITCH("Headset Mic"),
+};
+
+static const struct snd_kcontrol_new max98357a_controls[] = {
SOC_DAPM_PIN_SWITCH("Spk"),
 };
 
+static const struct snd_kcontrol_new max98390_controls[] = {
+   SOC_DAPM_PIN_SWITCH("Left Spk"),
+   SOC_DAPM_PIN_SWITCH("Right Spk"),
+};
+
 static const struct snd_soc_dapm_widget broxton_widgets[] = {
SND_SOC_DAPM_HP("Headphone Jack", NULL),
SND_SOC_DAPM_MIC("Headset Mic", NULL),
-   SND_SOC_DAPM_SPK("Spk", NULL),
SND_SOC_DAPM_MIC("SoC DMIC", NULL),
SND_SOC_DAPM_SPK("HDMI1", NULL),
SND_SOC_DAPM_SPK("HDMI2", NULL),
@@ -100,14 +113,20 @@ static const struct snd_soc_dapm_widget broxton_widgets[] 
= {
platform_clock_control, 
SND_SOC_DAPM_POST_PMD|SND_SOC_DAPM_PRE_PMU),
 };
 
+static const struct snd_soc_dapm_widget max98357a_widgets[] = {
+   SND_SOC_DAPM_SPK("Spk", NULL),
+};
+
+static const struct snd_soc_dapm_widget max98390_widgets[] = {
+   SND_SOC_DAPM_SPK("Left Spk", NULL),
+   SND_SOC_DAPM_SPK("Right Spk", NULL),
+};
+
 static const struct snd_soc_dapm_route audio_map[] = {
/* HP jack connectors - unknown if we have jack detection */
{"Headphone Jack", NULL, "HPL"},
{"Headphone Jack", NULL, "HPR"},
 
-   /* speaker */
-   {"Spk", NULL, "Speaker"},
-
/* other jacks */
{"MIC", NULL, "Headset Mic"},
 
@@ -134,6 +153,17 @@ static const struct snd_soc_dapm_route audio_map[] = {
{ "Headset Mic", NULL, "Platform Clock" },
 };
 
+static const struct snd_soc_dapm_route max98357a_routes[] = {
+   /* speaker */
+   {"Spk", NULL, "Speaker"},
+};
+
+static const struct snd_soc_dapm_route max98390_routes[] = {
+   /* Speaker */
+   {"Left Spk", NULL, "Left BE_OUT"},
+   {"Right Spk", NULL, "Right BE_OUT"},
+};
+
 static const struct snd_soc_dapm_route broxton_m

RE: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone support

[Andy Tang]

> -Original Message-
> From: Amit Kucheria 
> Sent: 2020年6月30日 13:37
> To: Andy Tang 
> Cc: Shawn Guo ; Leo Li ; Rob
> Herring ; lakml ;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> ; LKML 
> Subject: Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal
> zone support
> 
> Caution: EXT Email
> 
> On Tue, Jun 30, 2020 at 10:58 AM Andy Tang  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Amit Kucheria 
> > > Sent: 2020年6月30日 13:12
> > > To: Andy Tang 
> > > Cc: Shawn Guo ; Leo Li ;
> > > Rob Herring ; lakml
> > > ;
> > > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > > ; LKML 
> > > Subject: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal
> > > zone support
> > >
> > > Caution: EXT Email
> > >
> > > On Tue, Jun 30, 2020 at 8:56 AM  wrote:
> > > >
> > > > From: Yuantian Tang 
> > > >
> > > > There are 2 thermal zones in ls1088a soc. Add the other thermal
> > > > zone node to enable it.
> > > > Also update the values in calibration table to make the
> > > > temperatures monitored more precise.
> > > >
> > > > Signed-off-by: Yuantian Tang 
> > > > ---
> > > >  .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 100
> > > > +++---
> > > >  1 file changed, 62 insertions(+), 38 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > index 36a799554620..ccbbc23e6c85 100644
> > > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > > @@ -129,19 +129,19 @@
> > > > };
> > > >
> > > > thermal-zones {
> > > > -   cpu_thermal: cpu-thermal {
> > > > +   core-cluster {
> > > > polling-delay-passive = <1000>;
> > > > polling-delay = <5000>;
> > > > thermal-sensors = <&tmu 0>;
> > > >
> > > > trips {
> > > > -   cpu_alert: cpu-alert {
> > > > +   core_cluster_alert:
> > > core-cluster-alert
> > > > + {
> > > > temperature =
> <85000>;
> > > > hysteresis = <2000>;
> > > > type = "passive";
> > > > };
> > > >
> > > > -   cpu_crit: cpu-crit {
> > > > +   core_cluster_crit:
> > > > + core-cluster-crit {
> > > > temperature =
> <95000>;
> > > > hysteresis = <2000>;
> > > > type = "critical"; @@
> > > -150,7
> > > > +150,7 @@
> > > >
> > > > cooling-maps {
> > > > map0 {
> > > > -   trip = <&cpu_alert>;
> > > > +   trip =
> > > <&core_cluster_alert>;
> > > > cooling-device =
> > > > <&cpu0
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > > <&cpu1
> > > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, @@ -163,6 +163,26 @@
> > > > };
> > > > };
> > > > };
> > > > +
> > > > +   soc {
> > > > +   polling-delay-passive = <1000>;
> > > > +   polling-delay = <5000>;
> > > > +   thermal-sensors = <&tmu 1>;
> > > > +
> > > > +   trips {
> > > > +   soc-alert {
> > > > +   temperature =
> <85000>;
> > > > +   hysteresis = <2000>;
> > > > +   type = "passive";
> > > > +   };
> > > > +
> > > > +   soc-crit {
> > > > +   temperature =
> <95000>;
> > > > +   hysteresis = <2000>;
> > > > +   type = "critical";
> > > > +   };
> > > > +   };
> > > > +   };
> > >
> > > You should also add a cooling-maps section for this thermal zone
> > > given that it has a passive trip type. Otherwise there is no use for a
> passive trip type.
> > It is better to have a cooling device. But there is only one cooling
> > device on this platform which is used by core-cluster. So there is no extra
> cooling device for it.
> > This zone can take action when critical temp is reached. So it is still 
> > useful.
> > What do you suggest?
> 
> If the action taken by the core-cluster cooling-maps is the only one that can
> be taken, I suggest getti

[PATCH net] hinic: fix passing non negative value to ERR_PTR

[Luo bin]

get_dev_cap and set_resources_state functions may return a positive
value because of hardware failure, and the positive return value
can not be passed to ERR_PTR directly.

Fixes: 7dd29ee12865 ("net-next/hinic: add sriov feature support")
Signed-off-by: Luo bin 
---
 drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c 
b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
index 0245da02efbb..b735bc537508 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
@@ -814,6 +814,8 @@ struct hinic_hwdev *hinic_init_hwdev(struct pci_dev *pdev)
 err_init_msix:
 err_pfhwdev_alloc:
hinic_free_hwif(hwif);
+   if (err > 0)
+   err = -EIO;
return ERR_PTR(err);
 }
 
-- 
2.17.1

Re: [RFC PATCH 0/6] Support raw event and DT for perf on RISC-V

[Zong Li]

On Mon, Jun 29, 2020 at 9:23 PM Anup Patel  wrote:
>
> On Mon, Jun 29, 2020 at 6:23 PM Zong Li  wrote:
> >
> > On Mon, Jun 29, 2020 at 4:28 PM Anup Patel  wrote:
> > >
> > > On Mon, Jun 29, 2020 at 11:22 AM Zong Li  wrote:
> > > >
> > > > On Mon, Jun 29, 2020 at 12:53 PM Anup Patel  wrote:
> > > > >
> > > > > On Mon, Jun 29, 2020 at 8:49 AM Zong Li  wrote:
> > > > > >
> > > > > > This patch set adds raw event support on RISC-V. In addition, we
> > > > > > introduce the DT mechanism to make our perf more generic and common.
> > > > > >
> > > > > > Currently, we set the hardware events by writing the mhpmeventN 
> > > > > > CSRs, it
> > > > > > would raise an illegal instruction exception and trap into m-mode to
> > > > > > emulate event selector CSRs access. It doesn't make sense because we
> > > > > > shouldn't write the m-mode CSRs in s-mode. Ideally, we should set 
> > > > > > event
> > > > > > selector through standard SBI call or the shadow CSRs of s-mode. We 
> > > > > > have
> > > > > > prepared a proposal of a new SBI extension, called "PMU SBI 
> > > > > > extension",
> > > > > > but we also discussing the feasibility of accessing these PMU CSRs 
> > > > > > on
> > > > > > s-mode at the same time, such as delegation mechanism, so I was
> > > > > > wondering if we could use SBI calls first and make the PMU SBI 
> > > > > > extension
> > > > > > as legacy when s-mode access mechanism is accepted by Foundation? or
> > > > > > keep the current situation to see what would happen in the future.
> > > > > >
> > > > > > This patch set also introduces the DT mechanism, we don't want to 
> > > > > > add too
> > > > > > much platform-dependency code in perf like other architectures, so 
> > > > > > we
> > > > > > put the mapping of generic hardware events to DT, then we can easy 
> > > > > > to
> > > > > > transfer generic hardware events to vendor's own hardware events 
> > > > > > without
> > > > > > any platfrom-dependency stuff in our perf.
> > > > >
> > > > > Please re-write this series to have RISC-V PMU driver as a regular
> > > > > platform driver as drivers/perf/riscv_pmu.c.
> > > > >
> > > > > The PMU related sources will have to be removed from arch/riscv.
> > > > >
> > > > > Based on implementation of final drivers/perf/riscv_pmu.c we will
> > > > > come-up with drivers/perf/riscv_sbi_pmu.c driver for SBI perf 
> > > > > counters.
> > > > >
> > > >
> > > > There are some different ways to implement perf, and current
> > > > implementation seems to be consensus when perf was introduced at the
> > > > beginning [0][1]. I don't persist to which one, I could change the
> > > > implementation as you mentioned if it is a new consensus one.
> > > >
> > > > [0] https://github.com/riscv/riscv-linux/pull/124#issuecomment-367563910
> > >
> > > I would not recommend taking the original RISC-V linux fork as reference.
> > >
> > > Rather we should study how things are done on other architectures.
> > >
> > > I really appreciate the attempt to make RISC-V PMU driver depend on DT
> > > but if we are going this route then we should maximize the use of Linux
> > > platform driver framework. In fact, whenever possible we should integrate
> > > RISC-V features as platform drivers under the drivers/ directory.
> > >
> >
> > OK, I would change the implementation to platform driver if there is no
> > other voice.
> >
> > > I thought about SBI PMU counters as well. In future, we can easily
> > > expose SBI PMU counters as RAW events in the same RISC-V PMU
> > > driver. The sbi_probe_extension() can be used in RISC-V PMU driver
> > > to check for SBI PMU counters so no special provisions needed in DT
> > > for SBI PMU counters.
> > >
> >
> > I thought about probing raw events by SBI extension too, I'm interested if 
> > you
> > have more detail about this.
> >
> > It seems to me that it is a little bit hard to return all events
> > through one SBI call,
> > so I thought we could map the generic hardware events and maintain their own
> > raw events by each platform in OpenSBI. But eventually, I thought the
> > DT mechanism
> > is more clear and easy than that. Let me know if you have any ideas about
> > probe function. Thanks.
>
> We can design SBI calls such that no SBI call is required to read
> the perf counter.
>
> The sbi_probe_extension() will only be used to check whether
> underlying SBI implementation supports SBI PMU extension.
>
> As-per my initial thoughts, we can potentially have the following SBI calls:
>
> 1. SBI_PMU_NUM_COUNTERS
> This call will return the number of SBI PMU counters
> 2. SBI_PMU_COUNTER_DESCRIBE
>This call takes two parameters: 1) physical address 2) counter index
> It will write the description of SBI PMU counter at specified
> physical address.
> The details of the SBI PMU counter will include name, type, etc

The main things are that we need to pass the information of raw events
and the information of mapping of generic hardware events. Maybe
this information could be pas

RE: [EXT] Re: [PATCH v4 2/2] ARM: imx6plus: enable internal routing of clk_enet_ref where possible

[Andy Duan]

From: Sven Van Asbroeck  Sent: Monday, June 29, 2020 10:37 
PM
> On Mon, Jun 29, 2020 at 10:26 AM Fabio Estevam 
> wrote:
> >
> > Just tested 5.4.24_2.1.0 on an imx6qp sabresd and DHCP also fails there.
> 
> I think I discovered the problem !
> 
> When I compare the sabresd devicetree on mainline with the actual sabresd
> schematics, the devicetree is incorrect ! Things still work, but only by
> accident.
> 
> The sabresd has an AR8131 PHY, which generates the enet ref clock, not the
> imx6. So on the schematic we see that the clock output of the PHY is wired to
> imx6 ENET_REF_CLK, so it can be used as a clock source. And GPIO_16 is
> disconnected, as it should, because the imx6 is not generating the ref clk.
> 
> But the devicetree is written as if the imx6 is providing the clock ! See
> here:
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Ftr
> ee%2Farch%2Farm%2Fboot%2Fdts%2Fimx6qdl-sabresd.dtsi%3Fh%3Dv5.7.6
> %23n513&data=02%7C01%7Cfugang.duan%40nxp.com%7C16c43e8d9d
> 8e4ff0b9ee08d81c39f7f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C637290382588751887&sdata=hCRNGa9WrQzQ0XYwR%2FQTQ8h
> jY7CDHjhIbXr0L33fr%2Bc%3D&reserved=0
> 
> Also there is no override of the fec PTP clock:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Ftr
> ee%2Farch%2Farm%2Fboot%2Fdts%2Fimx6qdl-sabresd.dtsi%3Fh%3Dv5.7.6
> %23n202&data=02%7C01%7Cfugang.duan%40nxp.com%7C16c43e8d9d
> 8e4ff0b9ee08d81c39f7f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C637290382588751887&sdata=qOfiLs%2FGi01h9hSA787PHfGxTN
> bfYWFXVA3IhUB553Q%3D&reserved=0
> 
> Although Shawn's mainline patch mandates this?
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Fco
> mmit%2F%3Fh%3Dv5.7.6%26id%3D810c0ca879098a993e2ce0a190d24d11c
> 17df748&data=02%7C01%7Cfugang.duan%40nxp.com%7C16c43e8d9d8
> e4ff0b9ee08d81c39f7f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C637290382588751887&sdata=3PiAnDlxO8iqsVR6YQWjCk1xsg8iW
> RK8TSGee4LhkjI%3D&reserved=0
> 
> This will work, but only by accident. So on a plus, when we
> (incorrectly) switch the
> bypass bit on, things stop working.

Fabio, our QA double verify 5.4.24_2.1.0, no matter SD boot or tftp/nfs boot,
both work fine on i.MX6QP sabresd board,  please double check your environment.

Sven, no matter PHY supply 125Mhz clock to pad or not,  GPR5[9] is to select 
RGMII
gtx clock source from:
- 0 Clock from pad
- 1 Clock from PLL

Since i.MX6QP can internally supply clock to MAC, we can set GPR5[9] bit by 
default.

[PATCH] input: misc: remove needless check before usb_free_coherent()

[Chen Ni]

From: Xu Wang 

usb_free_coherent() is safe with NULL addr and this check is
not required.

Signed-off-by: Xu Wang 
---
 drivers/input/misc/cm109.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
index c09b9628ad34..e413801f0491 100644
--- a/drivers/input/misc/cm109.c
+++ b/drivers/input/misc/cm109.c
@@ -663,12 +663,8 @@ static const struct usb_device_id cm109_usb_table[] = {
 static void cm109_usb_cleanup(struct cm109_dev *dev)
 {
kfree(dev->ctl_req);
-   if (dev->ctl_data)
-   usb_free_coherent(dev->udev, USB_PKT_LEN,
- dev->ctl_data, dev->ctl_dma);
-   if (dev->irq_data)
-   usb_free_coherent(dev->udev, USB_PKT_LEN,
- dev->irq_data, dev->irq_dma);
+   usb_free_coherent(dev->udev, USB_PKT_LEN, dev->ctl_data, dev->ctl_dma);
+   usb_free_coherent(dev->udev, USB_PKT_LEN, dev->irq_data, dev->irq_dma);
 
usb_free_urb(dev->urb_irq); /* parameter validation in core/urb */
usb_free_urb(dev->urb_ctl); /* parameter validation in core/urb */
-- 
2.17.1

Re: [PATCH v3 00/15] HWPOISON: soft offline rework

[Oscar Salvador]

On Tue, 2020-06-30 at 01:08 -0400, Qian Cai wrote:
> On Wed, Jun 24, 2020 at 03:01:22PM +, nao.horigu...@gmail.com
> wrote:
> > I rebased soft-offline rework patchset [1][2] onto the latest
> > mmotm.  The
> > rebasing required some non-trivial changes to adjust, but mainly
> > that was
> > straightforward.  I confirmed that the reported problem doesn't
> > reproduce on
> > compaction after soft offline.  For more precise description of the
> > problem
> > and the motivation of this patchset, please see [2].
> > 
> > I think that the following two patches in v2 are better to be done
> > with
> > separate work of hard-offline rework, so it's not included in this
> > series.
> > 
> >   - mm,hwpoison: Take pages off the buddy when hard-offlining
> >   - mm/hwpoison-inject: Rip off duplicated checks
> > 
> > These two are not directly related to the reported problem, so they
> > seems
> > not urgent.  And the first one breaks num_poisoned_pages counting
> > in some
> > testcases, and The second patch needs more consideration about
> > commented point.
> > 
> > Any comment/suggestion/help would be appreciated.
> 
> Even after applied the compling fix,
> 
> https://lore.kernel.org/linux-mm/20200628065409.GA546944@u2004/
> 
> madvise(MADV_SOFT_OFFLINE) will fail with EIO with hugetlb where it
> would succeed without this series. Steps:
> 
> # git clone https://github.com/cailca/linux-mm
> # cd linux-mm; make
> # ./random 1 (Need at least two NUMA memory nodes)
>  start: migrate_huge_offline
> - use NUMA nodes 0,4.
> - mmap and free 8388608 bytes hugepages on node 0
> - mmap and free 8388608 bytes hugepages on node 4
> madvise: Input/output error

I think I know why.
It's been a while since I took a look, but I compared the posted
patchset with my newest patchset I had ready and I saw I made some
changes with regard of hugetlb pages.

I will be taking a look, although it might be better to re-post the
patchset instead of adding a fix on top since the changes are a bit
substantial.

Thanks for reporting.

-- 
Oscar Salvador
SUSE L3

Re: [PATCH 6/6] mm: Add memalloc_nowait

[Michal Hocko]

On Mon 29-06-20 22:28:30, Matthew Wilcox wrote:
[...]
> The documentation is hard to add a new case to, so I rewrote it.  What
> do you think?  (Obviously I'll split this out differently for submission;
> this is just what I have in my tree right now).

I am fine with your changes. Few notes below.

> -It turned out though that above approach has led to
> -abuses when the restricted gfp mask is used "just in case" without a
> -deeper consideration which leads to problems because an excessive use
> -of GFP_NOFS/GFP_NOIO can lead to memory over-reclaim or other memory
> -reclaim issues.

I believe this is an important part because it shows that new people
coming to the existing code shouldn't take it as correct and rather
question it. Also having a clear indication that overuse is causing real
problems that might be not immediately visible to subsystems outside of
MM.

> -FS/IO code then simply calls the appropriate save function before
> -any critical section with respect to the reclaim is started - e.g.
> -lock shared with the reclaim context or when a transaction context
> -nesting would be possible via reclaim.  

[...]

> +These functions should be called at the point where any memory allocation
> +would start to cause problems.  That is, do not simply wrap individual
> +memory allocation calls which currently use ``GFP_NOFS`` with a pair
> +of calls to memalloc_nofs_save() and memalloc_nofs_restore().  Instead,
> +find the lock which is taken that would cause problems if memory reclaim
> +reentered the filesystem, place a call to memalloc_nofs_save() before it
> +is acquired and a call to memalloc_nofs_restore() after it is released.
> +Ideally also add a comment explaining why this lock will be problematic.

The above text has mentioned the transaction context nesting as well and
that was a hint by Dave IIRC. It is imho good to have an example of
other reentrant points than just locks. I believe another useful example
would be something like loop device which is mixing IO and FS layers but
I am not familiar with all the details to give you an useful text.

[...]
> @@ -104,16 +134,19 @@ ARCH_KMALLOC_MINALIGN bytes.  For sizes which are a 
> power of two, the
>  alignment is also guaranteed to be at least the respective size.
>  
>  For large allocations you can use vmalloc() and vzalloc(), or directly
> -request pages from the page allocator. The memory allocated by `vmalloc`
> -and related functions is not physically contiguous.
> +request pages from the page allocator.  The memory allocated by `vmalloc`
> +and related functions is not physically contiguous.  The `vmalloc`
> +family of functions don't support the old ``GFP_NOFS`` or ``GFP_NOIO``
> +flags because there are hardcoded ``GFP_KERNEL`` allocations deep inside
> +the allocator which are hard to remove.  However, the scope APIs described
> +above can be used to limit the `vmalloc` functions.

I would reiterate "Do not just wrap vmalloc by the scope api but rather
rely on the real scope for the NOFS/NOIO context". Maybe we want to
stress out that once a scope is defined it is sticky to _all_
allocations and all allocators within that scope. The text is already
saying that but maybe we want to make it explicit and make it stand out.

[...]
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index 6484569f50df..9fc091274d1d 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -186,9 +186,10 @@ static inline gfp_t current_gfp_context(gfp_t flags)
>* them.  noio implies neither IO nor FS and it is a weaker
>* context so always make sure it takes precedence.
>*/
> - if (current->memalloc_nowait)
> + if (current->memalloc_nowait) {
>   flags &= ~__GFP_DIRECT_RECLAIM;
> - else if (current->memalloc_noio)
> + flags |= __GFP_NOWARN;

I dunno. I wouldn't make nowait implicitly NOWARN as well. At least not
with the initial implementation. Maybe we will learn later that there is
just too much unhelpful noise in the kernel log and will reconsider but
I wouldn't just start with that. Also we might learn that there will be
other modifiers for atomic (or should I say non-sleeping) scopes to be
defined. E.g. access to memory reserves but let's just wait for real
usecases.


Thanks a lot Matthew!
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] Remove handhelds.org links and email addresses

[Alexander A. Klimov]

Am 29.06.20 um 23:10 schrieb Wolfram Sang:

Hi Alexander,

thanks for trying to fix this, yet I have some doubts.

On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote:

Rationale:
https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/


I think we need some text here. Clicking on a link to understand what a
patch is about is not comfortable. You can add the link with a Link: tag
for additional information.

Fine. I can easily make a v2 patch, but first...



Removing stale email addresses may have some value, but removing...


  Compaq's Bootldr + John Dorsey's patch for Assabet support
-(http://www.handhelds.org/Compaq/bootldr.html)


... information like this is not good. 'Wayback machine' still has
copies in case someone wants to look at where the infos came from.

If we shall not remove *this link*, maybe we shall not remove *all links*?

@Jon You've kinda initiated the patch, what's your opinion? Bad 
squatters or good Wayback machine?





- * Copyright 2004-2005  Phil Blundell 
+ * Copyright 2004-2005  Phil Blundell


This is an OK case in my book...



-MODULE_AUTHOR("Phil Blundell ");
+MODULE_AUTHOR("Phil Blundell");


... same here ...


@@ -435,7 +435,6 @@
 case a PCI bridge (DEC chip 21152). The value of
 'pb' is now only initialized if a de4x5 chip is
 present.
-   


This is kind of a signature and should be kept IMO.
What for? An email address is for someone who'd like to send an email to 
it. At the moment handhelds.org doesn't even have an MX record.





   * 2001/07/23: 
- * - Hand merge version from handhelds.org CVS tree.  See patch
+ * - Hand merge version from CVS tree.  See patch


That information may be useful.

Again: What for? For visiting it and thinking like damn, it's gone?





  /* SPDX-License-Identifier: GPL-2.0-only */
  /* -*- linux-c -*-
- *
- * (C) 2003 ze...@handhelds.org


Removing copyright is a bad idea.

IMAO the CREDITS file is for (c) headers.
If you didn't submit a patch for that - your problem.

If you disagree, I can look up git blame.



Probably some comment blocks are cruft meanwhile and can be removed as a
whole. That can be discussed. But removing only the handhelds.org part
makes most parts worse IMHO.

Thanks and happy hacking,

Wolfram

Re: [PATCH 04/16] net: bpfilter: use 'userprogs' syntax to build bpfilter_umh

[Masahiro Yamada]

Hi Michal, Alexei,

On Mon, Jun 8, 2020 at 8:56 PM Michal Kubecek  wrote:
>
> On Thu, Apr 23, 2020 at 04:39:17PM +0900, Masahiro Yamada wrote:
> > The user mode helper should be compiled for the same architecture as
> > the kernel.
> >
> > This Makefile reuses the 'hostprogs' syntax by overriding HOSTCC with CC.
> >
> > Now that Kbuild provides the syntax 'userprogs', use it to fix the
> > Makefile mess.
> >
> > Signed-off-by: Masahiro Yamada 
> > Reported-by: kbuild test robot 
> > ---
> >
> >  net/bpfilter/Makefile | 11 ---
> >  1 file changed, 4 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/bpfilter/Makefile b/net/bpfilter/Makefile
> > index 36580301da70..6ee650c6badb 100644
> > --- a/net/bpfilter/Makefile
> > +++ b/net/bpfilter/Makefile
> > @@ -3,17 +3,14 @@
> >  # Makefile for the Linux BPFILTER layer.
> >  #
> >
> > -hostprogs := bpfilter_umh
> > +userprogs := bpfilter_umh
> >  bpfilter_umh-objs := main.o
> > -KBUILD_HOSTCFLAGS += -I $(srctree)/tools/include/ -I 
> > $(srctree)/tools/include/uapi
> > -HOSTCC := $(CC)
> > +user-ccflags += -I $(srctree)/tools/include/ -I 
> > $(srctree)/tools/include/uapi
> >
> > -ifeq ($(CONFIG_BPFILTER_UMH), y)
> > -# builtin bpfilter_umh should be compiled with -static
> > +# builtin bpfilter_umh should be linked with -static
> >  # since rootfs isn't mounted at the time of __init
> >  # function is called and do_execv won't find elf interpreter
> > -KBUILD_HOSTLDFLAGS += -static
> > -endif
> > +bpfilter_umh-ldflags += -static
> >
> >  $(obj)/bpfilter_umh_blob.o: $(obj)/bpfilter_umh
>
> Hello,
>
> I just noticed that this patch (now in mainline as commit 8a2cc0505cc4)
> drops the test if CONFIG_BPFILTER_UMH is "y" so that -static is now
> passed to the linker even if bpfilter_umh is built as a module which
> wasn't the case in v5.7.
>
> This is not mentioned in the commit message and the comment still says
> "*builtin* bpfilter_umh should be linked with -static" so this change
> doesn't seem to be intentional. Did I miss something?
>
> Michal Kubecek

I was away for a while from this because I saw long discussion in
"net/bpfilter: Remove this broken and apparently unmaintained"


Please let me resume this topic now.


The original behavior of linking umh was like this:
  - If CONFIG_BPFILTER_UMH=y, bpfilter_umh was linked with -static
  - If CONFIG_BPFILTER_UMH=m, bpfilter_umh was linked without -static



Restoring the original behavior will add more complexity because
now we have CONFIG_CC_CAN_LINK and CONFIG_CC_CAN_LINK_STATIC
since commit b1183b6dca3e0d5

If CONFIG_BPFILTER_UMH=y, we need to check CONFIG_CC_CAN_LINK_STATIC.
If CONFIG_BPFILTER_UMH=m, we need to check CONFIG_CC_CAN_LINK.
This would make the Kconfig dependency logic too complicated.


To make it simpler, I'd like to suggest two options.



Idea 1:

  Always use -static irrespective of whether
  CONFIG_BPFILTER_UMH is y or m.

  Add two more lines to clarify this
  in the comment in net/bpfilter/Makefile:

  # builtin bpfilter_umh should be linked with -static
  # since rootfs isn't mounted at the time of __init
  # function is called and do_execv won't find elf interpreter.
  # Static linking is not required when bpfilter is modular, but
  # we always pass -static to keep the 'depends on' in Kconfig simple.



Idea 2:

   Allow umh to become only modular,
   and drop -static flag entirely.

   If you look at net/bpfilter/Kconfig,
   BPFILTER_UMH already has 'default m'.
   So, I assume the most expected use-case
   is modular.

   My suggestion is to replace 'default m' with 'depends on m'.

   config BPFILTER_UMH
   tristate "bpfilter kernel module with user mode helper"
   depends on CC_CAN_LINK
   depends on m

   Then BPFILTER_UMH will be restricted to either m or n.
   Link umh dynamically because we can expect rootfs
   is already mounted for the module case.






Comments are appreciated.


-- 
Best Regards
Masahiro Yamada

[PATCH v5 bpf-next 2/4] bpf: introduce helper bpf_get_task_stack()

[Song Liu]

Introduce helper bpf_get_task_stack(), which dumps stack trace of given
task. This is different to bpf_get_stack(), which gets stack track of
current task. One potential use case of bpf_get_task_stack() is to call
it from bpf_iter__task and dump all /proc//stack to a seq_file.

bpf_get_task_stack() uses stack_trace_save_tsk() instead of
get_perf_callchain() for kernel stack. The benefit of this choice is that
stack_trace_save_tsk() doesn't require changes in arch/. The downside of
using stack_trace_save_tsk() is that stack_trace_save_tsk() dumps the
stack trace to unsigned long array. For 32-bit systems, we need to
translate it to u64 array.

Acked-by: Andrii Nakryiko 
Signed-off-by: Song Liu 
---
 include/linux/bpf.h|  1 +
 include/uapi/linux/bpf.h   | 36 +++-
 kernel/bpf/stackmap.c  | 77 --
 kernel/bpf/verifier.c  |  4 +-
 kernel/trace/bpf_trace.c   |  2 +
 scripts/bpf_helpers_doc.py |  2 +
 tools/include/uapi/linux/bpf.h | 36 +++-
 7 files changed, 151 insertions(+), 7 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 3d2ade703a357..0cd7f6884c5cd 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -1627,6 +1627,7 @@ extern const struct bpf_func_proto 
bpf_get_current_uid_gid_proto;
 extern const struct bpf_func_proto bpf_get_current_comm_proto;
 extern const struct bpf_func_proto bpf_get_stackid_proto;
 extern const struct bpf_func_proto bpf_get_stack_proto;
+extern const struct bpf_func_proto bpf_get_task_stack_proto;
 extern const struct bpf_func_proto bpf_sock_map_update_proto;
 extern const struct bpf_func_proto bpf_sock_hash_update_proto;
 extern const struct bpf_func_proto bpf_get_current_cgroup_id_proto;
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 0cb8ec9488168..cefb78a77d928 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -3285,6 +3285,39 @@ union bpf_attr {
  * Dynamically cast a *sk* pointer to a *udp6_sock* pointer.
  * Return
  * *sk* if casting is valid, or NULL otherwise.
+ *
+ * long bpf_get_task_stack(struct task_struct *task, void *buf, u32 size, u64 
flags)
+ * Description
+ * Return a user or a kernel stack in bpf program provided buffer.
+ * To achieve this, the helper needs *task*, which is a valid
+ * pointer to struct task_struct. To store the stacktrace, the
+ * bpf program provides *buf* with a nonnegative *size*.
+ *
+ * The last argument, *flags*, holds the number of stack frames to
+ * skip (from 0 to 255), masked with
+ * **BPF_F_SKIP_FIELD_MASK**. The next bits can be used to set
+ * the following flags:
+ *
+ * **BPF_F_USER_STACK**
+ * Collect a user space stack instead of a kernel stack.
+ * **BPF_F_USER_BUILD_ID**
+ * Collect buildid+offset instead of ips for user stack,
+ * only valid if **BPF_F_USER_STACK** is also specified.
+ *
+ * **bpf_get_task_stack**\ () can collect up to
+ * **PERF_MAX_STACK_DEPTH** both kernel and user frames, subject
+ * to sufficient large buffer size. Note that
+ * this limit can be controlled with the **sysctl** program, and
+ * that it should be manually increased in order to profile long
+ * user stacks (such as stacks for Java programs). To do so, use:
+ *
+ * ::
+ *
+ * # sysctl kernel.perf_event_max_stack=
+ * Return
+ * A non-negative value equal to or less than *size* on success,
+ * or a negative error in case of failure.
+ *
  */
 #define __BPF_FUNC_MAPPER(FN)  \
FN(unspec), \
@@ -3427,7 +3460,8 @@ union bpf_attr {
FN(skc_to_tcp_sock),\
FN(skc_to_tcp_timewait_sock),   \
FN(skc_to_tcp_request_sock),\
-   FN(skc_to_udp6_sock),
+   FN(skc_to_udp6_sock),   \
+   FN(get_task_stack),
 
 /* integer value in 'imm' field of BPF_CALL instruction selects which helper
  * function eBPF program intends to call
diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c
index 27dc9b1b08a52..0ba66b29ef227 100644
--- a/kernel/bpf/stackmap.c
+++ b/kernel/bpf/stackmap.c
@@ -348,6 +348,40 @@ static void stack_map_get_build_id_offset(struct 
bpf_stack_build_id *id_offs,
}
 }
 
+static struct perf_callchain_entry *
+get_callchain_entry_for_task(struct task_struct *task, u32 init_nr)
+{
+   struct perf_callchain_entry *entry;
+   int rctx;
+
+   entry = get_callchain_entry(&rctx);
+
+   if (!entry)
+   return NULL;
+
+   entry->nr = init_nr +
+   stack_trace_save_tsk(task, (unsigned long *)(entry->ip + 
init_nr),
+sysctl_perf_event_max_stack - init_nr, 0);
+

[PATCH v5 bpf-next 1/4] perf: expose get/put_callchain_entry()

[Song Liu]

Sanitize and expose get/put_callchain_entry(). This would be used by bpf
stack map.

Suggested-by: Peter Zijlstra 
Acked-by: Andrii Nakryiko 
Signed-off-by: Song Liu 
---
 include/linux/perf_event.h |  2 ++
 kernel/events/callchain.c  | 13 ++---
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index b4bb32082342c..00ab5efa38334 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1244,6 +1244,8 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, 
bool kernel, bool user,
 extern struct perf_callchain_entry *perf_callchain(struct perf_event *event, 
struct pt_regs *regs);
 extern int get_callchain_buffers(int max_stack);
 extern void put_callchain_buffers(void);
+extern struct perf_callchain_entry *get_callchain_entry(int *rctx);
+extern void put_callchain_entry(int rctx);
 
 extern int sysctl_perf_event_max_stack;
 extern int sysctl_perf_event_max_contexts_per_stack;
diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index 334d48b16c36d..c6ce894e4ce94 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -149,7 +149,7 @@ void put_callchain_buffers(void)
}
 }
 
-static struct perf_callchain_entry *get_callchain_entry(int *rctx)
+struct perf_callchain_entry *get_callchain_entry(int *rctx)
 {
int cpu;
struct callchain_cpus_entries *entries;
@@ -159,8 +159,10 @@ static struct perf_callchain_entry 
*get_callchain_entry(int *rctx)
return NULL;
 
entries = rcu_dereference(callchain_cpus_entries);
-   if (!entries)
+   if (!entries) {
+   put_recursion_context(this_cpu_ptr(callchain_recursion), *rctx);
return NULL;
+   }
 
cpu = smp_processor_id();
 
@@ -168,7 +170,7 @@ static struct perf_callchain_entry *get_callchain_entry(int 
*rctx)
(*rctx * perf_callchain_entry__sizeof()));
 }
 
-static void
+void
 put_callchain_entry(int rctx)
 {
put_recursion_context(this_cpu_ptr(callchain_recursion), rctx);
@@ -183,11 +185,8 @@ get_perf_callchain(struct pt_regs *regs, u32 init_nr, bool 
kernel, bool user,
int rctx;
 
entry = get_callchain_entry(&rctx);
-   if (rctx == -1)
-   return NULL;
-
if (!entry)
-   goto exit_put;
+   return NULL;
 
ctx.entry = entry;
ctx.max_stack = max_stack;
-- 
2.24.1

Re: Re: Upstream fixes not merged in 5.4.y

[SeongJae Park]

On Mon, 29 Jun 2020 18:15:42 +0200 Greg KH  wrote:

> On Mon, Jun 29, 2020 at 04:28:05PM +0200, SeongJae Park wrote:
> > Hello,
> > 
> > 
> > With my little script, I found below commits in the mainline tree are more 
> > than
> > 1 week old and fixing commits that back-ported in v5.4..v5.4.49, but not 
> > merged
> > in the stable/linux-5.4.y tree.  Are those need to be merged in but missed 
> > or
> > dealyed?
> > 
> > 9210c075cef2 ("nvme-pci: avoid race between nvme_reap_pending_cqes() and 
> > nvme_poll()")
> > 9fecd13202f5 ("btrfs: fix a block group ref counter leak after failure to 
> > remove block group")
> > 9d964e1b82d8 ("fix a braino in "sparc32: fix register window handling in 
> > genregs32_[gs]et()"")
> > 8ab3a3812aa9 ("drm/i915/gt: Incrementally check for rewinding")
> > 6e2f83884c09 ("bnxt_en: Fix AER reset logic on 57500 chips.")
> > efb94790852a ("drm/panel-simple: fix connector type for LogicPD Type28 
> > Display")
> > ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams")
> > ff58bbc7b970 ("ALSA: usb-audio: Fix potential use-after-free of streams")
> > 8dbe4c5d5e40 ("net: dsa: bcm_sf2: Fix node reference count")
> > ca8826095e4d ("selftests/net: report etf errors correctly")
> > 5a8d7f126c97 ("of: of_mdio: Correct loop scanning logic")
> > d35d3660e065 ("binder: fix null deref of proc->context")
> > 
> > The script found several more commits but I exclude those here, because 
> > those
> > seems not applicable on 5.4.y or fixing trivial problems only.  If I'm not
> > following a proper process for this kind of reports, please let me know.
> 
> For commits that only have a "Fixes:" tag, and not a "cc: stable..."
> tag, wait a few weeks, or a month, for us to catch up with them.  We
> usually get to them eventually, but it takes us a while as we have lots
> more to deal with by developers and maintainers that are properly
> tagging patches for this type of thing.
> 
> Some of the above commits are queued up already, but not all of them.
> I'll take a look at the list after this next round of patches go out,
> and will let you know.
> 
> And yes, we do want this type of list, it's greatly appreciated.

Appreciate your kind explanation.  I will keep those in my mind for future
reports.


Thanks,
SeongJae Park

> 
> thanks,
> 
> greg k-h

Re: [PATCH v3 4/8] mm/hugetlb: make hugetlb migration callback CMA aware

[Joonsoo Kim]

2020년 6월 29일 (월) 오후 4:55, Michal Hocko 님이 작성:
>
> On Mon 29-06-20 15:27:25, Joonsoo Kim wrote:
> [...]
> > Solution that Introduces a new
> > argument doesn't cause this problem while avoiding CMA regions.
>
> My primary argument is that there is no real reason to treat hugetlb
> dequeing somehow differently. So if we simply exclude __GFP_MOVABLE for
> _any_ other allocation then this certainly has some drawbacks on the
> usable memory for the migration target and it can lead to allocation
> failures (especially on movable_node setups where the amount of movable
> memory might be really high) and therefore longterm gup failures. And
> yes those failures might be premature. But my point is that the behavior
> would be _consistent_. So a user wouldn't see random failures for some
> types of pages while a success for others.

Hmm... I don't agree with your argument. Excluding __GFP_MOVABLE is
a *work-around* way to exclude CMA regions. Implementation for dequeuing
in this patch is a right way to exclude CMA regions. Why do we use a work-around
for this case? To be consistent is important but it's only meaningful
if it is correct.
It should not disrupt to make a better code. And, dequeing is already a special
process that is only available for hugetlb. I think that using
different (correct)
implementations there doesn't break any consistency.

> Let's have a look at this patch. It is simply working that around the
> restriction for a very limited types of pages - only hugetlb pages
> which have reserves in non-cma movable pools. I would claim that many
> setups will simply not have many (if any) spare hugetlb pages in the
> pool except for temporary time periods when a workload is (re)starting
> because this would be effectively a wasted memory.

This can not be a stopper to make the correct code.

> The patch is adding a special case flag to claim what the code already
> does by memalloc_nocma_{save,restore} API so the information is already
> there. Sorry I didn't bring this up earlier but I have completely forgot
> about its existence. With that one in place I do agree that dequeing
> needs a fixup but that should be something like the following instead.

Thanks for letting me know. I don't know it until now. It looks like it's
better to use this API rather than introducing a new argument.

> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 57ece74e3aae..c1595b1d36f3 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1092,10 +1092,14 @@ static struct page *dequeue_huge_page_nodemask(struct 
> hstate *h, gfp_t gfp_mask,
>  /* Movability of hugepages depends on migration support. */
>  static inline gfp_t htlb_alloc_mask(struct hstate *h)
>  {
> +   gfp_t gfp;
> +
> if (hugepage_movable_supported(h))
> -   return GFP_HIGHUSER_MOVABLE;
> +   gfp = GFP_HIGHUSER_MOVABLE;
> else
> -   return GFP_HIGHUSER;
> +   gfp = GFP_HIGHUSER;
> +
> +   return current_gfp_context(gfp);
>  }
>
>  static struct page *dequeue_huge_page_vma(struct hstate *h,
>
> If we even fix this general issue for other allocations and allow a
> better CMA exclusion then it would be implemented consistently for
> everybody.

Yes, I have reviewed the memalloc_nocma_{} APIs and found the better way
for CMA exclusion. I will do it after this patch is finished.

> Does this make more sense to you are we still not on the same page wrt
> to the actual problem?

Yes, but we have different opinions about it. As said above, I will make
a patch for better CMA exclusion after this patchset. It will make
code consistent.
I'd really appreciate it if you wait until then.

Thanks.

[PATCH v5 bpf-next 0/4] bpf: introduce bpf_get_task_stack()

[Song Liu]

This set introduces a new helper bpf_get_task_stack(). The primary use case
is to dump all /proc/*/stack to seq_file via bpf_iter__task.

A few different approaches have been explored and compared:

  1. A simple wrapper around stack_trace_save_tsk(), as v1 [1].

 This approach introduces new syntax, which is different to existing
 helper bpf_get_stack(). Therefore, this is not ideal.

  2. Extend get_perf_callchain() to support "task" as argument.

 This approach reuses most of bpf_get_stack(). However, extending
 get_perf_callchain() requires non-trivial changes to architecture
 specific code. Which is error prone.

  3. Current (v2) approach, leverages most of existing bpf_get_stack(), and
 uses stack_trace_save_tsk() to handle architecture specific logic.

[1] 
https://lore.kernel.org/netdev/20200623070802.2310018-1-songliubrav...@fb.com/

Changes v4 => v5:
1. Rebase and work around git-am issue. (Alexei)
2. Update commit log for 4/4. (Yonghong)

Changes v3 => v4:
1. Simplify the selftests with bpf_iter.h. (Yonghong)
2. Add example output to commit log of 4/4. (Yonghong)

Changes v2 => v3:
1. Rebase on top of bpf-next. (Yonghong)
2. Sanitize get_callchain_entry(). (Peter)
3. Use has_callchain_buf for bpf_get_task_stack. (Andrii)
4. Other small clean up. (Yonghong, Andrii).

Changes v1 => v2:
1. Reuse most of bpf_get_stack() logic. (Andrii)
2. Fix unsigned long vs. u64 mismatch for 32-bit systems. (Yonghong)
3. Add %pB support in bpf_trace_printk(). (Daniel)
4. Fix buffer size to bytes.

Song Liu (4):
  perf: expose get/put_callchain_entry()
  bpf: introduce helper bpf_get_task_stack()
  bpf: allow %pB in bpf_seq_printf() and bpf_trace_printk()
  selftests/bpf: add bpf_iter test with bpf_get_task_stack()

 include/linux/bpf.h   |  1 +
 include/linux/perf_event.h|  2 +
 include/uapi/linux/bpf.h  | 36 -
 kernel/bpf/stackmap.c | 77 ++-
 kernel/bpf/verifier.c |  4 +-
 kernel/events/callchain.c | 13 ++--
 kernel/trace/bpf_trace.c  | 12 ++-
 scripts/bpf_helpers_doc.py|  2 +
 tools/include/uapi/linux/bpf.h| 36 -
 .../selftests/bpf/prog_tests/bpf_iter.c   | 17 
 .../selftests/bpf/progs/bpf_iter_task_stack.c | 37 +
 11 files changed, 221 insertions(+), 16 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/progs/bpf_iter_task_stack.c

--
2.24.1

[PATCH 6/9] media: mtk-vcodec: vdec: support stateless H.264 decoding

[Alexandre Courbot]

From: Yunfei Dong 

Add support for H.264 decoding using the stateless API, as supported by
MT8183. This support takes advantage of the V4L2 H.264 reference list
builders.

Signed-off-by: Yunfei Dong 
[acourbot: refactor, cleanup and split]
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
---
 drivers/media/platform/Kconfig|   1 +
 drivers/media/platform/mtk-vcodec/Makefile|   1 +
 .../mtk-vcodec/vdec/vdec_h264_req_if.c| 802 ++
 .../media/platform/mtk-vcodec/vdec_drv_if.c   |   3 +
 .../media/platform/mtk-vcodec/vdec_drv_if.h   |   1 +
 5 files changed, 808 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f0dbe048efea..ff77c6db55db 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -255,6 +255,7 @@ config VIDEO_MEDIATEK_VCODEC
depends on ARCH_MEDIATEK || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
+   select V4L2_H264
select VIDEO_MEDIATEK_VPU
select MTK_SCP
help
diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index 057e2519aafd..f7c1d27a85d5 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \
 mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec/vdec_vp8_if.o \
vdec/vdec_vp9_if.o \
+   vdec/vdec_h264_req_if.o \
mtk_vcodec_dec_drv.o \
vdec_drv_if.o \
vdec_vpu_if.o \
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c 
b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
new file mode 100644
index ..f90518910d8d
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
@@ -0,0 +1,802 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../vdec_drv_if.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_dec.h"
+#include "../mtk_vcodec_intr.h"
+#include "../vdec_vpu_if.h"
+#include "../vdec_drv_base.h"
+
+#define NAL_NON_IDR_SLICE  0x01
+#define NAL_IDR_SLICE  0x05
+#define NAL_TYPE(value)((value) & 0x1F)
+
+#define BUF_PREDICTION_SZ  (64 * 4096)
+#define MB_UNIT_LEN16
+
+/* get used parameters for sps/pps */
+#define GET_MTK_VDEC_FLAG(cond, flag) \
+   { dst_param->cond = ((src_param->flags & (flag)) ? (1) : (0)); }
+#define GET_MTK_VDEC_PARAM(param) \
+   { dst_param->param = src_param->param; }
+/* motion vector size (bytes) for every macro block */
+#define HW_MB_STORE_SZ 64
+
+#define H264_MAX_MV_NUM32
+
+/**
+ * struct mtk_h264_dpb_info  - h264 dpb information
+ * @y_dma_addr: Y bitstream physical address
+ * @c_dma_addr: CbCr bitstream physical address
+ * @reference_flag: reference picture flag (short/long term reference picture)
+ * @field: field picture flag
+ */
+struct mtk_h264_dpb_info {
+   dma_addr_t y_dma_addr;
+   dma_addr_t c_dma_addr;
+   int reference_flag;
+   int field;
+};
+
+/**
+ * struct mtk_h264_sps_param  - parameters for sps
+ */
+struct mtk_h264_sps_param {
+   unsigned char chroma_format_idc;
+   unsigned char bit_depth_luma_minus8;
+   unsigned char bit_depth_chroma_minus8;
+   unsigned char log2_max_frame_num_minus4;
+   unsigned char pic_order_cnt_type;
+   unsigned char log2_max_pic_order_cnt_lsb_minus4;
+   unsigned char max_num_ref_frames;
+   unsigned char separate_colour_plane_flag;
+   unsigned short pic_width_in_mbs_minus1;
+   unsigned short pic_height_in_map_units_minus1;
+   unsigned int max_frame_nums;
+   unsigned char qpprime_y_zero_transform_bypass_flag;
+   unsigned char delta_pic_order_always_zero_flag;
+   unsigned char frame_mbs_only_flag;
+   unsigned char mb_adaptive_frame_field_flag;
+   unsigned char direct_8x8_inference_flag;
+   unsigned char reserved[3];
+};
+
+/**
+ * struct mtk_h264_pps_param  - parameters for pps
+ */
+struct mtk_h264_pps_param {
+   unsigned char num_ref_idx_l0_default_active_minus1;
+   unsigned char num_ref_idx_l1_default_active_minus1;
+   unsigned char weighted_bipred_idc;
+   char pic_init_qp_minus26;
+   char chroma_qp_index_offset;
+   char second_chroma_qp_index_offset;
+   unsigned char entropy_coding_mode_flag;
+   unsigned char pic_order_present_flag;
+   unsigned char deblocking_filter_control_present_flag;
+   unsigned char constrained_intra_pred_flag;
+   unsigned char weighted_pred_flag;
+   unsigned char redundant_p

[PATCH 5/9] media: mtk-vcodec: vdec: support stateless API

[Alexandre Courbot]

From: Yunfei Dong 

Support the stateless codec API that will be used by MT8183.

Signed-off-by: Yunfei Dong 
[acourbot: refactor, cleanup and split]
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
---
 drivers/media/platform/mtk-vcodec/Makefile|   1 +
 .../platform/mtk-vcodec/mtk_vcodec_dec.c  |  66 ++-
 .../platform/mtk-vcodec/mtk_vcodec_dec.h  |   9 +-
 .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 469 ++
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |   3 +
 5 files changed, 545 insertions(+), 3 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index a9e189af5ba4..057e2519aafd 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -12,6 +12,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec_vpu_if.o \
mtk_vcodec_dec.o \
mtk_vcodec_dec_stateful.o \
+   mtk_vcodec_dec_stateless.o \
mtk_vcodec_dec_pm.o \
mtk_vcodec_fw.o
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 7e01ac03887e..8de72879b1a0 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -46,6 +46,13 @@ static struct mtk_q_data *mtk_vdec_get_q_data(struct 
mtk_vcodec_ctx *ctx,
 static int vidioc_try_decoder_cmd(struct file *file, void *priv,
struct v4l2_decoder_cmd *cmd)
 {
+   struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
+
+   /* Use M2M stateless helper if relevant */
+   if (ctx->dev->vdec_pdata->uses_stateless_api)
+   return v4l2_m2m_ioctl_stateless_try_decoder_cmd(file, priv,
+   cmd);
+
switch (cmd->cmd) {
case V4L2_DEC_CMD_STOP:
case V4L2_DEC_CMD_START:
@@ -72,6 +79,10 @@ static int vidioc_decoder_cmd(struct file *file, void *priv,
if (ret)
return ret;
 
+   /* Use M2M stateless helper if relevant */
+   if (ctx->dev->vdec_pdata->uses_stateless_api)
+   return v4l2_m2m_ioctl_stateless_decoder_cmd(file, priv, cmd);
+
mtk_v4l2_debug(1, "decoder cmd=%u", cmd->cmd);
dst_vq = v4l2_m2m_get_vq(ctx->m2m_ctx,
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
@@ -420,7 +431,8 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
 * Setting OUTPUT format after OUTPUT buffers are allocated is invalid
 * if using the stateful API.
 */
-   if ((f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
+   if (!dec_pdata->uses_stateless_api &&
+   (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) &&
vb2_is_busy(&ctx->m2m_ctx->out_q_ctx.q)) {
mtk_v4l2_err("out_q_ctx buffers already requested");
ret = -EBUSY;
@@ -463,6 +475,7 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
ctx->quantization = pix_mp->quantization;
ctx->xfer_func = pix_mp->xfer_func;
 
+   ctx->current_codec = fmt->fourcc;
if (ctx->state == MTK_STATE_FREE) {
ret = vdec_if_init(ctx, q_data->fmt->fourcc);
if (ret) {
@@ -474,6 +487,49 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
}
}
 
+   /*
+* If using the stateless API, S_FMT should have the effect of setting
+* the CAPTURE queue resolution no matter which queue it was called on.
+*/
+   if (dec_pdata->uses_stateless_api) {
+   ctx->picinfo.pic_w = pix_mp->width;
+   ctx->picinfo.pic_h = pix_mp->height;
+
+   ret = vdec_if_get_param(ctx, GET_PARAM_PIC_INFO, &ctx->picinfo);
+   if (ret) {
+   mtk_v4l2_err("[%d]Error!! Get GET_PARAM_PICTURE_INFO 
Fail",
+   ctx->id);
+   return -EINVAL;
+   }
+
+   ctx->last_decoded_picinfo = ctx->picinfo;
+
+   if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 1) {
+   ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
+   ctx->picinfo.fb_sz[0] +
+   ctx->picinfo.fb_sz[1];
+   ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
+   ctx->picinfo.buf_w;
+   } else {
+   ctx->q_data[MTK_Q_DATA_DST].sizeimage[0] =
+   ctx->picinfo.fb_sz[0];
+   ctx->q_data[MTK_Q_DATA_DST].bytesperline[0] =
+   ctx->picinfo.buf_w;
+   ctx->q_data[MTK_Q_DATA_DST].sizeimage[1

[PATCH 9/9] dt-bindings: media: document mediatek,mt8183-vcodec-dec

[Alexandre Courbot]

MT8183's decoder is instantiated similarly to MT8173's.

Signed-off-by: Alexandre Courbot 
---
 Documentation/devicetree/bindings/media/mediatek-vcodec.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt 
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
index 8093335afecb..b844800e0153 100644
--- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -7,6 +7,7 @@ Required properties:
 - compatible : "mediatek,mt8173-vcodec-enc" for MT8173 encoder
   "mediatek,mt8183-vcodec-enc" for MT8183 encoder.
   "mediatek,mt8173-vcodec-dec" for MT8173 decoder.
+  "mediatek,mt8183-vcodec-dec" for MT8183 decoder.
 - reg : Physical base address of the video codec registers and length of
   memory mapped region.
 - interrupts : interrupt number to the cpu.
-- 
2.27.0.212.ge8ba1cc988-goog

[PATCH 8/9] media: mtk-vcodec: enable MT8183 decoder

[Alexandre Courbot]

From: Yunfei Dong 

Now that all the supporting blocks are present, enable decoder for
MT8183.

Signed-off-by: Yunfei Dong 
[acourbot: refactor, cleanup and split]
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
---
 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index e723f8573322..e7d90973e626 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -381,12 +381,17 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
 }
 
 extern const struct mtk_vcodec_dec_pdata mtk_vdec_8173_pdata;
+extern const struct mtk_vcodec_dec_pdata mtk_vdec_8183_pdata;
 
 static const struct of_device_id mtk_vcodec_match[] = {
{
.compatible = "mediatek,mt8173-vcodec-dec",
.data = &mtk_vdec_8173_pdata,
},
+   {
+   .compatible = "mediatek,mt8183-vcodec-dec",
+   .data = &mtk_vdec_8183_pdata,
+   },
{},
 };
 
-- 
2.27.0.212.ge8ba1cc988-goog

[PATCH 4/9] media: add Mediatek's MM21 format

[Alexandre Courbot]

Add Mediatek's non-compressed 8 bit block video mode. This format is
produced by the MT8183 codec and can be converted to a non-proprietary
format by the MDP3 component.

Signed-off-by: Alexandre Courbot 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 1 +
 include/uapi/linux/videodev2.h   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 02bfef0da76d..612be602bf76 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1398,6 +1398,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_META_FMT_UVC: descr = "UVC Payload Header Metadata"; 
break;
case V4L2_META_FMT_D4XX:descr = "Intel D4xx UVC Metadata"; 
break;
case V4L2_META_FMT_VIVID:   descr = "Vivid Metadata"; break;
+   case V4L2_PIX_FMT_MM21: descr = "Mediatek 8-bit block format"; 
break;
 
default:
/* Compressed formats */
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 303805438814..a35f65115bca 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -738,6 +738,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_Y12I v4l2_fourcc('Y', '1', '2', 'I') /* Greyscale 
12-bit L/R interleaved */
 #define V4L2_PIX_FMT_Z16  v4l2_fourcc('Z', '1', '6', ' ') /* Depth data 
16-bit */
 #define V4L2_PIX_FMT_MT21Cv4l2_fourcc('M', 'T', '2', '1') /* Mediatek 
compressed block mode  */
+#define V4L2_PIX_FMT_MM21 v4l2_fourcc('M', 'M', '2', '1') /* Mediatek 
8-bit block mode, two non-contiguous planes */
 #define V4L2_PIX_FMT_INZI v4l2_fourcc('I', 'N', 'Z', 'I') /* Intel Planar 
Greyscale 10-bit and Depth 16-bit */
 #define V4L2_PIX_FMT_SUNXI_TILED_NV12 v4l2_fourcc('S', 'T', '1', '2') /* Sunxi 
Tiled NV12 Format */
 #define V4L2_PIX_FMT_CNF4 v4l2_fourcc('C', 'N', 'F', '4') /* Intel 4-bit 
packed depth confidence information */
-- 
2.27.0.212.ge8ba1cc988-goog

[PATCH 3/9] media: mtk-vcodec: support version 2 of decoder firmware ABI

[Alexandre Courbot]

Add support for decoder firmware version 2, which makes the kernel
responsible for managing the VSI context and is used for stateless
codecs.

Signed-off-by: Alexandre Courbot 
---
 .../media/platform/mtk-vcodec/vdec_ipi_msg.h  | 18 +---
 .../media/platform/mtk-vcodec/vdec_vpu_if.c   | 28 +++
 .../media/platform/mtk-vcodec/vdec_vpu_if.h   |  5 
 3 files changed, 42 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h 
b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
index eb66729fda63..a0e773ae3ab3 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
@@ -29,11 +29,15 @@ enum vdec_ipi_msgid {
 /**
  * struct vdec_ap_ipi_cmd - generic AP to VPU ipi command format
  * @msg_id : vdec_ipi_msgid
- * @vpu_inst_addr  : VPU decoder instance address
+ * @vpu_inst_addr : VPU decoder instance address. Used if ABI version < 2.
+ * @inst_id : instance ID. Used if the ABI version >= 2.
  */
 struct vdec_ap_ipi_cmd {
uint32_t msg_id;
-   uint32_t vpu_inst_addr;
+   union {
+   uint32_t vpu_inst_addr;
+   uint32_t inst_id;
+   };
 };
 
 /**
@@ -63,7 +67,8 @@ struct vdec_ap_ipi_init {
 /**
  * struct vdec_ap_ipi_dec_start - for AP_IPIMSG_DEC_START
  * @msg_id : AP_IPIMSG_DEC_START
- * @vpu_inst_addr  : VPU decoder instance address
+ * @vpu_inst_addr : VPU decoder instance address. Used if ABI version < 2.
+ * @inst_id : instance ID. Used if the ABI version >= 2.
  * @data   : Header info
  * H264 decoder [0]:buf_sz [1]:nal_start
  * VP8 decoder  [0]:width/height
@@ -72,7 +77,10 @@ struct vdec_ap_ipi_init {
  */
 struct vdec_ap_ipi_dec_start {
uint32_t msg_id;
-   uint32_t vpu_inst_addr;
+   union {
+   uint32_t vpu_inst_addr;
+   uint32_t inst_id;
+   };
uint32_t data[3];
uint32_t reserved;
 };
@@ -87,6 +95,7 @@ struct vdec_ap_ipi_dec_start {
  * ensure that it is compatible with the firmware.
  * This field is not valid for MT8173 and must not be
  * accessed for this chip.
+ * @inst_id : instance ID. Valid only if the ABI version >= 2.
  */
 struct vdec_vpu_ipi_init_ack {
uint32_t msg_id;
@@ -94,6 +103,7 @@ struct vdec_vpu_ipi_init_ack {
uint64_t ap_inst_addr;
uint32_t vpu_inst_addr;
uint32_t vdec_abi_version;
+   uint32_t inst_id;
 };
 
 #endif
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index 203089213e67..5dffc459a33d 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -25,18 +25,30 @@ static void handle_init_ack_msg(const struct 
vdec_vpu_ipi_init_ack *msg)
 
mtk_vcodec_debug(vpu, "- vpu_inst_addr = 0x%x", vpu->inst_addr);
 
+   /* Set default ABI version if dealing with unversioned firmware. */
+   vpu->fw_abi_version = 0;
+   /*
+* Instance ID is only used if ABI version >= 2. Initialize it with
+* garbage by default.
+*/
+   vpu->inst_id = 0xdeadbeef;
+
/* Firmware version field does not exist on MT8173. */
if (vpu->ctx->dev->vdec_pdata->chip == MTK_MT8173)
return;
 
/* Check firmware version. */
-   mtk_vcodec_debug(vpu, "firmware version 0x%x\n", msg->vdec_abi_version);
-   switch (msg->vdec_abi_version) {
+   vpu->fw_abi_version = msg->vdec_abi_version;
+   mtk_vcodec_debug(vpu, "firmware version 0x%x\n", vpu->fw_abi_version);
+   switch (vpu->fw_abi_version) {
case 1:
break;
+   case 2:
+   vpu->inst_id = msg->inst_id;
+   break;
default:
mtk_vcodec_err(vpu, "unhandled firmware version 0x%x\n",
-  msg->vdec_abi_version);
+  vpu->fw_abi_version);
vpu->failure = 1;
break;
}
@@ -113,7 +125,10 @@ static int vcodec_send_ap_ipi(struct vdec_vpu_inst *vpu, 
unsigned int msg_id)
 
memset(&msg, 0, sizeof(msg));
msg.msg_id = msg_id;
-   msg.vpu_inst_addr = vpu->inst_addr;
+   if (vpu->fw_abi_version < 2)
+   msg.vpu_inst_addr = vpu->inst_addr;
+   else
+   msg.inst_id = vpu->inst_id;
 
err = vcodec_vpu_send_msg(vpu, &msg, sizeof(msg));
mtk_vcodec_debug(vpu, "- id=%X ret=%d", msg_id, err);
@@ -163,7 +178,10 @@ int vpu_dec_start(struct vdec_vpu_inst *vpu, uint32_t 
*data, unsigned int len)
 
memset(&msg, 0, sizeof(msg));
msg.msg_id = AP_IPIMSG_DEC_START;
-   msg.vpu_inst_addr = vpu->inst_addr;
+   if (vpu->fw_abi_version < 2)
+   msg.vpu_inst_addr = vpu->inst_addr;
+   else
+   msg.inst_id = vpu->inst_id;
 
for (i = 0; i < le

[PATCH 7/9] media: mtk-vcodec: vdec: add media device if using stateless api

[Alexandre Courbot]

From: Yunfei Dong 

The stateless API requires a media device for issuing requests. Add one
if we are being instantiated as a stateless decoder.

Signed-off-by: Yunfei Dong 
[acourbot: refactor, cleanup and split]
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
---
 drivers/media/platform/Kconfig|  1 +
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  | 39 +++
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |  2 +
 3 files changed, 42 insertions(+)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ff77c6db55db..cb5ffb98dc09 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -258,6 +258,7 @@ config VIDEO_MEDIATEK_VCODEC
select V4L2_H264
select VIDEO_MEDIATEK_VPU
select MTK_SCP
+   select MEDIA_CONTROLLER
help
Mediatek video codec driver provides HW capability to
encode and decode in a range of video formats
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 3d8eaf0746c2..e723f8573322 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mtk_vcodec_drv.h"
 #include "mtk_vcodec_dec.h"
@@ -322,6 +323,31 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
goto err_event_workq;
}
 
+   if (dev->vdec_pdata->uses_stateless_api) {
+   dev->mdev_dec.dev = &pdev->dev;
+   strscpy(dev->mdev_dec.model, MTK_VCODEC_DEC_NAME,
+   sizeof(dev->mdev_dec.model));
+
+   media_device_init(&dev->mdev_dec);
+   dev->mdev_dec.ops = &mtk_vcodec_media_ops;
+   dev->v4l2_dev.mdev = &dev->mdev_dec;
+
+   ret = v4l2_m2m_register_media_controller(dev->m2m_dev_dec,
+   dev->vfd_dec, MEDIA_ENT_F_PROC_VIDEO_DECODER);
+   if (ret) {
+   mtk_v4l2_err("Failed to register media controller");
+   goto err_reg_cont;
+   }
+
+   ret = media_device_register(&dev->mdev_dec);
+   if (ret) {
+   mtk_v4l2_err("Failed to register media device");
+   goto err_media_reg;
+   }
+
+   mtk_v4l2_debug(0, "media registered as /dev/media%d",
+   vfd_dec->num);
+   }
ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, 0);
if (ret) {
mtk_v4l2_err("Failed to register video device");
@@ -334,6 +360,12 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
return 0;
 
 err_dec_reg:
+   if (dev->vdec_pdata->uses_stateless_api)
+   media_device_unregister(&dev->mdev_dec);
+err_media_reg:
+   if (dev->vdec_pdata->uses_stateless_api)
+   v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec);
+err_reg_cont:
destroy_workqueue(dev->decode_workqueue);
 err_event_workq:
v4l2_m2m_release(dev->m2m_dev_dec);
@@ -366,6 +398,13 @@ static int mtk_vcodec_dec_remove(struct platform_device 
*pdev)
 
flush_workqueue(dev->decode_workqueue);
destroy_workqueue(dev->decode_workqueue);
+
+   if (media_devnode_is_registered(dev->mdev_dec.devnode)) {
+   media_device_unregister(&dev->mdev_dec);
+   v4l2_m2m_unregister_media_controller(dev->m2m_dev_dec);
+   media_device_cleanup(&dev->mdev_dec);
+   }
+
if (dev->m2m_dev_dec)
v4l2_m2m_release(dev->m2m_dev_dec);
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 755631d0fe92..7071434b5c5b 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -382,6 +382,7 @@ struct mtk_vcodec_enc_pdata {
  * struct mtk_vcodec_dev - driver data
  * @v4l2_dev: V4L2 device to register video devices for.
  * @vfd_dec: Video device for decoder
+ * @mdev_dec: Media device for decoder
  * @vfd_enc: Video device for encoder.
  *
  * @m2m_dev_dec: m2m device for decoder
@@ -418,6 +419,7 @@ struct mtk_vcodec_enc_pdata {
 struct mtk_vcodec_dev {
struct v4l2_device v4l2_dev;
struct video_device *vfd_dec;
+   struct media_device mdev_dec;
struct video_device *vfd_enc;
 
struct v4l2_m2m_dev *m2m_dev_dec;
-- 
2.27.0.212.ge8ba1cc988-goog

Re: [PATCH] rtc: max77686: Do not allow interrupt to fire before system resume

[Krzysztof Kozlowski]

On Tue, Jun 30, 2020 at 12:23:53AM +0200, Alexandre Belloni wrote:
> Hi,
> 
> On 15/06/2020 18:14:55+0200, Krzysztof Kozlowski wrote:
> > The rtc-max77686 device shares the main interrupt line with parent MFD
> > device (max77686 driver).  During the system suspend, the parent MFD
> > device disables this IRQ to prevent an early event happening before
> > resuming I2C bus controller.
> > 
> > The same should be done by rtc-max77686 driver because otherwise the
> > interrupt handler max77686_rtc_alarm_irq() will be called before its
> > resume function (max77686_rtc_resume()).  Such issue is not fatal but
> > disabling shared IRQ by all users ensures correct behavior.
> > 
> > Signed-off-by: Krzysztof Kozlowski 
> > 
> > ---
> > 
> > If this looks ok, I guess all maxim RTC drivers should be updated?
> 
> But then, shouldn't that means that this affects all RTCs on an i2c bus?
> 
> I'm not completely proficient with PM but shouldn't using _noirq
> propagate to the parents? Then you are sure that the resume is called
> with interrupts disabled and this also means that the i2c driver has
> resumed (hopefully with interrupts disabled).

This won't work, at least for Exynos platforms now, because of ordering
with other drivers.  The RTC and MFD enable wake up interrupt which goes
through pinctrl... but pinctrl suspends with "late", so before "noirq".
Therefore the wake does not work.

In the same time, the enable_irq_wake() (I am not sure why) also uses
I2C which goes to I2C bus driver... which suspends in "noirq" as well.
This results in some I2C timeouts during suspend and resume:

[   82.631344] wake enabled for irq 131
[   82.632743] wake enabled for irq 132
[   82.649868] samsung-pinctrl 1100.pinctrl: Setting external wakeup 
interrupt mask: 0xfffbf7ff
[   82.658367] max77686_rtc_suspend:811
[   82.658488] max77686_rtc_suspend:815
[   87.695000] s3c-i2c 1386.i2c: timeout waiting for bus idle
[   87.695574] dummy 0-0006: Failed to sync masks in 1
[   87.700446] wake enabled for irq 127
[   87.703883] max77686_rtc_suspend:818
[   87.707408] max77686_rtc_suspend:829
[   87.716862] max77686_suspend:236
[   87.716972] max77686_suspend:240
[   87.717714] max77686_suspend:252
[   87.723173] Disabling non-boot CPUs ...
[   87.745844] Enabling non-boot CPUs ...
[   87.751164] CPU1 is up
[   87.754842] CPU2 is up
[   87.759008] CPU3 is up
[   87.760598] s3c-i2c 1386.i2c: slave address 0x00
[   87.760709] s3c-i2c 1386.i2c: bus frequency set to 390 KHz
[   87.760851] s3c-i2c 1387.i2c: slave address 0x00
[   87.760951] s3c-i2c 1387.i2c: bus frequency set to 97 KHz
[   87.761085] s3c-i2c 1388.i2c: slave address 0x00
[   87.761185] s3c-i2c 1388.i2c: bus frequency set to 97 KHz
[   87.761319] s3c-i2c 138e.i2c: slave address 0x00
[   87.761418] s3c-i2c 138e.i2c: bus frequency set to 97 KHz
[   87.764159] max77686_resume:261
[   87.764236] max77686_resume:265
[   87.764303] max77686_resume:268
[   87.768204] max77686_rtc_resume:837
[   87.768283] max77686_rtc_resume:840
[   87.768370] max77686_rtc_resume:844
[   92.813964] s3c-i2c 1386.i2c: timeout waiting for bus idle
[   92.814105] dummy 0-0006: Failed to sync masks in 1
[   92.814205] wake disabled for irq 127

In general, disabling and enabling this shared interrupt seems like a
nice way to be able to suspend/resume driver in the "normal" time,
without the need to order anything (noirq, late).

Best regards,
Krzysztof


> 
> I must admit that I don't know and I hope that the answer would also
> answer whether moving all the RTC resume to resume_early is safe. (See
> https://lore.kernel.org/linux-rtc/20200610132403.2539519-1-mar...@geanix.com/#t)
> 
> > ---
> >  drivers/rtc/rtc-max77686.c | 20 ++--
> >  1 file changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
> > index 03ebcf1c0f3d..645de5af707b 100644
> > --- a/drivers/rtc/rtc-max77686.c
> > +++ b/drivers/rtc/rtc-max77686.c
> > @@ -805,17 +805,33 @@ static int max77686_rtc_remove(struct platform_device 
> > *pdev)
> >  #ifdef CONFIG_PM_SLEEP
> >  static int max77686_rtc_suspend(struct device *dev)
> >  {
> > +   struct max77686_rtc_info *info = dev_get_drvdata(dev);
> > +   int ret = 0;
> > +
> > if (device_may_wakeup(dev)) {
> > struct max77686_rtc_info *info = dev_get_drvdata(dev);
> >  
> > -   return enable_irq_wake(info->virq);
> > +   ret = enable_irq_wake(info->virq);
> > }
> >  
> > -   return 0;
> > +   /*
> > +* Main IRQ (not virtual) must be disabled during suspend because if it
> > +* happens while suspended it will be handled before resuming I2C.
> > +*
> > +* Since Main IRQ is shared, all its users should disable it to be sure
> > +* it won't fire while one of them is still suspended.
> > +*/
> > +   disable_irq(info->rtc_irq);
> > +
> > +   return ret;
> >  }
> >  
> >  static int max77686_rtc_resume(struct device *dev)

[PATCH 2/9] media: mtk-vcodec: vdec: handle firmware version field

[Alexandre Courbot]

Firmwares for decoders newer than MT8173 will include an ABI version
number in their initialization ack message. Add the capacity to manage
it and make initialization fail if the firmware ABI is of a version that
we don't support.

For MT8173, this ABI version field does not exist ; thus ignore it on
this chip. There should only be one firmware version available for it
anyway.

Signed-off-by: Alexandre Courbot 
---
 .../mtk-vcodec/mtk_vcodec_dec_stateful.c  |  1 +
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |  4 
 .../media/platform/mtk-vcodec/vdec_ipi_msg.h  |  5 +
 .../media/platform/mtk-vcodec/vdec_vpu_if.c   | 21 +--
 4 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
index 3224c8049255..b4dad8767f3c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
@@ -619,6 +619,7 @@ static struct vb2_ops mtk_vdec_frame_vb2_ops = {
 };
 
 const struct mtk_vcodec_dec_pdata mtk_vdec_8173_pdata = {
+   .chip = MTK_MT8173,
.init_vdec_params = mtk_init_vdec_params,
.ctrls_setup = mtk_vcodec_dec_ctrls_setup,
.vdec_vb2_ops = &mtk_vdec_frame_vb2_ops,
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 388659c28603..386712f9bffc 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -322,6 +322,8 @@ enum mtk_chip {
  * @vdec_framesizes: supported video decoder frame sizes
  * @num_framesizes: count of video decoder frame sizes
  *
+ * @chip: chip this decoder is compatible with
+ *
  * @uses_stateless_api: whether the decoder uses the stateless API with 
requests
  */
 
@@ -341,6 +343,8 @@ struct mtk_vcodec_dec_pdata {
const struct mtk_codec_framesizes *vdec_framesizes;
const int num_framesizes;
 
+   enum mtk_chip chip;
+
bool uses_stateless_api;
 };
 
diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h 
b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
index 47a1c1c0fd04..eb66729fda63 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
@@ -83,12 +83,17 @@ struct vdec_ap_ipi_dec_start {
  * @status : VPU exeuction result
  * @ap_inst_addr   : AP vcodec_vpu_inst instance address
  * @vpu_inst_addr  : VPU decoder instance address
+ * @vdec_abi_version:  ABI version of the firmware. Kernel can use it to
+ * ensure that it is compatible with the firmware.
+ * This field is not valid for MT8173 and must not be
+ * accessed for this chip.
  */
 struct vdec_vpu_ipi_init_ack {
uint32_t msg_id;
int32_t status;
uint64_t ap_inst_addr;
uint32_t vpu_inst_addr;
+   uint32_t vdec_abi_version;
 };
 
 #endif
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c 
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index 58b0e6fa8fd2..203089213e67 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -24,6 +24,22 @@ static void handle_init_ack_msg(const struct 
vdec_vpu_ipi_init_ack *msg)
vpu->inst_addr = msg->vpu_inst_addr;
 
mtk_vcodec_debug(vpu, "- vpu_inst_addr = 0x%x", vpu->inst_addr);
+
+   /* Firmware version field does not exist on MT8173. */
+   if (vpu->ctx->dev->vdec_pdata->chip == MTK_MT8173)
+   return;
+
+   /* Check firmware version. */
+   mtk_vcodec_debug(vpu, "firmware version 0x%x\n", msg->vdec_abi_version);
+   switch (msg->vdec_abi_version) {
+   case 1:
+   break;
+   default:
+   mtk_vcodec_err(vpu, "unhandled firmware version 0x%x\n",
+  msg->vdec_abi_version);
+   vpu->failure = 1;
+   break;
+   }
 }
 
 /*
@@ -44,6 +60,9 @@ static void vpu_dec_ipi_handler(void *data, unsigned int len, 
void *priv)
 
mtk_vcodec_debug(vpu, "+ id=%X", msg->msg_id);
 
+   vpu->failure = msg->status;
+   vpu->signaled = 1;
+
if (msg->status == 0) {
switch (msg->msg_id) {
case VPU_IPIMSG_DEC_INIT_ACK:
@@ -63,8 +82,6 @@ static void vpu_dec_ipi_handler(void *data, unsigned int len, 
void *priv)
}
 
mtk_vcodec_debug(vpu, "- id=%X", msg->msg_id);
-   vpu->failure = msg->status;
-   vpu->signaled = 1;
 }
 
 static int vcodec_vpu_send_msg(struct vdec_vpu_inst *vpu, void *msg, int len)
-- 
2.27.0.212.ge8ba1cc988-goog

[PATCH v3 6/7] kconfig: qconf: don't show goback button on splitMode

[Mauro Carvalho Chehab]

the goback button does nothing on splitMode. So, why display
it?

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kconfig/qconf.cc | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index e43fe4dcd4e7..6a327b69ff5f 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -437,9 +437,10 @@ void ConfigList::updateList(ConfigItem* item)
if (rootEntry != &rootmenu && (mode == singleMode ||
(mode == symbolMode && rootEntry->parent != &rootmenu))) {
item = (ConfigItem *)topLevelItem(0);
-   if (!item)
+   if (!item && mode != symbolMode) {
item = new ConfigItem(this, 0, true);
-   last = item;
+   last = item;
+   }
}
if ((mode == singleMode || (mode == symbolMode && !(rootEntry->flags & 
MENU_ROOT))) &&
rootEntry->sym && rootEntry->prompt) {
-- 
2.26.2

Re: [PATCH v2] ARM: dts: exynos: Fix missing empty reg/ranges property regulators on Trats

[Marek Szyprowski]

Hi Krzysztof,

On 29.06.2020 22:59, Krzysztof Kozlowski wrote:
> Remove the regulators node entirely because its children do not have any
> unit addresses.  This fixes DTC warning:
>
>  Warning (simple_bus_reg): /regulators/regulator-0: missing or empty 
> reg/ranges property
>
> Signed-off-by: Krzysztof Kozlowski 

Tested-by: Marek Szyprowski 

What about removing the regulators node from other boards: 
exynos4412-origen.dts, exynos5420-smdk5420.dts and exynos5250-arndale.dts?

On the other hand, maybe it would be really easier to add missing 
address/size-cells properties to exynos4210-trats.dts/regulators node?

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH v3 5/7] kconfig: qconf: simplify the goBack() logic

[Mauro Carvalho Chehab]

The goBack() logic is used only for the configList, as
it only makes sense on singleMode. So, let's simplify the
code.

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kconfig/qconf.cc | 50 +++-
 1 file changed, 18 insertions(+), 32 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 29ca4823cfb9..e43fe4dcd4e7 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1455,18 +1455,22 @@ ConfigMainWindow::ConfigMainWindow(void)
addToolBar(toolBar);
 
backAction = new QAction(QPixmap(xpm_back), "Back", this);
- connect(backAction, SIGNAL(triggered(bool)), SLOT(goBack()));
- backAction->setEnabled(false);
+   connect(backAction, SIGNAL(triggered(bool)), SLOT(goBack()));
+
QAction *quitAction = new QAction("&Quit", this);
quitAction->setShortcut(Qt::CTRL + Qt::Key_Q);
- connect(quitAction, SIGNAL(triggered(bool)), SLOT(close()));
+   connect(quitAction, SIGNAL(triggered(bool)), SLOT(close()));
+
QAction *loadAction = new QAction(QPixmap(xpm_load), "&Load", this);
loadAction->setShortcut(Qt::CTRL + Qt::Key_L);
- connect(loadAction, SIGNAL(triggered(bool)), SLOT(loadConfig()));
+   connect(loadAction, SIGNAL(triggered(bool)), SLOT(loadConfig()));
+
saveAction = new QAction(QPixmap(xpm_save), "&Save", this);
saveAction->setShortcut(Qt::CTRL + Qt::Key_S);
- connect(saveAction, SIGNAL(triggered(bool)), SLOT(saveConfig()));
+   connect(saveAction, SIGNAL(triggered(bool)), SLOT(saveConfig()));
+
conf_set_changed_callback(conf_changed);
+
// Set saveAction's initial state
conf_changed();
configname = xstrdup(conf_get_configname());
@@ -1667,21 +1671,11 @@ void ConfigMainWindow::searchConfig(void)
 void ConfigMainWindow::changeItens(struct menu *menu)
 {
configList->setRootMenu(menu);
-
-   if (configList->rootEntry->parent == &rootmenu)
-   backAction->setEnabled(false);
-   else
-   backAction->setEnabled(true);
 }
 
 void ConfigMainWindow::changeMenu(struct menu *menu)
 {
menuList->setRootMenu(menu);
-
-   if (menuList->rootEntry->parent == &rootmenu)
-   backAction->setEnabled(false);
-   else
-   backAction->setEnabled(true);
 }
 
 void ConfigMainWindow::setMenuLink(struct menu *menu)
@@ -1748,25 +1742,11 @@ void ConfigMainWindow::listFocusChanged(void)
 
 void ConfigMainWindow::goBack(void)
 {
-   ConfigItem* item, *oldSelection;
+qInfo() << __FUNCTION__;
+   if (configList->rootEntry == &rootmenu)
+   return;
 
configList->setParentMenu();
-   if (configList->rootEntry == &rootmenu)
-   backAction->setEnabled(false);
-
-   if (menuList->selectedItems().count() == 0)
-   return;
-
-   item = (ConfigItem*)menuList->selectedItems().first();
-   oldSelection = item;
-   while (item) {
-   if (item->menu == configList->rootEntry) {
-   oldSelection->setSelected(false);
-   item->setSelected(true);
-   break;
-   }
-   item = (ConfigItem*)item->parent();
-   }
 }
 
 void ConfigMainWindow::showSingleView(void)
@@ -1778,6 +1758,8 @@ void ConfigMainWindow::showSingleView(void)
fullViewAction->setEnabled(true);
fullViewAction->setChecked(false);
 
+   backAction->setEnabled(true);
+
menuView->hide();
menuList->setRootMenu(0);
configList->mode = singleMode;
@@ -1797,6 +1779,8 @@ void ConfigMainWindow::showSplitView(void)
fullViewAction->setEnabled(true);
fullViewAction->setChecked(false);
 
+   backAction->setEnabled(false);
+
configList->mode = menuMode;
if (configList->rootEntry == &rootmenu)
configList->updateListAll();
@@ -1820,6 +1804,8 @@ void ConfigMainWindow::showFullView(void)
fullViewAction->setEnabled(false);
fullViewAction->setChecked(true);
 
+   backAction->setEnabled(false);
+
menuView->hide();
menuList->setRootMenu(0);
configList->mode = fullMode;
-- 
2.26.2

[PATCH v3 3/7] kconfig: qconf: make debug links work again

[Mauro Carvalho Chehab]

The Qt5 conversion broke support for debug info links.

Restore the behaviour added by changeset
ab45d190fd4a ("kconfig: create links in info window").

The original approach was to pass a pointer for a data struct
via an . That doesn't sound a good idea, as, if something
gets wrong, the app could crash. So, instead, pass the name of
the symbol, and validate such symbol at the hyperlink handling
logic.

Link: https://lore.kernel.org/lkml/20200628125421.12458...@coco.lan/
Reported-by: Maxim Levitsky 
Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kconfig/qconf.cc | 75 +---
 scripts/kconfig/qconf.h  |  1 +
 2 files changed, 71 insertions(+), 5 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 9def59423743..1fddbdfa58b4 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1012,7 +1013,7 @@ ConfigInfoView::ConfigInfoView(QWidget* parent, const 
char *name)
: Parent(parent), sym(0), _menu(0)
 {
setObjectName(name);
-
+   setOpenLinks(false);
 
if (!objectName().isEmpty()) {
configSettings->beginGroup(objectName());
@@ -1085,7 +1086,7 @@ void ConfigInfoView::menuInfo(void)
if (sym->name) {
head += " (";
if (showDebug())
-   head += QString().sprintf("", sym);
+   head += QString().sprintf("", sym->name);
head += print_filter(sym->name);
if (showDebug())
head += "";
@@ -1094,7 +1095,7 @@ void ConfigInfoView::menuInfo(void)
} else if (sym->name) {
head += "";
if (showDebug())
-   head += QString().sprintf("", 
sym);
+   head += QString().sprintf("", 
sym->name);
head += print_filter(sym->name);
if (showDebug())
head += "";
@@ -1145,7 +1146,7 @@ QString ConfigInfoView::debug_info(struct symbol *sym)
switch (prop->type) {
case P_PROMPT:
case P_MENU:
-   debug += QString().sprintf("prompt: ", 
prop->menu);
+   debug += QString().sprintf("prompt: ", 
sym->name);
debug += print_filter(prop->text);
debug += "";
break;
@@ -1217,13 +1218,74 @@ void ConfigInfoView::expr_print_help(void *data, struct 
symbol *sym, const char
QString str2 = print_filter(str);
 
if (sym && sym->name && !(sym->flags & SYMBOL_CONST)) {
-   *text += QString().sprintf("", sym);
+   *text += QString().sprintf("", sym->name);
*text += str2;
*text += "";
} else
*text += str2;
 }
 
+void ConfigInfoView::clicked(const QUrl &url)
+{
+   QByteArray str = url.toEncoded();
+   const std::size_t count = str.size();
+   char *data = new char[count + 1];
+   struct symbol **result;
+   struct menu *m = NULL;
+   char type;
+
+   if (count < 1) {
+   qInfo() << "Clicked link is empty";
+   delete data;
+   return;
+   }
+
+   memcpy(data, str.constData(), count);
+   data[count] = '\0';
+   type = data[0];
+
+   /* Seek for exact match */
+   data[0] = '^';
+   strcat(data, "$");
+   result = sym_re_search(data);
+   if (!result) {
+   qInfo() << "Clicked symbol is invalid:" << data;
+   delete data;
+   return;
+   }
+
+   sym = *result;
+   if (type == 's') {
+   symbolInfo();
+   emit showDebugChanged(true);
+   free(result);
+   delete data;
+   return;
+   }
+
+   /* URL is a menu */
+   for (struct property *prop = sym->prop; prop; prop = prop->next) {
+   if (prop->type != P_PROMPT && prop->type != P_MENU)
+   continue;
+   m = prop->menu;
+   break;
+   }
+
+   if (!m) {
+   qInfo() << "Clicked menu is invalid:" << data;
+   free(result);
+   delete data;
+   return;
+   }
+
+   _menu = m;
+   menuInfo();
+
+   emit showDebugChanged(true);
+   free(result);
+   delete data;
+}
+
 QMenu* ConfigInfoView::createStandardContextMenu(const QPoint & pos)
 {
QMenu* popup = Parent::createStandardContextMenu(pos);
@@ -1497,6 +1559,9 @@ ConfigMainWindow::ConfigMainWindow(void)
helpMenu->addAction(showIntroAction);
helpMenu->addAction(showAb

[PATCH v3 7/7] kconfig: qconf: navigate menus on hyperlinks

[Mauro Carvalho Chehab]

Instead of just changing the helper window to show a
dependency, also navigate to it at the config and menu
widgets.

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kconfig/qconf.cc | 24 +---
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 6a327b69ff5f..f49fbac91995 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1233,7 +1233,6 @@ void ConfigInfoView::clicked(const QUrl &url)
char *data = new char[count + 1];
struct symbol **result;
struct menu *m = NULL;
-   char type;
 
if (count < 1) {
qInfo() << "Clicked link is empty";
@@ -1243,7 +1242,6 @@ void ConfigInfoView::clicked(const QUrl &url)
 
memcpy(data, str.constData(), count);
data[count] = '\0';
-   type = data[0];
 
/* Seek for exact match */
data[0] = '^';
@@ -1256,15 +1254,8 @@ void ConfigInfoView::clicked(const QUrl &url)
}
 
sym = *result;
-   if (type == 's') {
-   symbolInfo();
-   emit showDebugChanged(true);
-   free(result);
-   delete data;
-   return;
-   }
 
-   /* URL is a menu */
+   /* Seek for the menu which holds the symbol */
for (struct property *prop = sym->prop; prop; prop = prop->next) {
if (prop->type != P_PROMPT && prop->type != P_MENU)
continue;
@@ -1272,17 +1263,11 @@ void ConfigInfoView::clicked(const QUrl &url)
break;
}
 
-   if (!m) {
+   if (!m)
qInfo() << "Clicked menu is invalid:" << data;
-   free(result);
-   delete data;
-   return;
-   }
+   else
+   emit menuSelected(m);
 
-   _menu = m;
-   menuInfo();
-
-   emit showDebugChanged(true);
free(result);
delete data;
 }
@@ -1731,6 +1716,7 @@ void ConfigMainWindow::setMenuLink(struct menu *menu)
list->setSelected(item, true);
list->scrollToItem(item);
list->setFocus();
+   helpText->setInfo(menu);
}
}
 }
-- 
2.26.2

[PATCH v3 4/7] kconfig: qconf: re-implement setSelected()

[Mauro Carvalho Chehab]

The default implementation for setSelected() at QTreeWidgetItem
allows multiple items to be selected.

Well, this should never be possible for the configItem lists.

So, implement a function that will automatically clean any
previous selection. This simplifies the logic somewhat, while
making the selection logic to be applied atomically, avoiding
future issues on that.

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kconfig/qconf.cc | 15 ---
 scripts/kconfig/qconf.h  | 14 ++
 2 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 1fddbdfa58b4..29ca4823cfb9 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -537,7 +537,7 @@ void ConfigList::setRootMenu(struct menu *menu)
rootEntry = menu;
updateListAll();
if (currentItem()) {
-   currentItem()->setSelected(hasFocus());
+   setSelected(currentItem(), hasFocus());
scrollToItem(currentItem());
}
 }
@@ -865,7 +865,7 @@ void ConfigList::focusInEvent(QFocusEvent *e)
 
ConfigItem* item = (ConfigItem *)currentItem();
if (item) {
-   item->setSelected(true);
+   setSelected(item, true);
menu = item->menu;
}
emit gotFocus(menu);
@@ -1711,17 +1711,10 @@ void ConfigMainWindow::setMenuLink(struct menu *menu)
if (!parent)
return;
 
-   /* Clear an already-selected item */
-   if (!configList->selectedItems().isEmpty()) {
-   item = 
(ConfigItem*)configList->selectedItems().first();
-   if (item)
-   item->setSelected(false);
-   }
-
/* Select the config view */
item = configList->findConfigItem(parent);
if (item) {
-   item->setSelected(true);
+   configList->setSelected(item, true);
configList->scrollToItem(item);
}
 
@@ -1740,7 +1733,7 @@ void ConfigMainWindow::setMenuLink(struct menu *menu)
if (list) {
item = list->findConfigItem(menu);
if (item) {
-   item->setSelected(true);
+   list->setSelected(item, true);
list->scrollToItem(item);
list->setFocus();
}
diff --git a/scripts/kconfig/qconf.h b/scripts/kconfig/qconf.h
index a193137f2314..fb9e9729266f 100644
--- a/scripts/kconfig/qconf.h
+++ b/scripts/kconfig/qconf.h
@@ -45,11 +45,17 @@ class ConfigList : public QTreeWidget {
 public:
ConfigList(ConfigView* p, const char *name = 0);
void reinit(void);
-   ConfigView* parent(void) const
-   {
-   return (ConfigView*)Parent::parent();
-   }
ConfigItem* findConfigItem(struct menu *);
+   ConfigView* parent(void) const
+   {
+   return (ConfigView*)Parent::parent();
+   }
+   void setSelected(QTreeWidgetItem *item, bool enable) {
+   for (int i = 0; i < selectedItems().size(); i++)
+   selectedItems().at(i)->setSelected(false);
+
+   item->setSelected(enable);
+   }
 
 protected:
void keyPressEvent(QKeyEvent *e);
-- 
2.26.2

[PATCH 1/9] media: mtk-vcodec: vdec: move stateful ops into their own file

[Alexandre Courbot]

From: Yunfei Dong 

We are planning to add support for stateless decoders to this driver.
Part of the driver will be shared between stateful and stateless
codecs, but a few ops need to be specialized for both. Extract the
stateful part of the driver and move it into its own file, accessible
through ops that the common driver parts can call.

This patch only moves code around and introduces a set of abstractions ;
the behavior of the driver should not be changed in any way.

Signed-off-by: Yunfei Dong 
[acourbot: refactor, cleanup and split]
Co-developed-by: Alexandre Courbot 
Signed-off-by: Alexandre Courbot 
---
 drivers/media/platform/mtk-vcodec/Makefile|   1 +
 .../platform/mtk-vcodec/mtk_vcodec_dec.c  | 697 ++
 .../platform/mtk-vcodec/mtk_vcodec_dec.h  |  19 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  |  10 +-
 .../mtk-vcodec/mtk_vcodec_dec_stateful.c  | 633 
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |  41 ++
 6 files changed, 755 insertions(+), 646 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index b8636119ed0a..a9e189af5ba4 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -11,6 +11,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec_drv_if.o \
vdec_vpu_if.o \
mtk_vcodec_dec.o \
+   mtk_vcodec_dec_stateful.o \
mtk_vcodec_dec_pm.o \
mtk_vcodec_fw.o
 
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 0f3e710aed4e..7e01ac03887e 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -16,68 +16,17 @@
 #include "vdec_drv_if.h"
 #include "mtk_vcodec_dec_pm.h"
 
-#define OUT_FMT_IDX0
-#define CAP_FMT_IDX3
-
-#define MTK_VDEC_MIN_W 64U
-#define MTK_VDEC_MIN_H 64U
 #define DFT_CFG_WIDTH  MTK_VDEC_MIN_W
 #define DFT_CFG_HEIGHT MTK_VDEC_MIN_H
 
-static const struct mtk_video_fmt mtk_video_formats[] = {
-   {
-   .fourcc = V4L2_PIX_FMT_H264,
-   .type = MTK_FMT_DEC,
-   .num_planes = 1,
-   .flags = V4L2_FMT_FLAG_DYN_RESOLUTION,
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_VP8,
-   .type = MTK_FMT_DEC,
-   .num_planes = 1,
-   .flags = V4L2_FMT_FLAG_DYN_RESOLUTION,
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_VP9,
-   .type = MTK_FMT_DEC,
-   .num_planes = 1,
-   .flags = V4L2_FMT_FLAG_DYN_RESOLUTION,
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_MT21C,
-   .type = MTK_FMT_FRAME,
-   .num_planes = 2,
-   },
-};
-
-static const struct mtk_codec_framesizes mtk_vdec_framesizes[] = {
-   {
-   .fourcc = V4L2_PIX_FMT_H264,
-   .stepwise = {  MTK_VDEC_MIN_W, MTK_VDEC_MAX_W, 16,
-   MTK_VDEC_MIN_H, MTK_VDEC_MAX_H, 16 },
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_VP8,
-   .stepwise = {  MTK_VDEC_MIN_W, MTK_VDEC_MAX_W, 16,
-   MTK_VDEC_MIN_H, MTK_VDEC_MAX_H, 16 },
-   },
-   {
-   .fourcc = V4L2_PIX_FMT_VP9,
-   .stepwise = {  MTK_VDEC_MIN_W, MTK_VDEC_MAX_W, 16,
-   MTK_VDEC_MIN_H, MTK_VDEC_MAX_H, 16 },
-   },
-};
-
-#define NUM_SUPPORTED_FRAMESIZE ARRAY_SIZE(mtk_vdec_framesizes)
-#define NUM_FORMATS ARRAY_SIZE(mtk_video_formats)
-
-static const struct mtk_video_fmt *mtk_vdec_find_format(struct v4l2_format *f)
+static const struct mtk_video_fmt *mtk_vdec_find_format(struct v4l2_format *f,
+  const struct mtk_vcodec_dec_pdata *dec_pdata)
 {
const struct mtk_video_fmt *fmt;
unsigned int k;
 
-   for (k = 0; k < NUM_FORMATS; k++) {
-   fmt = &mtk_video_formats[k];
+   for (k = 0; k < dec_pdata->num_formats; k++) {
+   fmt = &dec_pdata->vdec_formats[k];
if (fmt->fourcc == f->fmt.pix_mp.pixelformat)
return fmt;
}
@@ -94,394 +43,6 @@ static struct mtk_q_data *mtk_vdec_get_q_data(struct 
mtk_vcodec_ctx *ctx,
return &ctx->q_data[MTK_Q_DATA_DST];
 }
 
-/*
- * This function tries to clean all display buffers, the buffers will return
- * in display order.
- * Note the buffers returned from codec driver may still be in driver's
- * reference list.
- */
-static struct vb2_buffer *get_display_buffer(struct mtk_vcodec_ctx *ctx)
-{
-   struct vdec_fb *disp_frame_buffer = NULL;
-   struct mtk_video_dec_buf *dstbuf;
-   struct vb2_v4l2_buffer *vb;
-
-   mtk_v4l2_debug(3, "[%d]", ctx->id);
-   if (vdec_if_get_param(ctx,

[PATCH 0/9] media: mtk-vcodec: vdec: support for MT8183

[Alexandre Courbot]

This patch series adds support for the H.264 stateless decoder found in MT8183.
It depends on the MT8183 encoder support series [1] and should thus be applied
on top of it.

Contrary to MT8173 which is stateful, MT8183 is a stateless decoder. So the
first patches take care of splitting the stateful-relevant code into its own
source file, and to add support for the stateless API. Then support for sending
the H.264 decoder is added, taking advantage of the H.264 helper functions to
build the reference lists.

No regressions to v4l2-compliance have been introduced by this series for
MT8173, and we could also confirm that decoding was still working as expected
on this chip. Following this series will be another one that fixes the remaining
v4l2-compliance issues for both encoder and decoder.

[1] https://lkml.org/lkml/2020/6/26/152

Alexandre Courbot (4):
  media: mtk-vcodec: vdec: handle firmware version field
  media: mtk-vcodec: support version 2 of decoder firmware ABI
  media: add Mediatek's MM21 format
  dt-bindings: media: document mediatek,mt8183-vcodec-dec

Yunfei Dong (5):
  media: mtk-vcodec: vdec: move stateful ops into their own file
  media: mtk-vcodec: vdec: support stateless API
  media: mtk-vcodec: vdec: support stateless H.264 decoding
  media: mtk-vcodec: vdec: add media device if using stateless api
  media: mtk-vcodec: enable MT8183 decoder

 .../bindings/media/mediatek-vcodec.txt|   1 +
 drivers/media/platform/Kconfig|   2 +
 drivers/media/platform/mtk-vcodec/Makefile|   3 +
 .../platform/mtk-vcodec/mtk_vcodec_dec.c  | 763 +++--
 .../platform/mtk-vcodec/mtk_vcodec_dec.h  |  28 +-
 .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c  |  54 +-
 .../mtk-vcodec/mtk_vcodec_dec_stateful.c  | 634 ++
 .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 469 ++
 .../platform/mtk-vcodec/mtk_vcodec_drv.h  |  50 ++
 .../mtk-vcodec/vdec/vdec_h264_req_if.c| 802 ++
 .../media/platform/mtk-vcodec/vdec_drv_if.c   |   3 +
 .../media/platform/mtk-vcodec/vdec_drv_if.h   |   1 +
 .../media/platform/mtk-vcodec/vdec_ipi_msg.h  |  23 +-
 .../media/platform/mtk-vcodec/vdec_vpu_if.c   |  43 +-
 .../media/platform/mtk-vcodec/vdec_vpu_if.h   |   5 +
 drivers/media/v4l2-core/v4l2-ioctl.c  |   1 +
 include/uapi/linux/videodev2.h|   1 +
 17 files changed, 2226 insertions(+), 657 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
 create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c

--
2.27.0.212.ge8ba1cc988-goog

[PATCH v3 2/7] kconfig: qconf: make search fully work again on split mode

[Mauro Carvalho Chehab]

When the search dialog box finds symbols/menus that match
the search criteria, it presents all results at the window.

Clicking on a search result should make qconf to navigate
to the selected item. This works on singleMode and on
fullMode, but on splitMode, the navigation is broken.

This was partially caused by an incomplete Qt5 conversion
and by the followup patches that restored the original
behavior.

When qconf is on split mode, it has to update both the
config and the menu views. Right now, such logic is broken,
as it is not seeking using the right structures.

On qconf, the screen is split into 3 parts:

++---+
||   |
|   Config   | Menu  |
||   |
++---+
||
| ConfigInfo |
||
++

On singleMode and on fullMode, the menuView is hidden, and search
updates only the configList (which controls the ConfigView).

On SplitMode, the search logic should detect if the variable is a
leaf or not. If it is a leaf, it should be presented at the menuView,
and both configList and menuList should be updated. Otherwise, just
the configList should be updated.

Link: 
https://lore.kernel.org/lkml/a98b0f0ebe0c23615a76f1d23f25fd0c84835e6b.ca...@redhat.com/
Reported-by: Maxim Levitsky 
Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kconfig/qconf.cc | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index 0e06afa08908..9def59423743 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1636,22 +1636,33 @@ void ConfigMainWindow::setMenuLink(struct menu *menu)
return;
list->setRootMenu(parent);
break;
-   case symbolMode:
+   case menuMode:
if (menu->flags & MENU_ROOT) {
-   configList->setRootMenu(menu);
+   menuList->setRootMenu(menu);
configList->clearSelection();
-   list = menuList;
-   } else {
list = configList;
+   } else {
parent = menu_get_parent_menu(menu->parent);
if (!parent)
return;
-   item = menuList->findConfigItem(parent);
+
+   /* Clear an already-selected item */
+   if (!configList->selectedItems().isEmpty()) {
+   item = 
(ConfigItem*)configList->selectedItems().first();
+   if (item)
+   item->setSelected(false);
+   }
+
+   /* Select the config view */
+   item = configList->findConfigItem(parent);
if (item) {
item->setSelected(true);
-   menuList->scrollToItem(item);
+   configList->scrollToItem(item);
}
-   list->setRootMenu(parent);
+
+   menuList->setRootMenu(parent);
+   menuList->clearSelection();
+   list = menuList;
}
break;
case fullMode:
-- 
2.26.2

[PATCH v3 0/7] Fix split view search and debug info navigation

[Mauro Carvalho Chehab]

This series fixes some issues with search while on split view and fix the
broken hyperlink navigation.

The first patches restore the pre-Qt5 conversion behavior. The last
one implements navigation on a different way. I opted to keep this one
in separate, as this one is a new feature.

-

v3:

- dropped a patch that it is not needed anymore;
- hyperlinks should now work for non-visible items;
- fixed a description at patch 3.

Mauro Carvalho Chehab (7):
  kconfig: qconf: cleanup includes
  kconfig: qconf: make search fully work again on split mode
  kconfig: qconf: make debug links work again
  kconfig: qconf: re-implement setSelected()
  kconfig: qconf: simplify the goBack() logic
  kconfig: qconf: don't show goback button on splitMode
  kconfig: qconf: navigate menus on hyperlinks

 scripts/kconfig/qconf.cc | 169 +++
 scripts/kconfig/qconf.h  |  29 ---
 2 files changed, 119 insertions(+), 79 deletions(-)

-- 
2.26.2

[PATCH v3 1/7] kconfig: qconf: cleanup includes

[Mauro Carvalho Chehab]

The usage of c-like include is deprecated on modern Qt
versions. Use the c++ style includes.

While here, remove uneeded and redundant ones, sorting
them on alphabetic order.

Signed-off-by: Mauro Carvalho Chehab 
---
 scripts/kconfig/qconf.cc | 27 +--
 scripts/kconfig/qconf.h  | 14 +++---
 2 files changed, 16 insertions(+), 25 deletions(-)

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index c0ac8f7b5f1a..0e06afa08908 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -4,27 +4,18 @@
  * Copyright (C) 2015 Boris Barbulovski 
  */
 
-#include 
-
-#include 
-#include 
-#include 
 #include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
 #include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 
 #include 
 
diff --git a/scripts/kconfig/qconf.h b/scripts/kconfig/qconf.h
index c879d79ce817..d913a02967ae 100644
--- a/scripts/kconfig/qconf.h
+++ b/scripts/kconfig/qconf.h
@@ -3,17 +3,17 @@
  * Copyright (C) 2002 Roman Zippel 
  */
 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
-#include 
+#include 
+#include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
+#include 
+#include 
+
 #include "expr.h"
 
 class ConfigView;
-- 
2.26.2

Re: [PATCH v2 5/5] kconfig: qconf: navigate menus on hyperlinks

[Mauro Carvalho Chehab]

Em Tue, 30 Jun 2020 12:36:27 +0900
Masahiro Yamada  escreveu:

> On Mon, Jun 29, 2020 at 6:35 PM Mauro Carvalho Chehab
>  wrote:
> >
> > Instead of just changing the helper window to show a
> > dependency, also navigate to it at the config and menu
> > widgets.
> >
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---  
> 
> 
> I noticed a regression.
> 
> Visit "Networking support",
> and click "select: BPF"
> from the window at the bottom.
> 
> Nothing happens except the following error message
> in the console:
> 
> Clicked menu is invalid: ^BPF$
> 
> 
> If I apply only 1-4 in this series,
> this works fine.

Hmm... perhaps this is related to symbol visibility. If the clicked
link is not visible, it won't be able to present the Kconfig option.

I guess we can implement a mixed approach here: update just the
configInfo data if it can't find the clicked item as a menu, like
the enclosed patch.

I'll send an updated version with this hybrid approach.

Thanks,
Mauro

diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
index f49fbac91995..fd721c6c4c94 100644
--- a/scripts/kconfig/qconf.cc
+++ b/scripts/kconfig/qconf.cc
@@ -1263,10 +1263,13 @@ void ConfigInfoView::clicked(const QUrl &url)
break;
}
 
-   if (!m)
-   qInfo() << "Clicked menu is invalid:" << data;
-   else
+   if (!m) {
+   /* Symbol is not visible as a menu */
+   symbolInfo();
+   emit showDebugChanged(true);
+   } else {
emit menuSelected(m);
+   }
 
free(result);
delete data;

[PATCH] MAINTAINERS: update Amit Kucheria's email to a single email address

[Amit Kucheria]

Emails currently go to different mailboxes. Switch to the kernel.org
address so I can forward them to a single mailbox.

Signed-off-by: Amit Kucheria 
---
 Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 2 +-
 MAINTAINERS   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml 
b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index d7be931b42d22..0985e65a9d871 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
 title: QCOM SoC Temperature Sensor (TSENS)
 
 maintainers:
-  - Amit Kucheria 
+  - Amit Kucheria 
 
 description: |
   QCOM SoCs have TSENS IP to allow temperature measurement. There are currently
diff --git a/MAINTAINERS b/MAINTAINERS
index 496fd4eafb68c..f80cb6185662f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14230,7 +14230,7 @@ F:  drivers/net/ethernet/qualcomm/rmnet/
 F: include/linux/if_rmnet.h
 
 QUALCOMM TSENS THERMAL DRIVER
-M: Amit Kucheria 
+M: Amit Kucheria 
 L: linux...@vger.kernel.org
 L: linux-arm-...@vger.kernel.org
 S: Maintained
@@ -16930,7 +16930,7 @@ F:  drivers/media/radio/radio-raremono.c
 THERMAL
 M: Zhang Rui 
 M: Daniel Lezcano 
-R: Amit Kucheria 
+R: Amit Kucheria 
 L: linux...@vger.kernel.org
 S: Supported
 Q: https://patchwork.kernel.org/project/linux-pm/list/
-- 
2.25.1

RE: [PATCH 4/4] iommu/vt-d: Add page response ops support

[Tian, Kevin]

> From: Lu Baolu 
> Sent: Sunday, June 28, 2020 8:34 AM
> 
> After a page request is handled, software must response the device which
> raised the page request with the handling result. This is done through
> the iommu ops.page_response if the request was reported to outside of
> vendor iommu driver through iommu_report_device_fault(). This adds the
> VT-d implementation of page_response ops.
> 
> Co-developed-by: Jacob Pan 
> Signed-off-by: Jacob Pan 
> Co-developed-by: Liu Yi L 
> Signed-off-by: Liu Yi L 
> Signed-off-by: Lu Baolu 
> ---
>  drivers/iommu/intel/iommu.c |  1 +
>  drivers/iommu/intel/svm.c   | 73
> +
>  include/linux/intel-iommu.h |  3 ++
>  3 files changed, 77 insertions(+)
> 
> diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
> index de17952ed133..7eb29167e8f9 100644
> --- a/drivers/iommu/intel/iommu.c
> +++ b/drivers/iommu/intel/iommu.c
> @@ -6057,6 +6057,7 @@ const struct iommu_ops intel_iommu_ops = {
>   .sva_bind   = intel_svm_bind,
>   .sva_unbind = intel_svm_unbind,
>   .sva_get_pasid  = intel_svm_get_pasid,
> + .page_response  = intel_svm_page_response,
>  #endif
>  };
> 
> diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
> index 4800bb6f8794..003ea9579632 100644
> --- a/drivers/iommu/intel/svm.c
> +++ b/drivers/iommu/intel/svm.c
> @@ -1092,3 +1092,76 @@ int intel_svm_get_pasid(struct iommu_sva *sva)
> 
>   return pasid;
>  }
> +
> +int intel_svm_page_response(struct device *dev,
> + struct iommu_fault_event *evt,
> + struct iommu_page_response *msg)
> +{
> + struct iommu_fault_page_request *prm;
> + struct intel_svm_dev *sdev;
> + struct intel_iommu *iommu;
> + struct intel_svm *svm;
> + bool private_present;
> + bool pasid_present;
> + bool last_page;
> + u8 bus, devfn;
> + int ret = 0;
> + u16 sid;
> +
> + if (!dev || !dev_is_pci(dev))
> + return -ENODEV;
> +
> + iommu = device_to_iommu(dev, &bus, &devfn);
> + if (!iommu)
> + return -ENODEV;

move to the place when iommu is referenced. This place is too early.

> +
> + if (!msg || !evt)
> + return -EINVAL;
> +
> + mutex_lock(&pasid_mutex);
> +
> + prm = &evt->fault.prm;
> + sid = PCI_DEVID(bus, devfn);
> + pasid_present = prm->flags &
> IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
> + private_present = prm->flags &
> IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA;
> + last_page = prm->flags &
> IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE;
> +
> + if (pasid_present) {
> + /* VT-d supports devices with full 20 bit PASIDs only */
> + if (pci_max_pasids(to_pci_dev(dev)) != PASID_MAX) {
> + ret = -EINVAL;
> + goto out;
> + }

shouldn't we check prm->pasid here? Above is more reasonable to be
checked when page request is reported.

> +
> + ret = pasid_to_svm_sdev(dev, prm->pasid, &svm, &sdev);
> + if (ret || !sdev)

if sdev==NULL, suppose an error (-ENODEV) should be returned here?

> + goto out;
> + }
> +
> + /*
> +  * Per VT-d spec. v3.0 ch7.7, system software must respond
> +  * with page group response if private data is present (PDP)
> +  * or last page in group (LPIG) bit is set. This is an
> +  * additional VT-d feature beyond PCI ATS spec.

feature->requirement

Thanks
Kevin

> +  */
> + if (last_page || private_present) {
> + struct qi_desc desc;
> +
> + desc.qw0 = QI_PGRP_PASID(prm->pasid) | QI_PGRP_DID(sid)
> |
> + QI_PGRP_PASID_P(pasid_present) |
> + QI_PGRP_PDP(private_present) |
> + QI_PGRP_RESP_CODE(msg->code) |
> + QI_PGRP_RESP_TYPE;
> + desc.qw1 = QI_PGRP_IDX(prm->grpid) |
> QI_PGRP_LPIG(last_page);
> + desc.qw2 = 0;
> + desc.qw3 = 0;
> + if (private_present)
> + memcpy(&desc.qw2, prm->private_data,
> +sizeof(prm->private_data));
> +
> + qi_submit_sync(iommu, &desc, 1, 0);
> + }
> +out:
> + mutex_unlock(&pasid_mutex);
> + return ret;
> +}
> diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
> index fc2cfc3db6e1..bf6009a344f5 100644
> --- a/include/linux/intel-iommu.h
> +++ b/include/linux/intel-iommu.h
> @@ -741,6 +741,9 @@ struct iommu_sva *intel_svm_bind(struct device
> *dev, struct mm_struct *mm,
>void *drvdata);
>  void intel_svm_unbind(struct iommu_sva *handle);
>  int intel_svm_get_pasid(struct iommu_sva *handle);
> +int intel_svm_page_response(struct device *dev, struct iommu_fault_event
> *evt,
> + struct iommu_page_response *msg);
> +
>  struct svm_dev_ops;
> 
>  

Re: [PATCH v2 00/15] Make the user mode driver code a better citizen

[Tetsuo Handa]

On 2020/06/30 10:13, Eric W. Biederman wrote:
> Alexei Starovoitov  writes:
> 
>> On Mon, Jun 29, 2020 at 02:55:05PM -0500, Eric W. Biederman wrote:
>>>
>>> I have tested thes changes by booting with the code compiled in and
>>> by killing "bpfilter_umh" and running iptables -vnL to restart
>>> the userspace driver.
>>>
>>> I have compiled tested each change with and without CONFIG_BPFILTER
>>> enabled.
>>
>> With
>> CONFIG_BPFILTER=y
>> CONFIG_BPFILTER_UMH=m
>> it doesn't build:
>>
>> ERROR: modpost: "kill_pid_info" [net/bpfilter/bpfilter.ko] undefined!
>>
>> I've added:
>> +EXPORT_SYMBOL(kill_pid_info);
>> to continue testing...

kill_pid() is already exported.

>>
>> And then did:
>> while true; do iptables -L;rmmod bpfilter; done
>>  
>> Unfortunately sometimes 'rmmod bpfilter' hangs in wait_event().
>>
>> I suspect patch 13 is somehow responsible:
>> +if (tgid) {
>> +kill_pid_info(SIGKILL, SEND_SIG_PRIV, tgid);
>> +wait_event(tgid->wait_pidfd, !pid_task(tgid, PIDTYPE_TGID));
>> +bpfilter_umh_cleanup(info);
>> +}
>>
>> I cannot figure out why it hangs. Some sort of race ?
>> Since adding short delay between kill and wait makes it work.

Because there is a race window that detach_pid() from __unhash_process() from
__exit_signal() from release_task() from exit_notify() from do_exit() is called
some time after wake_up_all(&pid->wait_pidfd) from do_notify_pidfd() from
do_notify_parent() from exit_notify() from do_exit() was called (in other words,
we can't use pid->wait_pidfd when pid_task() is used at wait_event()) ?

Below are changes I suggest.

diff --git a/kernel/umd.c b/kernel/umd.c
index ff79fb16d738..f688813b8830 100644
--- a/kernel/umd.c
+++ b/kernel/umd.c
@@ -26,7 +26,7 @@ static struct vfsmount *blob_to_mnt(const void *data, size_t 
len, const char *na
if (IS_ERR(mnt))
return mnt;
 
-   file = file_open_root(mnt->mnt_root, mnt, name, O_CREAT | O_WRONLY, 
0700);
+   file = file_open_root(mnt->mnt_root, mnt, name, O_CREAT | O_WRONLY | 
O_EXCL, 0700);
if (IS_ERR(file)) {
mntput(mnt);
return ERR_CAST(file);
@@ -52,16 +52,18 @@ static struct vfsmount *blob_to_mnt(const void *data, 
size_t len, const char *na
 
 /**
  * umd_load_blob - Remember a blob of bytes for fork_usermode_driver
- * @info: information about usermode driver
- * @data: a blob of bytes that can be executed as a file
- * @len:  The lentgh of the blob
+ * @info: information about usermode driver (shouldn't be NULL)
+ * @data: a blob of bytes that can be executed as a file (shouldn't be NULL)
+ * @len:  The lentgh of the blob (shouldn't be 0)
  *
  */
 int umd_load_blob(struct umd_info *info, const void *data, size_t len)
 {
struct vfsmount *mnt;
 
-   if (WARN_ON_ONCE(info->wd.dentry || info->wd.mnt))
+   if (!info || !info->driver_name || !data || !len)
+   return -EINVAL;
+   if (info->wd.dentry || info->wd.mnt)
return -EBUSY;
 
mnt = blob_to_mnt(data, len, info->driver_name);
@@ -76,15 +78,14 @@ EXPORT_SYMBOL_GPL(umd_load_blob);
 
 /**
  * umd_unload_blob - Disassociate @info from a previously loaded blob
- * @info: information about usermode driver
+ * @info: information about usermode driver (shouldn't be NULL)
  *
  */
 int umd_unload_blob(struct umd_info *info)
 {
-   if (WARN_ON_ONCE(!info->wd.mnt ||
-!info->wd.dentry ||
-info->wd.mnt->mnt_root != info->wd.dentry))
+   if (!info || !info->driver_name || !info->wd.dentry || !info->wd.mnt)
return -EINVAL;
+   BUG_ON(info->wd.mnt->mnt_root != info->wd.dentry);
 
kern_unmount(info->wd.mnt);
info->wd.mnt = NULL;
@@ -138,7 +139,7 @@ static void umd_cleanup(struct subprocess_info *info)
 {
struct umd_info *umd_info = info->data;
 
-   /* cleanup if umh_setup() was successful but exec failed */
+   /* cleanup if umd_setup() was successful but exec failed */
if (info->retval) {
fput(umd_info->pipe_to_umh);
fput(umd_info->pipe_from_umh);
@@ -163,7 +164,10 @@ int fork_usermode_driver(struct umd_info *info)
const char *argv[] = { info->driver_name, NULL };
int err;
 
-   if (WARN_ON_ONCE(info->tgid))
+   if (!info || !info->driver_name || !info->wd.dentry || !info->wd.mnt)
+   return -EINVAL;
+   BUG_ON(info->wd.mnt->mnt_root != info->wd.dentry);
+   if (info->tgid)
return -EBUSY;
 
err = -ENOMEM;
diff --git a/net/bpfilter/bpfilter_kern.c b/net/bpfilter/bpfilter_kern.c
index 91474884ddb7..9dd70aacb81a 100644
--- a/net/bpfilter/bpfilter_kern.c
+++ b/net/bpfilter/bpfilter_kern.c
@@ -19,8 +19,13 @@ static void shutdown_umh(void)
struct pid *tgid = info->tgid;
 
if (tgid) {
-   kill_pid_info(SIGKILL, SEND_SIG_PRIV, tgid);
-   wait_event(tgid->wait_pidfd, !pid_task(tgid, P

Re: wait_on_page_bit_common(TASK_KILLABLE, EXCLUSIVE) can miss wakeup?

[Oleg Nesterov]

On 06/30, Nicholas Piggin wrote:
> Excerpts from Oleg Nesterov's message of June 30, 2020 12:02 am:
> > On 06/29, Nicholas Piggin wrote:
> >>
> >> prepare_to_wait_event() has a pretty good pattern (and comment), I would
> >> favour using that (test the signal when inserting on the waitqueue).
> >>
> >> @@ -1133,6 +1133,15 @@ static inline int 
> >> wait_on_page_bit_common(wait_queue_head_t *q,
> >> for (;;) {
> >> spin_lock_irq(&q->lock);
> >>
> >> +   if (signal_pending_state(state, current)) {
> >> +   /* Must not lose an exclusive wake up, see
> >> +* prepare_to_wait_event comment */
> >> +   list_del_init(&wait->entry);
> >> +   spin_unlock_irq(&q->lock);
> >> +   ret = -EINTR;
> >
> > Basically this is what my patch in the 1st email does. But note that we 
> > can't
> > just set "ret = -EINTR" here, we will need to clear "ret" if 
> > test_and_set_bit()
> > below succeeds. That is why I used another "int intr" variable.
>
> You snipped off one more important line of context. No such games are
> required AFAIKS.

for (;;) {
spin_lock_irq(&q->lock);
 
+   if (signal_pending_state(state, current)) {
+   /* Must not lose an exclusive wake up, see
+* prepare_to_wait_event comment */
+   list_del_init(&wait->entry);
+   spin_unlock_irq(&q->lock);
+   ret = -EINTR;
+   break;
+   }


so wait_on_page_bit_common() just returns -EINTR if signal_pending_state() == T.
And this is wrong if "current" was already woken up by unlock_page().

That is why ___wait_event() checks the condition even if prepare_to_wait_event()
returns -EINTR. The comment in prepare_to_wait_event() tries to explain this.

Oleg.

Re: [PATCH v4 bpf-next 2/4] bpf: introduce helper bpf_get_task_stack()

[Song Liu]

> On Jun 29, 2020, at 9:18 PM, Alexei Starovoitov 
>  wrote:
> 
> On Sun, Jun 28, 2020 at 10:58 PM Song Liu  wrote:
>> 
>> Introduce helper bpf_get_task_stack(), which dumps stack trace of given
>> task. This is different to bpf_get_stack(), which gets stack track of
>> current task. One potential use case of bpf_get_task_stack() is to call
>> it from bpf_iter__task and dump all /proc//stack to a seq_file.
>> 
>> bpf_get_task_stack() uses stack_trace_save_tsk() instead of
>> get_perf_callchain() for kernel stack. The benefit of this choice is that
>> stack_trace_save_tsk() doesn't require changes in arch/. The downside of
>> using stack_trace_save_tsk() is that stack_trace_save_tsk() dumps the
>> stack trace to unsigned long array. For 32-bit systems, we need to
>> translate it to u64 array.
>> 
>> Acked-by: Andrii Nakryiko 
>> Signed-off-by: Song Liu 
> 
> It doesn't apply:
> Applying: bpf: Introduce helper bpf_get_task_stack()
> Using index info to reconstruct a base tree...
> error: patch failed: kernel/bpf/stackmap.c:471
> error: kernel/bpf/stackmap.c: patch does not apply
> error: Did you hand edit your patch?
> It does not apply to blobs recorded in its index.
> Patch failed at 0002 bpf: Introduce helper bpf_get_task_stack()

Hmm.. seems "git format-patch -b" (--ignore-space-change) breaks it:

# without -b, works fine

$ git format-patch HEAD~1
0001-bpf-introduce-helper-bpf_get_task_stack.patch
$ git reset --hard HEAD~1
HEAD is now at c385fe4fbd7bc perf: expose get/put_callchain_entry()
$ git am ./0001-bpf-introduce-helper-bpf_get_task_stack.patch
Applying: bpf: introduce helper bpf_get_task_stack()


# with -b, doesn't apply :(

$ git format-patch -b HEAD~1
0001-bpf-introduce-helper-bpf_get_task_stack.patch
$ git reset --hard HEAD~1
HEAD is now at c385fe4fbd7bc perf: expose get/put_callchain_entry()
$ git am ./0001-bpf-introduce-helper-bpf_get_task_stack.patch
Applying: bpf: introduce helper bpf_get_task_stack()
error: patch failed: kernel/bpf/stackmap.c:471
error: kernel/bpf/stackmap.c: patch does not apply
Patch failed at 0001 bpf: introduce helper bpf_get_task_stack()
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Let me see how to fix it...

Re: KASAN: out-of-bounds Read in kvm_arch_hardware_setup

[Sean Christopherson]

On Sat, Jun 27, 2020 at 01:01:13PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1654e38510
> kernel config:  https://syzkaller.appspot.com/x/.config?x=be4578b3f1083656
> dashboard link: https://syzkaller.appspot.com/bug?extid=e0240f9c36530bda7130
> compiler:   clang version 10.0.0 (https://github.com/llvm/llvm-project/ 
> c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15f3abc910
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=131b7bb510

#syz dup: general protection fault in syscall_return_slowpath

Re: general protection fault in pvclock_gtod_notify

[Sean Christopherson]

On Fri, Jun 26, 2020 at 01:08:19PM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:4a21185c Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16958f4d10
> kernel config:  https://syzkaller.appspot.com/x/.config?x=bf3aec367b9ab569
> dashboard link: https://syzkaller.appspot.com/bug?extid=b46fb19f175c5c7d1f03
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1080e9c510
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1685d2e310

#syz dup: general protection fault in syscall_return_slowpath

Re: KASAN: null-ptr-deref Read in kvm_arch_check_processor_compat

[Sean Christopherson]

On Tue, Jun 23, 2020 at 05:17:15AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=135e723510
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d195fe572fb15312
> dashboard link: https://syzkaller.appspot.com/bug?extid=a99874f5323ce6088e53
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=14d001be10

#syz dup: general protection fault in syscall_return_slowpath

Re: [PATCH 04/11] ppc64/kexec_file: avoid stomping memory used by special regions

[Hari Bathini]

On 30/06/20 9:00 am, piliu wrote:
> 
> 
> On 06/29/2020 01:55 PM, Hari Bathini wrote:
>>
>>
>> On 28/06/20 7:44 am, piliu wrote:
>>> Hi Hari,
>>
>> Hi Pingfan,
>>
>>>
>>> After a quick through for this series, I have a few question/comment on
>>> this patch for the time being. Pls see comment inline.
>>>
>>> On 06/27/2020 03:05 AM, Hari Bathini wrote:
 crashkernel region could have an overlap with special memory regions
 like  opal, rtas, tce-table & such. These regions are referred to as
 exclude memory ranges. Setup this ranges during image probe in order
 to avoid them while finding the buffer for different kdump segments.
>>
>> [...]
>>
 +  /*
 +   * Use the locate_mem_hole logic in kexec_add_buffer() for regular
 +   * kexec_file_load syscall
 +   */
 +  if (kbuf->image->type != KEXEC_TYPE_CRASH)
 +  return 0;
>>> Can the ranges overlap [crashk_res.start, crashk_res.end]?  Otherwise
>>> there is no requirement for @exclude_ranges.
>>
>> The ranges like rtas, opal are loaded by f/w. They almost always overlap with
>> crashkernel region. So, @exclude_ranges is required to support kdump.
> f/w passes rtas/opal as service, then must f/w mark these ranges as
> fdt_reserved_mem in order to make kernel aware not to use these ranges?

It does. Actually, reserve_map + reserved-ranges are reserved as soon as
memblock allocator is ready but not before crashkernel reservation.
Check early_reserve_mem() call in kernel/prom.c

> Otherwise kernel memory allocation besides kdump can also overwrite
> these ranges.> 
> Hmm, revisiting reserve_crashkernel(). It seems not to take any reserved
> memory into consider except kernel text. Could it work based on memblock
> allocator?

So, kdump could possibly overwrite these regions which is why an exclude
range list is needed. Same thing was done in kexec-tools as well.

Thanks
Hari

Re: [PATCH 3/7] kgdb: Add request_nmi() to the io ops table for kgdboc

[Sumit Garg]

On Mon, 29 Jun 2020 at 17:15, Daniel Thompson
 wrote:
>
> On Fri, Jun 26, 2020 at 12:44:15PM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Jun 23, 2020 at 3:59 AM Daniel Thompson
> >  wrote:
> > >
> > > On Tue, Jun 23, 2020 at 02:07:47PM +0530, Sumit Garg wrote:
> > > > On Mon, 22 Jun 2020 at 21:33, Daniel Thompson
> > > >  wrote:
> > > > > > + irq_set_status_flags(irq, IRQ_NOAUTOEN);
> > > > > > + res = request_nmi(irq, fn, IRQF_PERCPU, "kgdboc", dev_id);
> > > > >
> > > > > Why do we need IRQF_PERCPU here. A UART interrupt is not normally
> > > > > per-cpu?
> > > > >
> > > >
> > > > Have a look at this comment [1] and corresponding check in
> > > > request_nmi(). So essentially yes UART interrupt is not normally
> > > > per-cpu but in order to make it an NMI, we need to request it in
> > > > per-cpu mode.
> > > >
> > > > [1] 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/irq/manage.c#n2112
> > >
> > > Thanks! This is clear.
> > >
> > > > > > + if (res) {
> > > > > > + res = request_irq(irq, fn, IRQF_SHARED, "kgdboc", 
> > > > > > dev_id);
> > > > >
> > > > > IRQF_SHARED?
> > > > >
> > > > > Currrently there is nothing that prevents concurrent activation of
> > > > > ttyNMI0 and the underlying serial driver. Using IRQF_SHARED means it
> > > > > becomes possible for both drivers to try to service the same 
> > > > > interrupt.
> > > > > That risks some rather "interesting" problems.
> > > > >
> > > >
> > > > Could you elaborate more on "interesting" problems?
> > >
> > > Er... one of the serial drivers we have allowed the userspace to open
> > > will, at best, be stone dead and not passing any characters.
> > >
> > >
> > > > BTW, I noticed one more problem with this patch that is IRQF_SHARED
> > > > doesn't go well with IRQ_NOAUTOEN status flag. Earlier I tested it
> > > > with auto enable set.
> > > >
> > > > But if we agree that both shouldn't be active at the same time due to
> > > > some real problems(?) then I can rid of IRQF_SHARED as well. Also, I
> > > > think we should unregister underlying tty driver (eg. /dev/ttyAMA0) as
> > > > well as otherwise it would provide a broken interface to user-space.
> > >
> > > I don't have a particular strong opinion on whether IRQF_SHARED is
> > > correct or not correct since I think that misses the point.
> > >
> > > Firstly, using IRQF_SHARED shows us that there is no interlocking
> > > between kgdb_nmi and the underlying serial driver. That probably tells
> > > us about the importance of the interlock than about IRQF_SHARED.
> > >
> > > To some extent I'm also unsure that kgdb_nmi could ever actually know
> > > the correct flags to use in all cases (that was another reason for the
> > > TODO comment about poll_get_irq() being a bogus API).
> >
> > I do wonder a little bit if the architecture of the "kgdb_nmi_console"
> > should change.  I remember looking at it in the past and thinking it a
> > little weird that if I wanted to get it to work I'd need to change my
> > "console=" command line to go through this new driver and (I guess)
> > change the agetty I have running on my serial port to point to
> > ttyNMI0.  Is that how it's supposed to work?  Then if I want to do a
> > build without kgdb then I need to go in and change my agetty to point
> > back at my normal serial port?
> >
> > It kinda feels like a better way to much of what the driver does would be 
> > to:
> >
> > 1. Allow kgdb to sniff incoming serial bytes on a port and look for
> > its characters.  We already have this feature in the kernel to a small
> > extent for sniffing a break / sysrq character.
> >
> > 2. If userspace doesn't happen to have the serial port open then
> > ideally we could open the port (using all the standard APIs that
> > already exist) from in the kernel and just throw away all the bytes
> > (since we already sniffed them).  As soon as userspace tried to open
> > the port when it would get ownership and if userspace ever closed the
> > port then we'd start reading / throwing away bytes again.
> >
> > If we had a solution like that:
> >
> > a) No serial drivers would need to change.
> >
> > b) No kernel command line parameters would need to change.
> >
> > Obviously that solution wouldn't magically get you an NMI, though.
> > For that I'd presume the right answer would be to add a parameter for
> > each serial driver that can support it to run its rx interrupt in NMI
> > mode.
>

Thanks Doug for the suggestions.

> ... or allow modal changes to the uart driver when kgdboc comes up?
>
> We already allow UART drivers to de-optimize themselves and use
> different code paths when polling is enabled so its not totally crazy
> ;-).
>
>
> > Of course, perhaps I'm just confused and crazy and the above is a
> > really bad idea.
>
> Thanks for bringing this up.
>
> Sumit and I were chatting last week and our discussion went in a similar
> direction (I think not exactly the same which is why it is good to
> see you

Re: [PATCH 2/2] kconfig: qconf: don't show goback button on splitMode

[Mauro Carvalho Chehab]

Em Tue, 30 Jun 2020 12:55:05 +0900
Masahiro Yamada  escreveu:

> On Tue, Jun 30, 2020 at 12:30 AM Mauro Carvalho Chehab
>  wrote:
> >
> > the goback button does nothing on splitMode. So, why display
> > it?  
> 
> 
> Hmm, I still see the goback button
> on all of the three modes...

Huh? 

Perhaps we're talking about a different thing here...

What I meant by goback button is this:

◀ ..

Which is displayed as the first item is not the root config item.

This is implemented on this logic, within ConfigItem::updateMenu():

if (goParent) {
setPixmap(promptColIdx, list->menuBackPix);
prompt = "..";
goto set_prompt;
}

and it displays this image:

const char *xpm_menuback[] = {
"12 12 2 1",
"  c white",
". c black",
"",
" .. ",
" .. ",
" . .. . ",
" .    . ",
" . .. . ",
" . .. . ",
" .    . ",
" . .. . ",
" .. ",
" .. ",
""};

This item is should never be shown on fullMode, because it never 
changes the root item. 

Looking within the code logic, the only place that passes
goParent = true to "new ConfigItem" (thus creating it) is here:

if (rootEntry != &rootmenu && (mode == singleMode ||
(mode == symbolMode && rootEntry->parent != &rootmenu))) {
item = (ConfigItem *)topLevelItem(0);
if (!item && mode != symbolMode) {
item = new ConfigItem(this, 0, true);
last = item;
}
}

(Btw, I almost sent a patch making the "goParent" parameter explict
when creating ConfigItem)

So, even before this patch, the goback button is only displayed on
singleMode and symbolMode (with is one of the internal representations
for the split mode).

This patch should solve the split mode case.

> 
> 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  scripts/kconfig/qconf.cc | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/kconfig/qconf.cc b/scripts/kconfig/qconf.cc
> > index d0bcc0b717f0..f49fbac91995 100644
> > --- a/scripts/kconfig/qconf.cc
> > +++ b/scripts/kconfig/qconf.cc
> > @@ -437,9 +437,10 @@ void ConfigList::updateList(ConfigItem* item)
> > if (rootEntry != &rootmenu && (mode == singleMode ||
> > (mode == symbolMode && rootEntry->parent != &rootmenu))) {
> > item = (ConfigItem *)topLevelItem(0);
> > -   if (!item)
> > +   if (!item && mode != symbolMode) {
> > item = new ConfigItem(this, 0, true);
> > -   last = item;
> > +   last = item;
> > +   }
> > }
> > if ((mode == singleMode || (mode == symbolMode && 
> > !(rootEntry->flags & MENU_ROOT))) &&
> > rootEntry->sym && rootEntry->prompt) {
> > --
> > 2.26.2
> >  
> 
> 



Thanks,
Mauro

Re: [PATCH v4 15/23] ASoC: soc-core: Identify 'no_pcm' DAI links for DPCM

[Kuninori Morimoto]

Hi Sameer

> PCM devices are created for dai links with 'no-pcm' flag as '0'.
> Such DAI links have CPU component which implement pcm_construct()
> and pcm_destruct() callbacks. Based on this, current patch exposes
> a helper function to identify such components and populate 'no_pcm'
> flag for DPCM DAI link.
> 
> This helps to have BE<->BE component links where PCM devices need
> not be created for CPU components involved in the links.
> 
> Signed-off-by: Sameer Pujar 
> ---
(snip)
> +bool soc_component_is_pcm(struct snd_soc_dai_link_component *dlc)
> +{
> + struct snd_soc_component *component;
> + struct snd_soc_dai *dai;
> +
> + for_each_component(component) {
> + if (!component->driver)
> + continue;
> +
> + for_each_component_dais(component, dai) {
> + if (!dai->name || !dlc->dai_name)
> + continue;
> +
> + if (strcmp(dai->name, dlc->dai_name))
> + continue;
> +
> + if (component->driver->pcm_construct)
> + return true;
> + }
> + }
> +
> + return false;
> +}

At least my CPU driver doesn't use component:pcm_construct
but is using DAI:pcm_new for some reasons.
I'm not sure checking DAI:pcm here is enough, or not...

Thank you for your help !!

Best regards
---
Kuninori Morimoto

linux-next: build failure after merge of the thunderbolt tree

[Stephen Rothwell]

Hi all,

After merging the thunderbolt tree, today's linux-next build (powerpc
allyesconfig) failed like this:


Caused by commit

  54509f5005ca ("thunderbolt: Add KUnit tests for path walking")

interacting with commit

  d4cdd146d0db ("kunit: generalize kunit_resource API beyond allocated 
resources")

from the kunit-next tree.

I have applied the following merge fix patch.

From: Stephen Rothwell 
Date: Tue, 30 Jun 2020 15:51:50 +1000
Subject: [PATCH] thunderbolt: merge fix for kunix_resource changes

Signed-off-by: Stephen Rothwell 
---
 drivers/thunderbolt/test.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thunderbolt/test.c b/drivers/thunderbolt/test.c
index acb8b6256847..a4d78811f7e2 100644
--- a/drivers/thunderbolt/test.c
+++ b/drivers/thunderbolt/test.c
@@ -17,13 +17,13 @@ static int __ida_init(struct kunit_resource *res, void 
*context)
struct ida *ida = context;
 
ida_init(ida);
-   res->allocation = ida;
+   res->data = ida;
return 0;
 }
 
 static void __ida_destroy(struct kunit_resource *res)
 {
-   struct ida *ida = res->allocation;
+   struct ida *ida = res->data;
 
ida_destroy(ida);
 }
-- 
2.27.0

-- 
Cheers,
Stephen Rothwell


pgpDOXILdciDf.pgp
Description: OpenPGP digital signature

Unused lines

[Gon Solo]

Hi!

Are the 147MB or 1.6 million(!) lines in
drivers/gpu/drm/amd/include/asic_reg really necessary? I grepped a few
of them and they don't seem to be used, neither in the kernel nor drm or
mesa. As an example I removed one of the unused lines (see the attached
patch) and the amdgpu driver seems to build just fine.

Cheers,
g

>From 6dbc3e4d129ce46f952c8365f6ca22b2e1aaa33b Mon Sep 17 00:00:00 2001
From: Gon Solo 
Date: Tue, 30 Jun 2020 07:47:12 +0200
Subject: [PATCH] Remove unused line.

---
 drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_6_1_sh_mask.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_6_1_sh_mask.h b/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_6_1_sh_mask.h
index 29af5167cd00..d45bd18a05dd 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_6_1_sh_mask.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_6_1_sh_mask.h
@@ -24,7 +24,6 @@
 
 // addressBlock: nbio_pcie_pswuscfg0_cfgdecp
 //PSWUSCFG0_VENDOR_ID
-#define PSWUSCFG0_VENDOR_ID__VENDOR_ID__SHIFT 0x0
 #define PSWUSCFG0_VENDOR_ID__VENDOR_ID_MASK   0xL
 //PSWUSCFG0_DEVICE_ID
 #define PSWUSCFG0_DEVICE_ID__DEVICE_ID__SHIFT 0x0
-- 
2.25.1

RE: [PATCH v8 2/3] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU

[Pritesh Raithatha]

> Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based on ARM
> MMU-500.
> 
> Signed-off-by: Krishna Reddy 

Reviewed-by: Pritesh Raithatha 

Re: [PATCH v33 15/21] x86/vdso: Add support for exception fixup in vDSO functions

[Sean Christopherson]

On Mon, Jun 29, 2020 at 07:10:22PM +0200, Borislav Petkov wrote:
> On Thu, Jun 18, 2020 at 01:08:37AM +0300, Jarkko Sakkinen wrote:
> ...
> > intended benefit of massaging GCC's inlining algorithm is unlikely to
> > realized in the vDSO any time soon, if ever.
> 
> That is a very good explanation and I would prefer if it would be in a
> sgx-specific README or so instead of it getting lost in git...
> 
> > +bool fixup_vdso_exception(struct pt_regs *regs, int trapnr,
> > + unsigned long error_code, unsigned long fault_addr)
> > +{
> > +   const struct vdso_image *image = current->mm->context.vdso_image;
> > +   const struct vdso_exception_table_entry *extable;
> > +   unsigned int nr_entries, i;
> > +   unsigned long base;
> > +
> > +   /*
> > +* Do not attempt to fixup #DB or #BP.  It's impossible to identify
> > +* whether or not a #DB/#BP originated from within an SGX enclave and
> > +* SGX enclaves are currently the only use case for vDSO fixup.
> > +*/
> 
> So this is all fine and dandy but nowhere do I see the code doing:
> 
>   if (am_I_an_sgx_enclave(tsk))
>   fixup_vdso_exception()
> 
> because that vDSO exception fixup, albeit it looking kinda generic, is
> SGX-only for now. So it should be designed to run only for SGX enclaves
> for now.

That's not really feasible as there is no readily available identifier for
an SGX task.  The only indication that a relevant task is an SGX task is if
it has mmap()'d /dev/sgx/enclave, and hooking that would be heinous.  And
adding flag just to tag the task as SGX seems wasteful.

Even if we could easily condition the vDSO fixup on SGX tasks, I don't think
that'd be a good ABI for the SGX vDSO code.  The intended contract is that
fixup will happen simply by virtue of the code at the related IP taking a
fault (in userspace).  E.g. the vDSO function should get the fixup even if
userspace screws up mmap() and invokes __vdso_sgx_enter_enclave() without
being tagged an SGX task.

> Also, is there any particular reason for fixup_vdso_exception() to be in
> arch/x86/entry/vdso/extable.c instead of in arch/x86/mm/extable.c?
> 
> I mean, it gets called by traps.c so it looks like normal kernel code to
> me or am I missing some vdso magic?

No hard dependency, it's normal kernel code.  My reasoning for dropping it
in .../vdso was largely to co-locate it with vdso/extable.h due to the
dependency on the format of 'struct vdso_exception_table_entry'.  And I
put extable.h in .../vdso because it contains macros that are only for use
in actual vDSO code.
 
> And built only when CONFIG_INTEL_SGX is enabled.

Ya, shouldn't be a problem to stub it out for SGX=n.

RE: [PATCH 3/4] iommu/vt-d: Report page request faults for guest SVA

[Tian, Kevin]

> From: Lu Baolu 
> Sent: Sunday, June 28, 2020 8:34 AM
> 
> A pasid might be bound to a page table from a VM guest via the iommu
> ops.sva_bind_gpasid. In this case, when a DMA page fault is detected
> on the physical IOMMU, we need to inject the page fault request into
> the guest. After the guest completes handling the page fault, a page
> response need to be sent back via the iommu ops.page_response().
> 
> This adds support to report a page request fault. Any external module
> which is interested in handling this fault should regiester a notifier
> callback.
> 
> Co-developed-by: Jacob Pan 
> Signed-off-by: Jacob Pan 
> Co-developed-by: Liu Yi L 
> Signed-off-by: Liu Yi L 
> Signed-off-by: Lu Baolu 
> ---
>  drivers/iommu/intel/svm.c | 83
> +--
>  1 file changed, 80 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
> index c23167877b2b..4800bb6f8794 100644
> --- a/drivers/iommu/intel/svm.c
> +++ b/drivers/iommu/intel/svm.c
> @@ -815,6 +815,69 @@ static void intel_svm_drain_prq(struct device *dev,
> int pasid)
>   }
>  }
> 
> +static int prq_to_iommu_prot(struct page_req_dsc *req)
> +{
> + int prot = 0;
> +
> + if (req->rd_req)
> + prot |= IOMMU_FAULT_PERM_READ;
> + if (req->wr_req)
> + prot |= IOMMU_FAULT_PERM_WRITE;
> + if (req->exe_req)
> + prot |= IOMMU_FAULT_PERM_EXEC;
> + if (req->pm_req)
> + prot |= IOMMU_FAULT_PERM_PRIV;
> +
> + return prot;
> +}
> +
> +static int
> +intel_svm_prq_report(struct intel_iommu *iommu, struct page_req_dsc
> *desc)
> +{
> + struct iommu_fault_event event;
> + struct pci_dev *pdev;
> + u8 bus, devfn;
> + int ret = 0;
> +
> + memset(&event, 0, sizeof(struct iommu_fault_event));
> + bus = PCI_BUS_NUM(desc->rid);
> + devfn = desc->rid & 0xff;
> + pdev = pci_get_domain_bus_and_slot(iommu->segment, bus, devfn);

Is this step necessary? dev can be passed in (based on sdev), and more
importantly iommu_report_device_fault already handles the ref counting
e.g. get_device(dev) when fault handler is valid...

> +
> + if (!pdev) {
> + pr_err("No PCI device found for PRQ [%02x:%02x.%d]\n",
> +bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
> + return -ENODEV;
> + }
> +
> + /* Fill in event data for device specific processing */
> + event.fault.type = IOMMU_FAULT_PAGE_REQ;
> + event.fault.prm.addr = desc->addr;
> + event.fault.prm.pasid = desc->pasid;
> + event.fault.prm.grpid = desc->prg_index;
> + event.fault.prm.perm = prq_to_iommu_prot(desc);
> +
> + /*
> +  * Set last page in group bit if private data is present,
> +  * page response is required as it does for LPIG.
> +  */
> + if (desc->lpig)
> + event.fault.prm.flags |=
> IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE;
> + if (desc->pasid_present)
> + event.fault.prm.flags |=
> IOMMU_FAULT_PAGE_REQUEST_PASID_VALID;
> + if (desc->priv_data_present) {
> + event.fault.prm.flags |=
> IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE;

why setting lpig under this condition? 

> + event.fault.prm.flags |=
> IOMMU_FAULT_PAGE_REQUEST_PRIV_DATA;
> + memcpy(event.fault.prm.private_data, desc->priv_data,
> +sizeof(desc->priv_data));
> + }
> +
> + ret = iommu_report_device_fault(&pdev->dev, &event);
> + pci_dev_put(pdev);
> +
> + return ret;
> +}
> +
>  static irqreturn_t prq_event_thread(int irq, void *d)
>  {
>   struct intel_iommu *iommu = d;
> @@ -874,6 +937,19 @@ static irqreturn_t prq_event_thread(int irq, void *d)
>   if (!is_canonical_address(address))
>   goto bad_req;
> 
> + /*
> +  * If prq is to be handled outside iommu driver via receiver of
> +  * the fault notifiers, we skip the page response here.
> +  */
> + if (svm->flags & SVM_FLAG_GUEST_MODE) {
> + int res = intel_svm_prq_report(iommu, req);
> +
> + if (!res)
> + goto prq_advance;
> + else
> + goto bad_req;
> + }
> +

I noted in bad_req there is another reporting logic:

if (sdev && sdev->ops && sdev->ops->fault_cb) {
int rwxp = (req->rd_req << 3) | (req->wr_req << 2) |
(req->exe_req << 1) | (req->pm_req);
sdev->ops->fault_cb(sdev->dev, req->pasid, req->addr,
req->priv_data, rwxp, result);
}

It was introduced in the 1st version of svm.c. It might be unrelated to
this patch, but I wonder whether that one should be replaced with 
iommu_report_device_fault too?

Thanks
Kevin

>   /* If the mm is already defunct, don't handle fault

Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables

[Ahmed S. Darwish]

Peter Zijlstra wrote:

...

> -#define lockdep_assert_irqs_disabled()   do {\
> - WARN_ONCE(debug_locks && !current->lockdep_recursion && \
> -   current->hardirqs_enabled,\
> -   "IRQs not disabled as expected\n");   \
> - } while (0)

...

> +#define lockdep_assert_irqs_disabled()   \
> +do { \
> + WARN_ON_ONCE(debug_locks && this_cpu_read(hardirqs_enabled));   \
> +} while (0)

I think it would be nice to keep the "IRQs not disabled as expected"
message. It makes the lockdep splat much more readable.

This is similarly the case for the v3 lockdep preemption macros:

  https://lkml.kernel.org/r/20200630054452.3675847-5-a.darw...@linutronix.de

I did not add a message though to get in-sync with the IRQ macros above.

Thanks,

--
Ahmed S. Darwish
Linutronix GmbH

RE: [PATCH v8 3/3] iommu/arm-smmu: Add global/context fault implementation hooks

[Pritesh Raithatha]

> Add global/context fault hooks to allow NVIDIA SMMU implementation handle
> faults across multiple SMMUs.
> 
> Signed-off-by: Krishna Reddy 

Reviewed-by: Pritesh Raithatha 

Re: [PATCH] kdb: prevent possible null deref in kdb_msg_write

[Sumit Garg]

On Mon, 29 Jun 2020 at 21:07, Daniel Thompson
 wrote:
>
> On Mon, Jun 29, 2020 at 04:50:20PM +0200, Petr Mladek wrote:
> > On Mon 2020-06-29 16:59:24, Cengiz Can wrote:
> > > `kdb_msg_write` operates on a global `struct kgdb_io *` called
> > > `dbg_io_ops`.
> > >
> > > Although it is initialized in `debug_core.c`, there's a null check in
> > > `kdb_msg_write` which implies that it can be null whenever we dereference
> > > it in this function call.
> > >
> > > Coverity scanner caught this as CID 1465042.
> > >
> > > I have modified the function to bail out if `dbg_io_ops` is not properly
> > > initialized.
> > >
> > > Signed-off-by: Cengiz Can 
> > > ---
> > >  kernel/debug/kdb/kdb_io.c | 15 ---
> > >  1 file changed, 8 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
> > > index 683a799618ad..85e579812458 100644
> > > --- a/kernel/debug/kdb/kdb_io.c
> > > +++ b/kernel/debug/kdb/kdb_io.c
> > > @@ -549,14 +549,15 @@ static void kdb_msg_write(const char *msg, int 
> > > msg_len)
> > > if (msg_len == 0)
> > > return;
> > >
> > > -   if (dbg_io_ops) {
> > > -   const char *cp = msg;
> > > -   int len = msg_len;
> > > +   if (!dbg_io_ops)
> > > +   return;
> >
> > This looks wrong. The message should be printed to the consoles
> > even when dbg_io_ops is NULL. I mean that the for_each_console(c)
> > cycle should always get called.
> >
> > Well, the code really looks racy. dbg_io_ops is set under
> > kgdb_registration_lock. IMHO, it should also get accessed under this lock.
> >
> > It seems that the race is possible. kdb_msg_write() is called from
> > vkdb_printf(). This function is serialized on more CPUs using
> > kdb_printf_cpu lock. But it is not serialized with
> > kgdb_register_io_module() and kgdb_unregister_io_module() calls.
>
> We can't take the lock from the trap handler itself since we cannot
> have spinlocks contended between regular threads and the debug trap
> (which could be an NMI).
>
> Instead, the call to kgdb_unregister_callbacks() at the beginning
> of kgdb_unregister_io_module() should render kdb_msg_write()
> unreachable prior to dbg_io_ops becoming NULL.
>
> As it happens I am starting to believe there is a race in this area but
> the race is between register/unregister calls rather than against the
> trap handler (if there were register/unregister races then the trap
> handler is be a potential victim of the race though).
>
>
> > But I might miss something. dbg_io_ops is dereferenced on many other
> > locations without any check.
>
> There is already a paranoid "just in case there are bugs" check in
> kgdb_io_ready() so in any case I think the check in kdb_msg_write() can
> simply be removed.
>
> As I said in my other post, if dbg_io_ops were ever NULL then the
> system is completely hosed anyway: we can never receive the keystroke
> needed to leave the debugger... and may not be able to tell anybody
> why.
>
>
> > >
> > > -   while (len--) {
> > > -   dbg_io_ops->write_char(*cp);
> > > -   cp++;
> > > -   }
> > > +   const char *cp = msg;
> > > +   int len = msg_len;
> > > +
> > > +   while (len--) {
> > > +   dbg_io_ops->write_char(*cp);
> > > +   cp++;
> > > }
> > >
> > > for_each_console(c) {
> >
> > You probably got confused by this new code:
> >
> >   if (c == dbg_io_ops->cons)
> >   continue;
> >
> > It dereferences dbg_io_ops without NULL check. It should probably
> > get replaced by:
> >
> >   if (dbg_io_ops && c == dbg_io_ops->cons)
> >   continue;
> >
> > Daniel, Sumit, could you please put some light on this?
>
> As above, I think the NULL check that confuses coverity can simply be
> removed.
>

+1

-Sumit

>
> Daniel.

RE: [PATCH v8 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

[Pritesh Raithatha]

> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave IOVA
> accesses across them.
> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
> string for Tegra194 SoC SMMU topology.
> 
> Signed-off-by: Krishna Reddy 

Reviewed-by: Pritesh Raithatha 

Re: [PATCH 2/2] can: flexcan: add support for ISO CAN-FD

[Michael Walle]

[+ Oliver]

Hi Joakim,

Am 2020-06-30 04:42, schrieb Joakim Zhang:

-Original Message-
From: Michael Walle 
Sent: 2020年6月30日 2:18
To: linux-...@vger.kernel.org; net...@vger.kernel.org;
linux-kernel@vger.kernel.org
Cc: Wolfgang Grandegger ; Marc Kleine-Budde
; David S . Miller ; Jakub
Kicinski ; Joakim Zhang ;
dl-linux-imx ; Michael Walle 
Subject: [PATCH 2/2] can: flexcan: add support for ISO CAN-FD

Up until now, the controller used non-ISO CAN-FD mode, although it 
supports it.
Add support for ISO mode, too. By default the hardware is in non-ISO 
mode and

an enable bit has to be explicitly set.

Signed-off-by: Michael Walle 
---
 drivers/net/can/flexcan.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c 
index

183e094f8d66..a92d3cdf4195 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -94,6 +94,7 @@
 #define FLEXCAN_CTRL2_MRP  BIT(18)
 #define FLEXCAN_CTRL2_RRS  BIT(17)
 #define FLEXCAN_CTRL2_EACENBIT(16)
+#define FLEXCAN_CTRL2_ISOCANFDEN   BIT(12)

 /* FLEXCAN memory error control register (MECR) bits */
 #define FLEXCAN_MECR_ECRWRDIS  BIT(31)
@@ -1344,14 +1345,25 @@ static int flexcan_chip_start(struct 
net_device

*dev)
else
reg_mcr |= FLEXCAN_MCR_SRX_DIS;

-   /* MCR - CAN-FD */
-   if (priv->can.ctrlmode & CAN_CTRLMODE_FD)
+   /* MCR, CTRL2
+*
+* CAN-FD mode
+* ISO CAN-FD mode
+*/
+   reg_ctrl2 = priv->read(®s->ctrl2);
+   if (priv->can.ctrlmode & CAN_CTRLMODE_FD) {
reg_mcr |= FLEXCAN_MCR_FDEN;
-   else
+   reg_ctrl2 |= FLEXCAN_CTRL2_ISOCANFDEN;
+   } else {
reg_mcr &= ~FLEXCAN_MCR_FDEN;
+   }
+
+   if (priv->can.ctrlmode & CAN_CTRLMODE_FD_NON_ISO)
+   reg_ctrl2 &= ~FLEXCAN_CTRL2_ISOCANFDEN;





[..]

ip link set can0 up type can bitrate 100 dbitrate 500 fd on
ip link set can0 up type can bitrate 100 dbitrate 500 fd on \
   fd-non-iso on


vs.

ip link set can0 up type can bitrate 100 dbitrate 500 
fd-non-iso on


I haven't found anything if CAN_CTRLMODE_FD_NON_ISO depends on
CAN_CTRLMODE_FD. I.e. wether CAN_CTRLMODE_FD_NON_ISO can only be set if
CAN_CTRLMODE_FD is also set.

Only the following piece of code, which might be a hint that you
have to set CAN_CTRLMODE_FD if you wan't to use CAN_CTRLMODE_FD_NON_ISO:

drivers/net/can/dev.c:
  /* do not check for static fd-non-iso if 'fd' is disabled */
  if (!(maskedflags & CAN_CTRLMODE_FD))
  ctrlstatic &= ~CAN_CTRLMODE_FD_NON_ISO;

If CAN_CTRLMODE_FD_NON_ISO can be set without CAN_CTRLMODE_FD, what
should be the mode if both are set at the same time?

Marc? Oliver?

-michael

[PATCH v3 15/20] raid5: Use sequence counter with associated spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_spinlock_t data type, which allows to associate a
spinlock with the sequence counter. This enables lockdep to verify that
the spinlock used for writer serialization is held when the write side
critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 drivers/md/raid5.c | 2 +-
 drivers/md/raid5.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index ab8067f9ce8c..892aefe88fa7 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -6935,7 +6935,7 @@ static struct r5conf *setup_conf(struct mddev *mddev)
} else
goto abort;
spin_lock_init(&conf->device_lock);
-   seqcount_init(&conf->gen_lock);
+   seqcount_spinlock_init(&conf->gen_lock, &conf->device_lock);
mutex_init(&conf->cache_size_mutex);
init_waitqueue_head(&conf->wait_for_quiescent);
init_waitqueue_head(&conf->wait_for_stripe);
diff --git a/drivers/md/raid5.h b/drivers/md/raid5.h
index f90e0704bed9..a2c9e9e9f5ac 100644
--- a/drivers/md/raid5.h
+++ b/drivers/md/raid5.h
@@ -589,7 +589,7 @@ struct r5conf {
int prev_chunk_sectors;
int prev_algo;
short   generation; /* increments with every reshape */
-   seqcount_t  gen_lock;   /* lock against generation 
changes */
+   seqcount_spinlock_t gen_lock;   /* lock against generation 
changes */
unsigned long   reshape_checkpoint; /* Time we last updated
 * metadata */
long long   min_offset_diff; /* minimum difference between
-- 
2.20.1

[PATCH v3 20/20] hrtimer: Use sequence counter with associated raw spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_raw_spinlock_t data type, which allows to associate
a raw spinlock with the sequence counter. This enables lockdep to verify
that the raw spinlock used for writer serialization is held when the
write side critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 include/linux/hrtimer.h |  2 +-
 kernel/time/hrtimer.c   | 13 ++---
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 15c8ac313678..25993b86ac5c 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -159,7 +159,7 @@ struct hrtimer_clock_base {
struct hrtimer_cpu_base *cpu_base;
unsigned intindex;
clockid_t   clockid;
-   seqcount_t  seq;
+   seqcount_raw_spinlock_t seq;
struct hrtimer  *running;
struct timerqueue_head  active;
ktime_t (*get_time)(void);
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index d89da1c7e005..c4038511d5c9 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -135,7 +135,11 @@ static const int hrtimer_clock_to_base_table[MAX_CLOCKS] = 
{
  * timer->base->cpu_base
  */
 static struct hrtimer_cpu_base migration_cpu_base = {
-   .clock_base = { { .cpu_base = &migration_cpu_base, }, },
+   .clock_base = { {
+   .cpu_base = &migration_cpu_base,
+   .seq  = SEQCNT_RAW_SPINLOCK_ZERO(migration_cpu_base.seq,
+&migration_cpu_base.lock),
+   }, },
 };
 
 #define migration_base migration_cpu_base.clock_base[0]
@@ -1998,8 +2002,11 @@ int hrtimers_prepare_cpu(unsigned int cpu)
int i;
 
for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
-   cpu_base->clock_base[i].cpu_base = cpu_base;
-   timerqueue_init_head(&cpu_base->clock_base[i].active);
+   struct hrtimer_clock_base *clock_b = &cpu_base->clock_base[i];
+
+   clock_b->cpu_base = cpu_base;
+   seqcount_raw_spinlock_init(&clock_b->seq, &cpu_base->lock);
+   timerqueue_init_head(&clock_b->active);
}
 
cpu_base->cpu = cpu;
-- 
2.20.1

[PATCH v3 17/20] NFSv4: Use sequence counter with associated spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_spinlock_t data type, which allows to associate a
spinlock with the sequence counter. This enables lockdep to verify that
the spinlock used for writer serialization is held when the write side
critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 fs/nfs/nfs4_fs.h   | 2 +-
 fs/nfs/nfs4state.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/nfs4_fs.h b/fs/nfs/nfs4_fs.h
index 2b7f6dcd2eb8..210e590e1f71 100644
--- a/fs/nfs/nfs4_fs.h
+++ b/fs/nfs/nfs4_fs.h
@@ -117,7 +117,7 @@ struct nfs4_state_owner {
unsigned longso_flags;
struct list_head so_states;
struct nfs_seqid_counter so_seqid;
-   seqcount_t   so_reclaim_seqcount;
+   seqcount_spinlock_t  so_reclaim_seqcount;
struct mutex so_delegreturn_mutex;
 };
 
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index a8dc25ce48bb..b1dba24918f8 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -509,7 +509,7 @@ nfs4_alloc_state_owner(struct nfs_server *server,
nfs4_init_seqid_counter(&sp->so_seqid);
atomic_set(&sp->so_count, 1);
INIT_LIST_HEAD(&sp->so_lru);
-   seqcount_init(&sp->so_reclaim_seqcount);
+   seqcount_spinlock_init(&sp->so_reclaim_seqcount, &sp->so_lock);
mutex_init(&sp->so_delegreturn_mutex);
return sp;
 }
-- 
2.20.1

[PATCH v3 12/20] xfrm: policy: Use sequence counters with associated lock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. If the serialization primitive is
not disabling preemption implicitly, preemption has to be explicitly
disabled before entering the sequence counter write side critical
section.

A plain seqcount_t does not contain the information of which lock must
be held when entering a write side critical section.

Use the new seqcount_spinlock_t and seqcount_mutex_t data types instead,
which allow to associate a lock with the sequence counter. This enables
lockdep to verify that the lock used for writer serialization is held
when the write side critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 net/xfrm/xfrm_policy.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 564aa6492e7c..732a940468b0 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -122,7 +122,7 @@ struct xfrm_pol_inexact_bin {
/* list containing '*:*' policies */
struct hlist_head hhead;
 
-   seqcount_t count;
+   seqcount_spinlock_t count;
/* tree sorted by daddr/prefix */
struct rb_root root_d;
 
@@ -155,7 +155,7 @@ static struct xfrm_policy_afinfo const __rcu 
*xfrm_policy_afinfo[AF_INET6 + 1]
__read_mostly;
 
 static struct kmem_cache *xfrm_dst_cache __ro_after_init;
-static __read_mostly seqcount_t xfrm_policy_hash_generation;
+static __read_mostly seqcount_mutex_t xfrm_policy_hash_generation;
 
 static struct rhashtable xfrm_policy_inexact_table;
 static const struct rhashtable_params xfrm_pol_inexact_params;
@@ -719,7 +719,7 @@ xfrm_policy_inexact_alloc_bin(const struct xfrm_policy 
*pol, u8 dir)
INIT_HLIST_HEAD(&bin->hhead);
bin->root_d = RB_ROOT;
bin->root_s = RB_ROOT;
-   seqcount_init(&bin->count);
+   seqcount_spinlock_init(&bin->count, &net->xfrm.xfrm_policy_lock);
 
prev = rhashtable_lookup_get_insert_key(&xfrm_policy_inexact_table,
&bin->k, &bin->head,
@@ -1906,7 +1906,7 @@ static int xfrm_policy_match(const struct xfrm_policy 
*pol,
 
 static struct xfrm_pol_inexact_node *
 xfrm_policy_lookup_inexact_addr(const struct rb_root *r,
-   seqcount_t *count,
+   seqcount_spinlock_t *count,
const xfrm_address_t *addr, u16 family)
 {
const struct rb_node *parent;
@@ -4153,7 +4153,7 @@ void __init xfrm_init(void)
 {
register_pernet_subsys(&xfrm_net_ops);
xfrm_dev_init();
-   seqcount_init(&xfrm_policy_hash_generation);
+   seqcount_mutex_init(&xfrm_policy_hash_generation, &hash_resize_mutex);
xfrm_input_init();
 
 #ifdef CONFIG_INET_ESPINTCP
-- 
2.20.1

[PATCH v3 13/20] timekeeping: Use sequence counter with associated raw spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_raw_spinlock_t data type, which allows to associate
a raw spinlock with the sequence counter. This enables lockdep to verify
that the raw spinlock used for writer serialization is held when the
write side critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 kernel/time/timekeeping.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index d20d489841c8..05ecfd8a3314 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -39,18 +39,19 @@ enum timekeeping_adv_mode {
TK_ADV_FREQ
 };
 
+static DEFINE_RAW_SPINLOCK(timekeeper_lock);
+
 /*
  * The most important data for readout fits into a single 64 byte
  * cache line.
  */
 static struct {
-   seqcount_t  seq;
+   seqcount_raw_spinlock_t seq;
struct timekeeper   timekeeper;
 } tk_core cacheline_aligned = {
-   .seq = SEQCNT_ZERO(tk_core.seq),
+   .seq = SEQCNT_RAW_SPINLOCK_ZERO(tk_core.seq, &timekeeper_lock),
 };
 
-static DEFINE_RAW_SPINLOCK(timekeeper_lock);
 static struct timekeeper shadow_timekeeper;
 
 /**
@@ -63,7 +64,7 @@ static struct timekeeper shadow_timekeeper;
  * See @update_fast_timekeeper() below.
  */
 struct tk_fast {
-   seqcount_t  seq;
+   seqcount_raw_spinlock_t seq;
struct tk_read_base base[2];
 };
 
@@ -80,11 +81,13 @@ static struct clocksource dummy_clock = {
 };
 
 static struct tk_fast tk_fast_mono cacheline_aligned = {
+   .seq = SEQCNT_RAW_SPINLOCK_ZERO(tk_fast_mono.seq, &timekeeper_lock),
.base[0] = { .clock = &dummy_clock, },
.base[1] = { .clock = &dummy_clock, },
 };
 
 static struct tk_fast tk_fast_raw  cacheline_aligned = {
+   .seq = SEQCNT_RAW_SPINLOCK_ZERO(tk_fast_raw.seq, &timekeeper_lock),
.base[0] = { .clock = &dummy_clock, },
.base[1] = { .clock = &dummy_clock, },
 };
@@ -157,7 +160,7 @@ static inline void tk_update_sleep_time(struct timekeeper 
*tk, ktime_t delta)
  * tk_clock_read - atomic clocksource read() helper
  *
  * This helper is necessary to use in the read paths because, while the
- * seqlock ensures we don't return a bad value while structures are updated,
+ * seqcount ensures we don't return a bad value while structures are updated,
  * it doesn't protect from potential crashes. There is the possibility that
  * the tkr's clocksource may change between the read reference, and the
  * clock reference passed to the read function.  This can cause crashes if
@@ -222,10 +225,10 @@ static inline u64 timekeeping_get_delta(const struct 
tk_read_base *tkr)
unsigned int seq;
 
/*
-* Since we're called holding a seqlock, the data may shift
+* Since we're called holding a seqcount, the data may shift
 * under us while we're doing the calculation. This can cause
 * false positives, since we'd note a problem but throw the
-* results away. So nest another seqlock here to atomically
+* results away. So nest another seqcount here to atomically
 * grab the points we are checking with.
 */
do {
@@ -486,7 +489,7 @@ EXPORT_SYMBOL_GPL(ktime_get_raw_fast_ns);
  *
  * To keep it NMI safe since we're accessing from tracing, we're not using a
  * separate timekeeper with updates to monotonic clock and boot offset
- * protected with seqlocks. This has the following minor side effects:
+ * protected with seqcounts. This has the following minor side effects:
  *
  * (1) Its possible that a timestamp be taken after the boot offset is updated
  * but before the timekeeper is updated. If this happens, the new boot offset
-- 
2.20.1

[PATCH v3 11/20] netfilter: nft_set_rbtree: Use sequence counter with associated rwlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_rwlock_t data type, which allows to associate a
rwlock with the sequence counter. This enables lockdep to verify that
the rwlock used for writer serialization is held when the write side
critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 net/netfilter/nft_set_rbtree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index 62f416bc0579..9f58261ee4c7 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -18,7 +18,7 @@
 struct nft_rbtree {
struct rb_root  root;
rwlock_tlock;
-   seqcount_t  count;
+   seqcount_rwlock_t   count;
struct delayed_work gc_work;
 };
 
@@ -516,7 +516,7 @@ static int nft_rbtree_init(const struct nft_set *set,
struct nft_rbtree *priv = nft_set_priv(set);
 
rwlock_init(&priv->lock);
-   seqcount_init(&priv->count);
+   seqcount_rwlock_init(&priv->count, &priv->lock);
priv->root = RB_ROOT;
 
INIT_DEFERRABLE_WORK(&priv->gc_work, nft_rbtree_gc);
-- 
2.20.1

[PATCH v3 16/20] iocost: Use sequence counter with associated spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_spinlock_t data type, which allows to associate a
spinlock with the sequence counter. This enables lockdep to verify that
the spinlock used for writer serialization is held when the write side
critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 block/blk-iocost.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/block/blk-iocost.c b/block/blk-iocost.c
index 8ac4aad66ebc..8e940c27c27c 100644
--- a/block/blk-iocost.c
+++ b/block/blk-iocost.c
@@ -406,7 +406,7 @@ struct ioc {
enum ioc_runningrunning;
atomic64_t  vtime_rate;
 
-   seqcount_t  period_seqcount;
+   seqcount_spinlock_t period_seqcount;
u32 period_at;  /* wallclock starttime 
*/
u64 period_at_vtime; /* vtime starttime */
 
@@ -873,7 +873,6 @@ static void ioc_now(struct ioc *ioc, struct ioc_now *now)
 
 static void ioc_start_period(struct ioc *ioc, struct ioc_now *now)
 {
-   lockdep_assert_held(&ioc->lock);
WARN_ON_ONCE(ioc->running != IOC_RUNNING);
 
write_seqcount_begin(&ioc->period_seqcount);
@@ -2001,7 +2000,7 @@ static int blk_iocost_init(struct request_queue *q)
 
ioc->running = IOC_IDLE;
atomic64_set(&ioc->vtime_rate, VTIME_PER_USEC);
-   seqcount_init(&ioc->period_seqcount);
+   seqcount_spinlock_init(&ioc->period_seqcount, &ioc->lock);
ioc->period_at = ktime_to_us(ktime_get());
atomic64_set(&ioc->cur_period, 0);
atomic_set(&ioc->hweight_gen, 0);
-- 
2.20.1

[PATCH v3 19/20] kvm/eventfd: Use sequence counter with associated spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_spinlock_t data type, which allows to associate a
spinlock with the sequence counter. This enables lockdep to verify that
the spinlock used for writer serialization is held when the write side
critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
Acked-by: Paolo Bonzini 
---
 include/linux/kvm_irqfd.h | 2 +-
 virt/kvm/eventfd.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/kvm_irqfd.h b/include/linux/kvm_irqfd.h
index dc1da020305b..dac047abdba7 100644
--- a/include/linux/kvm_irqfd.h
+++ b/include/linux/kvm_irqfd.h
@@ -42,7 +42,7 @@ struct kvm_kernel_irqfd {
wait_queue_entry_t wait;
/* Update side is protected by irqfds.lock */
struct kvm_kernel_irq_routing_entry irq_entry;
-   seqcount_t irq_entry_sc;
+   seqcount_spinlock_t irq_entry_sc;
/* Used for level IRQ fast-path */
int gsi;
struct work_struct inject;
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index ef7ed916ad4a..d6408bb497dc 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -303,7 +303,7 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
INIT_LIST_HEAD(&irqfd->list);
INIT_WORK(&irqfd->inject, irqfd_inject);
INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
-   seqcount_init(&irqfd->irq_entry_sc);
+   seqcount_spinlock_init(&irqfd->irq_entry_sc, &kvm->irqfds.lock);
 
f = fdget(args->fd);
if (!f.file) {
-- 
2.20.1

[PATCH v3 18/20] userfaultfd: Use sequence counter with associated spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_spinlock_t data type, which allows to associate a
spinlock with the sequence counter. This enables lockdep to verify that
the spinlock used for writer serialization is held when the write side
critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 fs/userfaultfd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
index 52de29000c7e..26e8b23594fb 100644
--- a/fs/userfaultfd.c
+++ b/fs/userfaultfd.c
@@ -61,7 +61,7 @@ struct userfaultfd_ctx {
/* waitqueue head for events */
wait_queue_head_t event_wqh;
/* a refile sequence protected by fault_pending_wqh lock */
-   struct seqcount refile_seq;
+   seqcount_spinlock_t refile_seq;
/* pseudo fd refcounting */
refcount_t refcount;
/* userfaultfd syscall flags */
@@ -1998,7 +1998,7 @@ static void init_once_userfaultfd_ctx(void *mem)
init_waitqueue_head(&ctx->fault_wqh);
init_waitqueue_head(&ctx->event_wqh);
init_waitqueue_head(&ctx->fd_wqh);
-   seqcount_init(&ctx->refile_seq);
+   seqcount_spinlock_init(&ctx->refile_seq, &ctx->fault_pending_wqh.lock);
 }
 
 SYSCALL_DEFINE1(userfaultfd, int, flags)
-- 
2.20.1

[PATCH v3 14/20] vfs: Use sequence counter with associated spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_spinlock_t data type, which allows to associate a
spinlock with the sequence counter. This enables lockdep to verify that
the spinlock used for writer serialization is held when the write side
critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 fs/dcache.c   | 2 +-
 fs/fs_struct.c| 4 ++--
 include/linux/dcache.h| 2 +-
 include/linux/fs_struct.h | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index 361ea7ab30ea..ea0485861d93 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1746,7 +1746,7 @@ static struct dentry *__d_alloc(struct super_block *sb, 
const struct qstr *name)
dentry->d_lockref.count = 1;
dentry->d_flags = 0;
spin_lock_init(&dentry->d_lock);
-   seqcount_init(&dentry->d_seq);
+   seqcount_spinlock_init(&dentry->d_seq, &dentry->d_lock);
dentry->d_inode = NULL;
dentry->d_parent = dentry;
dentry->d_sb = sb;
diff --git a/fs/fs_struct.c b/fs/fs_struct.c
index ca639ed967b7..04b3f5b9c629 100644
--- a/fs/fs_struct.c
+++ b/fs/fs_struct.c
@@ -117,7 +117,7 @@ struct fs_struct *copy_fs_struct(struct fs_struct *old)
fs->users = 1;
fs->in_exec = 0;
spin_lock_init(&fs->lock);
-   seqcount_init(&fs->seq);
+   seqcount_spinlock_init(&fs->seq, &fs->lock);
fs->umask = old->umask;
 
spin_lock(&old->lock);
@@ -163,6 +163,6 @@ EXPORT_SYMBOL(current_umask);
 struct fs_struct init_fs = {
.users  = 1,
.lock   = __SPIN_LOCK_UNLOCKED(init_fs.lock),
-   .seq= SEQCNT_ZERO(init_fs.seq),
+   .seq= SEQCNT_SPINLOCK_ZERO(init_fs.seq, &init_fs.lock),
.umask  = 0022,
 };
diff --git a/include/linux/dcache.h b/include/linux/dcache.h
index a81f0c3cf352..65d975bf9390 100644
--- a/include/linux/dcache.h
+++ b/include/linux/dcache.h
@@ -89,7 +89,7 @@ extern struct dentry_stat_t dentry_stat;
 struct dentry {
/* RCU lookup touched fields */
unsigned int d_flags;   /* protected by d_lock */
-   seqcount_t d_seq;   /* per dentry seqlock */
+   seqcount_spinlock_t d_seq;  /* per dentry seqlock */
struct hlist_bl_node d_hash;/* lookup hash list */
struct dentry *d_parent;/* parent directory */
struct qstr d_name;
diff --git a/include/linux/fs_struct.h b/include/linux/fs_struct.h
index cf1015abfbf2..783b48dedb72 100644
--- a/include/linux/fs_struct.h
+++ b/include/linux/fs_struct.h
@@ -9,7 +9,7 @@
 struct fs_struct {
int users;
spinlock_t lock;
-   seqcount_t seq;
+   seqcount_spinlock_t seq;
int umask;
int in_exec;
struct path root, pwd;
-- 
2.20.1

[PATCH v3 07/20] dma-buf: Remove custom seqcount lockdep class key

[Ahmed S. Darwish]

Commit 3c3b177a9369 ("reservation: add support for read-only access
using rcu") introduced a sequence counter to manage updates to
reservations. Back then, the reservation object initializer
reservation_object_init() was always inlined.

Having the sequence counter initialization inlined meant that each of
the call sites would have a different lockdep class key, which would've
broken lockdep's deadlock detection. The aforementioned commit thus
introduced, and exported, a custom seqcount lockdep class key and name.

The commit 8735f16803f00 ("dma-buf: cleanup reservation_object_init...")
transformed the reservation object initializer to a normal non-inlined C
function. seqcount_init(), which automatically defines the seqcount
lockdep class key and must be called non-inlined, can now be safely used.

Remove the seqcount custom lockdep class key, name, and export. Use
seqcount_init() inside the dma reservation object initializer.

Signed-off-by: Ahmed S. Darwish 
Reviewed-by: Sebastian Andrzej Siewior 
Acked-by: Daniel Vetter 
---
 drivers/dma-buf/dma-resv.c | 9 +
 include/linux/dma-resv.h   | 2 --
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index b45f8514dc82..15efa0c2dacb 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -51,12 +51,6 @@
 DEFINE_WD_CLASS(reservation_ww_class);
 EXPORT_SYMBOL(reservation_ww_class);
 
-struct lock_class_key reservation_seqcount_class;
-EXPORT_SYMBOL(reservation_seqcount_class);
-
-const char reservation_seqcount_string[] = "reservation_seqcount";
-EXPORT_SYMBOL(reservation_seqcount_string);
-
 /**
  * dma_resv_list_alloc - allocate fence list
  * @shared_max: number of fences we need space for
@@ -135,9 +129,8 @@ subsys_initcall(dma_resv_lockdep);
 void dma_resv_init(struct dma_resv *obj)
 {
ww_mutex_init(&obj->lock, &reservation_ww_class);
+   seqcount_init(&obj->seq);
 
-   __seqcount_init(&obj->seq, reservation_seqcount_string,
-   &reservation_seqcount_class);
RCU_INIT_POINTER(obj->fence, NULL);
RCU_INIT_POINTER(obj->fence_excl, NULL);
 }
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index ee50d10f052b..a6538ae7d93f 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -46,8 +46,6 @@
 #include 
 
 extern struct ww_class reservation_ww_class;
-extern struct lock_class_key reservation_seqcount_class;
-extern const char reservation_seqcount_string[];
 
 /**
  * struct dma_resv_list - a list of shared fences
-- 
2.20.1

[PATCH v3 05/20] seqlock: lockdep assert non-preemptibility on seqcount_t write

[Ahmed S. Darwish]

Preemption must be disabled before entering a sequence count write side
critical section.  Failing to do so, the seqcount read side can preempt
the write side section and spin for the entire scheduler tick.  If that
reader belongs to a real-time scheduling class, it can spin forever and
the kernel will livelock.

Assert through lockdep that preemption is disabled for seqcount writers.

Signed-off-by: Ahmed S. Darwish 
---
 include/linux/seqlock.h | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index 057f7326a877..679c440b17fe 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -419,12 +419,29 @@ static inline void raw_write_seqcount_latch(seqcount_t *s)
smp_wmb();  /* increment "sequence" before following stores */
 }
 
-static inline void write_seqcount_begin_nested(seqcount_t *s, int subclass)
+static inline void __write_seqcount_begin_nested(seqcount_t *s, int subclass)
 {
raw_write_seqcount_begin(s);
seqcount_acquire(&s->dep_map, subclass, 0, _RET_IP_);
 }
 
+static inline void write_seqcount_begin_nested(seqcount_t *s, int subclass)
+{
+   lockdep_assert_preemption_disabled();
+   __write_seqcount_begin_nested(s, subclass);
+}
+
+/*
+ * write_seqcount_begin() without lockdep non-preemptibility checks.
+ *
+ * Use for internal seqlock.h code where it's known that preemption is
+ * already disabled. For example, seqlock_t write side functions.
+ */
+static inline void __write_seqcount_begin(seqcount_t *s)
+{
+   __write_seqcount_begin_nested(s, 0);
+}
+
 /**
  * write_seqcount_begin() - start a seqcount_t write-side critical section
  * @s: Pointer to &typedef seqcount_t
@@ -563,7 +580,7 @@ static inline unsigned read_seqretry(const seqlock_t *sl, 
unsigned start)
 static inline void write_seqlock(seqlock_t *sl)
 {
spin_lock(&sl->lock);
-   write_seqcount_begin(&sl->seqcount);
+   __write_seqcount_begin(&sl->seqcount);
 }
 
 /**
@@ -591,7 +608,7 @@ static inline void write_sequnlock(seqlock_t *sl)
 static inline void write_seqlock_bh(seqlock_t *sl)
 {
spin_lock_bh(&sl->lock);
-   write_seqcount_begin(&sl->seqcount);
+   __write_seqcount_begin(&sl->seqcount);
 }
 
 /**
@@ -618,7 +635,7 @@ static inline void write_sequnlock_bh(seqlock_t *sl)
 static inline void write_seqlock_irq(seqlock_t *sl)
 {
spin_lock_irq(&sl->lock);
-   write_seqcount_begin(&sl->seqcount);
+   __write_seqcount_begin(&sl->seqcount);
 }
 
 /**
@@ -639,7 +656,7 @@ static inline unsigned long 
__write_seqlock_irqsave(seqlock_t *sl)
unsigned long flags;
 
spin_lock_irqsave(&sl->lock, flags);
-   write_seqcount_begin(&sl->seqcount);
+   __write_seqcount_begin(&sl->seqcount);
return flags;
 }
 
-- 
2.20.1

[PATCH v3 09/20] sched: tasks: Use sequence counter with associated spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_spinlock_t data type, which allows to associate a
spinlock with the sequence counter. This enables lockdep to verify that
the spinlock used for writer serialization is held when the write side
critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 include/linux/sched.h | 2 +-
 init/init_task.c  | 3 ++-
 kernel/fork.c | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 03403ca6e44e..1b4e6b8dc523 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1055,7 +1055,7 @@ struct task_struct {
/* Protected by ->alloc_lock: */
nodemask_t  mems_allowed;
/* Seqence number to catch updates: */
-   seqcount_t  mems_allowed_seq;
+   seqcount_spinlock_t mems_allowed_seq;
int cpuset_mem_spread_rotor;
int cpuset_slab_spread_rotor;
 #endif
diff --git a/init/init_task.c b/init/init_task.c
index 15089d15010a..94fe3ba1bb60 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -154,7 +154,8 @@ struct task_struct init_task
.trc_holdout_list = LIST_HEAD_INIT(init_task.trc_holdout_list),
 #endif
 #ifdef CONFIG_CPUSETS
-   .mems_allowed_seq = SEQCNT_ZERO(init_task.mems_allowed_seq),
+   .mems_allowed_seq = SEQCNT_SPINLOCK_ZERO(init_task.mems_allowed_seq,
+&init_task.alloc_lock),
 #endif
 #ifdef CONFIG_RT_MUTEXES
.pi_waiters = RB_ROOT_CACHED,
diff --git a/kernel/fork.c b/kernel/fork.c
index f44d70307210..eb260c6bdb8b 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2032,7 +2032,7 @@ static __latent_entropy struct task_struct *copy_process(
 #ifdef CONFIG_CPUSETS
p->cpuset_mem_spread_rotor = NUMA_NO_NODE;
p->cpuset_slab_spread_rotor = NUMA_NO_NODE;
-   seqcount_init(&p->mems_allowed_seq);
+   seqcount_spinlock_init(&p->mems_allowed_seq, &p->alloc_lock);
 #endif
 #ifdef CONFIG_TRACE_IRQFLAGS
p->irq_events = 0;
-- 
2.20.1

[PATCH v3 10/20] netfilter: conntrack: Use sequence counter with associated spinlock

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. A plain seqcount_t does not
contain the information of which lock must be held when entering a write
side critical section.

Use the new seqcount_spinlock_t data type, which allows to associate a
spinlock with the sequence counter. This enables lockdep to verify that
the spinlock used for writer serialization is held when the write side
critical section is entered.

If lockdep is disabled this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 include/net/netfilter/nf_conntrack.h | 2 +-
 net/netfilter/nf_conntrack_core.c| 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/net/netfilter/nf_conntrack.h 
b/include/net/netfilter/nf_conntrack.h
index 90690e37a56f..ea4e2010b246 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -286,7 +286,7 @@ int nf_conntrack_hash_resize(unsigned int hashsize);
 
 extern struct hlist_nulls_head *nf_conntrack_hash;
 extern unsigned int nf_conntrack_htable_size;
-extern seqcount_t nf_conntrack_generation;
+extern seqcount_spinlock_t nf_conntrack_generation;
 extern unsigned int nf_conntrack_max;
 
 /* must be called with rcu read lock held */
diff --git a/net/netfilter/nf_conntrack_core.c 
b/net/netfilter/nf_conntrack_core.c
index 79cd9dde457b..b8c54d390f93 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -180,7 +180,7 @@ EXPORT_SYMBOL_GPL(nf_conntrack_htable_size);
 
 unsigned int nf_conntrack_max __read_mostly;
 EXPORT_SYMBOL_GPL(nf_conntrack_max);
-seqcount_t nf_conntrack_generation __read_mostly;
+seqcount_spinlock_t nf_conntrack_generation __read_mostly;
 static unsigned int nf_conntrack_hash_rnd __read_mostly;
 
 static u32 hash_conntrack_raw(const struct nf_conntrack_tuple *tuple,
@@ -2598,7 +2598,8 @@ int nf_conntrack_init_start(void)
/* struct nf_ct_ext uses u8 to store offsets/size */
BUILD_BUG_ON(total_extension_size() > 255u);
 
-   seqcount_init(&nf_conntrack_generation);
+   seqcount_spinlock_init(&nf_conntrack_generation,
+  &nf_conntrack_locks_all_lock);
 
for (i = 0; i < CONNTRACK_LOCKS; i++)
spin_lock_init(&nf_conntrack_locks[i]);
-- 
2.20.1

[PATCH v3 01/20] Documentation: locking: Describe seqlock design and usage

[Ahmed S. Darwish]

Proper documentation for the design and usage of sequence counters and
sequential locks does not exist. Complete the seqlock.h documentation as
follows:

  - Divide all documentation on a seqcount_t vs. seqlock_t basis. The
description for both mechanisms was intermingled, which is incorrect
since the usage constrains for each type are vastly different.

  - Add an introductory paragraph describing the internal design of, and
rationale for, sequence counters.

  - Document seqcount_t writer non-preemptibility requirement, which was
not previously documented anywhere, and provide a clear rationale.

  - Provide template code for seqcount_t and seqlock_t initialization
and reader/writer critical sections.

  - Recommend using seqlock_t by default. It implicitly handles the
serialization and non-preemptibility requirements of writers.

At seqlock.h:

  - Remove references to brlocks as they've long been removed from the
kernel.

  - Remove references to gcc-3.x since the kernel's minimum supported
gcc version is 4.6.

References: 0f6ed63b1707 ("no need to keep brlock macros anymore...")
References: cafa0010cd51 ("Raise the minimum required gcc version to 4.6")
Signed-off-by: Ahmed S. Darwish 
---
 Documentation/locking/index.rst   |   1 +
 Documentation/locking/seqlock.rst | 184 ++
 include/linux/seqlock.h   |  77 ++---
 3 files changed, 221 insertions(+), 41 deletions(-)
 create mode 100644 Documentation/locking/seqlock.rst

diff --git a/Documentation/locking/index.rst b/Documentation/locking/index.rst
index d785878cad65..7003bd5aeff4 100644
--- a/Documentation/locking/index.rst
+++ b/Documentation/locking/index.rst
@@ -14,6 +14,7 @@ locking
 mutex-design
 rt-mutex-design
 rt-mutex
+seqlock
 spinlocks
 ww-mutex-design
 preempt-locking
diff --git a/Documentation/locking/seqlock.rst 
b/Documentation/locking/seqlock.rst
new file mode 100644
index ..c9916efe038e
--- /dev/null
+++ b/Documentation/locking/seqlock.rst
@@ -0,0 +1,184 @@
+==
+Sequence counters and sequential locks
+==
+
+Introduction
+
+
+Sequence counters are a reader-writer consistency mechanism with
+lockless readers (read-only retry loops), and no writer starvation. They
+are used for data that's rarely written to (e.g. system time), where the
+reader wants a consistent set of information and is willing to retry if
+that information changes.
+
+A data set is consistent when the sequence count at the beginning of the
+read side critical section is even and the same sequence count value is
+read again at the end of the critical section. The data in the set must
+be copied out inside the read side critical section. If the sequence
+count has changed between the start and the end of the critical section,
+the reader must retry.
+
+Writers increment the sequence count at the start and the end of their
+critical section. After starting the critical section the sequence count
+is odd and indicates to the readers that an update is in progress. At
+the end of the write side critical section the sequence count becomes
+even again which lets readers make progress.
+
+A sequence counter write side critical section must never be preempted
+or interrupted by read side sections. Otherwise the reader will spin for
+the entire scheduler tick due to the odd sequence count value and the
+interrupted writer. If that reader belongs to a real-time scheduling
+class, it can spin forever and the kernel will livelock.
+
+This mechanism cannot be used if the protected data contains pointers,
+as the writer can invalidate a pointer that the reader is following.
+
+.. _seqcount_t:
+
+Sequence counters (:c:type:`seqcount_t`)
+
+
+This is the the raw counting mechanism, which does not protect against
+multiple writers.  Write side critical sections must thus be serialized
+by an external lock.
+
+If the write serialization primitive is not implicitly disabling
+preemption, preemption must be explicitly disabled before entering the
+write side section. If the read section can be invoked from hardirq or
+softirq contexts, interrupts or bottom halves must also be respectively
+disabled before entering the write section.
+
+If it's desired to automatically handle the sequence counter
+requirements of writer serialization and non-preemptibility, use a
+:ref:`sequential lock ` instead.
+
+Initialization:
+
+.. code-block:: c
+
+   /* dynamic */
+   seqcount_t foo_seqcount;
+   seqcount_init(&foo_seqcount);
+
+   /* static */
+   static seqcount_t foo_seqcount = SEQCNT_ZERO(foo_seqcount);
+
+   /* C99 struct init */
+   struct {
+   .seq   = SEQCNT_ZERO(foo.seq),
+   } foo;
+
+Write path:
+
+.. code-block:: c
+
+   /* Serialized context with disabled preemption */
+
+   write_seqcount_begin(&foo_

[PATCH v3 04/20] lockdep: Add preemption enabled/disabled assertion APIs

[Ahmed S. Darwish]

Asserting that preemption is enabled or disabled is a critical sanity
check.  Developers are usually reluctant to add such a check in a
fastpath as reading the preemption count can be costly.

Extend the lockdep API with macros asserting that preemption is disabled
or enabled. If lockdep is disabled, or if the underlying architecture
does not support kernel preemption, this assert has no runtime overhead.

References: f54bb2ec02c8 ("locking/lockdep: Add IRQs disabled/enabled assertion 
APIs: ...")
Signed-off-by: Ahmed S. Darwish 
---
 include/linux/lockdep.h | 18 ++
 lib/Kconfig.debug   |  1 +
 2 files changed, 19 insertions(+)

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index fd04b9e96091..53eff6b26fac 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -548,6 +548,22 @@ do {   
\
WARN_ON_ONCE(debug_locks && !this_cpu_read(hardirq_context));   \
 } while (0)
 
+#define lockdep_assert_preemption_enabled()\
+do {   \
+   WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)   &&  \
+debug_locks&&  \
+(preempt_count() != 0  ||  \
+ !this_cpu_read(hardirqs_enabled)));   \
+} while (0)
+
+#define lockdep_assert_preemption_disabled()   \
+do {   \
+   WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_COUNT)   &&  \
+debug_locks&&  \
+(preempt_count() == 0  &&  \
+ this_cpu_read(hardirqs_enabled)));\
+} while (0)
+
 #else
 # define might_lock(lock) do { } while (0)
 # define might_lock_read(lock) do { } while (0)
@@ -556,6 +572,8 @@ do {
\
 # define lockdep_assert_irqs_enabled() do { } while (0)
 # define lockdep_assert_irqs_disabled() do { } while (0)
 # define lockdep_assert_in_irq() do { } while (0)
+# define lockdep_assert_preemption_enabled() do { } while (0)
+# define lockdep_assert_preemption_disabled() do { } while (0)
 #endif
 
 #ifdef CONFIG_PROVE_RAW_LOCK_NESTING
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index d74ac0fd6b2d..e5e2e632b749 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1118,6 +1118,7 @@ config PROVE_LOCKING
select DEBUG_RWSEMS
select DEBUG_WW_MUTEX_SLOWPATH
select DEBUG_LOCK_ALLOC
+   select PREEMPT_COUNT if !ARCH_NO_PREEMPT
select TRACE_IRQFLAGS
default n
help
-- 
2.20.1

[PATCH v3 08/20] dma-buf: Use sequence counter with associated wound/wait mutex

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. If the serialization primitive is
not disabling preemption implicitly, preemption has to be explicitly
disabled before entering the sequence counter write side critical
section.

The dma-buf reservation subsystem uses plain sequence counters to manage
updates to reservations. Writer serialization is accomplished through a
wound/wait mutex.

Acquiring a wound/wait mutex does not disable preemption, so this needs
to be done manually before and after the write side critical section.

Use the newly-added seqcount_ww_mutex_t instead:

  - It associates the ww_mutex with the sequence count, which enables
lockdep to validate that the write side critical section is properly
serialized.

  - It removes the need to explicitly add preempt_disable/enable()
around the write side critical section because the write_begin/end()
functions for this new data type automatically do this.

If lockdep is disabled this ww_mutex lock association is compiled out
and has neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
Acked-by: Daniel Vetter 
---
 drivers/dma-buf/dma-resv.c   | 8 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 2 --
 include/linux/dma-resv.h | 2 +-
 3 files changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 15efa0c2dacb..a7631352a486 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -129,7 +129,7 @@ subsys_initcall(dma_resv_lockdep);
 void dma_resv_init(struct dma_resv *obj)
 {
ww_mutex_init(&obj->lock, &reservation_ww_class);
-   seqcount_init(&obj->seq);
+   seqcount_ww_mutex_init(&obj->seq, &obj->lock);
 
RCU_INIT_POINTER(obj->fence, NULL);
RCU_INIT_POINTER(obj->fence_excl, NULL);
@@ -260,7 +260,6 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct 
dma_fence *fence)
fobj = dma_resv_get_list(obj);
count = fobj->shared_count;
 
-   preempt_disable();
write_seqcount_begin(&obj->seq);
 
for (i = 0; i < count; ++i) {
@@ -282,7 +281,6 @@ void dma_resv_add_shared_fence(struct dma_resv *obj, struct 
dma_fence *fence)
smp_store_mb(fobj->shared_count, count);
 
write_seqcount_end(&obj->seq);
-   preempt_enable();
dma_fence_put(old);
 }
 EXPORT_SYMBOL(dma_resv_add_shared_fence);
@@ -309,14 +307,12 @@ void dma_resv_add_excl_fence(struct dma_resv *obj, struct 
dma_fence *fence)
if (fence)
dma_fence_get(fence);
 
-   preempt_disable();
write_seqcount_begin(&obj->seq);
/* write_seqcount_begin provides the necessary memory barrier */
RCU_INIT_POINTER(obj->fence_excl, fence);
if (old)
old->shared_count = 0;
write_seqcount_end(&obj->seq);
-   preempt_enable();
 
/* inplace update, no shared fences */
while (i--)
@@ -394,13 +390,11 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct 
dma_resv *src)
src_list = dma_resv_get_list(dst);
old = dma_resv_get_excl(dst);
 
-   preempt_disable();
write_seqcount_begin(&dst->seq);
/* write_seqcount_begin provides the necessary memory barrier */
RCU_INIT_POINTER(dst->fence_excl, new);
RCU_INIT_POINTER(dst->fence, dst_list);
write_seqcount_end(&dst->seq);
-   preempt_enable();
 
dma_resv_list_free(src_list);
dma_fence_put(old);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index b91b5171270f..ff4b583cb96a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -258,11 +258,9 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct 
amdgpu_bo *bo,
new->shared_count = k;
 
/* Install the new fence list, seqcount provides the barriers */
-   preempt_disable();
write_seqcount_begin(&resv->seq);
RCU_INIT_POINTER(resv->fence, new);
write_seqcount_end(&resv->seq);
-   preempt_enable();
 
/* Drop the references to the removed fences or move them to ef_list */
for (i = j, k = 0; i < old->shared_count; ++i) {
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index a6538ae7d93f..d44a77e8a7e3 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -69,7 +69,7 @@ struct dma_resv_list {
  */
 struct dma_resv {
struct ww_mutex lock;
-   seqcount_t seq;
+   seqcount_ww_mutex_t seq;
 
struct dma_fence __rcu *fence_excl;
struct dma_resv_list __rcu *fence;
-- 
2.20.1

[PATCH v3 06/20] seqlock: Extend seqcount API with associated locks

[Ahmed S. Darwish]

A sequence counter write side critical section must be protected by some
form of locking to serialize writers. If the serialization primitive is
not disabling preemption implicitly, preemption has to be explicitly
disabled before entering the write side critical section.

There is no built-in debugging mechanism to verify that the lock used
for writer serialization is held and preemption is disabled. Some usage
sites like dma-buf have explicit lockdep checks for the writer-side
lock, but this covers only a small portion of the sequence counter usage
in the kernel.

Add new sequence counter types which allows to associate a lock to the
sequence counter at initialization time. The seqcount API functions are
extended to provide appropriate lockdep assertions depending on the
seqcount/lock type.

For sequence counters with associated locks that do not implicitly
disable preemption, preemption protection is enforced in the sequence
counter write side functions. This removes the need to explicitly add
preempt_disable/enable() around the write side critical sections: the
write_begin/end() functions for these new sequence counter types
automatically do this.

Introduce the following seqcount types with associated locks:

 seqcount_spinlock_t
 seqcount_raw_spinlock_t
 seqcount_rwlock_t
 seqcount_mutex_t
 seqcount_ww_mutex_t

Extend the seqcount read and write functions to branch out to the
specific seqcount_LOCKTYPE_t implementation at compile-time. This avoids
kernel API explosion per each new seqcount_LOCKTYPE_t added. Add such
compile-time type detection logic into a new, internal, seqlock header.

Document the proper seqcount_LOCKTYPE_t usage, and rationale, at
Documentation/locking/seqlock.rst.

If lockdep is disabled, this lock association is compiled out and has
neither storage size nor runtime overhead.

Signed-off-by: Ahmed S. Darwish 
---
 Documentation/locking/seqlock.rst  |  64 -
 MAINTAINERS|   2 +-
 include/linux/seqlock.h| 372 -
 include/linux/seqlock_types_internal.h | 186 +
 4 files changed, 558 insertions(+), 66 deletions(-)
 create mode 100644 include/linux/seqlock_types_internal.h

diff --git a/Documentation/locking/seqlock.rst 
b/Documentation/locking/seqlock.rst
index c9916efe038e..2d526dc95408 100644
--- a/Documentation/locking/seqlock.rst
+++ b/Documentation/locking/seqlock.rst
@@ -48,9 +48,11 @@ write side section. If the read section can be invoked from 
hardirq or
 softirq contexts, interrupts or bottom halves must also be respectively
 disabled before entering the write section.
 
-If it's desired to automatically handle the sequence counter
-requirements of writer serialization and non-preemptibility, use a
-:ref:`sequential lock ` instead.
+If the write serialization mechanism is one of the common kernel locking
+primitives, use :ref:`sequence counters with associated locks
+` instead. If it's desired to automatically handle
+the sequence counter writer serialization and non-preemptibility
+requirements, use a :ref:`sequential lock `.
 
 Initialization:
 
@@ -70,6 +72,7 @@ Initialization:
 
 Write path:
 
+.. _seqcount_write_ops:
 .. code-block:: c
 
/* Serialized context with disabled preemption */
@@ -82,6 +85,7 @@ Write path:
 
 Read path:
 
+.. _seqcount_read_ops:
 .. code-block:: c
 
do {
@@ -91,6 +95,60 @@ Read path:
 
} while (read_seqcount_retry(&foo_seqcount, seq));
 
+.. _seqcount_locktype_t:
+
+Sequence counters with associated locks (:c:type:`seqcount_LOCKTYPE_t`)
+---
+
+As :ref:`earlier discussed `, seqcount write side critical
+sections must be serialized and non-preemptible. This variant of
+sequence counters associate the lock used for writer serialization at
+the seqcount initialization time. This enables lockdep to validate that
+the write side critical section is properly serialized.
+
+This lock association is a NOOP if lockdep is disabled and has neither
+storage nor runtime overhead. If lockdep is enabled, the lock pointer is
+stored in struct seqcount and lockdep's "lock is held" assertions are
+injected at the beginning of the write side critical section to validate
+that it is properly protected.
+
+For lock types which do not implicitly disable preemption, preemption
+protection is enforced in the write side function.
+
+The following seqcounts with associated locks are defined:
+
+  - :c:type:`seqcount_spinlock_t`
+  - :c:type:`seqcount_raw_spinlock_t`
+  - :c:type:`seqcount_rwlock_t`
+  - :c:type:`seqcount_mutex_t`
+  - :c:type:`seqcount_ww_mutex_t`
+
+The plain seqcount read and write APIs branch out to the specific
+seqcount_LOCKTYPE_t implementation at compile-time. This avoids kernel
+API explosion per each new seqcount LOCKTYPE.
+
+Initialization (replace "LOCKTYPE" with one of the supported locks):
+
+.. code-block:: c
+
+   /* dynamic */
+   seqc

[PATCH v3 03/20] seqlock: Add missing kernel-doc annotations

[Ahmed S. Darwish]

A small number of the the exported seqlock.h functions are kernel-doc
annotated.

Since seqlock.h is now included by the kernel's RST documentation, add
kernel-doc annotations for all of the remaining functions.

Signed-off-by: Ahmed S. Darwish 
---
 include/linux/seqlock.h | 398 ++--
 1 file changed, 339 insertions(+), 59 deletions(-)

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index d3bba59eb4df..057f7326a877 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -75,6 +75,10 @@ static inline void __seqcount_init(seqcount_t *s, const char 
*name,
 # define SEQCOUNT_DEP_MAP_INIT(lockname) \
.dep_map = { .name = #lockname } \
 
+/**
+ * seqcount_init() - runtime initializer for seqcount_t
+ * @s: Pointer to the &typedef seqcount_t instance
+ */
 # define seqcount_init(s)  \
do {\
static struct lock_class_key __key; \
@@ -98,13 +102,17 @@ static inline void seqcount_lockdep_reader_access(const 
seqcount_t *s)
 # define seqcount_lockdep_reader_access(x)
 #endif
 
-#define SEQCNT_ZERO(lockname) { .sequence = 0, SEQCOUNT_DEP_MAP_INIT(lockname)}
+/**
+ * SEQCNT_ZERO() - static initializer for seqcount_t
+ * @name: Name of the &typedef seqcount_t instance
+ */
+#define SEQCNT_ZERO(name) { .sequence = 0, SEQCOUNT_DEP_MAP_INIT(name) }
 
 
 /**
- * __read_seqcount_begin - begin a seq-read critical section (without barrier)
- * @s: pointer to seqcount_t
- * Returns: count to be passed to read_seqcount_retry
+ * __read_seqcount_begin() - begin a seqcount_t read section (without barrier)
+ * @s: Pointer to &typedef seqcount_t
+ * Returns: count to be passed to read_seqcount_retry()
  *
  * __read_seqcount_begin is like read_seqcount_begin, but has no smp_rmb()
  * barrier. Callers should ensure that smp_rmb() or equivalent ordering is
@@ -129,13 +137,14 @@ static inline unsigned __read_seqcount_begin(const 
seqcount_t *s)
 }
 
 /**
- * raw_read_seqcount - Read the raw seqcount
- * @s: pointer to seqcount_t
- * Returns: count to be passed to read_seqcount_retry
+ * raw_read_seqcount() - Read the seqcount_t raw counter value
+ * @s: Pointer to &typedef seqcount_t
+ * Returns: count to be passed to read_seqcount_retry()
  *
  * raw_read_seqcount opens a read critical section of the given
- * seqcount without any lockdep checking and without checking or
- * masking the LSB. Calling code is responsible for handling that.
+ * seqcount_t, without any lockdep checks and without checking or
+ * masking the sequence counter LSB. Calling code is responsible for
+ * handling that.
  */
 static inline unsigned raw_read_seqcount(const seqcount_t *s)
 {
@@ -146,13 +155,13 @@ static inline unsigned raw_read_seqcount(const seqcount_t 
*s)
 }
 
 /**
- * raw_read_seqcount_begin - start seq-read critical section w/o lockdep
- * @s: pointer to seqcount_t
- * Returns: count to be passed to read_seqcount_retry
+ * raw_read_seqcount_begin() - start a seqcount_t read section w/o lockdep
+ * @s: Pointer to &typedef seqcount_t
+ * Returns: count to be passed to read_seqcount_retry()
  *
  * raw_read_seqcount_begin opens a read critical section of the given
- * seqcount, but without any lockdep checking. Validity of the critical
- * section is tested by checking read_seqcount_retry function.
+ * seqcount_t, but without any lockdep checking. Validity of the read
+ * section must be checked with read_seqcount_retry().
  */
 static inline unsigned raw_read_seqcount_begin(const seqcount_t *s)
 {
@@ -162,13 +171,13 @@ static inline unsigned raw_read_seqcount_begin(const 
seqcount_t *s)
 }
 
 /**
- * read_seqcount_begin - begin a seq-read critical section
- * @s: pointer to seqcount_t
- * Returns: count to be passed to read_seqcount_retry
+ * read_seqcount_begin() - start a seqcount_t read critical section
+ * @s: Pointer to &typedef seqcount_t
+ * Returns: count to be passed to read_seqcount_retry()
  *
- * read_seqcount_begin opens a read critical section of the given seqcount.
- * Validity of the critical section is tested by checking read_seqcount_retry
- * function.
+ * read_seqcount_begin opens a read critical section of the given
+ * seqcount_t. Validity of the read section must be checked with
+ * read_seqcount_retry().
  */
 static inline unsigned read_seqcount_begin(const seqcount_t *s)
 {
@@ -177,11 +186,11 @@ static inline unsigned read_seqcount_begin(const 
seqcount_t *s)
 }
 
 /**
- * raw_seqcount_begin - begin a seq-read critical section
- * @s: pointer to seqcount_t
+ * raw_seqcount_begin() - begin a seq-read critical section
+ * @s: Pointer to &typedef seqcount_t
  * Returns: count to be passed to read_seqcount_retry
  *
- * raw_seqcount_begin opens a read critical section of the given seqcount.
+ * raw_seqcount_begin opens a read critical section of the given seqcount_t.
  * Validity of the critical section is tested by checking read_seqcount_retry
 

[PATCH v3 00/20] seqlock: Extend seqcount API with associated locks

[Ahmed S. Darwish]

Hi,

This is v3 of the seqlock patch series:

   [PATCH v1 00/25] seqlock: Extend seqcount API with associated locks
   https://lore.kernel.org/lkml/20200519214547.352050-1-a.darw...@linutronix.de

   [PATCH v2 00/18]
   https://lore.kernel.org/lkml/20200608005729.1874024-1-a.darw...@linutronix.de

It's based over:

   git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core

to get Peter's lockdep irqstate tracking series below, which untangles
mainline seqlock.h<=>sched.h 'current->' task_struct circular dependency:

   https://lkml.kernel.org/r/linuxppc-dev/20200623083645.277342...@infradead.org

Changelog-v3:

 - Re-add lockdep non-preemptibility checks on seqcount_t write paths.
   They were removed from v2 due to the circular dependencies mentioned.

 - Slight rebase over the new v5.8-rc1 KCSAN seqlock.h changes

 - Collect seqcount_t call-sites acked-by tags

Thanks,

8<--

Ahmed S. Darwish (20):
  Documentation: locking: Describe seqlock design and usage
  seqlock: Properly format kernel-doc code samples
  seqlock: Add missing kernel-doc annotations
  lockdep: Add preemption enabled/disabled assertion APIs
  seqlock: lockdep assert non-preemptibility on seqcount_t write
  seqlock: Extend seqcount API with associated locks
  dma-buf: Remove custom seqcount lockdep class key
  dma-buf: Use sequence counter with associated wound/wait mutex
  sched: tasks: Use sequence counter with associated spinlock
  netfilter: conntrack: Use sequence counter with associated spinlock
  netfilter: nft_set_rbtree: Use sequence counter with associated rwlock
  xfrm: policy: Use sequence counters with associated lock
  timekeeping: Use sequence counter with associated raw spinlock
  vfs: Use sequence counter with associated spinlock
  raid5: Use sequence counter with associated spinlock
  iocost: Use sequence counter with associated spinlock
  NFSv4: Use sequence counter with associated spinlock
  userfaultfd: Use sequence counter with associated spinlock
  kvm/eventfd: Use sequence counter with associated spinlock
  hrtimer: Use sequence counter with associated raw spinlock

 Documentation/locking/index.rst   |   1 +
 Documentation/locking/seqlock.rst | 242 +
 MAINTAINERS   |   2 +-
 block/blk-iocost.c|   5 +-
 drivers/dma-buf/dma-resv.c|  15 +-
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  |   2 -
 drivers/md/raid5.c|   2 +-
 drivers/md/raid5.h|   2 +-
 fs/dcache.c   |   2 +-
 fs/fs_struct.c|   4 +-
 fs/nfs/nfs4_fs.h  |   2 +-
 fs/nfs/nfs4state.c|   2 +-
 fs/userfaultfd.c  |   4 +-
 include/linux/dcache.h|   2 +-
 include/linux/dma-resv.h  |   4 +-
 include/linux/fs_struct.h |   2 +-
 include/linux/hrtimer.h   |   2 +-
 include/linux/kvm_irqfd.h |   2 +-
 include/linux/lockdep.h   |  18 +
 include/linux/sched.h |   2 +-
 include/linux/seqlock.h   | 872 ++
 include/linux/seqlock_types_internal.h| 186 
 include/net/netfilter/nf_conntrack.h  |   2 +-
 init/init_task.c  |   3 +-
 kernel/fork.c |   2 +-
 kernel/time/hrtimer.c |  13 +-
 kernel/time/timekeeping.c |  19 +-
 lib/Kconfig.debug |   1 +
 net/netfilter/nf_conntrack_core.c |   5 +-
 net/netfilter/nft_set_rbtree.c|   4 +-
 net/xfrm/xfrm_policy.c|  10 +-
 virt/kvm/eventfd.c|   2 +-
 32 files changed, 1211 insertions(+), 225 deletions(-)
 create mode 100644 Documentation/locking/seqlock.rst
 create mode 100644 include/linux/seqlock_types_internal.h

base-commit: 997e89fa345e9006f311cf9f9c8fd9f7d96c240f
--
2.20.1

[PATCH v3 02/20] seqlock: Properly format kernel-doc code samples

[Ahmed S. Darwish]

Align the code samples and note sections inside kernel-doc comments with
tabs. This way they can be properly parsed and rendered by Sphinx. It
also makes the code samples easier to read from text editors.

Signed-off-by: Ahmed S. Darwish 
---
 include/linux/seqlock.h | 82 +
 1 file changed, 43 insertions(+), 39 deletions(-)

diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index e54ff48e87f8..d3bba59eb4df 100644
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -256,7 +256,7 @@ static inline void raw_write_seqcount_end(seqcount_t *s)
  *
  * This can be used to provide an ordering guarantee instead of the
  * usual consistency guarantee. It is one wmb cheaper, because we can
- * collapse the two back-to-back wmb()s.
+ * collapse the two back-to-back wmb()s::
  *
  * Note that writes surrounding the barrier should be declared atomic (e.g.
  * via WRITE_ONCE): a) to ensure the writes become visible to other threads
@@ -325,64 +325,68 @@ static inline int raw_read_seqcount_latch(seqcount_t *s)
  * Very simply put: we first modify one copy and then the other. This ensures
  * there is always one copy in a stable state, ready to give us an answer.
  *
- * The basic form is a data structure like:
+ * The basic form is a data structure like::
  *
- * struct latch_struct {
- * seqcount_t  seq;
- * struct data_struct  data[2];
- * };
+ * struct latch_struct {
+ * seqcount_t  seq;
+ * struct data_struct  data[2];
+ * };
  *
  * Where a modification, which is assumed to be externally serialized, does the
- * following:
+ * following::
  *
- * void latch_modify(struct latch_struct *latch, ...)
- * {
- * smp_wmb();  <- Ensure that the last data[1] update is visible
- * latch->seq++;
- * smp_wmb();  <- Ensure that the seqcount update is visible
+ * void latch_modify(struct latch_struct *latch, ...)
+ * {
+ * smp_wmb();  // Ensure that the last data[1] update is 
visible
+ * latch->seq++;
+ * smp_wmb();  // Ensure that the seqcount update is visible
  *
- * modify(latch->data[0], ...);
+ * modify(latch->data[0], ...);
  *
- * smp_wmb();  <- Ensure that the data[0] update is visible
- * latch->seq++;
- * smp_wmb();  <- Ensure that the seqcount update is visible
+ * smp_wmb();  // Ensure that the data[0] update is visible
+ * latch->seq++;
+ * smp_wmb();  // Ensure that the seqcount update is visible
  *
- * modify(latch->data[1], ...);
- * }
+ * modify(latch->data[1], ...);
+ * }
  *
- * The query will have a form like:
+ * The query will have a form like::
  *
- * struct entry *latch_query(struct latch_struct *latch, ...)
- * {
- * struct entry *entry;
- * unsigned seq, idx;
+ * struct entry *latch_query(struct latch_struct *latch, ...)
+ * {
+ * struct entry *entry;
+ * unsigned seq, idx;
  *
- * do {
- * seq = raw_read_seqcount_latch(&latch->seq);
+ * do {
+ * seq = raw_read_seqcount_latch(&latch->seq);
  *
- * idx = seq & 0x01;
- * entry = data_query(latch->data[idx], ...);
+ * idx = seq & 0x01;
+ * entry = data_query(latch->data[idx], ...);
  *
- * smp_rmb();
- * } while (seq != latch->seq);
+ * smp_rmb();
+ * } while (seq != latch->seq);
  *
- * return entry;
- * }
+ * return entry;
+ * }
  *
  * So during the modification, queries are first redirected to data[1]. Then we
  * modify data[0]. When that is complete, we redirect queries back to data[0]
  * and we can modify data[1].
  *
- * NOTE: The non-requirement for atomic modifications does _NOT_ include
- *   the publishing of new entries in the case where data is a dynamic
- *   data structure.
+ * NOTE:
  *
- *   An iteration might start in data[0] and get suspended long enough
- *   to miss an entire modification sequence, once it resumes it might
- *   observe the new entry.
+ * The non-requirement for atomic modifications does _NOT_ include
+ * the publishing of new entries in the case where data is a dynamic
+ * data structure.
  *
- * NOTE: When data is a dynamic data structure; one should use regular RCU
- *   patterns to manage the lifetimes of the objects within.
+ * An iteration might start in data[0] and get suspended long enough
+ * to miss an entire modification sequence, once it resumes it might
+ * observe the new entry.
+ *
+ * NOTE:
+ *
+ * When data is a dynamic data structure; one should use regular RCU
+ * patterns to manage the lifetimes of the objects within.
  */
 static inline void raw_write_seqcount_latch(seqcount_t *s)
 {
-- 
2.20.1

Re: [PATCH v2 10/15] exec: Remove do_execve_file

[Christoph Hellwig]

FYI, this clashes badly with my exec rework.  I'd suggest you
drop everything touching exec here for now, and I can then
add the final file based exec removal to the end of my series.

Re: [PATCH] doc: cgroup: add f2fs and xfs to supported list for writeback

[Christoph Hellwig]

On Mon, Jun 29, 2020 at 02:08:09PM -0500, Eric Sandeen wrote:
> f2fs and xfs have both added support for cgroup writeback:
> 
> 578c647 f2fs: implement cgroup writeback support
> adfb5fb xfs: implement cgroup aware writeback
> 
> so add them to the supported list in the docs.
> 
> Signed-off-by: Eric Sandeen 
> ---
> 
> TBH I wonder about the wisdom of having this detail in
> the doc, as it apparently gets missed quite often ...

I'd rather remove the list of file systems.  It has no chance of
staying uptodate.

Re: [PATCH v3 1/2] remoteproc: Add remoteproc character device interface

[Siddharth Gupta]

On 6/17/2020 1:44 AM, Arnaud POULIQUEN wrote:


On 6/16/20 9:56 PM, risha...@codeaurora.org wrote:

On 2020-04-30 01:30, Arnaud POULIQUEN wrote:

Hi Rishabh,


On 4/21/20 8:10 PM, Rishabh Bhatnagar wrote:

Add the character device interface into remoteproc framework.
This interface can be used in order to boot/shutdown remote
subsystems and provides a basic ioctl based interface to implement
supplementary functionality. An ioctl call is implemented to enable
the shutdown on release feature which will allow remote processors to
be shutdown when the controlling userpsace application crashes or
hangs.


Thanks for intruducing Ioctl, this will help for future evolutions.


Signed-off-by: Rishabh Bhatnagar 
---
  Documentation/userspace-api/ioctl/ioctl-number.rst |   1 +
  drivers/remoteproc/Kconfig |   9 ++
  drivers/remoteproc/Makefile|   1 +
  drivers/remoteproc/remoteproc_cdev.c   | 143
+
  drivers/remoteproc/remoteproc_internal.h   |  21 +++
  include/linux/remoteproc.h |   3 +
  include/uapi/linux/remoteproc_cdev.h   |  20 +++
  7 files changed, 198 insertions(+)
  create mode 100644 drivers/remoteproc/remoteproc_cdev.c
  create mode 100644 include/uapi/linux/remoteproc_cdev.h

diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst
b/Documentation/userspace-api/ioctl/ioctl-number.rst
index 2e91370..412b2a0 100644
--- a/Documentation/userspace-api/ioctl/ioctl-number.rst
+++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
@@ -337,6 +337,7 @@ Code  Seq#Include File
   Comments
  0xB4  00-0F  linux/gpio.h

  0xB5  00-0F  uapi/linux/rpmsg.h

  0xB6  alllinux/fpga-dfl.h
+0xB7  alluapi/linux/remoteproc_cdev.h  

  0xC0  00-0F  linux/usb/iowarrior.h
  0xCA  00-0F  uapi/misc/cxl.h
  0xCA  10-2F  uapi/misc/ocxl.h
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index de3862c..6374b79 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -14,6 +14,15 @@ config REMOTEPROC

  if REMOTEPROC

+config REMOTEPROC_CDEV
+   bool "Remoteproc character device interface"
+   help
+ Say y here to have a character device interface for Remoteproc
+ framework. Userspace can boot/shutdown remote processors through
+ this interface.
+
+ It's safe to say N if you don't want to use this interface.
+
  config IMX_REMOTEPROC
tristate "IMX6/7 remoteproc support"
depends on ARCH_MXC
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index e30a1b1..b7d4f77 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -9,6 +9,7 @@ remoteproc-y+= remoteproc_debugfs.o
  remoteproc-y  += remoteproc_sysfs.o
  remoteproc-y  += remoteproc_virtio.o
  remoteproc-y  += remoteproc_elf_loader.o
+obj-$(CONFIG_REMOTEPROC_CDEV)  += remoteproc_cdev.o
  obj-$(CONFIG_IMX_REMOTEPROC)  += imx_rproc.o
  obj-$(CONFIG_MTK_SCP) += mtk_scp.o mtk_scp_ipi.o
  obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
diff --git a/drivers/remoteproc/remoteproc_cdev.c
b/drivers/remoteproc/remoteproc_cdev.c
new file mode 100644
index 000..65142ec
--- /dev/null
+++ b/drivers/remoteproc/remoteproc_cdev.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Character device interface driver for Remoteproc framework.
+ *
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define NUM_RPROC_DEVICES  64
+static dev_t rproc_major;
+
+static ssize_t rproc_cdev_write(struct file *filp, const char __user
*buf,
+size_t len, loff_t *pos)
+{
+   struct rproc *rproc = container_of(filp->f_inode->i_cdev,
+  struct rproc, char_dev);
+   int ret = 0;
+   char cmd[10];
+
+   if (!len || len > sizeof(cmd))
+   return -EINVAL;
+
+   ret = copy_from_user(cmd, buf, sizeof(cmd));
+   if (ret)
+   return -EFAULT;
+
+   if (sysfs_streq(cmd, "start")) {
+   if (rproc->state == RPROC_RUNNING)
+   return -EBUSY;
+
+   ret = rproc_boot(rproc);
+   if (ret)
+   dev_err(&rproc->dev, "Boot failed:%d\n", ret);
+   } else if (sysfs_streq(cmd, "stop")) {
+   if (rproc->state == RPROC_OFFLINE)
+   return -ENXIO;

returning ENXIO in this case seems to me no appropriate , what about
EPERM or
EINVAL (rproc_sysfs) ?


I think EPERM would indicate the operati

Re: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone support

[Amit Kucheria]

On Tue, Jun 30, 2020 at 10:58 AM Andy Tang  wrote:
>
>
>
> > -Original Message-
> > From: Amit Kucheria 
> > Sent: 2020年6月30日 13:12
> > To: Andy Tang 
> > Cc: Shawn Guo ; Leo Li ; Rob
> > Herring ; lakml ;
> > open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> > ; LKML 
> > Subject: [EXT] Re: [PATCH 1/2] arm64: dts: ls1088a: add more thermal zone
> > support
> >
> > Caution: EXT Email
> >
> > On Tue, Jun 30, 2020 at 8:56 AM  wrote:
> > >
> > > From: Yuantian Tang 
> > >
> > > There are 2 thermal zones in ls1088a soc. Add the other thermal zone
> > > node to enable it.
> > > Also update the values in calibration table to make the temperatures
> > > monitored more precise.
> > >
> > > Signed-off-by: Yuantian Tang 
> > > ---
> > >  .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 100
> > > +++---
> > >  1 file changed, 62 insertions(+), 38 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > index 36a799554620..ccbbc23e6c85 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > @@ -129,19 +129,19 @@
> > > };
> > >
> > > thermal-zones {
> > > -   cpu_thermal: cpu-thermal {
> > > +   core-cluster {
> > > polling-delay-passive = <1000>;
> > > polling-delay = <5000>;
> > > thermal-sensors = <&tmu 0>;
> > >
> > > trips {
> > > -   cpu_alert: cpu-alert {
> > > +   core_cluster_alert:
> > core-cluster-alert
> > > + {
> > > temperature = <85000>;
> > > hysteresis = <2000>;
> > > type = "passive";
> > > };
> > >
> > > -   cpu_crit: cpu-crit {
> > > +   core_cluster_crit: core-cluster-crit {
> > > temperature = <95000>;
> > > hysteresis = <2000>;
> > > type = "critical"; @@
> > -150,7
> > > +150,7 @@
> > >
> > > cooling-maps {
> > > map0 {
> > > -   trip = <&cpu_alert>;
> > > +   trip =
> > <&core_cluster_alert>;
> > > cooling-device =
> > > <&cpu0
> > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > > <&cpu1
> > > THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, @@ -163,6 +163,26 @@
> > > };
> > > };
> > > };
> > > +
> > > +   soc {
> > > +   polling-delay-passive = <1000>;
> > > +   polling-delay = <5000>;
> > > +   thermal-sensors = <&tmu 1>;
> > > +
> > > +   trips {
> > > +   soc-alert {
> > > +   temperature = <85000>;
> > > +   hysteresis = <2000>;
> > > +   type = "passive";
> > > +   };
> > > +
> > > +   soc-crit {
> > > +   temperature = <95000>;
> > > +   hysteresis = <2000>;
> > > +   type = "critical";
> > > +   };
> > > +   };
> > > +   };
> >
> > You should also add a cooling-maps section for this thermal zone given that 
> > it
> > has a passive trip type. Otherwise there is no use for a passive trip type.
> It is better to have a cooling device. But there is only one cooling device 
> on this platform
> which is used by core-cluster. So there is no extra cooling device for it.
> This zone can take action when critical temp is reached. So it is still 
> useful.
> What do you suggest?

If the action taken by the core-cluster cooling-maps is the only one
that can be taken, I suggest getting rid of the the soc-alert passive
trip completely. It is not of any use.

If there is a chance that your soc thermal-zone can heat up before
your cpu-cluster zone (unlikely), you could use the same cooling
device (cpu0, cpu1) for soc thermal zone too.

Re: [PATCH] vhost: Fix documentation

[Jason Wang]

On 2020/6/30 下午1:29, Eli Cohen wrote:

Fix documentation to match actual function prototypes

"end" used instead of "last". Fix that.

Signed-off-by: Eli Cohen 
---



Acked-by: Jason Wang 

Thanks



  drivers/vhost/iotlb.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c
index 1f0ca6e44410..0d4213a54a88 100644
--- a/drivers/vhost/iotlb.c
+++ b/drivers/vhost/iotlb.c
@@ -149,7 +149,7 @@ EXPORT_SYMBOL_GPL(vhost_iotlb_free);
   * vhost_iotlb_itree_first - return the first overlapped range
   * @iotlb: the IOTLB
   * @start: start of IOVA range
- * @end: end of IOVA range
+ * @last: last byte in IOVA range
   */
  struct vhost_iotlb_map *
  vhost_iotlb_itree_first(struct vhost_iotlb *iotlb, u64 start, u64 last)
@@ -162,7 +162,7 @@ EXPORT_SYMBOL_GPL(vhost_iotlb_itree_first);
   * vhost_iotlb_itree_first - return the next overlapped range
   * @iotlb: the IOTLB
   * @start: start of IOVA range
- * @end: end of IOVA range
+ * @last: last byte IOVA range
   */
  struct vhost_iotlb_map *
  vhost_iotlb_itree_next(struct vhost_iotlb_map *map, u64 start, u64 last)