* Re: [PATCH kvm-unit-tests v2 08/17] pci: provide pci_scan_bars()
From: Peter Xu @ 2016-11-14 21:27 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvm, rkrcmar, agordeev, jan.kiszka, pbonzini
In-Reply-To: <20161114211834.ixslran5xejinji6@hawk.localdomain>
On Mon, Nov 14, 2016 at 10:18:34PM +0100, Andrew Jones wrote:
[...]
> > diff --git a/lib/pci.c b/lib/pci.c
> > index 0593699..2a58b30 100644
> > --- a/lib/pci.c
> > +++ b/lib/pci.c
> > @@ -230,11 +230,15 @@ void pci_print(void)
> >
> > void pci_scan_bars(struct pci_dev *dev)
> > {
> > - int i = 0;
> > + int i;
> > +
> > + memset(&dev->bar[0], 0, sizeof(dev->bar));
>
> I'm not sure what this memset is for. Anyway, if you need to zero a
> bar, why not just
>
> bar = (phys_addr_t)0;
The memset is to zero all bars before hand. But I think bar =
(phys_addr_t)0 works enough here:
void pci_scan_bars(struct pci_dev *dev)
{
int i;
for (i = 0; i < PCI_BAR_NUM; i++) {
if (!pci_bar_is_valid(dev, i))
continue;
dev->bar[i] = pci_bar_get_addr(dev, i);
if (pci_bar_is64(dev, i)) {
i++;
dev->bar[i] = (phys_addr_t)0;
}
}
}
Thanks,
-- peterx
^ permalink raw reply
* Re: [PATCH 6/6] usb: musb: Drop pointless PM runtime code for dsps glue
From: Tony Lindgren @ 2016-11-14 21:26 UTC (permalink / raw)
To: Johan Hovold
Cc: Bin Liu, Boris Brezillon, Greg Kroah-Hartman, Andreas Kemnade,
Felipe Balbi, George Cherian, Kishon Vijay Abraham I,
Ivaylo Dimitrov, Ladislav Michl, Laurent Pinchart,
Sergei Shtylyov, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114155916.GV14744@localhost>
* Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161114 07:59]:
> On Fri, Nov 11, 2016 at 10:43:02AM -0800, Tony Lindgren wrote:
> > This already gets done automatically by PM runtime and we have
> > a separate autosuspend timeout in musb_core.c.
> >
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>
> > @@ -816,8 +801,6 @@ static int dsps_remove(struct platform_device *pdev)
> > platform_device_unregister(glue->musb);
> >
> > /* disable usbss clocks */
>
> Perhaps also drop this comment which no longer applies.
OK will drop and repost the whole series one more time on Tuesday
in case more comments are still coming.
> > - pm_runtime_dont_use_autosuspend(&pdev->dev);
> > - pm_runtime_put_sync(&pdev->dev);
> > pm_runtime_disable(&pdev->dev);
>
> Reviewed-by: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: rgw/multisite: unlock failure problem
From: Yehuda Sadeh-Weinraub @ 2016-11-14 21:26 UTC (permalink / raw)
To: Tianshan Qu; +Cc: ceph-devel
In-Reply-To: <CAEv+sP6p9sdMt61yucxy10azo5jwQf-e765YbcHvDYQcXrfWPQ@mail.gmail.com>
On Sun, Nov 13, 2016 at 10:40 PM, Tianshan Qu <qutianshan@gmail.com> wrote:
> Hi:
>
> There is a problem with unlock multiste sync log.
> The situation is set rgw_num_rados_handles > 1 and
> rgw_num_async_rados_threads default 32. since multisite use async
> thread pool, so lock and unlock operation may get different threads,
> which may direct to different rados handles, and lock operation use
> client.xxxx to identify owner, different rados handles means different
> client, leads to unlock fail, and next lock will return locked, rgw
> log will show many -16 error.
> Is there a good way to solve this?
Can you open a ceph tracker issue for that?
Thanks,
Yehuda
^ permalink raw reply
* [PATCH] qla2xxx: do not abort all commands in the adapter during EEH recovery
From: Mauricio Faria de Oliveira @ 2016-11-14 21:26 UTC (permalink / raw)
To: Himanshu.Madhani, qla2xxx-upstream
Cc: martin.petersen, jejb, linux-scsi, linux-kernel
The previous commit ("qla2xxx: fix invalid DMA access after command
aborts in PCI device remove") introduced a regression during an EEH
recovery, since the change to the qla2x00_abort_all_cmds() function
calls qla2xxx_eh_abort(), which verifies the EEH recovery condition
but handles it heavy-handed. (commit a465537ad1a4 "qla2xxx: Disable
the adapter and skip error recovery in case of register disconnect.")
This problem warrants a more general/optimistic solution right into
qla2xxx_eh_abort() (eg in case a real command abort arrives during
EEH recovery, or if it takes long enough to trigger command aborts);
but it's still worth to add a check to ensure the code added by the
previous commit is correct and contained within its owner function.
This commit just adds a 'if (!ha->flags.eeh_busy)' check around it.
(ahem; a trivial fix for this -rc series; sorry for this oversight.)
With it applied, both PCI device remove and EEH recovery works fine.
Fixes: 1535aa75a3d8 ("scsi: qla2xxx: fix invalid DMA access after
command aborts in PCI device remove")
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
---
drivers/scsi/qla2xxx/qla_os.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 567fa080e261..56d6142852a5 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -1456,15 +1456,20 @@ uint32_t qla2x00_isp_reg_stat(struct qla_hw_data *ha)
for (cnt = 1; cnt < req->num_outstanding_cmds; cnt++) {
sp = req->outstanding_cmds[cnt];
if (sp) {
- /* Get a reference to the sp and drop the lock.
- * The reference ensures this sp->done() call
- * - and not the call in qla2xxx_eh_abort() -
- * ends the SCSI command (with result 'res').
+ /* Don't abort commands in adapter during EEH
+ * recovery as it's not accessible/responding.
*/
- sp_get(sp);
- spin_unlock_irqrestore(&ha->hardware_lock, flags);
- qla2xxx_eh_abort(GET_CMD_SP(sp));
- spin_lock_irqsave(&ha->hardware_lock, flags);
+ if (!ha->flags.eeh_busy) {
+ /* Get a reference to the sp and drop the lock.
+ * The reference ensures this sp->done() call
+ * - and not the call in qla2xxx_eh_abort() -
+ * ends the SCSI command (with result 'res').
+ */
+ sp_get(sp);
+ spin_unlock_irqrestore(&ha->hardware_lock, flags);
+ qla2xxx_eh_abort(GET_CMD_SP(sp));
+ spin_lock_irqsave(&ha->hardware_lock, flags);
+ }
req->outstanding_cmds[cnt] = NULL;
sp->done(vha, sp, res);
}
--
1.8.3.1
^ permalink raw reply related
* [Buildroot] [PATCH v1 2/2] openjpeg: fix static linking of liblcms2
From: Peter Seiderer @ 2016-11-14 21:26 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161113143415.611cb424@free-electrons.com>
Hello Thomas,
On Sun, 13 Nov 2016 14:34:15 +0100, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 11 Nov 2016 23:54:11 +0100, Peter Seiderer wrote:
> > Fixes [1]:
> >
> > .../host/usr/bfin-buildroot-uclinux-uclibc/sysroot/usr/lib/liblcms2.a(cmsplugin.o): In function `_cmsDeleteContext':
> > cmsplugin.c:(.text+0x1c2): undefined reference to `_pthread_mutex_lock'
> > cmsplugin.c:(.text+0x1f6): undefined reference to `_pthread_mutex_unlock'
> >
> > http://autobuild.buildroot.net/results/5ce/5cee20afd8bef5268832cddcb3a5270746be7a57
> >
> > Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> > ---
> > Depends on [2] from Samuel Martin.
>
> Applied to master, thanks. Also, please submit the patch upstream.
O.k, done [1] ...
Regards,
Peter
[1] https://github.com/uclouvain/openjpeg/pull/867
> Thanks!
>
> Thomas
^ permalink raw reply
* Re: [PATCH] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: Florian Fainelli @ 2016-11-14 21:25 UTC (permalink / raw)
To: David Miller, alex.g; +Cc: gokhan, netdev, linux-kernel
In-Reply-To: <20161114.161818.1460191406108019273.davem@davemloft.net>
On 11/14/2016 01:18 PM, David Miller wrote:
> From: Alexandru Gagniuc <alex.g@adaptrum.com>
> Date: Sat, 12 Nov 2016 15:32:13 -0800
>
>> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
>> + ret = vsc8601_add_skew(phydev);
>
> I think you should use phy_interface_is_rgmii() here.
>
This would include all RGMII modes, here I think the intent is to check
for PHY_INTERFACE_MODE_RGMII_ID and PHY_INTERFACE_MODE_RGMII_TXID (or
RXID), Alexandru, what direction does the skew settings apply to?
--
Florian
^ permalink raw reply
* [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program
From: Alexander Graf @ 2016-11-14 21:24 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ3NXN_0vdiFcXoGjv5dzpz2fJYRRth2VvzrYqeYyKsCqQ@mail.gmail.com>
On 14/11/2016 21:58, Simon Glass wrote:
> Hi Alex,
>
> On 14 November 2016 at 13:46, Alexander Graf <agraf@suse.de> wrote:
>>
>>
>> On 14/11/2016 21:44, Simon Glass wrote:
>>>
>>> Hi Alex,
>>>
>>> On 11 November 2016 at 23:23, Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>>
>>>>
>>>>> Am 11.11.2016 um 17:17 schrieb Simon Glass <sjg@chromium.org>:
>>>>>
>>>>> Hi Alex,
>>>>>
>>>>>> On 7 November 2016 at 09:32, Alexander Graf <agraf@suse.de> wrote:
>>>>>>
>>>>>>
>>>>>>> On 07/11/2016 10:46, Simon Glass wrote:
>>>>>>>
>>>>>>> Hi Alex,
>>>>>>>
>>>>>>>> On 19 October 2016 at 01:09, Alexander Graf <agraf@suse.de> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 18/10/2016 22:37, Simon Glass wrote:
>>>>>>>>>
>>>>>>>>> Hi Alex,
>>>>>>>>>
>>>>>>>>>> On 18 October 2016 at 01:14, Alexander Graf <agraf@suse.de> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 10/18/2016 04:29 AM, Simon Glass wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It is useful to have a basic sanity check for EFI loader support.
>>>>>>>>>>> Add
>>>>>>>>>>> a
>>>>>>>>>>> 'bootefi hello' command which loads HelloWord.efi and runs it
>>>>>>>>>>> under
>>>>>>>>>>> U-Boot.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> Changes in v3:
>>>>>>>>>>> - Include a link to the program instead of adding it to the tree
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> So, uh, where is the link?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I put it in the README (see the arm patch).
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'm really not convinced this command buys us anything yet. I do
>>>>>>>>>> agree
>>>>>>>>>> that
>>>>>>>>>> we want automated testing - but can't we get that using QEMU and a
>>>>>>>>>> downloadable image file that we pass in as disk and have the distro
>>>>>>>>>> boot do
>>>>>>>>>> its magic?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That seems very heavyweight as a sanity check, although I agree it
>>>>>>>>> is
>>>>>>>>> useful.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It's not really much more heavy weight. The "image file" could simply
>>>>>>>> contain your hello world binary. But with this we don't just verify
>>>>>>>> whether "bootefi" works, but also whether the default boot path works
>>>>>>>> ok.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I don't think I understand what you mean by 'image file'. Is it
>>>>>>> something other than the .efi file? Do you mean a disk image?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes. For reasonable test coverage, we should also verify that the
>>>>>> distro
>>>>>> defaults wrote a sane boot script that automatically searches for a
>>>>>> default
>>>>>> EFI binary in /efi/boot/bootx86.efi on the first partition of all
>>>>>> devices
>>>>>> and runs it.
>>>>>>
>>>>>> So if we just provide an SD card image or hard disk image to QEMU which
>>>>>> contains a hello world .efi binary as that default boot file, we don't
>>>>>> only
>>>>>> test whether the "bootefi" command works, but also whether the distro
>>>>>> boot
>>>>>> script works.
>>>>>
>>>>>
>>>>> That's right.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> Here I am just making sure that EFI programs can start, print output
>>>>>>>>> and exit. It is a test that we can easily run without a lot of
>>>>>>>>> overhead, much less than a full distro boot.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Again, I don't think it's much more overhead and I do believe it
>>>>>>>> gives
>>>>>>>> us much cleaner separation between responsibilities of code (tests go
>>>>>>>> where tests are).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> You are talking about a functional test, something that tests things
>>>>>>> end to end. I prefer to at least start with a smaller test. Granted it
>>>>>>> takes a little more work but it means there are fewer things to hunt
>>>>>>> through when something goes wrong.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, I personally find unit tests terribly annoying and unproductive
>>>>>> and
>>>>>> functional tests very helpful :). And in this case, the effort to write
>>>>>> it
>>>>>> is about the same for both, just that the functional test actually
>>>>>> tells you
>>>>>> that things work or don't work at the end of the day.
>>>>>>
>>>>>> With a code base like U-Boot, a simple functional test like the above
>>>>>> plus
>>>>>> git bisect should get you to an offending patch very quickly.
>>>>>
>>>>>
>>>>> This is not a unit test - in fact the EFI stuff has no unit tests. I
>>>>> suppose if we are trying to find a name this is a small functional
>>>>> test since it exercises the general functionality.
>>>>>
>>>>> I am much keener on small tests than large ones for finding simple
>>>>> bugs. Of course you can generally bisect to find a bug, but the more
>>>>> layers of software you need to look for the harder this is.
>>>>>
>>>>> We could definitely use a pytest which checks an EFI boot into an
>>>>> image, but I don't think this obviates the need for a smaller targeted
>>>>> test like this one.
>>>>
>>>>
>>>> I think arguing over this is moot :). More tests is usually a good thing,
>>>> so whoever gets to write them gets to push them ;). As long as the licenses
>>>> are sound at least.
>>>
>>>
>>> OK good, well please can you review this at some point?
>>
>>
>> Review what exactly?
>
> I mean the patches. There should be ~14 in your queue.
Interesting. I see them on patchwork, but neither in my U-Boot folder,
my inbox nor my spam folder. I wonder what happened there.
Alex
^ permalink raw reply
* Re: [PATCH 3/4] PCI: dra7xx: Add support to force RC to work in GEN1 mode
From: Bjorn Helgaas @ 2016-11-14 21:24 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Rob Herring, linux-omap, linux-pci, devicetree,
linux-kernel, nsekhar, Shawn Lin
In-Reply-To: <8ecc1325-365d-bdec-d435-729e0ea49d20@ti.com>
[+cc Shawn]
On Sat, Nov 12, 2016 at 12:40:10PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 02:45 AM, Bjorn Helgaas wrote:
> > Hi Kishon,
> >
> > On Tue, Oct 11, 2016 at 06:28:34PM +0530, Kishon Vijay Abraham I wrote:
> >> PCIe in AM57x/DRA7x devices is by default
> >> configured to work in GEN2 mode. However there
> >> may be situations when working in GEN1 mode is
> >> desired. One example is limitation i925 (PCIe GEN2
> >> mode not supported at junction temperatures < 0C).
> >>
> >> Add support to force Root Complex to work in GEN1
> >> mode if so desired, but don't force GEN1 mode on
> >> any board just yet.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> >> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> >> ---
> >> Documentation/devicetree/bindings/pci/ti-pci.txt | 1 +
> >> drivers/pci/host/pci-dra7xx.c | 27 ++++++++++++++++++++++
> >> 2 files changed, 28 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> index 60e2516..a3d6ca3 100644
> >> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> @@ -25,6 +25,7 @@ PCIe Designware Controller
> >>
> >> Optional Property:
> >> - gpios : Should be added if a gpio line is required to drive PERST# line
> >> + - ti,pcie-is-gen1 : Force the PCIe controller to work in GEN1 (2.5 GT/s).
> >
> > Can we use "max-link-speed" so it's similar to imx6?
>
> yeah, maybe we should make it a generic PCI property?
I forgot that Shawn has already done this! I had already merged those
patches on pci/host-rockchip, but I moved them to pci/host since
they're not Rockchip-specific. Can you take a look at that and see if
you can do what you need based on that pci/host branch?
Bjorn
^ permalink raw reply
* [U-Boot] [PATCH v6 1/2] armv8/fsl-layerscape: fdt: fixup LS1043A rev1 GIC node
From: york sun @ 2016-11-14 21:24 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1477970547-28846-1-git-send-email-wenbin.song@nxp.com>
On 10/31/2016 08:35 PM, Wenbin song wrote:
> The LS1043A rev1.1 silicon supports two types of GIC offset: 4K alignment
> and 64K alignment. The bit SCFG_GIC400_ALIGN[GIC_ADDR_BIT] is used to choose
> which offset will be used. If GIC_ADDR_BIT bit is set, 4K alignment is used,
> or else 64K alignment is used. The rev1.0 silicon only supports the CIG offset
> with 4K alignment.
Wenbin,
According to your patch and your explanation, the rev 1 SoC supports 4K
alignment only. The rev 1.1 and newer SoC supports both 4K and 64K. If
you don't do anything in PBI, the default is 64K. Does this 64k
alignment apply to any other SoCs?
York
^ permalink raw reply
* Re: [PATCH 3/4] PCI: dra7xx: Add support to force RC to work in GEN1 mode
From: Bjorn Helgaas @ 2016-11-14 21:24 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Bjorn Helgaas, Rob Herring, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
Shawn Lin
In-Reply-To: <8ecc1325-365d-bdec-d435-729e0ea49d20-l0cyMroinI0@public.gmane.org>
[+cc Shawn]
On Sat, Nov 12, 2016 at 12:40:10PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 02:45 AM, Bjorn Helgaas wrote:
> > Hi Kishon,
> >
> > On Tue, Oct 11, 2016 at 06:28:34PM +0530, Kishon Vijay Abraham I wrote:
> >> PCIe in AM57x/DRA7x devices is by default
> >> configured to work in GEN2 mode. However there
> >> may be situations when working in GEN1 mode is
> >> desired. One example is limitation i925 (PCIe GEN2
> >> mode not supported at junction temperatures < 0C).
> >>
> >> Add support to force Root Complex to work in GEN1
> >> mode if so desired, but don't force GEN1 mode on
> >> any board just yet.
> >>
> >> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> >> Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
> >> ---
> >> Documentation/devicetree/bindings/pci/ti-pci.txt | 1 +
> >> drivers/pci/host/pci-dra7xx.c | 27 ++++++++++++++++++++++
> >> 2 files changed, 28 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> index 60e2516..a3d6ca3 100644
> >> --- a/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> +++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
> >> @@ -25,6 +25,7 @@ PCIe Designware Controller
> >>
> >> Optional Property:
> >> - gpios : Should be added if a gpio line is required to drive PERST# line
> >> + - ti,pcie-is-gen1 : Force the PCIe controller to work in GEN1 (2.5 GT/s).
> >
> > Can we use "max-link-speed" so it's similar to imx6?
>
> yeah, maybe we should make it a generic PCI property?
I forgot that Shawn has already done this! I had already merged those
patches on pci/host-rockchip, but I moved them to pci/host since
they're not Rockchip-specific. Can you take a look at that and see if
you can do what you need based on that pci/host branch?
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] sctp: change sk state only when it has assocs in sctp_shutdown
From: David Miller @ 2016-11-14 21:23 UTC (permalink / raw)
To: lucien.xin
Cc: netdev, linux-sctp, marcelo.leitner, nhorman, vyasevich,
andreyknvl
In-Reply-To: <d260f8b59f52d7ef00b83a554fc19d4aa91766a2.1479044677.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sun, 13 Nov 2016 21:44:37 +0800
> Now when users shutdown a sock with SEND_SHUTDOWN in sctp, even if
> this sock has no connection (assoc), sk state would be changed to
> SCTP_SS_CLOSING, which is not as we expect.
>
> Besides, after that if users try to listen on this sock, kernel
> could even panic when it dereference sctp_sk(sk)->bind_hash in
> sctp_inet_listen, as bind_hash is null when sock has no assoc.
>
> This patch is to move sk state change after checking sk assocs
> is not empty, and also merge these two if() conditions and reduce
> indent level.
>
> Fixes: d46e416c11c8 ("sctp: sctp should change socket state when shutdown is received")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: change sk state only when it has assocs in sctp_shutdown
From: David Miller @ 2016-11-14 21:23 UTC (permalink / raw)
To: lucien.xin
Cc: netdev, linux-sctp, marcelo.leitner, nhorman, vyasevich,
andreyknvl
In-Reply-To: <d260f8b59f52d7ef00b83a554fc19d4aa91766a2.1479044677.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sun, 13 Nov 2016 21:44:37 +0800
> Now when users shutdown a sock with SEND_SHUTDOWN in sctp, even if
> this sock has no connection (assoc), sk state would be changed to
> SCTP_SS_CLOSING, which is not as we expect.
>
> Besides, after that if users try to listen on this sock, kernel
> could even panic when it dereference sctp_sk(sk)->bind_hash in
> sctp_inet_listen, as bind_hash is null when sock has no assoc.
>
> This patch is to move sk state change after checking sk assocs
> is not empty, and also merge these two if() conditions and reduce
> indent level.
>
> Fixes: d46e416c11c8 ("sctp: sctp should change socket state when shutdown is received")
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Zygo Blaxell @ 2016-11-14 21:22 UTC (permalink / raw)
To: James Pharaoh; +Cc: Austin S. Hemmelgarn, Mark Fasheh, linux-btrfs
In-Reply-To: <ab787485-c6ba-cada-07c5-f226d1c395e2@wellbehavedsoftware.com>
[-- Attachment #1: Type: text/plain, Size: 3411 bytes --]
On Mon, Nov 14, 2016 at 09:07:51PM +0100, James Pharaoh wrote:
> On 14/11/16 20:51, Zygo Blaxell wrote:
> >On Mon, Nov 14, 2016 at 01:39:02PM -0500, Austin S. Hemmelgarn wrote:
> >>On 2016-11-14 13:22, James Pharaoh wrote:
> >>>One thing I am keen to understand is if BTRFS will automatically ignore
> >>>a request to deduplicate a file if it is already deduplicated? Given the
> >>>performance I see when doing a repeat deduplication, it seems to me that
> >>>it can't be doing so, although this could be caused by the CPU usage you
> >>>mention above.
> >>
> >>What's happening is that the dedupe ioctl does a byte-wise comparison of the
> >>ranges to make sure they're the same before linking them. This is actually
> >>what takes most of the time when calling the ioctl, and is part of why it
> >>takes longer the larger the range to deduplicate is. In essence, it's
> >>behaving like an OS should and not trusting userspace to make reasonable
> >>requests (which is also why there's a separate ioctl to clone a range from
> >>another file instead of deduplicating existing data).
> >
> > - the extent-same ioctl could check to see which extents
> > are referenced by the src and dst ranges, and return success
> > immediately without reading data if they are the same (but
> > userspace should already know this, or it's wasting a huge amount
> > of time before it even calls the kernel).
>
> Yes, this is what I am talking about. I believe I should be able to read
> data about the BTRFS data structures and determine if this is the case. I
> don't care if there are false matches, due to concurrent updates, but
> there'll be a /lot/ of repeat deduplications unless I do this, because even
> if the file is identical, the mtime etc hasn't changed, and I have a record
> of previously doing a dedupe, there's no guarantee that the file hasn't been
> rewritten in place (eg by rsync), and no way that I know of to reliably
> detect if a file has been changed.
>
> I am sure there are libraries out there which can look into the data
> structures of a BTRFS file system, I haven't researched this in detail
> though. I imagine that with some kind of lock on a BTRFS root, this could be
> achieved by simply reading the data from the disk, since I believe that
> everything is copy-on-write, so no existing data should be overwritten until
> all roots referring to it are updated. Perhaps I'm missing something
> though...
FIEMAP (VFS) and SEARCH_V2 (btrfs-specific) will both give you access
to the underlying physical block numbers. SEARCH_V2 is non-trivial
to use without reverse-engineering significant parts of btrfs-progs.
SEARCH_V2 is a generic tree-searching tool which will give you all kinds
of information about btrfs structures...it's essential for a sophisticated
deduplicator and overkill for a simple one.
For full-file dedup using FIEMAP you only need to look at the "physical"
field of the first extent (if it's zero or the same as the other file, the
files cannot be deduplicated or are already deduplicated, respectively).
The source for 'filefrag' (from e2fsprogs) is good for learning how
FIEMAP works.
For block-level dedup you need to look at each extent individually.
That's much slower and full of additional caveats. If you're going down
that road it's probably better to just improve duperemove instead.
> James
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-11-14 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108115129.f315ca5feefd22614859bbe3@free.fr>
On Tue, Nov 08, 2016 at 11:51:29AM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Nov 2016 21:05:05 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens@csie.org> wrote:
> > >
> > > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > > >
> > > > > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> > > > > ---
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > >
> > > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > > the newer SoCs.
> > >
> > > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > > regmap.
> > > Many H3 registers are common with the A10, but some of them have more
> > > or less fields, the fields may be at different offsets. And, finally,
> > > some registers are completely different.
> > > This would not raise any problem, except with regmap which is really
> > > painful.
> >
> > That's weird, because regmap's regmap_field should make that much
> > easier.
>
> #define field_relaxed(addr, mask, val) \
> writel_relaxed((readl_relaxed(addr) & mask) | val, addr)
I'm not sure what you mean here.
> > > As I may understood, regmap is used to simplify suspend/resume, but, is
> > > it useful to save the I2S register on suspend?
> > > Practically, I am streaming some tune on my device. I suspend it for
> > > any reason. The next morning, I resume it. Are you sure I want to
> > > continue to hear the end of the tune?
> > >
> > > I better think that streaming should be simply stopped on suspend.
> >
> > You're mistaken. The code in there is for *runtime* suspend, ie when
> > the device is no longer used, so that case shouldn't even happen at
> > all.
> >
> > (And real suspend isn't supported anyway)
>
> Is it time to remove this useless code?
Which useless code?
> > > Then, there is no need to save the playing registers, and, here I am,
> > > there is no need to use regmap.
> > >
> > > May I go this way?
> >
> > No, please don't. regmap is also providing very useful features, such
> > as access to all the registers through debugfs, or tracing. What
> > exactly feels painful to you?
>
> When the I/O registers are in memory (that's the case), you may access
> them (read and write) thru /dev/mem.
For all the registers if you want to dump all of them. It needs
scripting, it needs root access, and it needs some tool (either devmem
or a custom one) to dump the values. And this is if you have the right
kernel configuration options (devmem enabled, with the protection
against mapped devices disabled).
It just works with debugfs.
> Also, is a register access trace really needed in this driver?
Yes.
> The pain is to define the regmap_config (which registers can be
> read/write/volatile and which can be the values the u-boot let us in
> the registers at startup time), and the lot of code which is run instead
> of simple load/store machine instructions.
This is only needed if you want to use caching, and caching is
optional.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/5cda6589/attachment.sig>
^ permalink raw reply
* Re: [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-11-14 21:22 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Chen-Yu Tsai, Dave Airlie, Liam Girdwood, Mark Brown, Rob Herring,
Linux-ALSA, devicetree, dri-devel, linux-arm-kernel, linux-sunxi
In-Reply-To: <20161108115129.f315ca5feefd22614859bbe3-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3472 bytes --]
On Tue, Nov 08, 2016 at 11:51:29AM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Nov 2016 21:05:05 +0100
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > Hi,
> >
> > On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> > >
> > > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org> wrote:
> > > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > > >
> > > > > Signed-off-by: Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org>
> > > > > ---
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > >
> > > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > > the newer SoCs.
> > >
> > > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > > regmap.
> > > Many H3 registers are common with the A10, but some of them have more
> > > or less fields, the fields may be at different offsets. And, finally,
> > > some registers are completely different.
> > > This would not raise any problem, except with regmap which is really
> > > painful.
> >
> > That's weird, because regmap's regmap_field should make that much
> > easier.
>
> #define field_relaxed(addr, mask, val) \
> writel_relaxed((readl_relaxed(addr) & mask) | val, addr)
I'm not sure what you mean here.
> > > As I may understood, regmap is used to simplify suspend/resume, but, is
> > > it useful to save the I2S register on suspend?
> > > Practically, I am streaming some tune on my device. I suspend it for
> > > any reason. The next morning, I resume it. Are you sure I want to
> > > continue to hear the end of the tune?
> > >
> > > I better think that streaming should be simply stopped on suspend.
> >
> > You're mistaken. The code in there is for *runtime* suspend, ie when
> > the device is no longer used, so that case shouldn't even happen at
> > all.
> >
> > (And real suspend isn't supported anyway)
>
> Is it time to remove this useless code?
Which useless code?
> > > Then, there is no need to save the playing registers, and, here I am,
> > > there is no need to use regmap.
> > >
> > > May I go this way?
> >
> > No, please don't. regmap is also providing very useful features, such
> > as access to all the registers through debugfs, or tracing. What
> > exactly feels painful to you?
>
> When the I/O registers are in memory (that's the case), you may access
> them (read and write) thru /dev/mem.
For all the registers if you want to dump all of them. It needs
scripting, it needs root access, and it needs some tool (either devmem
or a custom one) to dump the values. And this is if you have the right
kernel configuration options (devmem enabled, with the protection
against mapped devices disabled).
It just works with debugfs.
> Also, is a register access trace really needed in this driver?
Yes.
> The pain is to define the regmap_config (which registers can be
> read/write/volatile and which can be the values the u-boot let us in
> the registers at startup time), and the lot of code which is run instead
> of simple load/store machine instructions.
This is only needed if you want to use caching, and caching is
optional.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 5/5] PCI: Balance ports to avoid ACS errata on Pericom switches
From: Alex Williamson @ 2016-11-14 21:21 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, bhelgaas, iommu, linux-kernel
In-Reply-To: <20161114210319.GC9868@bhelgaas-glaptop.roam.corp.google.com>
On Mon, 14 Nov 2016 15:03:19 -0600
Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Oct 26, 2016 at 12:01:40PM -0600, Alex Williamson wrote:
> > As described in the included code comment, this quirk is intended to
> > work around an errata in a variety of Pericom 4-lane, 3 and 4 port
> > PCIe 2.0 switches. The switches advertise ACS capabilities, but the
> > P2P Request Redirection support includes an errata that PCI_ACS_RR
> > effectively doesn't work and results in transactions being queued and
> > not delivered within the PCIe switch. The errata has no planned
> > hardware fix.
>
> Is there a published erratum we can reference here? It'd be really
> nice to have a URL.
Unfortunately only the product briefs seem to be public. I was sent an
errata, but it's marked confidential, so I don't think I'll risk adding
it to the bz. I haven't even been granted access to the datasheet.
I'm only guessing at the affected devices IDs based on my sample of one.
One thing I've thought of since I posted this series is that it's
possible to have a configuration where the downstream ports don't all
match. If the upstream port is running at 5GT/s, the first downstream
port is also running 5GT/s, but another downstream port is running
2.5GT/s, this code will retrain the upstream port to 2.5GT/s w/o
revisiting that first port. I should fix that, but I likely won't have
time for v4.10. If you want to de-queue this, I'll try to look at it
again for v4.11 and take your other suggestions into account. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 5/5] PCI: Balance ports to avoid ACS errata on Pericom switches
From: Alex Williamson @ 2016-11-14 21:21 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114210319.GC9868-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
On Mon, 14 Nov 2016 15:03:19 -0600
Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Oct 26, 2016 at 12:01:40PM -0600, Alex Williamson wrote:
> > As described in the included code comment, this quirk is intended to
> > work around an errata in a variety of Pericom 4-lane, 3 and 4 port
> > PCIe 2.0 switches. The switches advertise ACS capabilities, but the
> > P2P Request Redirection support includes an errata that PCI_ACS_RR
> > effectively doesn't work and results in transactions being queued and
> > not delivered within the PCIe switch. The errata has no planned
> > hardware fix.
>
> Is there a published erratum we can reference here? It'd be really
> nice to have a URL.
Unfortunately only the product briefs seem to be public. I was sent an
errata, but it's marked confidential, so I don't think I'll risk adding
it to the bz. I haven't even been granted access to the datasheet.
I'm only guessing at the affected devices IDs based on my sample of one.
One thing I've thought of since I posted this series is that it's
possible to have a configuration where the downstream ports don't all
match. If the upstream port is running at 5GT/s, the first downstream
port is also running 5GT/s, but another downstream port is running
2.5GT/s, this code will retrain the upstream port to 2.5GT/s w/o
revisiting that first port. I should fix that, but I likely won't have
time for v4.10. If you want to de-queue this, I'll try to look at it
again for v4.11 and take your other suggestions into account. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v2 0/2] bnx2: Wait for in-flight DMA to complete at probe stage
From: David Miller @ 2016-11-14 21:21 UTC (permalink / raw)
To: bhe
Cc: netdev, michael.chan, linux-kernel, Dept-GELinuxNICDev,
rasesh.mody, harish.patil, frank, jsr, pmenzel, jroedel, dyoung
In-Reply-To: <1479013293-21001-1-git-send-email-bhe@redhat.com>
From: Baoquan He <bhe@redhat.com>
Date: Sun, 13 Nov 2016 13:01:31 +0800
> This is v2 post.
>
> In commit 3e1be7a ("bnx2: Reset device during driver initialization"),
> firmware requesting code was moved from open stage to probe stage.
> The reason is in kdump kernel hardware iommu need device be reset in
> driver probe stage, otherwise those in-flight DMA from 1st kernel
> will continue going and look up into the newly created io-page tables.
> However bnx2 chip resetting involves firmware requesting issue, that
> need be done in open stage.
>
> Michale Chan suggested we can just wait for the old in-flight DMA to
> complete at probe stage, then though without device resetting, we
> don't need to worry the old in-flight DMA could continue looking up
> the newly created io-page tables.
>
> v1->v2:
> Michael suggested to wait for the in-flight DMA to complete at probe
> stage. So give up the old method of trying to reset chip at probe
> stage, take the new way accordingly.
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: ✗ Fi.CI.BAT: warning for series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass
From: Chris Wilson @ 2016-11-14 21:21 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20161114211608.16476.40375@emeril.freedesktop.org>
On Mon, Nov 14, 2016 at 09:16:08PM -0000, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass
> URL : https://patchwork.freedesktop.org/series/15303/
> State : warning
>
> == Summary ==
>
> Series 15303v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/15303/revisions/1/mbox/
>
> Test drv_module_reload_basic:
> pass -> DMESG-WARN (fi-skl-6770hq)
That darn lpscon
[ 36.848874] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[ 36.848916] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [RFH] limiting ref advertisements
From: Jeff King @ 2016-11-14 21:21 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8DwKxz14Dow9dEKeXnBriMzN_OptnGM7nPigPcS_pHX9w@mail.gmail.com>
On Tue, Oct 25, 2016 at 06:46:21PM +0700, Duy Nguyen wrote:
> > So it seems like left-anchoring the refspecs can never be fully correct.
> > We can communicate "master" to the server, who can then look at every
> > ref it would advertise and ask "could this be called master"? But it
> > will be setting in stone the set of "could this be" patterns. Granted,
> > those haven't changed much over the history of git, but it seems awfully
> > fragile.
>
> The first thought that comes to mind is, if left anchoring does not
> work, let's support both left and right anchoring. I guess you
> considered and discarded this.
>
> If prefix matching does not work, and assuming "some-prefix" sent by
> client to be in fact "**/some-prefix" pattern at server side will set
> the "could this be" in stone, how about use wildmatch? It's flexible
> enough and we have full control over the pattern matching engine so C
> Git <-> C Git should be good regardless of platforms. I understand
> that wildmatch is still complicated enough that a re-implementation
> can easily divert in behavior. But a pattern with only '*', '/**',
> '/**/' and '**/' wildcards (in other words, no [] or ?) could make the
> engine a lot simpler and still fit our needs (and give some room for
> client-optimization).
Thanks for responding to this. I've been meaning to get back to it with
some code experiments, but they keep getting bumped down in priority. So
let me at least outline some of my thoughts, without code. :)
I was hoping to avoid right-anchoring because it's expensive to find all
of the right-anchored cases (assuming that ref storage is generally
hierarchical, which it is now and probably will be for future backends).
I also don't think it covers all cases. As bizarre as it is, I believe
you can currently do:
git fetch $remote origin
and find refs/remotes/origin/HEAD.
So I think the best we can ever do is have the server look at a specific
set of patterns. Those patterns could be expressed by wildmatch. I was
just a little nervous to turn to wildmatch, because it's complicated and
we may want to update it in the future in a slightly-incompatible way.
We also want to give some preference-order to the patterns. If I give
you "refs/heads/master", and that ref exists, you do not need to tell me
whether you also have "refs/heads/refs/heads/master". So you have to
provide multiple patterns for each possible ref. And you need to group
them as "show the first one that matches from this group".
The pattern the client is using really is the ref_rev_parse_rules. So I
think the solution is more like one of:
1. Specify the pattern set ahead of time, and then the server applies
it to each refname. We need some pattern language that can express
"fill in the thing in the middle". IOW, something like:
advertise-pattern=%s
advertise-pattern=refs/tags/%s
advertise-pattern=refs/heads/%s
advertise-lookup=master
advertise-lookup=v1.0
except that the thought of using snprintf() to handle formats
provided by the user is vaguely terrifying. We could make sure they
contain only a single "%s", but given the history there, it still
makes me nervous. I guess we could write our own pseudo-%s parser
that is much more careful and complains on bugs instead of
executing arbitrary code. ;)
I don't think wildmatch quite works for that, because it wants to
have the full pattern.
2. Declare the current set of ref_rev_parse_rules as "version 1", and
send:
advertise-lookup-v1=master
advertise-lookup-v1=v1.0
and the server would do the right thing. We could do a v2, but it
gets hairy. Let's imagine we add "refs/notes/%s" to the lookup
rules, and we'll call that v2.
But remember that these are "early capabilities", before the server
has spoken at all. So the client doesn't know if we can handle v2.
So we have to send _both_ (and v2-aware servers can ignore the v1).
advertise-lookup-v1=master
advertise-lookup-v2=master
But that's not quite enough. A v1 server won't look in refs/notes
at all. So we have to say that, too:
advertise-lookup-v1=refs/notes/master
And of course the v1 server has no idea that this isn't necessary
if we already found refs/heads/master.
So I think you really do need the client to be able to say "also
look at this pattern".
Of course we do still want left-anchoring, too. Wildcards like
"refs/heads/*" are always left-anchored. So I think we'd have two types,
and a full request for
git fetch origin +refs/heads/*:refs/remotes/origin/* master:foo
would look like:
(1) advertise-pattern-v1
(2) advertise-pattern=refs/notes/%s
(3) advertise-prefix=refs/heads
(4) advertise-lookup=master
where the lines mean:
1. Use the standard v1 patterns (we could spell them out, but this
just saves bandwidth. In fact, it could just be implicit that v1
patterns are included, and we could skip this line).
2. This is for our fictional future version where the client knows
added refs/notes/* to its DWIM but the server hasn't yet.
3. Give me all of refs/heads/*
4. Look up "master" using the advertise patterns and give me the first
one you find.
So given that we can omit (1), and that (2) is just an example for the
future, it could look like:
advertise-prefix=refs/heads
advertise-lookup=master
which is pretty reasonable. It's not _completely_ bulletproof in terms
of backwards compatibility. The "v1" thing means the client can't insert
a new pattern in the middle (remember they're ordered by priority). So
maybe it is better to spell them all out (one thing that makes me
hesitate is that these will probably end up as URL parameters for the
HTTP version, which means our URL can start to get a little long).
Anyway. That's the direction I'm thinking. I haven't written the code
yet. The trickiest thing will probably be that the server would want to
avoid advertising the same ref twice via two mechanisms (or perhaps the
client just be tolerant of duplicates; that relieves the server of any
duplicate-storage requirements).
-Peff
^ permalink raw reply
* [Buildroot] [PATCHv2] dtv-scan-tables: rename file to have only ASCII characters
From: Thomas Petazzoni @ 2016-11-14 21:20 UTC (permalink / raw)
To: buildroot
Since the bump of dtv-scan-tables to version
ceb11833b35f05813b1f0397a60e0f3b99430aab in commit
b1c8794d8ac0eb3895d13ae91d8e912ec469a105, one file contains non-ASCII
characters, which causes encoding issues tvheadend. Since no other
file in the dtv-scan-tables code base contains files with non-ASCII
characters (despite having files named after cities in various
countries that definitely do have non-ASCII characters), we rename
this file so that it is named with only ASCII characters.
This fixes the build of tvheadend, which was failing when the host
Python interpreter was python3, due to a file name encoding issue.
Fixes:
http://autobuild.buildroot.net/results/1ae8bee297edb089535a2fb6ec724ebf7976888d/
(tvheadend)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Changes since v1:
- use a post-patch hook instead of doing the rename at the end of the
installation step
---
package/dtv-scan-tables/dtv-scan-tables.mk | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/package/dtv-scan-tables/dtv-scan-tables.mk b/package/dtv-scan-tables/dtv-scan-tables.mk
index 8ef42b9..8a782cb 100644
--- a/package/dtv-scan-tables/dtv-scan-tables.mk
+++ b/package/dtv-scan-tables/dtv-scan-tables.mk
@@ -17,6 +17,15 @@ DTV_SCAN_TABLES_SITE_METHOD = git
DTV_SCAN_TABLES_LICENSE = GPLv2, LGPLv2.1
DTV_SCAN_TABLES_LICENSE_FILES = COPYING COPYING.LGPL
+# In order to avoid issues with file name encodings, we rename the
+# only dtv-scan-tables file that has non-ASCII characters to have a
+# name using only ASCII characters (pl-Krosno_Sucha_Gora)
+define DTV_SCAN_TABLES_FIX_NONASCII_FILENAMES
+ mv $(@D)/dvb-t/pl-Krosno_Sucha* $(@D)/dvb-t/pl-Krosno_Sucha_Gora
+endef
+
+DTV_SCAN_TABLES_POST_PATCH_HOOKS += DTV_SCAN_TABLES_FIX_NONASCII_FILENAMES
+
define DTV_SCAN_TABLES_INSTALL_TARGET_CMDS
for f in atsc dvb-c dvb-s dvb-t; do \
$(INSTALL) -d -m 0755 $(TARGET_DIR)/usr/share/dvb/$$f; \
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] cpufreq: intel_pstate: Use cpu load based algorithm for PM_MOBILE
From: Rafael J. Wysocki @ 2016-11-14 21:20 UTC (permalink / raw)
To: Srinivas Pandruvada; +Cc: linux-pm, rdunlap, sfr, arnd, linux-kernel
In-Reply-To: <1479148271-21681-1-git-send-email-srinivas.pandruvada@linux.intel.com>
On Monday, November 14, 2016 10:31:11 AM Srinivas Pandruvada wrote:
> Use get_target_pstate_use_cpu_load() to calculate target P-State for
> devices, which uses preferred power management profile as PM_MOBILE
> in ACPI FADT.
> This may help in resolving some thermal issues caused by low sustained
> cpu bound workloads. The current algorithm tend to over provision in this
> case as it doesn't look at the CPU busyness.
>
> Also included the fix from Arnd Bergmann <arnd@arndb.de> to solve compile
> issue, when CONFIG_ACPI is not defined.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> v2:
> Include fix from Arnd Bergmann for fixing compile issue
>
> drivers/cpufreq/intel_pstate.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index eb76073..9be0720 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1828,6 +1828,19 @@ static void __init copy_pid_params(struct pstate_adjust_policy *policy)
> pid_params.setpoint = policy->setpoint;
> }
>
> +#ifdef CONFIG_ACPI
> +static void intel_pstate_use_acpi_profile(void)
> +{
> + if (acpi_gbl_FADT.preferred_profile == PM_MOBILE)
> + pstate_funcs.get_target_pstate =
> + get_target_pstate_use_cpu_load;
> +}
> +#else
> +static void intel_pstate_use_acpi_profile(void)
> +{
> +}
> +#endif
> +
> static void __init copy_cpu_funcs(struct pstate_funcs *funcs)
> {
> pstate_funcs.get_max = funcs->get_max;
> @@ -1839,6 +1852,7 @@ static void __init copy_cpu_funcs(struct pstate_funcs *funcs)
> pstate_funcs.get_vid = funcs->get_vid;
> pstate_funcs.get_target_pstate = funcs->get_target_pstate;
>
> + intel_pstate_use_acpi_profile();
> }
>
> #ifdef CONFIG_ACPI
>
I've replaced the original commit with this patch.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] remote-curl: don't hang when a server dies before any output
From: Junio C Hamano @ 2016-11-14 21:19 UTC (permalink / raw)
To: Jeff King; +Cc: David Turner, git, spearce
In-Reply-To: <20161114194049.mktpsvgdhex2f4zv@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So something like this. It turned out to be a lot uglier than I had
> hoped because we get fed the data from curl in odd-sized chunks, so we
> need a state machine.
It is unfortunate that we have to snoop the protocol like this to
infer an error, but I do not think we can do better than that
approach. FWIW, I did not find the logic in update_pktline_state()
you wrote ugly at all.
Having to assume that the end of each round from the other end must
be a FLUSH does feel somewhat ugly and brittle, though.
> diff --git a/remote-curl.c b/remote-curl.c
> index f14c41f4c..605357d77 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -403,6 +403,18 @@ struct rpc_state {
> struct strbuf result;
> unsigned gzip_request : 1;
> unsigned initial_buffer : 1;
> +
> + enum {
> + RPC_PKTLINE_ERROR, /* bogus hex chars in length */
> + RPC_PKTLINE_INITIAL, /* no packets received yet */
> + RPC_PKTLINE_1, /* got one hex char */
> + RPC_PKTLINE_2, /* got two hex chars */
> + RPC_PKTLINE_3, /* got three hex chars */
> + RPC_PKTLINE_DATA, /* reading data; pktline_len holds remaining */
> + RPC_PKTLINE_END_OF_PACKET, /* last packet completed */
> + RPC_PKTLINE_FLUSH, /* last packet was flush */
> + } pktline_state;
> + size_t pktline_len;
> };
>
> static size_t rpc_out(void *ptr, size_t eltsize,
> @@ -451,11 +463,77 @@ static curlioerr rpc_ioctl(CURL *handle, int cmd, void *clientp)
> }
> #endif
>
> +static void update_pktline_state(struct rpc_state *rpc,
> + const char *buf, size_t len)
> +{
> +#define READ_ONE_HEX(shift) do { \
> + int val = hexval(buf[0]); \
> + if (val < 0) { \
> + warning("error on %d", *buf); \
> + rpc->pktline_state = RPC_PKTLINE_ERROR; \
> + return; \
> + } \
> + rpc->pktline_len |= val << shift; \
> + buf++; \
> + len--; \
> +} while(0)
> +
> + while (len > 0) {
> + switch (rpc->pktline_state) {
> + case RPC_PKTLINE_ERROR:
> + /* previous error; there is no recovery */
> + return;
> +
> + /* We can start a new pktline at any of these states */
> + case RPC_PKTLINE_INITIAL:
> + case RPC_PKTLINE_FLUSH:
> + case RPC_PKTLINE_END_OF_PACKET:
> + rpc->pktline_len = 0;
> + READ_ONE_HEX(12);
> + rpc->pktline_state = RPC_PKTLINE_1;
> + break;
> +
> + case RPC_PKTLINE_1:
> + READ_ONE_HEX(8);
> + rpc->pktline_state = RPC_PKTLINE_2;
> + break;
> +
> + case RPC_PKTLINE_2:
> + READ_ONE_HEX(4);
> + rpc->pktline_state = RPC_PKTLINE_3;
> + break;
> +
> + case RPC_PKTLINE_3:
> + READ_ONE_HEX(0);
> + if (rpc->pktline_len) {
> + rpc->pktline_state = RPC_PKTLINE_DATA;
> + rpc->pktline_len -= 4;
> + } else
> + rpc->pktline_state = RPC_PKTLINE_FLUSH;
> + break;
> +
> + case RPC_PKTLINE_DATA:
> + if (len < rpc->pktline_len) {
> + rpc->pktline_len -= len;
> + len = 0;
> + } else {
> + buf += rpc->pktline_len;
> + len -= rpc->pktline_len;
> + rpc->pktline_len = 0;
> + rpc->pktline_state = RPC_PKTLINE_END_OF_PACKET;
> + }
> + break;
> + }
> + }
> +#undef READ_ONE_HEX
> +}
> +
> static size_t rpc_in(char *ptr, size_t eltsize,
> size_t nmemb, void *buffer_)
> {
> size_t size = eltsize * nmemb;
> struct rpc_state *rpc = buffer_;
> + update_pktline_state(rpc, ptr, size);
> write_or_die(rpc->in, ptr, size);
> return size;
> }
> @@ -659,6 +737,8 @@ static int post_rpc(struct rpc_state *rpc)
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in);
> curl_easy_setopt(slot->curl, CURLOPT_FILE, rpc);
>
> + rpc->pktline_state = RPC_PKTLINE_INITIAL;
> +
> err = run_slot(slot, NULL);
> if (err == HTTP_REAUTH && !large_request) {
> credential_fill(&http_auth);
> @@ -667,6 +747,11 @@ static int post_rpc(struct rpc_state *rpc)
> if (err != HTTP_OK)
> err = -1;
>
> + if (rpc->pktline_state != RPC_PKTLINE_FLUSH) {
> + error("invalid or truncated response from http server");
> + err = -1;
> + }
> +
> curl_slist_free_all(headers);
> free(gzip_body);
> return err;
^ permalink raw reply
* Re: [PATCH -next] PCI: dra7xx: Add missing of_node_put() in dra7xx_pcie_init_irq_domain()
From: Bjorn Helgaas @ 2016-11-14 21:19 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Wei Yongjun, Bjorn Helgaas, Wei Yongjun, linux-omap, linux-pci,
Shawn Lin, Heiko Stuebner, michal.simek, soren.brinkmann,
bharat.kumar.gogada, robh, Frank Rowand, devicetree
In-Reply-To: <1d95b915-ddc0-b48f-270b-fffb60ecfe5e@ti.com>
[+cc Shawn, Heiko, Michal, Soren, Bharat, Rob H, Frank, devicetree@vger]
On Sat, Nov 12, 2016 at 12:39:01PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 03:08 AM, Bjorn Helgaas wrote:
> > On Mon, Oct 17, 2016 at 02:54:37PM +0000, Wei Yongjun wrote:
> >> From: Wei Yongjun <weiyongjun1@huawei.com>
> >>
> >> This node pointer is returned by of_get_next_child() with refcount
> >> incremented in this function. of_node_put() on it before exitting
> >> this function on error.
> >>
> >> This is detected by Coccinelle semantic patch.
> >>
> >> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> >
> > Kishon, this looks correct to me, so I applied it to pci/host-dra7xx for
> > v4.10. Let me know if you have any issue with it.
> >
> >> ---
> >> drivers/pci/host/pci-dra7xx.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> >> index 9595fad..79297e9 100644
> >> --- a/drivers/pci/host/pci-dra7xx.c
> >> +++ b/drivers/pci/host/pci-dra7xx.c
> >> @@ -177,6 +177,7 @@ static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
> >> &intx_domain_ops, pp);
> >> if (!pp->irq_domain) {
> >> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> >> + of_node_put(pcie_intc_node);
>
> I think of_node_put should be used for both the error case and non-error case.
Hmm, OK. I don't know what the rules are. Certainly if we made these
drivers modular, I don't think we'd want to leak these references
every time we unload/reload the module. Should we do the put
immediately here, or in the module remove path, or ...?
Adding other driver and DT folks for comment.
I dropped these patches for now (dra7xx, rockchip, xilinx-nwl,
xilinx).
^ permalink raw reply
* Re: [PATCH -next] PCI: dra7xx: Add missing of_node_put() in dra7xx_pcie_init_irq_domain()
From: Bjorn Helgaas @ 2016-11-14 21:19 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Wei Yongjun, Bjorn Helgaas, Wei Yongjun,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Shawn Lin, Heiko Stuebner,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA,
bharat.kumar.gogada-gjFFaj9aHVfQT0dZR+AlfA,
robh-DgEjT+Ai2ygdnm+yROfE0A, Frank Rowand,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1d95b915-ddc0-b48f-270b-fffb60ecfe5e-l0cyMroinI0@public.gmane.org>
[+cc Shawn, Heiko, Michal, Soren, Bharat, Rob H, Frank, devicetree@vger]
On Sat, Nov 12, 2016 at 12:39:01PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 03:08 AM, Bjorn Helgaas wrote:
> > On Mon, Oct 17, 2016 at 02:54:37PM +0000, Wei Yongjun wrote:
> >> From: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>
> >> This node pointer is returned by of_get_next_child() with refcount
> >> incremented in this function. of_node_put() on it before exitting
> >> this function on error.
> >>
> >> This is detected by Coccinelle semantic patch.
> >>
> >> Signed-off-by: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >
> > Kishon, this looks correct to me, so I applied it to pci/host-dra7xx for
> > v4.10. Let me know if you have any issue with it.
> >
> >> ---
> >> drivers/pci/host/pci-dra7xx.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> >> index 9595fad..79297e9 100644
> >> --- a/drivers/pci/host/pci-dra7xx.c
> >> +++ b/drivers/pci/host/pci-dra7xx.c
> >> @@ -177,6 +177,7 @@ static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
> >> &intx_domain_ops, pp);
> >> if (!pp->irq_domain) {
> >> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> >> + of_node_put(pcie_intc_node);
>
> I think of_node_put should be used for both the error case and non-error case.
Hmm, OK. I don't know what the rules are. Certainly if we made these
drivers modular, I don't think we'd want to leak these references
every time we unload/reload the module. Should we do the put
immediately here, or in the module remove path, or ...?
Adding other driver and DT folks for comment.
I dropped these patches for now (dra7xx, rockchip, xilinx-nwl,
xilinx).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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.