* [PATCH v4 4/8] dt-bindings: add axentia to vendor-prefixes
From: Peter Rosin @ 2016-11-08 11:58 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Jonathan Cameron, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Rob Herring, Mark Rutland, Daniel Baluta,
Slawomir Stepien, Thomas Gleixner, linux-iio, devicetree
In-Reply-To: <1478606339-31253-1-git-send-email-peda@axentia.se>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..a437120a7eee 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -39,6 +39,7 @@ auo AU Optronics Corporation
auvidea Auvidea GmbH
avago Avago Technologies
avic Shanghai AVIC Optoelectronics Co., Ltd.
+axentia Axentia Technologies AB
axis Axis Communications AB
boe BOE Technology Group Co., Ltd.
bosch Bosch Sensortec GmbH
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v1] ufs: introduce UFSHCD_QUIRK_BROKEN_DWORD_UTRD quirk
From: Subhash Jadavani @ 2016-11-08 19:34 UTC (permalink / raw)
To: Kiwoong Kim
Cc: James E.J. Bottomley, linux-scsi, Martin K. Petersen,
vinholikatti, 추헌광, linux-scsi-owner
In-Reply-To: <002101d23994$a1026f00$e3074d00$@samsung.com>
On 2016-11-07 23:49, Kiwoong Kim wrote:
> Some UFS host controllers may think
> granularitys of PRDT length and offset as bytes, not double words.
>
> Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
> ---
> drivers/scsi/ufs/ufshcd.c | 24 +++++++++++++++++++-----
> drivers/scsi/ufs/ufshcd.h | 2 ++
> 2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 8e19631..549e3e8 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1161,8 +1161,13 @@ static int ufshcd_map_sg(struct ufshcd_lrb
> *lrbp)
> return sg_segments;
>
> if (sg_segments) {
> - lrbp->utr_descriptor_ptr->prd_table_length =
> - cpu_to_le16((u16) (sg_segments));
> + if (hba->quirks & UFSHCD_QUIRK_BROKEN_DWORD_UTRD)
This might sound more specific:
s/UFSHCD_QUIRK_BROKEN_DWORD_UTRD/UFSHCD_QUIRK_PRDT_BYTE_GRAN .
> + lrbp->utr_descriptor_ptr->prd_table_length =
> + cpu_to_le16((u16)(sg_segments *
> + sizeof(struct ufshcd_sg_entry)));
> + else
> + lrbp->utr_descriptor_ptr->prd_table_length =
> + cpu_to_le16((u16) (sg_segments));
>
> prd_table = (struct ufshcd_sg_entry *)lrbp->ucd_prdt_ptr;
>
> @@ -2385,12 +2390,21 @@ static void
> ufshcd_host_memory_configure(struct ufs_hba *hba)
> cpu_to_le32(upper_32_bits(cmd_desc_element_addr));
>
> /* Response upiu and prdt offset should be in double words */
> - utrdlp[i].response_upiu_offset =
> + if (hba->quirks & UFSHCD_QUIRK_BROKEN_DWORD_UTRD) {
> + utrdlp[i].response_upiu_offset =
> + cpu_to_le16(response_offset);
> + utrdlp[i].prd_table_offset =
> + cpu_to_le16(prdt_offset);
> + utrdlp[i].response_upiu_length =
> + cpu_to_le16(ALIGNED_UPIU_SIZE);
> + } else {
> + utrdlp[i].response_upiu_offset =
> cpu_to_le16((response_offset >> 2));
> - utrdlp[i].prd_table_offset =
> + utrdlp[i].prd_table_offset =
> cpu_to_le16((prdt_offset >> 2));
> - utrdlp[i].response_upiu_length =
> + utrdlp[i].response_upiu_length =
> cpu_to_le16(ALIGNED_UPIU_SIZE >> 2);
> + }
>
> hba->lrb[i].utr_descriptor_ptr = (utrdlp + i);
> hba->lrb[i].ucd_req_ptr =
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 8cf3991..565f005 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -494,6 +494,8 @@ struct ufs_hba {
> #define UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION UFS_BIT(5)
>
> #define UFSHCD_QUIRK_GET_VS_RESULT UFS_BIT(6)
> + #define UFSHCD_QUIRK_BROKEN_DWORD_UTRD UFS_BIT(7)
> +
This extra line space isn't needed.
>
> unsigned int quirks; /* Deviations from standard UFSHCI spec. */
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 1/2] dma-buf: return index of the first signaled fence (v2)
From: Sumit Semwal @ 2016-11-08 19:34 UTC (permalink / raw)
To: Alex Deucher; +Cc: Alex Deucher, DRI mailing list, amd-gfx list, monk.liu
In-Reply-To: <CAO_48GH5Xzc-+wWxpAqcE7t7yjQz7XS=U4M+E-PR_X+RFfvRew@mail.gmail.com>
Hi Alex, Christian,
On 8 November 2016 at 04:12, Sumit Semwal <sumit.semwal@linaro.org> wrote:
> Hi Alex,
>
> On 07-Nov-2016 11:14 PM, "Alex Deucher" <alexdeucher@gmail.com> wrote:
>>
>> On Fri, Nov 4, 2016 at 6:03 PM, Sumit Semwal <sumit.semwal@linaro.org>
>> wrote:
>> > Hi Alex,
>> >
>> > Thanks for the patches.
>> >
>> > On 4 November 2016 at 14:16, Alex Deucher <alexdeucher@gmail.com> wrote:
>> >> From: "monk.liu" <monk.liu@amd.com>
>> >>
>> >> Return the index of the first signaled fence. This information
>> >> is useful in some APIs like Vulkan.
>> >>
>> >> v2: rebase on drm-next (fence -> dma_fence)
>> >>
>> >> Signed-off-by: monk.liu <monk.liu@amd.com>
>> >> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
>> >> Cc: Sumit Semwal <sumit.semwal@linaro.org>
>> >> ---
>> >>
>> >> This is the same patch set I send out yesterday, I just
>> >> squashed the amdgpu patches together and rebased everything on
>> >> the fence -> dma_fence renaming. This is used by our VK driver
>> >> and we are planning to use it in mesa as well.
>> >>
>> >
>> > Would you be ok if I apply this and the amdgpu patch both together via
>> > drm-misc, or would you like me to notify you once I merge this for you
>> > to take the amdgpu patch via your tree? I'm fine either ways, but
>> > perhaps drm-misc would be a bit neater.
>> >
>>
>> Either way works for me. Whatever is easier for you.
>>
> Thanks, will take these and Christian's patches through the drm-misc tree,
> hopefully today. (returning from LPC and just landed at my home city, 4am
> here, but will hope to push these today! )
>> Alex
>
Applied to drm-misc; Thanks!
> Best,
> Sumit.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Alexander Duyck @ 2016-11-08 19:33 UTC (permalink / raw)
To: Hisashi T Fujinaka, Cao jin, Netdev, intel-wired-lan,
linux-kernel@vger.kernel.org, Izumi, Taku/泉 拓
In-Reply-To: <20161108183739.GA3744@calimero.vinschen.de>
On Tue, Nov 8, 2016 at 10:37 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
> On Nov 8 09:16, Hisashi T Fujinaka wrote:
>> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
>> > On Nov 8 15:06, Cao jin wrote:
>> > > When running as guest, under certain condition, it will oops as following.
>> > > writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr
>> > > is NULL. While other register access won't oops kernel because they use
>> > > wr32/rd32 which have a defense against NULL pointer.
>> > > [...]
>> >
>> > Incidentally we're just looking for a solution to that problem too.
>> > Do three patches to fix the same problem at rougly the same time already
>> > qualify as freak accident?
>> >
>> > FTR, I attached my current patch, which I was planning to submit after
>> > some external testing.
>> >
>> > However, all three patches have one thing in common: They workaround
>> > a somewhat dubious resetting of the hardware address to NULL in case
>> > reading from a register failed.
>> >
>> > That makes me wonder if setting the hardware address to NULL in
>> > rd32/igb_rd32 is really such a good idea. It's performed in a function
>> > which return value is *never* tested for validity in the calling
>> > functions and leads to subsequent crashes since no tests for hw_addr ==
>> > NULL are performed.
>> >
>> > Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
>> > graceful way to handle the "surprise removal"?
>>
>> Answering this from my home account because, well, work is Outlook.
>>
>> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
>> uncertain that the surprise removal code actually works the way I
>> thought previously and I think I took a lot of it out of my local code.
>>
>> Unfortuantely I don't have any equipment that I can use to reproduce
>> surprise removal any longer so that means I wouldn't be able to test
>> anything. I have to defer to you or Cao Jin.
>
> I'm not too keen to rip out a PCIe NIC under power from my locale
> desktop machine, but I think an actual surprise removal is not the
> problem.
>
> As described in my git log entry, the error condition in igb_rd32 can be
> triggered during a suspend. The HW has been put into a sleep state but
> some register read requests are apparently not guarded against that
> situation. Reading a register in this state returns -1, thus a suspend
> is erroneously triggering the "surprise removal" sequence.
The question I would have is what is reading the device when it is in
this state. The watchdog and any other functions that would read the
device should be disabled.
One possibility could be a race between a call to igb_close and the
igb_suspend function. We have seen some of those pop up recently on
ixgbe and it looks like igb has the same bug. We should probably be
using the rtnl_lock to guarantee that netif_device_detach and the call
to __igb_close are completed before igb_close could possibly be called
by the network stack.
> Here's a raw idea:
>
> - Note that device is suspended in e1000_hw struct. Don't trigger
> error sequence in igb_rd32 if so (...and return a 0 value???)
The thing is that a suspended device should not be accessed at all.
If we are accessing it while it is suspended then that is a bug. If
you could throw a WARN_ON call in igb_rd32 to capture where this is
being triggered that might be useful.
> - Otherwise assume it's actually a surprise removal. In theory that
> should somehow trigger a device removal sequence, kind of like
> calling igb_remove, no?
Well a read of the MMIO region while suspended is more of a surprise
read since there shouldn't be anything going on. We need to isolate
where that read is coming from and fix it.
Thanks.
- Alex
^ permalink raw reply
* [Intel-wired-lan] [PATCH] igb: use igb_adapter->io_addr instead of e1000_hw->hw_addr
From: Alexander Duyck @ 2016-11-08 19:33 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20161108183739.GA3744@calimero.vinschen.de>
On Tue, Nov 8, 2016 at 10:37 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
> On Nov 8 09:16, Hisashi T Fujinaka wrote:
>> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
>> > On Nov 8 15:06, Cao jin wrote:
>> > > When running as guest, under certain condition, it will oops as following.
>> > > writel() in igb_configure_tx_ring() results in oops, because hw->hw_addr
>> > > is NULL. While other register access won't oops kernel because they use
>> > > wr32/rd32 which have a defense against NULL pointer.
>> > > [...]
>> >
>> > Incidentally we're just looking for a solution to that problem too.
>> > Do three patches to fix the same problem at rougly the same time already
>> > qualify as freak accident?
>> >
>> > FTR, I attached my current patch, which I was planning to submit after
>> > some external testing.
>> >
>> > However, all three patches have one thing in common: They workaround
>> > a somewhat dubious resetting of the hardware address to NULL in case
>> > reading from a register failed.
>> >
>> > That makes me wonder if setting the hardware address to NULL in
>> > rd32/igb_rd32 is really such a good idea. It's performed in a function
>> > which return value is *never* tested for validity in the calling
>> > functions and leads to subsequent crashes since no tests for hw_addr ==
>> > NULL are performed.
>> >
>> > Maybe commit 22a8b2915 should be reconsidered? Isn't there some more
>> > graceful way to handle the "surprise removal"?
>>
>> Answering this from my home account because, well, work is Outlook.
>>
>> "Reconsidering" would be great. In fact, revert if if you'd like. I'm
>> uncertain that the surprise removal code actually works the way I
>> thought previously and I think I took a lot of it out of my local code.
>>
>> Unfortuantely I don't have any equipment that I can use to reproduce
>> surprise removal any longer so that means I wouldn't be able to test
>> anything. I have to defer to you or Cao Jin.
>
> I'm not too keen to rip out a PCIe NIC under power from my locale
> desktop machine, but I think an actual surprise removal is not the
> problem.
>
> As described in my git log entry, the error condition in igb_rd32 can be
> triggered during a suspend. The HW has been put into a sleep state but
> some register read requests are apparently not guarded against that
> situation. Reading a register in this state returns -1, thus a suspend
> is erroneously triggering the "surprise removal" sequence.
The question I would have is what is reading the device when it is in
this state. The watchdog and any other functions that would read the
device should be disabled.
One possibility could be a race between a call to igb_close and the
igb_suspend function. We have seen some of those pop up recently on
ixgbe and it looks like igb has the same bug. We should probably be
using the rtnl_lock to guarantee that netif_device_detach and the call
to __igb_close are completed before igb_close could possibly be called
by the network stack.
> Here's a raw idea:
>
> - Note that device is suspended in e1000_hw struct. Don't trigger
> error sequence in igb_rd32 if so (...and return a 0 value???)
The thing is that a suspended device should not be accessed at all.
If we are accessing it while it is suspended then that is a bug. If
you could throw a WARN_ON call in igb_rd32 to capture where this is
being triggered that might be useful.
> - Otherwise assume it's actually a surprise removal. In theory that
> should somehow trigger a device removal sequence, kind of like
> calling igb_remove, no?
Well a read of the MMIO region while suspended is more of a surprise
read since there shouldn't be anything going on. We need to isolate
where that read is coming from and fix it.
Thanks.
- Alex
^ permalink raw reply
* I've found some great stuff
From: nop @ 2016-11-08 19:32 UTC (permalink / raw)
To: linux-btrfs, knujon spam advisory, linux-fsdevel,
knujon_spam_advisory10, kyoungrkim
Hi,
I've recently found some great stuff and just wanted to share this with you, just take a look <http://key.colfaxrx.com/lnny/622>
Hope this helps, nop
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: update Sync File Framework files
From: Sumit Semwal @ 2016-11-08 19:32 UTC (permalink / raw)
To: Gustavo Padovan; +Cc: Gustavo Padovan, DRI mailing list
In-Reply-To: <1477515862-7980-1-git-send-email-gustavo@padovan.org>
On 27 October 2016 at 02:34, Gustavo Padovan <gustavo@padovan.org> wrote:
> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> ---
Applied to drm-misc; Thanks!
> MAINTAINERS | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e60e0a1..10f1bc0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3913,8 +3913,10 @@ R: Gustavo Padovan <gustavo@padovan.org>
> S: Maintained
> L: linux-media@vger.kernel.org
> L: dri-devel@lists.freedesktop.org
> -F: drivers/dma-buf/sync_file.c
> +F: drivers/dma-buf/sync_*
> +F: drivers/dma-buf/sw_sync.c
> F: include/linux/sync_file.h
> +F: include/uapi/linux/sync_file.h
> F: Documentation/sync_file.txt
> T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
>
> --
> 2.5.5
>
--
Thanks and regards,
Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH] scsi_devinfo: remove synchronous ALUA for NETAPP/RDAC devices
From: Xose Vazquez Perez @ 2016-11-08 19:32 UTC (permalink / raw)
Cc: Xose Vazquez Perez, Martin George, Robert Stankey,
Steven Schremmer, Sean Stewart, Hannes Reinecke,
Christophe Varoqui, James E . J . Bottomley, Martin K . Petersen,
SCSI ML, device-mapper development
NetApp did confirm this is only required for ONTAP(LUN C-Mode).
Cc: Martin George <Martin.George@netapp.com>
Cc: Robert Stankey <Robert.Stankey@netapp.com>
Cc: Steven Schremmer <Steven.Schremmer@netapp.com>
Cc: Sean Stewart <Sean.Stewart@netapp.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>
Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: SCSI ML <linux-scsi@vger.kernel.org>
Cc: device-mapper development <dm-devel@redhat.com>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
drivers/scsi/scsi_devinfo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 2464569..1fb7964 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -221,7 +221,6 @@ static struct {
{"NEC", "PD-1 ODX654P", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
{"NEC", "iStorage", NULL, BLIST_REPORTLUN2},
{"NETAPP", "LUN C-Mode", NULL, BLIST_SYNC_ALUA},
- {"NETAPP", "INF-01-00", NULL, BLIST_SYNC_ALUA},
{"NRC", "MBR-7", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
{"NRC", "MBR-7.4", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
{"PIONEER", "CD-ROM DRM-600", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] dma-buf/sw_sync: put fence reference from the fence creation
From: Sumit Semwal @ 2016-11-08 19:32 UTC (permalink / raw)
To: Chris Wilson, Gustavo Padovan, DRI mailing list, Gustavo Padovan
In-Reply-To: <20161026215434.GV10167@nuc-i3427.alporthouse.com>
On 27 October 2016 at 03:24, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Wed, Oct 26, 2016 at 06:59:59PM -0200, Gustavo Padovan wrote:
>> From: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
>>
>> Once sw_sync_ioctl_create_fence() returns we no longer have the
>> *pt pointer to the fence base object thus we need to put the reference
>> we have from the fence creation to keep a correct reference accounting.
>>
>> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
> Fixes: 30cd85dd6edc ("dma-buf/sync_file: hold reference to fence when creating sync_file")
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris
>
Applied to drm-misc; Thanks!
> --
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: Patch: Allow Ext4 partitions with encrypted directories.
From: Samee Zahur @ 2016-11-08 19:31 UTC (permalink / raw)
To: Andrei Borzenkov; +Cc: bug-grub, The development of GNU GRUB
In-Reply-To: <ff7f1fd9-f487-0909-ab23-b5b8a767851f@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5380 bytes --]
It should be possible, but I'm not sure if I can test that patch (both for
lack of knowledge, and time constraints). I am happy to send the patch over
if somebody else wants to take over testing it.
Here's what my patch would probably do:
In grub-core/fs/ext2.c, at the end of grub_ext2_read_inode, it can test
inode->flags to see if it's encrypted. If so, return some error code
(suggestions?). I think that will do the trick, although I'm not familiar
with grub enough to know for sure.
Testing: it requires creating scenario grub tries to access a file that it
doesn't normally do during the boot process, and observe what the error is.
Possibly using grub shell? Not sure.
Status without any additional files, as things stand:
I have tested on machines here, and things work without a problem. grub
will not return garbage in the sense of arbitrary data from unknown blocks
of disk ... it will return a valid, well-structured file with actual
ciphertext. This was never a problem since, in our configuration, grub
never tries to access files with names it doesn't recognize.
So we can either:
1) Have me send a patch for proper detection so that somebody else can test
it.
2) Accept the current patch as is, given I have already tested it.
3) Ignore it, and not add this feature to grub at this point.
Let me know what you want do.
On Sun, Nov 6, 2016 at 12:08 AM, Andrei Borzenkov <arvidjaar@gmail.com>
wrote:
> 03.11.2016 20:24, Samee Zahur пишет:
> >> Hmm ... I had to sign contributor agreement that transfers copyright
> >> to FSF. Not that I care personally but that may be problem ...
> >
> > Yeah, I don't personally care either. If someone at FSF raises an issue,
> I
> > can reach out to legal experts here. But this is not the first time
> Google
> > (C) has been checked into GRUB. We patch FSF GNU code all the time.
> >
> >> And what happens when grub does see encrypted content? Returning
> >> garbage is not an option here.
> >
> > Good question. The files simply won't be found. The filenames are also
> > garbled, so GRUB won't find the files it's looking for.
> >
>
> Do you mean that if grub tries to open this garbled name it succeeds? Is
> it possible to detect that directory is encrypted? Then we should refuse
> to access this directory with clear explanation.
>
> > On Thu, Nov 3, 2016 at 8:16 AM, Andrei Borzenkov <arvidjaar@gmail.com>
> > wrote:
> >
> >> On Wed, Nov 2, 2016 at 12:22 AM, Samee Zahur <szahur@google.com> wrote:
> >>> Ext4 filesystem now allows users to choose directory trees to be stored
> >>> encrypted. However, GRUB refuses to boot from such partitions, even if
> >> none
> >>> of the boot-critical files are actually affected. The following patch
> >> fixes
> >>> this. It was tested on the latest release version of ext4.
> >>>
> >>> Please let me know if more information is needed.
> >>>
> >>> diff --git a/grub-core/fs/ext2.c b/grub-core/fs/ext2.c
> >>> index cdce63b..eca10e4 100644
> >>> --- a/grub-core/fs/ext2.c
> >>> +++ b/grub-core/fs/ext2.c
> >>> @@ -2,6 +2,7 @@
> >>> /*
> >>> * GRUB -- GRand Unified Bootloader
> >>> * Copyright (C) 2003,2004,2005,2007,2008,2009 Free Software
> >> Foundation,
> >>> Inc.
> >>> + * Copyright (C) 2016 Google, Inc.
> >>> *
> >>
> >> Hmm ... I had to sign contributor agreement that transfers copyright
> >> to FSF. Not that I care personally but that may be problem ...
> >>
> >>> * GRUB is free software: you can redistribute it and/or modify
> >>> * it under the terms of the GNU General Public License as published
> by
> >>> @@ -102,6 +103,7 @@ GRUB_MOD_LICENSE ("GPLv3+");
> >>> #define EXT4_FEATURE_INCOMPAT_64BIT 0x0080
> >>> #define EXT4_FEATURE_INCOMPAT_MMP 0x0100
> >>> #define EXT4_FEATURE_INCOMPAT_FLEX_BG 0x0200
> >>> +#define EXT4_FEATURE_INCOMPAT_ENCRYPT 0x10000
> >>>
> >>> /* The set of back-incompatible features this driver DOES support. Add
> >> (OR)
> >>> * flags here as the related features are implemented into the driver.
> >> */
> >>> @@ -120,9 +122,12 @@ GRUB_MOD_LICENSE ("GPLv3+");
> >>> * mmp: Not really back-incompatible - was added as such to
> >>> * avoid multiple read-write mounts. Safe to ignore
> for
> >>> this
> >>> * RO driver.
> >>> + * encrypt: We assume boot files are not encrypted (grub
> config,
> >>> kernel,
> >>> + * initramd etc.). If we are wrong, boot will fail as
> it
> >>> should.
> >>> */
> >>
> >> Do not assume users won't try to access something else.
> >>
> >>> #define EXT2_DRIVER_IGNORED_INCOMPAT ( EXT3_FEATURE_INCOMPAT_RECOVER \
> >>> - | EXT4_FEATURE_INCOMPAT_MMP)
> >>> + | EXT4_FEATURE_INCOMPAT_MMP \
> >>> + | EXT4_FEATURE_INCOMPAT_ENCRYPT)
> >>>
> >>
> >> And what happens when grub does see encrypted content? Returning
> >> garbage is not an option here.
> >>
> >>>
> >>> #define EXT3_JOURNAL_MAGIC_NUMBER 0xc03b3998U
> >>>
> >>>
> >>> _______________________________________________
> >>> Bug-grub mailing list
> >>> Bug-grub@gnu.org
> >>> https://lists.gnu.org/mailman/listinfo/bug-grub
> >>>
> >>
> >
>
>
[-- Attachment #2: Type: text/html, Size: 7150 bytes --]
^ permalink raw reply
* [U-Boot] MMC write failed - Can't read partition table
From: DaveKucharczyk @ 2016-11-08 19:31 UTC (permalink / raw)
To: u-boot
Hi, we've been using a new SD card for 6+ months without issues, but recently
noticed issues with newer releases. I'm not sure if it's the SD cards, our
burner stations or our build process. Were using U-Boot 2014.07
The problem is that we can't read/write to the SD card during boot. This
happens intermittently on freshly burned cards. 75% of the time it works.
Our bootcmd starts with ext2load mmc ... but obviously it fails due to
"can't read partition table".
Manually debugging in U-Boot if I run mmc rescan then it can read the
partition table, but if I reboot the system then the issue comes back upon
next power-up.
If I run rescan AND then saveenv then everything works after that.
My questions are:
1. Is it good practice to run mmc rescan as one of the first things in
bootcmd?
2. I'm a little confised as to why saveenv would cause the SD card to work
again *persistently*.
3. Any recommendations on getting root cause as to what it could be (SD
card, our burner stations or our build process)?
Troubleshooting steps below...
MX51 U-Boot > mmc info
Device: FSL_SDHC
Manufacturer ID: 87
OEM: 494f
Name: 004GB
Tran Speed: 50000000
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 3.8 GiB
Bus Width: 1-bit
MX51 U-Boot > mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
** Can't read partition table on 0:0 **
MX51 U-Boot > mmc rescan
MX51 U-Boot > mmc part
Partition Map for MMC device 0 -- Partition Type: DOS
Part Start Sector Num Sectors UUID Type
1 31000 3844000 00000000-01 83
2 3882750 4037750 00000000-02 83
MX51 U-Boot > saveenv
Saving Environment to MMC...
reboot and everything works.
--
View this message in context: http://u-boot.10912.n7.nabble.com/MMC-write-failed-Can-t-read-partition-table-tp272634.html
Sent from the U-Boot mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 5/6] mm: workingset: switch shadow entry tracking to radix tree exceptional counting
From: Johannes Weiner @ 2016-11-08 19:30 UTC (permalink / raw)
To: Jan Kara
Cc: Andrew Morton, Linus Torvalds, Kirill A. Shutemov, linux-mm,
linux-kernel, kernel-team
In-Reply-To: <20161108102716.GL32353@quack2.suse.cz>
On Tue, Nov 08, 2016 at 11:27:16AM +0100, Jan Kara wrote:
> On Mon 07-11-16 14:07:40, Johannes Weiner wrote:
> > Currently, we track the shadow entries in the page cache in the upper
> > bits of the radix_tree_node->count, behind the back of the radix tree
> > implementation. Because the radix tree code has no awareness of them,
> > we rely on random subtleties throughout the implementation (such as
> > the node->count != 1 check in the shrinking code which is meant to
> > exclude multi-entry nodes, but also happens to skip nodes with only
> > one shadow entry since it's accounted in the upper bits). This is
> > error prone and has, in fact, caused the bug fixed in d3798ae8c6f3
> > ("mm: filemap: don't plant shadow entries without radix tree node").
> >
> > To remove these subtleties, this patch moves shadow entry tracking
> > from the upper bits of node->count to the existing counter for
> > exceptional entries. node->count goes back to being a simple counter
> > of valid entries in the tree node and can be shrunk to a single byte.
>
> ...
>
> > diff --git a/mm/truncate.c b/mm/truncate.c
> > index 6ae44571d4c7..d3ce5f261f47 100644
> > --- a/mm/truncate.c
> > +++ b/mm/truncate.c
> > @@ -53,7 +53,6 @@ static void clear_exceptional_entry(struct address_space *mapping,
> > mapping->nrexceptional--;
> > if (!node)
> > goto unlock;
> > - workingset_node_shadows_dec(node);
> > /*
> > * Don't track node without shadow entries.
> > *
> > @@ -61,8 +60,7 @@ static void clear_exceptional_entry(struct address_space *mapping,
> > * The list_empty() test is safe as node->private_list is
> > * protected by mapping->tree_lock.
> > */
> > - if (!workingset_node_shadows(node) &&
> > - !list_empty(&node->private_list))
> > + if (!node->exceptional && !list_empty(&node->private_list))
> > list_lru_del(&workingset_shadow_nodes,
> > &node->private_list);
> > __radix_tree_delete_node(&mapping->page_tree, node);
>
> Is this really correct now? The radix tree implementation can move a single
> exceptional entry at index 0 from a node into a direct pointer and free
> the node while it is still in the LRU list. Or am I missing something?
You're right. I missed that scenario.
> To fix this I'd prefer to just have a callback from radix tree code when it
> is freeing a node, rather that trying to second-guess its implementation in
> the page-cache code...
>
> Otherwise the patch looks good to me and I really like the simplification!
That's a good idea. I'll do away with __radix_tree_delete_node()
altogether and move not just the slot accounting but also the tree
shrinking and the maintenance callback into __radix_tree_replace().
The page cache can then simply do
__radix_tree_replace(&mapping->page_tree, node, slot, new,
workingset_node_update, mapping)
And workingset_node_update() gets called on every node that changes,
where it can track and untrack it depending on count & exceptional.
I'll give it some testing before posting it, but currently it's
include/linux/radix-tree.h | 4 +-
include/linux/swap.h | 1 -
lib/radix-tree.c | 212 ++++++++++++++++++++-----------------------
mm/filemap.c | 48 +---------
mm/truncate.c | 16 +---
mm/workingset.c | 31 +++++--
6 files changed, 134 insertions(+), 178 deletions(-)
on top of the simplifications of this patch 5/6.
Thanks for your input, Jan!
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2] xen: Fix xenpv machine initialisation
From: Stefano Stabellini @ 2016-11-08 19:30 UTC (permalink / raw)
To: Anthony PERARD
Cc: qemu-devel, xen-devel, Wei Liu, Eduardo Habkost,
Stefano Stabellini
In-Reply-To: <20161108140722.25194-1-anthony.perard@citrix.com>
On Tue, 8 Nov 2016, Anthony PERARD wrote:
> When using QEMU for Xen PV guest, QEMU abort with:
> xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type generic-pc-machine
>
> This is because the machine 'xenpv' also use accel=xen. Moving the code
> to xen_hvm_init() fix the issue.
>
> This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Eduardo Habkost <ehabkost@redhat.com>
> ---
> xen-common.c | 6 ------
> xen-hvm.c | 4 ++++
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/xen-common.c b/xen-common.c
> index bacf962..9099760 100644
> --- a/xen-common.c
> +++ b/xen-common.c
> @@ -9,7 +9,6 @@
> */
>
> #include "qemu/osdep.h"
> -#include "hw/i386/pc.h"
> #include "hw/xen/xen_backend.h"
> #include "qmp-commands.h"
> #include "sysemu/char.h"
> @@ -115,11 +114,6 @@ static void xen_change_state_handler(void *opaque, int running,
>
> static int xen_init(MachineState *ms)
> {
> - PCMachineState *pcms = PC_MACHINE(ms);
> -
> - /* Disable ACPI build because Xen handles it */
> - pcms->acpi_build_enabled = false;
> -
> xen_xc = xc_interface_open(0, 0, 0);
> if (xen_xc == NULL) {
> xen_pv_printf(NULL, 0, "can't open xen interface\n");
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 2f348ed..150c7e7 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1316,6 +1316,10 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
> }
> xen_be_register_common();
> xen_read_physmap(state);
> +
> + /* Disable ACPI build because Xen handles it */
> + pcms->acpi_build_enabled = false;
> +
> return;
>
> err:
> --
> Anthony PERARD
>
^ permalink raw reply
* Re: [PATCH v2] xen: Fix xenpv machine initialisation
From: Stefano Stabellini @ 2016-11-08 19:30 UTC (permalink / raw)
To: Anthony PERARD
Cc: Stefano Stabellini, Wei Liu, qemu-devel, Eduardo Habkost,
xen-devel
In-Reply-To: <20161108140722.25194-1-anthony.perard@citrix.com>
On Tue, 8 Nov 2016, Anthony PERARD wrote:
> When using QEMU for Xen PV guest, QEMU abort with:
> xen-common.c:118:xen_init: Object 0x7f2b8325dcb0 is not an instance of type generic-pc-machine
>
> This is because the machine 'xenpv' also use accel=xen. Moving the code
> to xen_hvm_init() fix the issue.
>
> This fix 021746c131cdfeab9d82ff918795a9f18d20d7ae.
>
> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Eduardo Habkost <ehabkost@redhat.com>
> ---
> xen-common.c | 6 ------
> xen-hvm.c | 4 ++++
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/xen-common.c b/xen-common.c
> index bacf962..9099760 100644
> --- a/xen-common.c
> +++ b/xen-common.c
> @@ -9,7 +9,6 @@
> */
>
> #include "qemu/osdep.h"
> -#include "hw/i386/pc.h"
> #include "hw/xen/xen_backend.h"
> #include "qmp-commands.h"
> #include "sysemu/char.h"
> @@ -115,11 +114,6 @@ static void xen_change_state_handler(void *opaque, int running,
>
> static int xen_init(MachineState *ms)
> {
> - PCMachineState *pcms = PC_MACHINE(ms);
> -
> - /* Disable ACPI build because Xen handles it */
> - pcms->acpi_build_enabled = false;
> -
> xen_xc = xc_interface_open(0, 0, 0);
> if (xen_xc == NULL) {
> xen_pv_printf(NULL, 0, "can't open xen interface\n");
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 2f348ed..150c7e7 100644
> --- a/xen-hvm.c
> +++ b/xen-hvm.c
> @@ -1316,6 +1316,10 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion **ram_memory)
> }
> xen_be_register_common();
> xen_read_physmap(state);
> +
> + /* Disable ACPI build because Xen handles it */
> + pcms->acpi_build_enabled = false;
> +
> return;
>
> err:
> --
> Anthony PERARD
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 5/6] mm: workingset: switch shadow entry tracking to radix tree exceptional counting
From: Johannes Weiner @ 2016-11-08 19:30 UTC (permalink / raw)
To: Jan Kara
Cc: Andrew Morton, Linus Torvalds, Kirill A. Shutemov, linux-mm,
linux-kernel, kernel-team
In-Reply-To: <20161108102716.GL32353@quack2.suse.cz>
On Tue, Nov 08, 2016 at 11:27:16AM +0100, Jan Kara wrote:
> On Mon 07-11-16 14:07:40, Johannes Weiner wrote:
> > Currently, we track the shadow entries in the page cache in the upper
> > bits of the radix_tree_node->count, behind the back of the radix tree
> > implementation. Because the radix tree code has no awareness of them,
> > we rely on random subtleties throughout the implementation (such as
> > the node->count != 1 check in the shrinking code which is meant to
> > exclude multi-entry nodes, but also happens to skip nodes with only
> > one shadow entry since it's accounted in the upper bits). This is
> > error prone and has, in fact, caused the bug fixed in d3798ae8c6f3
> > ("mm: filemap: don't plant shadow entries without radix tree node").
> >
> > To remove these subtleties, this patch moves shadow entry tracking
> > from the upper bits of node->count to the existing counter for
> > exceptional entries. node->count goes back to being a simple counter
> > of valid entries in the tree node and can be shrunk to a single byte.
>
> ...
>
> > diff --git a/mm/truncate.c b/mm/truncate.c
> > index 6ae44571d4c7..d3ce5f261f47 100644
> > --- a/mm/truncate.c
> > +++ b/mm/truncate.c
> > @@ -53,7 +53,6 @@ static void clear_exceptional_entry(struct address_space *mapping,
> > mapping->nrexceptional--;
> > if (!node)
> > goto unlock;
> > - workingset_node_shadows_dec(node);
> > /*
> > * Don't track node without shadow entries.
> > *
> > @@ -61,8 +60,7 @@ static void clear_exceptional_entry(struct address_space *mapping,
> > * The list_empty() test is safe as node->private_list is
> > * protected by mapping->tree_lock.
> > */
> > - if (!workingset_node_shadows(node) &&
> > - !list_empty(&node->private_list))
> > + if (!node->exceptional && !list_empty(&node->private_list))
> > list_lru_del(&workingset_shadow_nodes,
> > &node->private_list);
> > __radix_tree_delete_node(&mapping->page_tree, node);
>
> Is this really correct now? The radix tree implementation can move a single
> exceptional entry at index 0 from a node into a direct pointer and free
> the node while it is still in the LRU list. Or am I missing something?
You're right. I missed that scenario.
> To fix this I'd prefer to just have a callback from radix tree code when it
> is freeing a node, rather that trying to second-guess its implementation in
> the page-cache code...
>
> Otherwise the patch looks good to me and I really like the simplification!
That's a good idea. I'll do away with __radix_tree_delete_node()
altogether and move not just the slot accounting but also the tree
shrinking and the maintenance callback into __radix_tree_replace().
The page cache can then simply do
__radix_tree_replace(&mapping->page_tree, node, slot, new,
workingset_node_update, mapping)
And workingset_node_update() gets called on every node that changes,
where it can track and untrack it depending on count & exceptional.
I'll give it some testing before posting it, but currently it's
include/linux/radix-tree.h | 4 +-
include/linux/swap.h | 1 -
lib/radix-tree.c | 212 ++++++++++++++++++++-----------------------
mm/filemap.c | 48 +---------
mm/truncate.c | 16 +---
mm/workingset.c | 31 +++++--
6 files changed, 134 insertions(+), 178 deletions(-)
on top of the simplifications of this patch 5/6.
Thanks for your input, Jan!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature
From: Daniel Bristot de Oliveira @ 2016-11-08 19:29 UTC (permalink / raw)
To: Peter Zijlstra, Steven Rostedt
Cc: Daniel Bristot de Oliveira, Ingo Molnar, Christoph Lameter,
linux-rt-users, LKML, Tommaso Cucinotta
In-Reply-To: <20161108180548.GN3117@twins.programming.kicks-ass.net>
On 11/08/2016 07:05 PM, Peter Zijlstra wrote:
>> >
>> > I know what we want to do, but there's some momentous problems that
>> > need to be solved first.
> Like what?
The problem is that using RT_RUNTIME_SHARE a CPU will almost always
borrow enough runtime to make a CPU intensive rt task to run forever...
well not forever, but until the system crash because a kworker starved
in this CPU. Kworkers are sched fair by design and users do not always
have a way to avoid them in an isolated CPU, for example.
The user then can disable RT_RUNTIME_SHARE, but then the user will have
the CPU going idle for (period - runtime) at each period... throwing CPU
time in the trash.
>> > Until then, we may be forced to continue with
>> > hacks.
> Well, the more ill specified hacks we put in, the harder if will be to
> replace because people will end up depending on it.
The proposed patch seems to be the expected behavior for users/rt
throttling - they want a safeguard for fair tasks while allowing -rt
tasks to run as much as possible.
I see (and completely agree) that a DL server for fair/rt task would be
the best way to deal with this problem, but it will take some time until
such solution :-(. We even discussed this at Retis today, but yeah, it
will take sometime even in the best case.
(thinking aloud... a DL Server would react like the proposed patch, in
the sense that it would not be activated without tasks to run and would
return the CPU for other tasks if the tasks inside the server finish
their job before the end of the DL server runtime...)
-- Daniel
^ permalink raw reply
* RE: [Resend] [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer
From: Long Li @ 2016-11-08 16:56 UTC (permalink / raw)
To: Greg KH
Cc: KY Srinivasan, Haiyang Zhang, Bjorn Helgaas,
devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org
In-Reply-To: <20161108070001.GA13866@kroah.com>
> -----Original Message-----
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Sent: Monday, November 7, 2016 11:00 PM
> To: Long Li <longli@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; Bjorn Helgaas <bhelgaas@google.com>;
> devel@linuxdriverproject.org; linux-kernel@vger.kernel.org; linux-
> pci@vger.kernel.org
> Subject: Re: [Resend] [PATCH] pci-hyperv: use kmalloc to allocate hypercall
> params buffer
>
> On Tue, Nov 08, 2016 at 12:14:14AM -0800, Long Li wrote:
> > From: Long Li <longli@microsoft.com>
> >
> > hv_do_hypercall assumes that we pass a segment from a physically
> continuous buffer. Buffer allocated on the stack may not work if
> CONFIG_VMAP_STACK=y is set. Use kmalloc to allocate this buffer.
>
> Please wrap your changelog at 72 columns.
>
> >
> > Signed-off-by: Long Li <longli@microsoft.com>
> > Reported-by: Haiyang Zhang <haiyangz@microsoft.com>
> > ---
> > drivers/pci/host/pci-hyperv.c | 24 +++++++++++++-----------
> > 1 file changed, 13 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/pci/host/pci-hyperv.c
> > b/drivers/pci/host/pci-hyperv.c index 763ff87..97e6daf 100644
> > --- a/drivers/pci/host/pci-hyperv.c
> > +++ b/drivers/pci/host/pci-hyperv.c
> > @@ -378,6 +378,7 @@ struct hv_pcibus_device {
> > struct msi_domain_info msi_info;
> > struct msi_controller msi_chip;
> > struct irq_domain *irq_domain;
> > + struct retarget_msi_interrupt retarget_msi_interrupt_params;
>
> Can you handle potentially unaligned accesses like this? Is there some lock
> preventing you from using this structure more than once at the same time?
>
> > };
> >
> > /*
> > @@ -774,7 +775,7 @@ void hv_irq_unmask(struct irq_data *data) {
> > struct msi_desc *msi_desc = irq_data_get_msi_desc(data);
> > struct irq_cfg *cfg = irqd_cfg(data);
> > - struct retarget_msi_interrupt params;
> > + struct retarget_msi_interrupt *params;
> > struct hv_pcibus_device *hbus;
> > struct cpumask *dest;
> > struct pci_bus *pbus;
> > @@ -785,23 +786,24 @@ void hv_irq_unmask(struct irq_data *data)
> > pdev = msi_desc_to_pci_dev(msi_desc);
> > pbus = pdev->bus;
> > hbus = container_of(pbus->sysdata, struct hv_pcibus_device,
> > sysdata);
> > -
> > - memset(¶ms, 0, sizeof(params));
> > - params.partition_id = HV_PARTITION_ID_SELF;
> > - params.source = 1; /* MSI(-X) */
> > - params.address = msi_desc->msg.address_lo;
> > - params.data = msi_desc->msg.data;
> > - params.device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> > + params = &hbus->retarget_msi_interrupt_params;
> > +
> > + memset(params, 0, sizeof(*params));
> > + params->partition_id = HV_PARTITION_ID_SELF;
> > + params->source = 1; /* MSI(-X) */
> > + params->address = msi_desc->msg.address_lo;
> > + params->data = msi_desc->msg.data;
> > + params->device_id = (hbus->hdev->dev_instance.b[5] << 24) |
> > (hbus->hdev->dev_instance.b[4] << 16) |
> > (hbus->hdev->dev_instance.b[7] << 8) |
> > (hbus->hdev->dev_instance.b[6] & 0xf8) |
> > PCI_FUNC(pdev->devfn);
> > - params.vector = cfg->vector;
> > + params->vector = cfg->vector;
> >
> > for_each_cpu_and(cpu, dest, cpu_online_mask)
> > - params.vp_mask |= (1ULL <<
> vmbus_cpu_number_to_vp_number(cpu));
> > + params->vp_mask |= (1ULL <<
> vmbus_cpu_number_to_vp_number(cpu));
> >
> > - hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, ¶ms, NULL);
> > + hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, params, NULL);
>
> As you only use this in one spot, why not just allocate it here and then free
> it? Why add it to the pcibus device structure?
Thanks Greg. I will send a V2.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] mm: hugetlb: support gigantic surplus pages
From: Gerald Schaefer @ 2016-11-08 19:27 UTC (permalink / raw)
To: Huang Shijie
Cc: akpm, catalin.marinas, n-horiguchi, mhocko, kirill.shutemov,
aneesh.kumar, mike.kravetz, linux-mm, will.deacon, steve.capper,
kaly.xin, nd, linux-arm-kernel
In-Reply-To: <20161108091725.GA18678@sha-win-210.asiapac.arm.com>
On Tue, 8 Nov 2016 17:17:28 +0800
Huang Shijie <shijie.huang@arm.com> wrote:
> > I will look at the lockdep issue.
> I tested the new patch (will be sent out later) on the arm64 platform,
> and I did not meet the lockdep issue when I enabled the lockdep.
> The following is my config:
>
> CONFIG_LOCKD=y
> CONFIG_LOCKD_V4=y
> CONFIG_LOCKUP_DETECTOR=y
> # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
> CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
> CONFIG_DEBUG_SPINLOCK=y
> CONFIG_DEBUG_LOCK_ALLOC=y
> CONFIG_PROVE_LOCKING=y
> CONFIG_LOCKDEP=y
> CONFIG_LOCK_STAT=y
> CONFIG_DEBUG_LOCKDEP=y
> CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
>
> So do I miss something?
Those options should be OK. Meanwhile I looked into this a little more,
and the problematic line/lock is spin_lock_irqsave(&z->lock, flags) at
the top of alloc_gigantic_page(). From the lockdep trace we see that
it is triggered by an mmap(), and then hugetlb_acct_memory() ->
__alloc_huge_page() -> alloc_gigantic_page().
However, in between those functions (inside gather_surplus_pages())
a NUMA_NO_NODE node id comes into play. And this finally results in
alloc_gigantic_page() being called with NUMA_NO_NODE as nid (which is
-1), and NODE_DATA(nid)->node_zones will then reach into Nirvana.
So, I guess the problem is a missing NUMA_NO_NODE check in
alloc_gigantic_page(), similar to the one in
__hugetlb_alloc_buddy_huge_page(). And somehow this was not a problem
before the gigantic surplus change.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 07/18] link_alt_odb_entry: handle normalize_path errors
From: Bryan Turner @ 2016-11-08 19:27 UTC (permalink / raw)
To: Jeff King; +Cc: Git Users, René Scharfe
In-Reply-To: <20161108053333.jta7bmqsyvy2ijoh@sigill.intra.peff.net>
>
>> Is there anything I can do to help? I'm happy to test out changes.
>
> The patch at the end of his mail obviously passes the newly-added tests
> for me, but please confirm that it fixes your test suite.
>
> I gather your suite is about noticing behavior changes between different
> versions. For cases where we know there is an obvious right behavior, it
> would be nice if you could contribute them as patches to git's test
> suite. This case was overlooked because there was no test coverage at
> all.
>
> Barring that, running your suite and giving easily-reproducible problem
> reports is valuable. The earlier the better. So I am happy to see this
> on -rc0, and not on the final release. Periodically running it on
> "master" during the development cycle would have caught it even sooner.
I've applied your patch to the tip of the 2.11.0-rc0 tag (just to make
sure I don't accidentally pick up anything else on master; I'll test
that separately) and my full test suite passes without issue.
I'm going to investigate whether I can setup a version of this build
that runs "periodically" (I'm not sure what that period will be)
against git/git master. I've got a lot of the infrastructure in place,
but I'm going to need to automate a few things to make it really
viable.
As for contributing extensions to the test suite, that's a good idea.
I need to fast track getting a development environment setup.
^ permalink raw reply
* [PATCH 2/2] mm: hugetlb: support gigantic surplus pages
From: Gerald Schaefer @ 2016-11-08 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108091725.GA18678@sha-win-210.asiapac.arm.com>
On Tue, 8 Nov 2016 17:17:28 +0800
Huang Shijie <shijie.huang@arm.com> wrote:
> > I will look at the lockdep issue.
> I tested the new patch (will be sent out later) on the arm64 platform,
> and I did not meet the lockdep issue when I enabled the lockdep.
> The following is my config:
>
> CONFIG_LOCKD=y
> CONFIG_LOCKD_V4=y
> CONFIG_LOCKUP_DETECTOR=y
> # CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
> CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
> CONFIG_DEBUG_SPINLOCK=y
> CONFIG_DEBUG_LOCK_ALLOC=y
> CONFIG_PROVE_LOCKING=y
> CONFIG_LOCKDEP=y
> CONFIG_LOCK_STAT=y
> CONFIG_DEBUG_LOCKDEP=y
> CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
>
> So do I miss something?
Those options should be OK. Meanwhile I looked into this a little more,
and the problematic line/lock is spin_lock_irqsave(&z->lock, flags) at
the top of alloc_gigantic_page(). From the lockdep trace we see that
it is triggered by an mmap(), and then hugetlb_acct_memory() ->
__alloc_huge_page() -> alloc_gigantic_page().
However, in between those functions (inside gather_surplus_pages())
a NUMA_NO_NODE node id comes into play. And this finally results in
alloc_gigantic_page() being called with NUMA_NO_NODE as nid (which is
-1), and NODE_DATA(nid)->node_zones will then reach into Nirvana.
So, I guess the problem is a missing NUMA_NO_NODE check in
alloc_gigantic_page(), similar to the one in
__hugetlb_alloc_buddy_huge_page(). And somehow this was not a problem
before the gigantic surplus change.
^ permalink raw reply
* Re: "random" syn packets dropped
From: Bjørnar Ness @ 2016-11-08 19:26 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel
In-Reply-To: <20161108140857.GE24908@breakpoint.cc>
2016-11-08 15:08 GMT+01:00 Florian Westphal <fw@strlen.de>:
> Bjørnar Ness <bjornar.ness@gmail.com> wrote:
>> * this issue seem to suddenly appeared, is this a known bug?
>
> No.
>
>> * hint? All connections from the client is established from the same
>> source port.
>
> can you show conntrack -S output?
cpu=0 searched=121227494 found=39167580 new=304 invalid=7359
ignore=323276 delete=58920554 delete_list=58920526 insert=304
insert_failed=0 drop=0 early_drop=0 error=7359 search_restart=0
cpu=1 searched=769896688 found=3223427856 new=1824070235
invalid=99676863 ignore=9456795 delete=1803700815
delete_list=1731666319 insert=1745298679 insert_failed=3 drop=3
early_drop=0 error=3674946 search_restart=2
cpu=2 searched=488983917 found=2793077405 new=1800015302
invalid=97556206 ignore=9424173 delete=1789649391
delete_list=1705077976 insert=1724463703 insert_failed=9 drop=9
early_drop=0 error=3748383 search_restart=2
cpu=3 searched=449939710 found=3134174470 new=1839530428
invalid=99941483 ignore=9734373 delete=1811219076
delete_list=1735637482 insert=1761666050 insert_failed=6 drop=6
early_drop=0 error=3914932 search_restart=2
> Is nat in use?
yes, but not on there connections
> Does 'perf script net_dropmonitor' show anything?
Sorry. no ftrace
--
Bj(/)rnar
^ permalink raw reply
* Re: [Resend][PATCH] cpufreq: conservative: Decrease frequency faster when the timer deferred
From: Stratos Karafotis @ 2016-11-08 19:25 UTC (permalink / raw)
To: Viresh Kumar
Cc: linux-pm@vger.kernel.org, Linux Kernel Mailing List,
Rafael J. Wysocki
In-Reply-To: <CAKohpo=kbyXvjOYFdOyu6d6x1TP45UWT0kB9eAk3XUXTG5iUpQ@mail.gmail.com>
On 08/11/2016 10:32 πμ, Viresh Kumar wrote:
> On 8 November 2016 at 12:49, Stratos Karafotis <stratosk@semaphore.gr> wrote:
>> I think we shouldn't. That's why the patch first decreases the frequency
>> by n freq steps (where n the number of deferred periods).
>> Then the normal processing takes place.
>
> The problem that I see is that the new algorithm will reduce the
> frequency even if we are
> on a ramp up phase.
>
> For example consider this case:
>
> - We have a special load running, that runs in bursts. i.e. runs for
> some time, lets the CPU idle
> then and then again runs.
>
> - To run the load properly, we need to ramp up the frequency
>
> - But the new algorithm can make the frequency stagnant in this case.
> i.e. because of the idle
> period you may want to decrease the frequency by delta A and then the
> regular algorithm may
> want to increase it by same delta A.
>
> That's why I was asking to adopt this only in the ramp down path.
>
But this is the supposed behaviour of conservative governor. We want
the CPU to increase the frequency in steps. The patch just resets
the frequency to a lower frequency in case of idle.
For argument's sake, let's assume that the governor timer is never
deferred and runs every sampling period even on completely idle CPU.
And let's assume, for example, a burst load that runs every 100ms
for 20ms. The default sampling rate is also 20ms.
What would conservative do in case of that burst load? It would
increase the frequency by one freq step after 20ms and then it would
decrease the frequency 4 times by one frequency step. Most probably
on the next burst load, the CPU will run on min frequency.
I agree that maybe this is not ideal for performance but maybe this is
how we want conservative governor to work (lazily increase and decrease
frequency).
Regards,
Stratos
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: sunxi: Add support for interrupt debouncing
From: Maxime Ripard @ 2016-11-08 19:23 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, Rob Herring, Chen-Yu Tsai
In-Reply-To: <CACRpkdZ40e03VV_ScKceahG-7jmFmbBmgCqxBv9bGcvS3TnrOA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]
On Mon, Nov 07, 2016 at 10:40:04AM +0100, Linus Walleij wrote:
> On Wed, Nov 2, 2016 at 8:51 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Thu, Oct 20, 2016 at 03:56:25PM +0200, Maxime Ripard wrote:
> >> On Thu, Oct 20, 2016 at 03:04:46PM +0200, Linus Walleij wrote:
> >> > On Wed, Oct 19, 2016 at 11:15 AM, Maxime Ripard
> >> > <maxime.ripard@free-electrons.com> wrote:
> >> >
> >> > > The pin controller found in the Allwinner SoCs has support for interrupts
> >> > > debouncing.
> >> > >
> >> > > However, this is not done per-pin, preventing us from using the generic
> >> > > pinconf binding for that,
> >> >
> >> > How typical.
> >> >
> >> > > but per irq bank, which, depending on the SoC,
> >> > > ranges from one to five.
> >> > >
> >> > > Introduce a device-wide property to deal with this using a nanosecond
> >> > > resolution.
> >> > >
> >> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >> > (...)
> >> > > +Note: For backward compatibility reasons, the hosc and losc clocks are
> >> > > +only required if you need to use the optional
> >> > > +allwinner,debounce-time-ns property. Any new device tree should set them.
> >> > > +
> >> > > +Optional properties:
> >> > > + - allwinner,debounce-time-ns: Array of debouncing periods in
> >> > > + nanoseconds. One period per irq bank found in the controller
> >> >
> >> > Do you really *need* to specify this with nanosecond resolution?
> >> >
> >> > Else I would suggest to use microsecond resolution and just use
> >> > the generic binding (input-debounce) but on the device node instead
> >> > of the specific handler.
> >>
> >> Theorically, the debouncing clock can be set at 24MHz, which means a
> >> 42ns resolution.
> >>
> >> I've seen that the other bindings usually use microseconds, but in our
> >> case, we can really go lower than that.
> >>
> >> I don't really know if it makes sense though.
> >
> > Any comments on this?
>
> My first thought: can you atleast support both?
>
> My preference would be to add the standard binding and use that,
> and the day you realize that "howli mackarowli, this thingofabob
> actually needs to specify with nanosecond precision" then we
> could add the nanosecond granularity binding?
That works for me. I'll resend the patch.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC][ATCH 3/3] syscalls: Remove start and number from syscall_get_arguments() args
From: Steven Rostedt @ 2016-11-08 19:21 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-kernel@vger.kernel.org, Linus Torvalds, Ingo Molnar,
Andrew Morton, Roland McGrath, Oleg Nesterov, linux-arch,
Peter Zijlstra
In-Reply-To: <CALCETrVt-tPAFOx5wMvA51pjO51VyNwN5cP821WsagDGdjM36Q@mail.gmail.com>
On Mon, 7 Nov 2016 15:54:14 -0800
Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Nov 7, 2016 at 1:26 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > From: Steven Rostedt <rostedt@goodmis.org>
> >
>
> > diff --git a/arch/x86/include/asm/syscall.h b/arch/x86/include/asm/syscall.h
> > index e3c95e8e61c5..050891169b51 100644
> > --- a/arch/x86/include/asm/syscall.h
> > +++ b/arch/x86/include/asm/syscall.h
>
> x86 part is:
>
> Reviewed-by: Andy Lutomirski <luto@kernel.org>
>
> Although I wonder why this takes a task argument.
Thanks, although kbuild bot discovered a slight mistake:
} else {
# endif
*args++ = regs->di;
Should be:
} else
# endif
{
*args++ = regs->di;
I'll update, and also look at making it a struct.
-- Steve
^ permalink raw reply
* Re: [PATCH 1/1 v7] ARM: imx: Added perf functionality to mmdc driver
From: Zhi Li @ 2016-11-08 19:21 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Frank Li, Shawn Guo, linux-arm-kernel@lists.infradead.org, LKML,
Peter Zijlstra, Ingo Molnar, acme, alexander.shishkin,
Mark Rutland, jerry shen, Zhengyu Shen
In-Reply-To: <CAP=VYLo_p3ZmOFcyM9om_31-=5O3ZiRLCBkJDDtj84JxAA7h8Q@mail.gmail.com>
On Tue, Nov 8, 2016 at 1:00 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> On Mon, Sep 19, 2016 at 1:47 PM, Frank Li <Frank.Li@nxp.com> wrote:
>> From: Zhengyu Shen <zhengyu.shen@nxp.com>
>>
>> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64
>> and LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high
>> performance, and optimized. MMDC is present on i.MX6 Quad and i.MX6
>> QuadPlus devices, but this driver only supports i.MX6 Quad at the moment.
>> MMDC provides registers for performance counters which read via this
>> driver to help debug memory throughput and similar issues.
>>
>> $ perf stat -a -e mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/ dd if=/dev/zero of=/dev/null bs=1M count=5000
>> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
>>
>> 898021787 mmdc/busy-cycles/
>> 14819600 mmdc/read-accesses/
>> 471.30 MB mmdc/read-bytes/
>> 2815419216 mmdc/total-cycles/
>> 13367354 mmdc/write-accesses/
>> 427.76 MB mmdc/write-bytes/
>>
>> 5.334757334 seconds time elapsed
>>
>> Signed-off-by: Zhengyu Shen <zhengyu.shen@nxp.com>
>> Signed-off-by: Frank Li <frank.li@nxp.com>
>> ---
>> Changes from v6 to v7
>> use mmdc_pmu prefix
>> remove unnecessary check
>> improve group event check according to mark's feedback.
>> check pmu_mmdc->mmdc_events[cfg] at event_add
>> only check == 0 at event_del
>>
>> Changes from v5 to v6
>> Improve group event error handle
>>
>> Changes from v4 to v5
>> Remove mmdc_pmu:irq
>> remove static variable cpuhp_mmdc_pmu
>> remove spin_lock
>> check is_sampling_event(event)
>> remove unnecessary cast
>> use hw_perf_event::prev_count
>>
>> Changes from v3 to v4:
>> Tested and fixed crash relating to removing events with perf fuzzer
>> Adjusted formatting
>> Moved all perf event code under CONFIG_PERF_EVENTS
>> Switched cpuhp_setup_state to cpuhp_setup_state_nocalls
>>
>> Changes from v2 to v3:
>> Use WARN_ONCE instead of returning generic error values
>> Replace CPU Notifiers with newer state machine hotplug
>> Added additional checks on event_init for grouping and sampling
>> Remove useless mmdc_enable_profiling function
>> Added comments
>> Moved start index of events from 0x01 to 0x00
>> Added a counter to pmu_mmdc to only stop hrtimer after all events are finished
>> Replace readl_relaxed and writel_relaxed with readl and writel
>> Removed duplicate update function
>> Used devm_kasprintf when naming mmdcs probed
>>
>> Changes from v1 to v2:
>> Added cpumask and migration handling support to driver
>> Validated event during event_init
>> Added code to properly stop counters
>> Used perf_invalid_context instead of perf_sw_context
>> Added hrtimer to poll for overflow
>> Added better description
>> Added support for multiple mmdcs
>>
>> arch/arm/mach-imx/mmdc.c | 459 ++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 457 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
>> index db9621c..1f70376 100644
>> --- a/arch/arm/mach-imx/mmdc.c
>> +++ b/arch/arm/mach-imx/mmdc.c
>> @@ -1,5 +1,5 @@
>> /*
>> - * Copyright 2011 Freescale Semiconductor, Inc.
>> + * Copyright 2011,2016 Freescale Semiconductor, Inc.
>> * Copyright 2011 Linaro Ltd.
>> *
>> * The code contained herein is licensed under the GNU General Public
>> @@ -10,12 +10,16 @@
>> * http://www.gnu.org/copyleft/gpl.html
>> */
>>
>> +#include <linux/hrtimer.h>
>> #include <linux/init.h>
>> +#include <linux/interrupt.h>
>> #include <linux/io.h>
>> #include <linux/module.h>
>> #include <linux/of.h>
>> #include <linux/of_address.h>
>> #include <linux/of_device.h>
>> +#include <linux/perf_event.h>
>> +#include <linux/slab.h>
>>
>> #include "common.h"
>>
>> @@ -27,8 +31,458 @@
>> #define BM_MMDC_MDMISC_DDR_TYPE 0x18
>> #define BP_MMDC_MDMISC_DDR_TYPE 0x3
>>
>> +#define TOTAL_CYCLES 0x0
>> +#define BUSY_CYCLES 0x1
>> +#define READ_ACCESSES 0x2
>> +#define WRITE_ACCESSES 0x3
>> +#define READ_BYTES 0x4
>> +#define WRITE_BYTES 0x5
>> +
>> +/* Enables, resets, freezes, overflow profiling*/
>> +#define DBG_DIS 0x0
>> +#define DBG_EN 0x1
>> +#define DBG_RST 0x2
>> +#define PRF_FRZ 0x4
>> +#define CYC_OVF 0x8
>> +
>> +#define MMDC_MADPCR0 0x410
>> +#define MMDC_MADPSR0 0x418
>> +#define MMDC_MADPSR1 0x41C
>> +#define MMDC_MADPSR2 0x420
>> +#define MMDC_MADPSR3 0x424
>> +#define MMDC_MADPSR4 0x428
>> +#define MMDC_MADPSR5 0x42C
>> +
>> +#define MMDC_NUM_COUNTERS 6
>> +
>> +#define to_mmdc_pmu(p) container_of(p, struct mmdc_pmu, pmu)
>> +
>> static int ddr_type;
>>
>> +#ifdef CONFIG_PERF_EVENTS
>> +
>> +static DEFINE_IDA(mmdc_ida);
>> +
>> +PMU_EVENT_ATTR_STRING(total-cycles, mmdc_pmu_total_cycles, "event=0x00")
>> +PMU_EVENT_ATTR_STRING(busy-cycles, mmdc_pmu_busy_cycles, "event=0x01")
>> +PMU_EVENT_ATTR_STRING(read-accesses, mmdc_pmu_read_accesses, "event=0x02")
>> +PMU_EVENT_ATTR_STRING(write-accesses, mmdc_pmu_write_accesses, "config=0x03")
>> +PMU_EVENT_ATTR_STRING(read-bytes, mmdc_pmu_read_bytes, "event=0x04")
>> +PMU_EVENT_ATTR_STRING(read-bytes.unit, mmdc_pmu_read_bytes_unit, "MB");
>> +PMU_EVENT_ATTR_STRING(read-bytes.scale, mmdc_pmu_read_bytes_scale, "0.000001");
>> +PMU_EVENT_ATTR_STRING(write-bytes, mmdc_pmu_write_bytes, "event=0x05")
>> +PMU_EVENT_ATTR_STRING(write-bytes.unit, mmdc_pmu_write_bytes_unit, "MB");
>> +PMU_EVENT_ATTR_STRING(write-bytes.scale, mmdc_pmu_write_bytes_scale, "0.000001");
>> +
>> +struct mmdc_pmu {
>> + struct pmu pmu;
>> + void __iomem *mmdc_base;
>> + cpumask_t cpu;
>> + struct hrtimer hrtimer;
>> + unsigned int active_events;
>> + struct device *dev;
>> + struct perf_event *mmdc_events[MMDC_NUM_COUNTERS];
>> + struct hlist_node node;
>> +};
>> +
>> +/*
>> + * Polling period is set to one second, overflow of total-cycles (the fastest
>> + * increasing counter) takes ten seconds so one second is safe
>> + */
>> +static unsigned int mmdc_pmu_poll_period_us = 1000000;
>> +
>> +module_param_named(pmu_pmu_poll_period_us, mmdc_pmu_poll_period_us, uint,
>> + S_IRUGO | S_IWUSR);
>
> I just noticed this commit now that linux-next is back after the week off.
>
> This should probably use core_param or setup_param since the Kconfig
> for this is bool and not tristate. Similarly, that means that the .remove
> function you've added is dead code -- unless you envision a case where
> the user needs to forcibly unbind the driver...
>
> Do you want to redo the existing commit or do you want me to submit
> a follow-up fixup patch?
I will do follow-up fixup patch.
I think pmu_pmu_poll_period_us should be removed because no benefit to
change it.
I can delete .remove
best regards
Frank Li
>
> Thanks
> Paul.
> --
>
>> +
>> +static ktime_t mmdc_pmu_timer_period(void)
>> +{
>> + return ns_to_ktime((u64)mmdc_pmu_poll_period_us * 1000);
>> +}
>> +
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.