* Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases
From: Matt Roper @ 2016-11-09 1:38 UTC (permalink / raw)
To: Paulo Zanoni; +Cc: intel-gfx, stable
In-Reply-To: <1478636531-6081-1-git-send-email-paulo.r.zanoni@intel.com>
On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> The previous spec version said "double Ytile planes minimum lines",
> and I interpreted this as referring to what the spec calls "Y tile
> minimum", but in fact it was referring to what the spec calls "Minimum
> Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> interpretation, so I sent and email to the spec authors and got
> clarification on the correct meaning. Also, BSpec was updated and
> should be clear now.
>
> Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the memory bandwidth WA")
> Cc: stable@vger.kernel.org
> Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
This seems to match my reading of the spec update from Nov 4th, so:
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
> ---
> drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index cc9e0c0..653525f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
> y_min_scanlines = 4;
> }
>
> + if (apply_memory_bw_wa)
> + y_min_scanlines *= 2;
> +
> plane_bytes_per_line = width * cpp;
> if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv,
> plane_blocks_per_line);
>
> y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> - if (apply_memory_bw_wa)
> - y_tile_minimum *= 2;
>
> if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> --
> 2.7.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
^ permalink raw reply
* For playback method of stopping after the execution aplay command
From: 高井和也 @ 2016-11-09 1:36 UTC (permalink / raw)
To: alsa-devel
Hello
Use ALSA aplay command we have developed a device for audio reproduction.
After the audio playback at aplay command, forcibly or will not tell us
what should take what way to halt the play.
(After starting the aplay command, I tried a way to kill the process, but
it could have taken to stop playing, rarely Linux There was to be a
iowaitsleep state)
best regards
^ permalink raw reply
* Re: [v2] cw1200: Don't leak memory if krealloc failes
From: Kalle Valo @ 2016-11-09 1:37 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: Solomon Peachy, linux-wireless, netdev, linux-kernel,
Johannes Thumshirn, Johannes Berg
In-Reply-To: <1475239157-16448-1-git-send-email-jthumshirn@suse.de>
Johannes Thumshirn <jthumshirn@suse.de> wrote:
> The call to krealloc() in wsm_buf_reserve() directly assigns the newly
> returned memory to buf->begin. This is all fine except when krealloc()
> failes we loose the ability to free the old memory pointed to by
> buf->begin. If we just create a temporary variable to assign memory to
> and assign the memory to it we can mitigate the memory leak.
>
> Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
> Cc: Johannes Berg <johannes@sipsolutions.net>
Patch applied to wireless-drivers-next.git, thanks.
9afdd6128c39 cw1200: Don't leak memory if krealloc failes
--
https://patchwork.kernel.org/patch/9358185/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] cw1200: Don't leak memory if krealloc failes
From: Kalle Valo @ 2016-11-09 1:37 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: Solomon Peachy, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Johannes Thumshirn,
Johannes Berg
In-Reply-To: <1475239157-16448-1-git-send-email-jthumshirn-l3A5Bk7waGM@public.gmane.org>
Johannes Thumshirn <jthumshirn-l3A5Bk7waGM@public.gmane.org> wrote:
> The call to krealloc() in wsm_buf_reserve() directly assigns the newly
> returned memory to buf->begin. This is all fine except when krealloc()
> failes we loose the ability to free the old memory pointed to by
> buf->begin. If we just create a temporary variable to assign memory to
> and assign the memory to it we can mitigate the memory leak.
>
> Signed-off-by: Johannes Thumshirn <jthumshirn-l3A5Bk7waGM@public.gmane.org>
> Cc: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Patch applied to wireless-drivers-next.git, thanks.
9afdd6128c39 cw1200: Don't leak memory if krealloc failes
--
https://patchwork.kernel.org/patch/9358185/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 00/15] Enable L2 Cache Allocation Technology
From: Yi Sun @ 2016-11-09 1:28 UTC (permalink / raw)
To: xen-devel
Cc: wei.liu2, he.chen, andrew.cooper3, ian.jackson, jbeulich,
chao.p.peng
In-Reply-To: <1477366863-5246-1-git-send-email-yi.y.sun@linux.intel.com>
Hi, all,
Any comment or suggestion to this patch set? That would be very appreciated.
Thank you!
BRs,
Sun Yi
On 16-10-25 11:40:48, Yi Sun wrote:
> Hi all,
>
> We plan to bring a new PSR (Platform Shared Resource) feature called
> Intel L2 Cache Allocation Technology (L2 CAT) to Xen.
>
> Besides the L2 CAT implementaion, we refactor the psr.c to make it more
> flexible to add new features and fulfill the principle, open for extension
> but closed for modification. We abstract the general operations of all
> features and encapsulate them into a structure. Then, the development
> of new feature is simple to mainly implement these callback functions.
>
> The patch set can be found at:
> https://github.com/yisun-git/xen_l2_cat.git xen_l2_v3_3
>
> ---
> Changes since v2:
> * Add design document into docs/.
> * Split "refactor psr" patch to several small patches.
> * Function and variables names are changed to express accurately.
> * Revert some unnecessary changes.
> * Fix issues according to comments provided by reviewers.
>
> --
> 2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: How to handle GPIO differences between P8 and P9
From: Andrew Jeffery @ 2016-11-09 1:34 UTC (permalink / raw)
To: Xo Wang, Mine; +Cc: OpenBMC Maillist
In-Reply-To: <CAPH-5w7+to8ch2w8LDYeh97D8wTKdNKdFvtXCYJ=KhbaL7nh-Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
On Tue, 2016-11-08 at 15:38 -0800, Xo Wang wrote:
> FYI something that I didn't implement was adding GPIO polarity
> support into libopenbmc_intf/gpio. So, all the polarity (active
> high/low) logic needs to be handled by the application, which is less
> than ideal.
Ultimately this should be handled by the kernel via devicetree and
pinconf. I'd hold off on fixing the application because of that, but
there's also no timeline for implementing pinconf support in pinctrl.
Andrew
>
> cheers
> xo
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [-next] mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virtual_intf()
From: Kalle Valo @ 2016-11-09 1:34 UTC (permalink / raw)
To: Wei Yongjun
Cc: Amitkumar Karwar, Nishant Sarmukadam, Wei Yongjun, linux-wireless
In-Reply-To: <1475161076-1409-1-git-send-email-weiyj.lk@gmail.com>
Wei Yongjun <weiyj.lk@gmail.com> wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Add the missing destroy_workqueue() before return from
> mwifiex_add_virtual_intf() in the error handling case.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
424342ff0e03 mwifiex: fix missing destroy_workqueue() on error in mwifiex_add_virtual_intf()
--
https://patchwork.kernel.org/patch/9356567/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] Change the document about iowait
From: Chao Fan @ 2016-11-09 1:33 UTC (permalink / raw)
To: linux-doc, linux-kernel; +Cc: peterz, corbet, akpm, izumi.taku, Cao Jin
In-Reply-To: <1477449688-19397-1-git-send-email-fanc.fnst@cn.fujitsu.com>
ping
Thanks,
Chao Fan
On Wed, Oct 26, 2016 at 10:41:28AM +0800, Chao Fan wrote:
>The iowait is not reliable by reading from /proc/stat, so this
>method to get iowait is not suggested. And we mark it in the
>document.
>
>Signed-off-by: Cao Jin <caoj.fnst@cn.fujitsu.com>
>Signed-off-by: Chao Fan <fanc.fnst@cn.fujitsu.com>
>---
> Documentation/filesystems/proc.txt | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
>diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
>index 74329fd..71f5096 100644
>--- a/Documentation/filesystems/proc.txt
>+++ b/Documentation/filesystems/proc.txt
>@@ -1305,7 +1305,16 @@ second). The meanings of the columns are as follows, from left to right:
> - nice: niced processes executing in user mode
> - system: processes executing in kernel mode
> - idle: twiddling thumbs
>-- iowait: waiting for I/O to complete
>+- iowait: In a word, iowait stands for waiting for I/O to complete. But there
>+ are several problems:
>+ 1. Cpu will not wait for I/O to complete, iowait is the time that a task is
>+ waiting for I/O to complete. When cpu goes into idle state for
>+ outstanding task io, another task will be scheduled on this CPU.
>+ 2. In a multi-core CPU, the task waiting for I/O to complete is not running
>+ on any CPU, so the iowait of each CPU is difficult to calculate.
>+ 3. The value of iowait field in /proc/stat will decrease in certain
>+ conditions.
>+ So, the iowait is not reliable by reading from /proc/stat.
> - irq: servicing interrupts
> - softirq: servicing softirqs
> - steal: involuntary wait
>--
>2.7.4
>
^ permalink raw reply
* Re: [1/8] mwifiex: prevent register accesses after host is sleeping
From: Kalle Valo @ 2016-11-09 1:34 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> Following is mwifiex driver-firmware host sleep handshake.
> It involves three threads. suspend handler, interrupt handler, interrupt
> processing in main work queue.
>
> 1) Enter suspend handler
> 2) Download HS_CFG command
> 3) Response from firmware for HS_CFG
> 4) Suspend thread waits until handshake completes(i.e hs_activate becomes
> true)
> 5) SLEEP from firmware
> 6) SLEEP confirm downloaded to firmware.
> 7) SLEEP confirm response from firmware
> 8) Driver processes SLEEP confirm response and set hs_activate to wake up
> suspend thread
> 9) Exit suspend handler
> 10) Read sleep cookie in loop and wait until it indicates firmware is
> sleep.
> 11) After processing SLEEP confirm response, we are at the end of interrupt
> processing routine. Recheck if there are interrupts received while we were
> processing them.
>
> During suspend-resume stress test, it's been observed that we may end up
> acessing PCIe hardware(in 10 and 11) when PCIe bus is closed which leads
> to a kernel crash.
>
> This patch solves the problem with below changes.
> a) action 10 above can be done before 8
> b) Skip 11 if hs_activated is true. SLEEP confirm response
> is the last interrupt from firmware. No need to recheck for
> pending interrupts.
> c) Add flush_workqueue() in suspend handler.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Tested-by: Brian Norris <briannorris@chromium.org>
8 patches applied to wireless-drivers-next.git, thanks.
ec815dd2a5f1 mwifiex: prevent register accesses after host is sleeping
5190f2e40591 mwifiex: report error to PCIe for suspend failure
c44c040300d7 mwifiex: Fix NULL pointer dereference in skb_dequeue()
113630b581d6 mwifiex: vendor_ie length check for parse WMM IEs
a936ea543657 mwifiex: add memrw command information in README
77f486c8bb39 mwifiex: update tx_pkts_queued for requeued packets
49abe5c83cd0 mwifiex: fix command timeout problem seen in stress tests
3d8bd85c2c9e mwifiex: fix p2p device doesn't find in scan problem
--
https://patchwork.kernel.org/patch/9353809/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
From: Peter Chen @ 2016-11-09 1:33 UTC (permalink / raw)
To: NeilBrown
Cc: Baolin Wang, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, Mark Brown,
John Stultz, Charles Keepax, patches, Linux PM list, USB,
device-mainlining, LKML
In-Reply-To: <87vavxn1v7.fsf@notabene.neil.brown.name>
On Wed, Nov 09, 2016 at 07:38:36AM +1100, NeilBrown wrote:
> On Tue, Nov 08 2016, Peter Chen wrote:
>
> > On Thu, Nov 03, 2016 at 12:25:42PM +1100, NeilBrown wrote:
> >>
> >>
> >>
> >> 2/ Change all usb phys to register an extcon and to send appropriate
> >> notifications. Many already do, but I don't think it is universal.
> >> It is probable that the extcon should be registered using common code
> >> instead of each phy driver having its own
> >> extcon_get_edev_by_phandle()
> >> or whatever.
> >> If the usb phy driver needs to look at battery charger registers to
> >> know what sort of cable was connected (which I believe is the case
> >> for the chips you are interested in), then it should do that.
> >
> > Not only USB PHY to register an extcon, but also for the drivers which
> > can detect USB charger type, it may be USB controller driver, USB type-c
> > driver, pmic driver, and these drivers may not have an extcon device
> > since the internal part can finish the vbus detect.
>
> Can you point to an example of the sort of hardware/driver you are
> referring to, preferably in the mainline kernel. Concrete examples make
> this sort of thing much easier to understand.
>
Eg, the nxp/fsl USB charger detector part, the register used to begin
the detection is in USB controller register region, and we also need to
use controller register to pull up dp to begin the secondary detect.
Since there is no USB charger framework, the code is not in mainline.
It finished an upstream version based on patch set in this thread [1]
Some SoCs uses chipidea IP doesn't need to use extcon to detect plugging
in/out, since the vbus pin connects to SoC's vbus pin.
The pmic has abilities to charger detection, eg, drivers/mfd/axp20x.c
and drivers/extcon/extcon-axp288.c.
> I think I would argue that if some piece of hardware can detect the USB
> charger type, then that piece of hardware is part of the "USB PHY", even
> if the hardware manufacturer has chosen to partition the register set in
> a way which doesn't make that obvious.
I agree with that the charger detect hardware is in the USB PHY part,
but some USB PHY's control is integrated in USB controller (eg, some
controller uses drivers/usb/phy/phy-generic.c as its PHY driver), so
we have to use controller register to finish some PHY function, eg
charger detection.
[1] https://www.spinics.net/lists/linux-usb/msg139425.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start
From: Chanwoo Choi @ 2016-11-09 1:33 UTC (permalink / raw)
To: Saravana Kannan
Cc: Rafael J. Wysocki, MyungJoo Ham, Kyungmin Park, linux-pm,
linux-kernel
In-Reply-To: <58223AF1.2030605@codeaurora.org>
On 2016년 11월 09일 05:52, Saravana Kannan wrote:
> On 11/08/2016 01:02 AM, Chanwoo Choi wrote:
>> Hi,
>>
>> On 2016년 11월 08일 03:57, Saravana Kannan wrote:
>>> On 10/26/2016 05:06 PM, Chanwoo Choi wrote:
>>>> Hi,
>>>>
>>>> On 2016년 10월 27일 04:17, Saravana Kannan wrote:
>>>>> If the new governor fails to start, switch back to old governor so that the
>>>>> devfreq state is not left in some weird limbo.
>>>>>
>>>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>>>>> ---
>>>>> * Fix NULL deref for real this time.
>>>>> * Addressed some style preferences.
>>>>>
>>>>> drivers/devfreq/devfreq.c | 13 +++++++++++--
>>>>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>>>> index bf3ea76..77c41a5 100644
>>>>> --- a/drivers/devfreq/devfreq.c
>>>>> +++ b/drivers/devfreq/devfreq.c
>>>>> @@ -919,7 +919,7 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
>>>>> struct devfreq *df = to_devfreq(dev);
>>>>> int ret;
>>>>> char str_governor[DEVFREQ_NAME_LEN + 1];
>>>>> - struct devfreq_governor *governor;
>>>>> + const struct devfreq_governor *governor, *prev_governor;
>>>>>
>>>>> ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", str_governor);
>>>>> if (ret != 1)
>>>>> @@ -944,12 +944,21 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
>>>>> goto out;
>>>>> }
>>>>> }
>>>>> + prev_governor = df->governor;
>>>>> df->governor = governor;
>>>>> strncpy(df->governor_name, governor->name, DEVFREQ_NAME_LEN);
>>>>> ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
>>>>> - if (ret)
>>>>> + if (ret) {
>>>>> dev_warn(dev, "%s: Governor %s not started(%d)\n",
>>>>> __func__, df->governor->name, ret);
>>>>> + if (prev_governor) {
>>>>
>>>> I think that prev_governor is always set. You don't need to check it.
>>>> Why do check it?
>>>
>>> Not true. Even higher up in this function, we check if df->governor != NULL. Simple example would be that the default governor passed in while adding the device isn't compiled in.
>>
>> I don't understand. If device is not registered by devfreq_add_device(),
>> you don't change the governor by using governor_store().
>>
>> If you can change the governor through governor_store(),
>> it means that the devfreq instance was added without any problem.
>> The added devfreq instance must have the sepecific governor
>> on df->governor variable.
>>
>> So, I think that df->governor is always set and then prev_governor is always set.
>
> Read the code more closely. add_device doesn't (and shouldn't) fail if the governor isn't present. After that, the governor could be changed from user space.
If governor is not present during devfreq_add_device(),
the devfreq instance is not able to register the devfreq framework.
So, the user never touch the sysfs[1] to change the governor
because the sysfs[1] is not created by devfreq framework.
[1] /sys/class/devfreq/[device name]/governor
In summary, if governor is not present during devfreq_add_device(),
the devfreq framework doesn't create tye sysfs[1] for governor.
The user-space never change the governor through sysfs[1]
because there is no any sysfs entry[1].
Best Regards,
Chanwoo Choi
^ permalink raw reply
* Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
From: Peter Chen @ 2016-11-09 1:33 UTC (permalink / raw)
To: NeilBrown
Cc: Baolin Wang, Felipe Balbi, Greg KH, Sebastian Reichel,
Dmitry Eremin-Solenikov, David Woodhouse, robh, Jun Li,
Marek Szyprowski, Ruslan Bilovol, Peter Chen, Alan Stern,
grygorii.strashko, Yoshihiro Shimoda, Lee Jones, Mark Brown,
John Stultz, Charles Keepax, patches, Linux PM list
In-Reply-To: <87vavxn1v7.fsf@notabene.neil.brown.name>
On Wed, Nov 09, 2016 at 07:38:36AM +1100, NeilBrown wrote:
> On Tue, Nov 08 2016, Peter Chen wrote:
>
> > On Thu, Nov 03, 2016 at 12:25:42PM +1100, NeilBrown wrote:
> >>
> >>
> >>
> >> 2/ Change all usb phys to register an extcon and to send appropriate
> >> notifications. Many already do, but I don't think it is universal.
> >> It is probable that the extcon should be registered using common code
> >> instead of each phy driver having its own
> >> extcon_get_edev_by_phandle()
> >> or whatever.
> >> If the usb phy driver needs to look at battery charger registers to
> >> know what sort of cable was connected (which I believe is the case
> >> for the chips you are interested in), then it should do that.
> >
> > Not only USB PHY to register an extcon, but also for the drivers which
> > can detect USB charger type, it may be USB controller driver, USB type-c
> > driver, pmic driver, and these drivers may not have an extcon device
> > since the internal part can finish the vbus detect.
>
> Can you point to an example of the sort of hardware/driver you are
> referring to, preferably in the mainline kernel. Concrete examples make
> this sort of thing much easier to understand.
>
Eg, the nxp/fsl USB charger detector part, the register used to begin
the detection is in USB controller register region, and we also need to
use controller register to pull up dp to begin the secondary detect.
Since there is no USB charger framework, the code is not in mainline.
It finished an upstream version based on patch set in this thread [1]
Some SoCs uses chipidea IP doesn't need to use extcon to detect plugging
in/out, since the vbus pin connects to SoC's vbus pin.
The pmic has abilities to charger detection, eg, drivers/mfd/axp20x.c
and drivers/extcon/extcon-axp288.c.
> I think I would argue that if some piece of hardware can detect the USB
> charger type, then that piece of hardware is part of the "USB PHY", even
> if the hardware manufacturer has chosen to partition the register set in
> a way which doesn't make that obvious.
I agree with that the charger detect hardware is in the USB PHY part,
but some USB PHY's control is integrated in USB controller (eg, some
controller uses drivers/usb/phy/phy-generic.c as its PHY driver), so
we have to use controller register to finish some PHY function, eg
charger detection.
[1] https://www.spinics.net/lists/linux-usb/msg139425.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* Re: brcmfmac: proto: add callback for queuing TX data
From: Kalle Valo @ 2016-11-09 1:30 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, netdev, linux-kernel,
Rafał Miłecki
In-Reply-To: <20160926215144.9923-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> So far our core code was calling brcmf_fws_process_skb which wasn't
> a proper thing to do. If case of devices using msgbuf protocol fwsignal
> shouldn't be used. It was an unnecessary extra layer simply calling
> a protocol specifix txdata function.
>
> Please note we already have txdata callback, but it's used for calls
> between bcdc and fwsignal so it couldn't be simply used there.
>
> This makes core code more generic (instead of bcdc/fwsignal specific).
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Patch applied to wireless-drivers-next.git, thanks.
b073ac1fcf42 brcmfmac: proto: add callback for queuing TX data
--
https://patchwork.kernel.org/patch/9351305/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: sunxi: Add the missing clocks to the pinctrl nodes
From: Chen-Yu Tsai @ 2016-11-09 1:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Linus Walleij, Alexandre Courbot, linux-gpio@vger.kernel.org,
devicetree, Rob Herring, Chen-Yu Tsai
In-Reply-To: <dbf6796cb2857e09072d57dc29152c153c2c8f61.1478636546.git-series.maxime.ripard@free-electrons.com>
On Wed, Nov 9, 2016 at 4:24 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The pin controllers also use the two oscillators for debouncing. Add them
> to the DTs.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
You should also do the R_PIO block for the ones that have them too.
^ permalink raw reply
* Re: [v2] rt2x00: add support for mac addr from device tree
From: Kalle Valo @ 2016-11-09 1:29 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless
In-Reply-To: <1472195813-30471-1-git-send-email-dev@kresin.me>
Mathias Kresin <dev@kresin.me> wrote:
> On some devices the EEPROMs of Ralink Wi-Fi chips have a default Ralink
> MAC address set (RT3062F: 00:0C:43:30:62:00, RT3060F:
> 00:0C:43:30:60:00). Using multiple of these devices in the same network
> can cause nasty issues.
>
> Allow to override the MAC in the EEPROM with (a known good) one set in
> the device tree to bypass the issue.
>
> Signed-off-by: Mathias Kresin <dev@kresin.me>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
9766cb709089 rt2x00: add support for mac addr from device tree
--
https://patchwork.kernel.org/patch/9300893/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: BUG: Hung task timeouts in for-4.10/dio
From: Jens Axboe @ 2016-11-09 1:28 UTC (permalink / raw)
To: Damien Le Moal, Christoph Hellwig
Cc: Logan Gunthorpe, linux-block, Mike Snitzer
In-Reply-To: <b3d8c5fa-b930-b21f-3986-1ff94611c7f9@wdc.com>
On 11/08/2016 06:25 PM, Damien Le Moal wrote:
>
> On 11/9/16 10:09, Christoph Hellwig wrote:
>> Ok, sounds like I'm really the one to blame. I'll see if I can
>> find a reproducer. Damien, or you using device mapper on that
>> system?
>
> No LVM/md/dm used on boot. Mount is direct to the block device (SSDs
> with ext4). The devices are simple SSDs, so no polling involved.
>
> The hangs suspiciously look like they are either background write or
> flush. So I was wondering if it is indeed related to FLUSH/FUA as Logan
> suggested or the background write stuff, rather than the direct-IO
> optimization & polling.
The background write stuff is not in either of those branches, plus the
backtrace would have looked different. Yours is showing us waiting for a
request. I don't think it's the direct-io or polling code, it looks like
a generic issue.
> Will try again/bisect to see if I can get more info.
Maybe try and revert the one that Logan pointed his finger at, if that
is doable.
--
Jens Axboe
^ permalink raw reply
* Re: [RFC PATCH 19/24] ARM: vITS: handle DISCARD command
From: Stefano Stabellini @ 2016-11-09 1:28 UTC (permalink / raw)
To: Andre Przywara; +Cc: xen-devel, Julien Grall, Stefano Stabellini
In-Reply-To: <20160928182457.12433-20-andre.przywara@arm.com>
On Wed, 28 Sep 2016, Andre Przywara wrote:
> The DISCARD command drops the connection between a DeviceID/EventID
> and an LPI/collection pair.
> We mark the respective structure entries as not allocated and make
> sure that any queued IRQs are removed.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> xen/arch/arm/gic-its.c | 21 +++++++++++++++++++
> xen/arch/arm/vgic-its.c | 48 +++++++++++++++++++++++++++++++++++++++++++
> xen/include/asm-arm/gic-its.h | 5 +++++
> 3 files changed, 74 insertions(+)
>
> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
> index d1b1cbb..766a7cb 100644
> --- a/xen/arch/arm/gic-its.c
> +++ b/xen/arch/arm/gic-its.c
> @@ -634,6 +634,27 @@ int gicv3_lpi_change_vcpu(struct domain *d, uint32_t host_lpi, int new_vcpu_id)
> return 0;
> }
>
> +/* Looks up a given host LPI assigned to that domain and returns the
> + * connected virtual LPI number. Also stores the target vcpu ID in
> + * the passed vcpu_id pointer.
> + * Returns 0 if no host LPI could be found for that domain, or the
> + * virtual LPI number (>= 8192) if the lookup succeeded.
> + */
> +uint32_t gicv3_lpi_lookup_lpi(struct domain *d, uint32_t host_lpi, int *vcpu_id)
> +{
> + union host_lpi *hlpip, hlpi;
> +
> + hlpip = gic_find_host_lpi(host_lpi, d);
> + if ( !hlpip )
> + return 0;
> +
> + hlpi.data = hlpip->data;
> + if ( vcpu_id )
> + *vcpu_id = hlpi.vcpu_id;
> +
> + return hlpi.virt_lpi;
> +}
> +
> void gicv3_its_dt_init(const struct dt_device_node *node)
> {
> const struct dt_device_node *its = NULL;
> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
> index c0a60ad..028d234 100644
> --- a/xen/arch/arm/vgic-its.c
> +++ b/xen/arch/arm/vgic-its.c
> @@ -367,6 +367,51 @@ out_unlock:
> return 0;
> }
>
> +static int its_handle_discard(struct virt_its *its, uint64_t *cmdptr)
> +{
> + uint32_t devid = its_cmd_get_deviceid(cmdptr);
> + uint32_t eventid = its_cmd_get_id(cmdptr);
> + struct pending_irq *pirq;
> + struct vits_itte *itte;
> + struct vcpu *vcpu;
> + uint32_t vlpi;
> + int ret = -1, vcpu_id;
> +
> + spin_lock(&its->its_lock);
> + itte = get_devid_evid(its, devid, eventid);
> + if ( !itte )
> + goto out_unlock;
> +
> + vlpi = gicv3_lpi_lookup_lpi(its->d, itte->hlpi, &vcpu_id);
> + if ( !vlpi )
> + goto out_unlock;
Using itte->hlpi like that is very dangerous because the guest could be
modifying that field while we run gicv3_lpi_lookup_lpi or
gicv3_lpi_drop_host_lpi. Actually we need a compiler barrier after
reading all guest accessible fields and before using them to access our
own data structures.
> + vcpu = its->d->vcpu[vcpu_id];
> +
> + pirq = lpi_to_pending(vcpu, vlpi, false);
> + if ( pirq )
> + {
> + clear_bit(GIC_IRQ_GUEST_QUEUED, &pirq->status);
> + gic_remove_from_queues(vcpu, vlpi);
> +
> + /* Mark this pending IRQ struct as availabe again. */
> + if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, &pirq->status) )
> + pirq->irq = 0;
We need to do something in case the vlpi is in a GICH_LR register
> + }
> +
> + gicv3_lpi_drop_host_lpi(its->hw_its, devid, eventid, itte->hlpi);
Same here regarding itte->hlpi
> + itte->hlpi = 0; /* Mark this ITTE as unused. */
> + ret = 0;
> +
> + put_devid_evid(its, itte);
> +
> +out_unlock:
> + spin_unlock(&its->its_lock);
> +
> + return ret;
> +}
> +
> #define ITS_CMD_BUFFER_SIZE(baser) ((((baser) & 0xff) + 1) << 12)
>
> static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> @@ -390,6 +435,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
> case GITS_CMD_CLEAR:
> its_handle_clear(its, cmdptr);
> break;
> + case GITS_CMD_DISCARD:
> + its_handle_discard(its, cmdptr);
> + break;
> case GITS_CMD_INT:
> its_handle_int(its, cmdptr);
> break;
> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
> index 7e1142f..3f5698d 100644
> --- a/xen/include/asm-arm/gic-its.h
> +++ b/xen/include/asm-arm/gic-its.h
> @@ -133,6 +133,11 @@ int gicv3_its_map_device(struct host_its *hw_its, struct domain *d,
> int gicv3_lpi_allocate_host_lpi(struct host_its *its,
> uint32_t devid, uint32_t eventid,
> struct vcpu *v, int virt_lpi);
> +/* Given a physical LPI, looks up and returns the associated virtual LPI
> + * and the target VCPU in the given domain.
> + */
> +uint32_t gicv3_lpi_lookup_lpi(struct domain *d, uint32_t host_lpi,
> + int *vcpu_id);
> int gicv3_lpi_change_vcpu(struct domain *d, uint32_t host_lpi, int new_vcpu_id);
> int gicv3_lpi_drop_host_lpi(struct host_its *its,
> uint32_t devid, uint32_t eventid,
> --
> 2.9.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] [RFC 11/17] ppc: Add ppc_set_compat_all()
From: Alexey Kardashevskiy @ 2016-11-09 1:27 UTC (permalink / raw)
To: David Gibson; +Cc: nikunj, mdroth, thuth, lvivier, qemu-ppc, qemu-devel
In-Reply-To: <20161108051847.GS28688@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 6364 bytes --]
On 08/11/16 16:18, David Gibson wrote:
> On Fri, Nov 04, 2016 at 03:01:40PM +1100, Alexey Kardashevskiy wrote:
>> On 30/10/16 22:12, David Gibson wrote:
>>> Once a compatiblity mode is negotiated with the guest,
>>> h_client_architecture_support() uses run_on_cpu() to update each CPU to
>>> the new mode. We're going to want this logic somewhere else shortly,
>>> so make a helper function to do this global update.
>>>
>>> We put it in target-ppc/compat.c - it makes as much sense at the CPU level
>>> as it does at the machine level. We also move the cpu_synchronize_state()
>>> into ppc_set_compat(), since it doesn't really make any sense to call that
>>> without synchronizing state.
>>>
>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>> ---
>>> hw/ppc/spapr_hcall.c | 31 +++++--------------------------
>>> target-ppc/compat.c | 36 ++++++++++++++++++++++++++++++++++++
>>> target-ppc/cpu.h | 3 +++
>>> 3 files changed, 44 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
>>> index 3bd6d06..4eaf9a6 100644
>>> --- a/hw/ppc/spapr_hcall.c
>>> +++ b/hw/ppc/spapr_hcall.c
>>> @@ -881,20 +881,6 @@ static target_ulong h_set_mode(PowerPCCPU *cpu, sPAPRMachineState *spapr,
>>> return ret;
>>> }
>>>
>>> -typedef struct {
>>> - uint32_t compat_pvr;
>>> - Error *err;
>>> -} SetCompatState;
>>> -
>>> -static void do_set_compat(CPUState *cs, void *arg)
>>> -{
>>> - PowerPCCPU *cpu = POWERPC_CPU(cs);
>>> - SetCompatState *s = arg;
>>> -
>>> - cpu_synchronize_state(cs);
>>> - ppc_set_compat(cpu, s->compat_pvr, &s->err);
>>> -}
>>> -
>>> static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
>>> sPAPRMachineState *spapr,
>>> target_ulong opcode,
>>> @@ -902,7 +888,6 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
>>> {
>>> target_ulong list = ppc64_phys_to_real(args[0]);
>>> target_ulong ov_table;
>>> - CPUState *cs;
>>> bool explicit_match = false; /* Matched the CPU's real PVR */
>>> uint32_t max_compat = cpu->max_compat;
>>> uint32_t best_compat = 0;
>>> @@ -949,18 +934,12 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
>>>
>>> /* Update CPUs */
>>> if (cpu->compat_pvr != best_compat) {
>>> - CPU_FOREACH(cs) {
>>> - SetCompatState s = {
>>> - .compat_pvr = best_compat,
>>> - .err = NULL,
>>> - };
>>> + Error *local_err = NULL;
>>>
>>> - run_on_cpu(cs, do_set_compat, &s);
>>> -
>>> - if (s.err) {
>>> - error_report_err(s.err);
>>> - return H_HARDWARE;
>>> - }
>>> + ppc_set_compat_all(best_compat, &local_err);
>>> + if (local_err) {
>>> + error_report_err(local_err);
>>> + return H_HARDWARE;
>>> }
>>> }
>>>
>>> diff --git a/target-ppc/compat.c b/target-ppc/compat.c
>>> index 1059555..0b12b58 100644
>>> --- a/target-ppc/compat.c
>>> +++ b/target-ppc/compat.c
>>> @@ -124,6 +124,8 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
>>> pcr = compat->pcr;
>>> }
>>>
>>> + cpu_synchronize_state(CPU(cpu));
>>> +
>>> cpu->compat_pvr = compat_pvr;
>>> env->spr[SPR_PCR] = pcr & pcc->pcr_mask;
>>>
>>> @@ -136,6 +138,40 @@ void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp)
>>> }
>>> }
>>>
>>> +#if !defined(CONFIG_USER_ONLY)
>>> +typedef struct {
>>> + uint32_t compat_pvr;
>>> + Error *err;
>>> +} SetCompatState;
>>> +
>>> +static void do_set_compat(CPUState *cs, void *arg)
>>> +{
>>> + PowerPCCPU *cpu = POWERPC_CPU(cs);
>>> + SetCompatState *s = arg;
>>> +
>>> + ppc_set_compat(cpu, s->compat_pvr, &s->err);
>>> +}
>>> +
>>> +void ppc_set_compat_all(uint32_t compat_pvr, Error **errp)
>>> +{
>>> + CPUState *cs;
>>> +
>>> + CPU_FOREACH(cs) {
>>> + SetCompatState s = {
>>> + .compat_pvr = compat_pvr,
>>> + .err = NULL,
>>> + };
>>> +
>>> + run_on_cpu(cs, do_set_compat, &s);
>>> +
>>> + if (s.err) {
>>> + error_propagate(errp, s.err);
>>> + return;
>>> + }
>>> + }
>>> +}
>>> +#endif
>>> +
>>> int ppc_compat_max_threads(PowerPCCPU *cpu)
>>> {
>>> const CompatInfo *compat = compat_by_pvr(cpu->compat_pvr);
>>> diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
>>> index 91e8be8..201a655 100644
>>> --- a/target-ppc/cpu.h
>>> +++ b/target-ppc/cpu.h
>>> @@ -1317,6 +1317,9 @@ static inline int cpu_mmu_index (CPUPPCState *env, bool ifetch)
>>> bool ppc_check_compat(PowerPCCPU *cpu, uint32_t compat_pvr,
>>> uint32_t min_compat_pvr, uint32_t max_compat_pvr);
>>> void ppc_set_compat(PowerPCCPU *cpu, uint32_t compat_pvr, Error **errp);
>>> +#if !defined(CONFIG_USER_ONLY)
>>> +void ppc_set_compat_all(uint32_t compat_pvr, Error **errp);
>>> +#endif
>>
>> I would put all ppc*compat*() under #if defined(CONFIG_USER_ONLY) &&
>> defined(TARGET_PPC64) (or even moved this to target-ppc/Makefile.objs).
>
> I was originally going to do that, but decided against it.
>
>> Otherwise, functions like ppc_check_compat() have #if
>> !defined(CONFIG_USER_ONLY) which suggests that the rest of
>> ppc_check_compat() can actually be executed in ppc64-linux-user (while it
>> cannot, can it?).
>
> It won't be, but there's no theoretical reason they couldn't be. User
> mode, like spapr, doesn't execute hypervisor privilege code, and so
> the PCR isn't owned by the "guest" (if you can call the user mode
> executable that). Which means it could make sense to set it from the
> outside, although that's not something we currently do.
Compatibility modes are designed to disable sets of instructions to keep
working old userspace software which relies on some opcodes to be invalid.
linux-user is TCG, right? The user can pick any CPU he likes if there is
need to run such an old software, why on earth would anyone bother with
this compat mode in linux-user?
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 839 bytes --]
^ permalink raw reply
* Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue
From: J. Bruce Fields @ 2016-11-09 1:27 UTC (permalink / raw)
To: Tejun Heo; +Cc: Bhaktipriya Shridhar, Jeff Layton, linux-nfs, linux-kernel
In-Reply-To: <20161108225221.GB6460@htj.duckdns.org>
On Tue, Nov 08, 2016 at 05:52:21PM -0500, Tejun Heo wrote:
> Hello, Bruce.
>
> On Tue, Nov 08, 2016 at 04:39:11PM -0500, J. Bruce Fields wrote:
> > Apologies, just cleaning out old mail and finding some I should have
> > responded to long ago:
> >
> > On Wed, Aug 31, 2016 at 02:23:48AM +0530, Bhaktipriya Shridhar wrote:
> > > The workqueue "callback_wq" queues a single work item &cb->cb_work per
> > > nfsd4_callback instance and thus, it doesn't require execution ordering.
> >
> > What's "execution ordering"?
> >
> > We definitely do depend on the fact that at most one of these is running
> > at a time.
>
> If there can be multiple cb's and thus cb->cb_work's per callback_wq,
> it'd need explicit ordering. Is that the case?
Yes, there can be multiple cb_work's.
--b.
^ permalink raw reply
* RE: [PATCH v2 2/2] scsi: ufs: Use the resource-managed function to add devfreq device
From: MyungJoo Ham @ 2016-11-09 1:26 UTC (permalink / raw)
To: Chanwoo Choi, Kyungmin Park
Cc: rjw@rjwysocki.net, subhashj@codeaurora.org, cpgs .,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
Vinayak Holikatti, James E.J. Bottomley, Martin K. Petersen,
linux-scsi@vger.kernel.org
In-Reply-To: <CGME20161108091702epcas5p4779c47d7341e22697e7e49dd2f91ae0b@epcas5p4.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
> This patch uses the resource-managed to add the devfreq device.
> This function will make it easy to handle the devfreq device.
>
> - struct devfreq *devm_devfreq_add_device(struct device *dev,
> struct devfreq_dev_profile *profile,
> const char *governor_name,
> void *data);
> Cc: Vinayak Holikatti <vinholikatti@gmail.com>
> Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
> Cc: Martin K. Petersen <martin.petersen@oracle.com>
> Cc: linux-scsi@vger.kernel.org
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> ---
> drivers/scsi/ufs/ufshcd.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
^ permalink raw reply
* Re: [ANNOUNCE] xfs: for-next branch updated to 84716639acc3
From: Dave Chinner @ 2016-11-09 1:23 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs, linux-fsdevel, jack, tytso, ross.zwisler
In-Reply-To: <20161109000152.GB16813@birch.djwong.org>
On Tue, Nov 08, 2016 at 04:01:53PM -0800, Darrick J. Wong wrote:
> On Wed, Nov 09, 2016 at 10:16:39AM +1100, Dave Chinner wrote:
> > Hi folks,
> >
> > The for-next branch of the xfs kernel repository at
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git
> >
> > has just been updated.
> >
> > This update includes the DAX iomap PMD fault infrastructure, a bunch
> > of libxfs cleanups that sync the kernel code with changes that
> > have been made in the userspace libxfs and a few bug fixes thrown in
> > there for good measure.
>
> /me notices the commit message for 132f2ac5055a96 ("xfs: check minimum block
> size for CRC filesystems") says that you cleaned up the XFS_MIN_CRC_BLOCKSIZE
> check, but the patch appears identical to the one that I sent. I think all
> you changed was removing the unlikely()...?
>
> (<shrug> I doubt it's a big deal either way really...)
Ok, that's a little strange.
Hmmm - looks like I hadn't saved the modified file when I refreshed
the patch after modifying the commit message. I've already updated
my local for-next tree, so when I next push it out it will have this
update in it.
/me accidentally demonstrates why he uses topic branches to isolate
different bodies of work and the reasons that for-next needs to be
considered an unstable branch...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* RE: ACPI module-level code (MLC) not working?
From: Zheng, Lv @ 2016-11-09 1:26 UTC (permalink / raw)
To: Peter Wu
Cc: Rick Kerkhof, Bartosz Skrzypczak, Moore, Robert,
linux-acpi@vger.kernel.org
In-Reply-To: <20161109011729.GB16755@al>
Hi,
> From: Peter Wu [mailto:peter@lekensteyn.nl]
> Subject: Re: ACPI module-level code (MLC) not working?
>
> On Wed, Nov 09, 2016 at 12:43:37AM +0000, Zheng, Lv wrote:
> > Hi,
> >
> > > -----Original Message-----
> > > From: Peter Wu [mailto:peter@lekensteyn.nl]
> > > Sent: Tuesday, November 8, 2016 4:33 PM
> > > To: Zheng, Lv <lv.zheng@intel.com>
> > > Cc: Rick Kerkhof <rick.2889@gmail.com>; Bartosz Skrzypczak <barteks2x@gmail.com>; Moore, Robert
> > > <robert.moore@intel.com>; linux-acpi@vger.kernel.org
> > > Subject: Re: ACPI module-level code (MLC) not working?
> > >
> > > On Wed, Nov 09, 2016 at 12:07:47AM +0000, Zheng, Lv wrote:
> > > > Hi,
> > > >
> > > > > From: Peter Wu [mailto:peter@lekensteyn.nl]
> > > > > Subject: Re: ACPI module-level code (MLC) not working?
> > > > >
> > > > > On Tue, Nov 08, 2016 at 05:35:07PM +0000, Zheng, Lv wrote:
> > > > > > Hi,
> > > > > >
> > > > > > > From: Peter Wu [mailto:peter@lekensteyn.nl]
> > > > > > > Subject: ACPI module-level code (MLC) not working?
> > > > > > >
> > > > > > > Hi Lv,
> > > > > > >
> > > > > > > According to some tests, setting acpi_gbl_parse_table_as_term_list to
> > > > > > > TRUE does is not effective. The code within the If-block is still not
> > > > > > > executed early enough or something else is wrong.
> > > > > > >
> > > > > > > Previously Rick had an issue with an Acer Aspire V7-582PG where the dGPU
> > > > > > > could not be powered off and I demonstrated an isolated test case in
> > > > > > > http://www.spinics.net/lists/linux-acpi/msg70069.html
> > > > > > >
> > > > > > > In Bartosz's case, the dGPU cannot be powered on (also using nouveau),
> > > > > > > preventing suspend from working. Situation is as follows (tested with
> > > > > > > Linux 3.16, 4.8.4, 4.9-rc2, 4.9-rc4):
> > > > > > >
> > > > > > > His Lenovo IdeaPad Z510 laptop (BIOS date 2014) enables power resources
> > > > > > > and related _PR3 objects under the conditional If(_OSI("Windows 2013")).
> > > > > > > Both with and without acpi_gbl_parse_table_as_term_list set to TRUE, the
> > > > > > > module-level code is not loaded properly. Via a SSDT override, it was
> > > > > > > confirmed that removing the If conditional results in the expected
> > > > > > > behavior.
> > > > > > >
> > > > > > > Various details are given in https://github.com/Bumblebee-Project/bbswitch/issues/142
> > > > > > > including lots of dmesg logs (see posts at the bottom).
> > > > > > > With above MLC flag set (v4.9-rc4): https://pastebin.com/raw/vCEPGezX
> > > > > > > With SSDT override (v4.9-rc2): https://pastebin.com/raw/3Fsf2VPU
> > > > > >
> > > > > > I checked the post.
> > > > > > It seems the current working way is: disabling _OSI(Windows 2013) which disables power
> resources.
> > > > >
> > > > > That is how Lenovo probably intended to use it (only add Power Resources
> > > > > when Windows 8 is detected).
> > > > >
> > > > > > I have several questions related to this issue:
> > > > > > 1. The following messages are prompt up when "acpi_gbl_parse_table_as_term_list = TRUE":
> > > > > > [ 2.519113] ACPI Error: [\_SB_.PCI0.GFX0.DD02._BCL] Namespace lookup failure,
> AE_NOT_FOUND
> > > > > (20160831/psargs-359)
> > > > > > [ 2.519121] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG1.PEGP.DD02._BCL]
> (Node
> > > > > ffff8802568d3cf8), AE_NOT_FOUND (20160831/psparse-543)
> > > > > > How was this triggered?
> > > > >
> > > > > This comes from acpi_video.c, ssdt4.dsl contains a \_SB.PCI0.GFX0.DD02
> > > > > device with an _ADR method, but no _BCL one. It is not a regression
> > > > > though, let's ignore this for now.
> > > > >
> > > > > > 2. I noticed the following statement:
> > > > > > So, for some reason Lenovo has decided to give all tables the same name.
> > > > > > The ACPI table override functionality matches possible candidates by signature, OEM ID
> and
> > > OEM
> > > > > Revision ID which are all the same.
> > > > > > As a result, the wrong SSDT is overridden.
> > > > > > Could you provide the detail of the tables from the platform?
> > > > > > What is the reason of doing such kind of craps in BIOS?
> > > > >
> > > > > I have no idea why Lenovo would do such a silly thing, but that is why
> > > > > we had to patch tables.c with:
> > > > >
> > > > > if (existing_table->checksum != 0xAF) {
> > > > > acpi_os_unmap_memory(table, ACPI_HEADER_SIZE);
> > > > > pr_info("Skipping next table\n");
> > > > > goto next_table;
> > > > > }
> > > > >
> > > > > This is of course an unacceptable hard-coded value, but it was needed in
> > > > > as a quick hack. For a longterm solution, maybe we can name the table
> > > > > files specially such that additional match conditions can be given. This
> > > > > is a different issue though.
> > > > >
> > > > > What would you like to know about the platform? The acpidump is
> > > > > available at
> > > > > https://bugs.launchpad.net/lpbugreporter/+bug/752542/+attachment/4773050/+files/LENOVO-
> > > 20287.tar.gz
> > > > >
> > > > > ssdt5.dsl is the file of interest, grep for "Windows 2013".
> > > >
> > > > The table headers are:
> > > >
> > > > DefinitionBlock ("dsdt.aml", "DSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > > > DefinitionBlock ("ssdt1.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > > > DefinitionBlock ("ssdt2.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > > > DefinitionBlock ("ssdt3.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > > > DefinitionBlock ("ssdt4.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > > > DefinitionBlock ("ssdt5.aml", "SSDT", 1, "LENOVO", "CB-01 ", 0x00000001)
> > > >
> > > > They will be deemed as different versions of the same table from linux ACPI's point of view.
> > > > Whether override will be done or not depends on Linux version.
> > >
> > > When I mentioned override, I referred to the method described in
> > > Documentation/acpi/method-customizing.txt where any ACPI table can be
> > > overridden via the initrd. Indeed, that method is unable to pick
> > > arbitrary tables when they all have the same ID.
> > >
> > > > In recent Linux, ssdt1.aml will be used (no override), while in old Linux, ssdt5.aml will be
> used
> > > (override).
> > >
> > > Does this refer to the same override method as described above? The
> > > tables are loaded normally even if they have the same name.
> > >
> > > > Let me ask further.
> > > > 1. Should OSPM load only ssdt5.aml or load only ssdt1.aml, or load
> > > ssdt1.aml,ssdt2.aml,ssdt3.aml,ssdt4.aml,ssdt5.aml?
> > > > 2. Can you confirm Windows behavior here via amli?
> > > >
> > > > Anyway, this is a special case that violates spec and seems to be aiming to trigger regressions
> > > against changed logic brought by me.
> > > > No matter whether the change is reasonable.
> > >
> > > OSPM should load all tables, they are all different. Perhaps you are
> > > confusing this override method with how Linux normally loads tables?
> > > (Aren't the identifiers just used for visual purposes and irrelevant for
> > > normal operation?)
> >
> > No, I'm not confusing it.
> > I want to know the exact behavior here.
>
> I am a bit confused about what you would like to know and will try my
> best to answer it. In the dmesg without patching the kernel, the first
> SSDT is overwritten, all others are left intact. This can be seen in the
> dmesg from https://pastebin.com/raw/LuTLQnU1:
>
> ACPI: MCFG 0x000000009CFF4000 00003C (v01 LENOVO CB-01 00000001 ACPI 00040000)
> ACPI: Table Upgrade: override [SSDT-LENOVO-CB-01 ]
> ACPI: SSDT 0x000000009CFE6000 Physical table override, new table: 0x000000009C2AB000
> ACPI: SSDT 0x000000009C2AB000 003E32 (v01 LENOVO CB-01 00000002 INTL 20160729)
> ACPI: BOOT 0x000000009CFE4000 000028 (v01 LENOVO CB-01 00000001 ACPI 00040000)
> ACPI: LPIT 0x000000009CFE3000 00005C (v01 LENOVO CB-01 00000001 ACPI 00040000)
> ACPI: ASPT 0x000000009CFE1000 000034 (v07 LENOVO CB-01 00000001 ACPI 00040000)
> ACPI: DBGP 0x000000009CFE0000 000034 (v01 LENOVO CB-01 00000001 ACPI 00040000)
> ACPI: SSDT 0x000000009CFD8000 000539 (v01 LENOVO CB-01 00000001 ACPI 00040000)
> ACPI: SSDT 0x000000009CFD7000 000AD8 (v01 LENOVO CB-01 00000001 ACPI 00040000)
> ACPI: SSDT 0x000000009CFD3000 0034C6 (v01 LENOVO CB-01 00000001 ACPI 00040000)
> ACPI: SSDT 0x000000009CFCE000 00399A (v01 LENOVO CB-01 00000001 ACPI 00040000)
>
> > Because I'm actually about to change acpi_tb_compare_tables().
> > This allows and acpi_install_table() invocations to override matched tables.
> > So I'll remove Linux table override callback.
>
> No idea why you have to change acpi_tb_compare_tables, this is only used
> for "reloading" functionality.
acpi_tb_compare_tables() matches entire table now, so reloading is actually not functioning.
It's just there to prevent loading the same table twice.
So if we change this function to match IDs, then reloading can work.
This means if a new table handling by acpi_tb_install_standard_table() matches old table IDs, reloading can happen.
The old table can gets unloaded, and thenew table can gets loaded.
As acpi_install_table() invokes acpi_tb_install_standard_table(), it can trigger table re-loading automatically if acpi_tb_compare_tables() is changed.
So there will be no need to implement 2 override callbacks.
Linux just need to invoke acpi_install_table() to all tables found in initrd.
>
> There are two calls from ACPICA to Linux in acpi_tb_override_table,
> namely acpi_os_table_override (for DSDT override) and
> acpi_os_physical_table_override (for others, like SSDT). Did you meant
> to refer to these as "callback"?
Yes, if I acpi_tb_compare_tables() is changed, the 2 callbacks becomes useless and can be eliminated.
>
> If you want to adjust the matching functionality, I guess that
> acpi_table_initrd_override needs to be modified. The ACPI header cannot
> be modified, so you would then have to read the checksum, size or index
> based on the filename.
That sounds really ugly...
Lenovo BIOS developers are really crazy!
Thanks
Lv
>
> Kind regards,
> Peter
>
> > Please see my recent comment in the following link:
> > https://github.com/Bumblebee-Project/bbswitch/issues/142
> >
> > Thanks
> > Lv
> >
> > >
> > > I have not checked Windows, but I would guess that it loads normally.
> > > Otherwise Lenovo QA has really been sleeping.
> > >
> > > Kind regards,
> > > Peter
> > >
> > > > Linux only need a quirk for this platform.
> > > >
> > > > Thanks
> > > > Lv
> > > >
> > > > >
> > > > > Kind regards,
> > > > > Peter
> > > > >
> > > > > > Thanks and best regards
> > > > > > Lv
> > > > > >
> > > > > > >
> > > > > > > If you would like a new bugzilla entry or have some patches to test, you
> > > > > > > know where to find us :)
> > > > > > > --
> > > > > > > Kind regards,
> > > > > > > Peter Wu
> > > > > > > https://lekensteyn.nl
^ permalink raw reply
* [PATCH v2] btrfs-progs: send-test: add checking of clone-src option
From: Tsutomu Itoh @ 2016-11-09 1:25 UTC (permalink / raw)
To: dsterba; +Cc: linux-btrfs
In-Reply-To: <201611040835.AA00012@WIN-5MHF4RKU941.jp.fujitsu.com>
Sending stream size of clone-src(-c) option is checked.
Fixed by "btrfs-progs: send: fix handling of -c option".
Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
---
V2: old sending stream image is used
---
.../016-send-clone-src/send-stream-v4.8.2.img | Bin 0 -> 6299778 bytes
tests/misc-tests/016-send-clone-src/test.sh | 49 +++++++++++++++++++++
2 files changed, 49 insertions(+)
create mode 100644 tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img
create mode 100755 tests/misc-tests/016-send-clone-src/test.sh
diff --git a/tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img b/tests/misc-tests/016-send-clone-src/send-stream-v4.8.2.img
new file mode 100644
index 0000000000000000000000000000000000000000..ab774171b9677344f59fbfdacf13aebe8929ccfc
GIT binary patch
literal 6299778
zcmeF(ZOmk6eID>@pU2*reZgmaX3g3hD@1my$dNbp%(Gj+Db32RVkxA>5UH|hn<G2S
z!9&Mu<n@aj0a=QIO%;U@2?>>0!Hq?o5XmG;Qa4t~QB_K*0r>@2l-dmu7-T7c`@tb<
z!StT<_+@aUe({I-^7~6O&wb`xbIvut^L)N<y8X89)X`J7-!{MTmh4G#U3qQgNB`@t
ztttm|>W-W4JbLQnjqjPZvpqSKyWe{IuRZ<TpZ$}6^Z8G{`?)LrUcZ%b_LXm}=5RUx
znTH;|_@hr<a`nSUPL8g+_q?~CQ_dgUJ)L7i=8gaL=Kooh)q(Q)12<oA{p#f1-+u1!
z{<Y(s`|oM?z2^A9@SW}#{`OdvQM$!)K5M7vmJhe{fsa33%8qmE?D%CzFF$(ec3JOP
z{gyIE%4=W#<ZYk+?t0?TOP83o)7RJP9p&<e^8Anf`mws)^yN8sSRWb=Uv67&wE}wX
zp}+j?Km3(PuKmab`@eYZb=Q1-1@!V4-}q{)Bd>h8`xDO2pWg89pIy7w8Edz=u-s^p
zYZi~ccP+4Y?Fyr{^$MiU`yRdb{<ZL#CGfyYVpo;G;e6>+_dLE9SbtiVjeqsX`qNq+
zuRpET@$Q59-QWE4$6jK;{OA?C4`%Df9?TVopM7CH@#=$_y}k$2^huSk{L%{tUi}rb
z^=C9mO2iN#K!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB=Eb3p9OFW$Take4@%I-C{YPwzE3pq?}mI<dxO#v3CLl2oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FoHAfu>KY
zeE3_>Us7e1Zn2zC+gY7)a(d6uX_AzPAwYlt0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0-G0T`lQOUw^ZM+GD^2t&Zq6H&Nw--
zHME-~C1MB=AV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!CvJ1)4soa`K87uc<Ohw^+`n?X1qYG}|89O_CBZ1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZVDkb^pHzAH
ztNWj<GD^2t&Zq6H&N%6}hjx>)+I&q72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+K+^O{m1}SK&iAW~(k+(rX*;VkPEMaO
z_)L-#F$4$@AV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyKw$F%O`lYG@E0HXy(*)0i{*UU&gzVl6K4+XCP|4H0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyuz7)|PpW+K
zL*MvBl~KCIaz1Tmb;hOH-l5$jDG@_}009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXzFVOT!l{?>c<Uo~Cy2WxnZD)1HNxye!
zHz}*l*VKRj0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&oO`lZx;m)`IqRJ@UVmY6-vpVDC^l0#zBqd@95FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7e?<^`HQsdDc-
zzj}3*QM$!)K5b`p#>t8DDl<t+#1J4rfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+0D;X5G<{NK`_ha4rphSYVmY6-vpVC_Y~Rps
zl9Y%cK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pkn-^&Mq{>r|KhsqirCTiL({@&8ob>yKc9XK&d`%4q5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7dX()3A{XPRIC
z<tn3ei{*UU&gzVl)B6XXNm3$)009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXFY+j)0lPa^bp4?w$ly0${Pup3YadP6o&~B2H
zh#^3L009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0Ro#BX!@kemp*drXR3_SEtd0XJF7D;%?=LjCP|4H0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyuz7)|PpUL0`_EPx
zrCTiL({@&8ob(5Wc9XK&d`%4q5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7dX()3A{-@0<Tzse}xVmY6-vpVDC^cx1BNm3$)
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXFY+j)0lPW*>qc1;EWt48QoKM?XopEyFtfAc`DG@_}009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXzFVOT!mAjt(xvt76
z-C{YPwzE3p(ySWVO_CBZ1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZVDkdaiKNPde{kPhtBleumh)*lt20jeYG^k}O2iN#
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pkn-(}y3Y?ucoqhgtZIggAR+|Lm(9rF|@;=EokN?J5Yk|E(
zU^rj47FdOMXLYqYPkivj=hwn#mcRphb^}+HKZnzP?T#1M0ta$158Qmg^{dFv{r5Ec
zUvs?gHOH&mIk|56h5K&0{kHDZ(NnkIHox(ftZs2#d2Qv^bKiMJRlaoUj+^d0dg|nj
z@0qqcd&=*5@-1&a>(+mG{#zco^zhq0bnxGPZmTrgzq(qP!{z*E9(wfRk3MzD)ej#z
zIlAiJ^WJ_=Ie&2XbdC*~pIUzYuU4BUtXIDK+s_?duYAdsAA9q9<<;?l;XB<g{Oz%q
zfA_4No?AZL&IdmJ^j1}FbnEQ+Wk)YRdg*pq?|F%9<+(3^^0rTZcRg|FmF*m+udmfR
z%H<E``5*oDW5c!(<!CkMmI5z7{g>NL+vy7ExrhGpxBu{09=Y}-7wrGyxz}Cu^%c;|
zPydatwmS04hso|g*q`3;?w?(|*5CaHyJqqDd)EU0|9`OeJ$mo`YvI595B8-`-ShZb
zVEt)bHvZKk>rZQSy#BOS$GZ>acYpKGAA5=Y@}pPmKA5c^doWiVe)fg+#H$Zx_WB-7
z)33Jf_{uN6aNyNnvAcE0>H(E0TX*!s!W#hs1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oTt?K+`8xw*Gj}C#sCnEtd0XJF7EJ
z%8AuXURmuPdnZ7E009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0Ro#6X!@kehrjjwB~?c07R&jxoz)p9r}qq<CP|4H0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyuz7)|
zPpUk7OZELKqjZbqeA>?HjFS^vL%T^*B8C6~0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PE+ipy`t;C$D(%nku7oi{*UU&gzUy
zv+beXBq<R?fB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C7HZRchNtK7cy8p>4qjZbqeA>?HjFWzQXg4XV&DYd`009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXFBu$@G
zx%P(de80*l-C{YPwzE3p<n$SX&m<`kLx2DQ0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1U4_w^huQmfANvut1?QrSk9;Itj;(&
zapur&l9Y%cK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pkn-^&Mq{=5h^o>tc8Kqk+=hJppXIz@?9okKj5-|h_5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV6UA0!^P(
zx$|8|4pbSXTP)|(c2;Mc^m~VPld{@;O$`VTAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!8Bf^huQ;?tJSns*KVtmh)*lt20hc
zj|QJfQX+-`0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5(bUZCldD)+wgt5;VUrCTiL({@&8oSZ1HGLxi43;_ZJ2oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5ZJsx(<fE7
zFTLn*s*KVtmh)*lt1~Xm_6_YONr@N&1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNB!d4Z-+syy}hGhLNYy2WxnZD)1HNxyGs
zHz}*l*VKRj0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&oO`lYGrup?>t};ruSk9;Itj;(&y?^kTBqd@95FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7e?<^`HQsWLn3
z$^BJE=@!fRw4K!%CnpXJ?IuZy7y<+c5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAh3CXrcbJT=_AK}rphSYVmY6-vpVC_?BLLD
zl9Y%cK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pkn-^&Mq)KzL|7?{}y2WxnZD)1HNq=x?Hz}*l*VKRj0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&oO`lZxtt+Sd
ztBleumh)*lt20hczhUs1Bqd@95FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7e?<^`HQsq%wA`tlQ1M(GyI`LvzY87C*s8rn^g
z5-|h_5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV6UA0!^P(x$D`V>#B^>Etd0XJF7D;&8nf@Bq<R?fB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7HZRbeNUA*e2lu_T
z$|&7pIiI$(I^(3ThIW&rL<|7}1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNB!X@Mi9z}b1z+2=3UHVHUm
zwMjq@4c#s*?~{D<_-~xG7T7xkhVx}>fmL{SR#&U@#0Ot|el2`v2|Tc8H*i(?b2#nS
z?s#!6a3BZsz|9w2zl!YKe^0ajHOKp2b9`ROZRa2Ts}KBHm3_H&cKnK?(@T$Dx?S$G
z{nCBTEs=e>`1kL7*N;UGy|NL)&asj>oS#~L{;yV>A*@%p``gbQUaxS;l^=WadWF?-
z)35ecc<Lwq`*&ac9XrF`3gu#}DSIpQ!@?T@0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBn=ut3u%RknY0!TYO>(k+(rX}eQr
zoRkx*nY^;vJ@!t3009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXzCD8Oqm3u$^<bSI&O1D_fr|nLiadLXk&}ovCh#^3L009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0Ro#B
zX!@keH-GZty2>csVmY6-J9Wm%iLIgCBq<R?fB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7HZRchNtIh~f96wFM(GyI`Lx}s
zGcL`xhjx>sL<|7}1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oTu3K+`8x{=>&E`Uh1;=@!fRwB4yQPWtVk-K4BGUsD4D1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNBU
zG<{O#=MR6mt};ruSk9;IPMvXb`i#M6l9Y%cK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pkn-^&Mq{{E_`S{OQ8Kqk+=hJql
z&Nw-7=Fo1El!zfffB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009D<7ijvV%KeY_@2@gSw^+`n?M|I>X|{K0H%Usw5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7csfz1mv
zeNyGFpFZ~8Dx-9Z<$T)i)EOuJ-l5&3tTta$0|EpH5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAdobDQsoEl|J*yOjM6QZ^J%+N
zXPlfK4L*~kL<|7}1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oTu3K+`8xK77&t{dZMH=@!fRwB4yQPEM3pnMqP2h5!Kq1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72y9-U
z>60p3@7q7AGD^2t&Zq58opEWlZ)i73O2iN#K!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB=Eb3p9OF<txAQ;s>jY(k+(rX}eQr
zob>yKc9XK&d`%4q5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7dX()3A{r~m1v9;q@)w^+`n?M|I>a(e&ZGf7Is5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7csfz1mv
zeNtuTn&-b)Wt48QoKM@GI^*QTfuY?bDG@_}009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXzFVOT!l`sCMBac=YrCTiL({`uM
zxHLOBw3{R)Vh9i*K!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfWYPjnm(!WrVGFE&#H{lEtd0XyHjVJ^aqD_ld{@;O$`VTAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!8Bf
z^huSE-c^6E$|&7pIiI#Wb;il*Hw-?Lq(lq>0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBn=yg<_@Retz`?_5@8ly0${Purb3
z<K)CyL%T^*B8C6~0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PE+ipy`t;cRqOj2dj+IEtd0XyHjUenpH!)Nm3$)009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXFY+j%_
zkyLsAse{*48Kqk+=hJql&N%6-q1_}Y5kr6g0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5(bTHr`2aCUy}
zqA&mRwM_!fSZxxJLqoR<%ljmEzxeP^t_AiEf#H1FT3{94oz>Oq{QE~PE;|govgN>;
zCGfzW-N04l&*9v6VE?~f3mnM7JaF>`*RLX%T=}s#?_WE<^}P?gdEaY}SGjX?-SP|f
z-E{kH-KnFeZoh4Q<1Ja;;=1zM%46@l=zmn@OQ-I*>CU64PTu&QSv%WPe$TPV@vUR`
zKk<+M<L~^7BUk_LJ5O(wW^Y(st<2$a{xc6fdhth}y5#DIkDMG`b?<p^Kc}2OxO+Os
zhRo-7epq%>NY*R=%b)n(h3l37{(q@|dcE@M_`LF+?Y!mxTzh?$eYtgZ{PLsIouij-
zmm6%oM00M5?8_IvaQx{XiyV3hviyYCSE1=w+d<s?w*8mCOkXZJYzI+pyqdBdL_aLN
z5g<T-009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7csfei~ZeNyGKpLy}YDx-9Z<$Tu8>Wq_eVl|UjR=daE2@oJafB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+z@`M6KB;p2o7MSM
zM(GyI`K+DQ87HUr44o!Pi5LO|2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FoI5fu>KY+;Hpj|GCO2-C{YPwX-_o<iys{ZjzLU
zAwYlt0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0-G0T`lQMeSM7OEl~KCIaz1Nkb;hOH_RwyUl!zfffB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009D<7ijvV${AmK;p<gK
z=@!fRtew>v|G#$b?$wsFFa!8=az19A<d`?kB*w$UkDMU3X-=BVP9SM6vLh+d55<<I
zL_}62%rt`&O^kXWLJyJ)FN`11QhJeIg=*7_YE#-?6f=}4#DG>qr4)rq3tDQi7ZqBi
z(%ExFx4G@b-25KcYrn&K_FB*W{Q++>pIp~9%W3<W77!pnfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+0D+{Plae34qkg`m$}moS
zx9{rgl1rynpC(x<LVy4P0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1hyAw=cMG?x8DEBk}AVE_1(U!vr7(7uj`s*sR#iA1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oTs_
zpq-PF8=kn~GbL4qaq7E$S7)~@JF~89lBFU92oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkKcdx3UNO1{*8=dO|}!#MTbzN@oK
z<}>TMW;ty?(*gnn2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5Fn7Wb5e5O?dLyMQe_yYzT0<ocFCn`^=Xo&A_NE!AV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyKwx`;c1}v}
z7~c3;NtI!o`flIV*(Ha|&yprtDnft&0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0tB`fXy>Hlx$f&<D5)}xQ{U~oI=f}r*>zo$
zEEOR@fB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009Eq3$$}mGQM=-fs!i2IQ8AWtFueyv+KHMIc-1F0s;gG5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAds|kQu5IG4?R*+
zWf-Tv+jn(#$)zh-pC(x<LVy4P0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1hyAw=cMH0=We;Xq{=W(eYfxG?2^N))^$y?RD=Kl
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PE*|(9TK8V^6;LnvyERIQ8AWtFv2{om<y6$x;yl1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNB!y+AuBC7+(|eX^v=Fiw59
z@9ON5`P{m$Sx(!}w15Bs0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PCPUoRr*h*O%`usWOaH-|f3PyX4X<R-YzWDnft&0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0tB`f
zXy>Hl@Y&nHRZ?Xbr@q^Fb#}?&)$6(@St>$+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjZJ7ij0C<i&5#50q3H#;Nc2U7g*s
ztgP#rWT^-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBn=UZ6cpN<MYd=MGD%4CB;y`>xI|najGaNtTKbAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0$U4QzYKU~&cEst&mX%a;MCD20l8+~cGL3O<kUyL^4(*FGizaef4N%VsC+p`
zpH}CqPdxJAvGVDq@brnxg?pA?*XHoHNAEpWxGLxJ^ure(JgU6mi}lS{9((S07j8cL
zvgf1Tb$Q$L!c*^h|NDl=FFyYM_w^4wlB2J9+wyZoZv3-<8_V)XkAL7@AH4YZdmehU
z+aH`*{-4)9d;ed2?XOS&^0V*w`{&;I_J9BK70a@#k3Mb5wafdT{qq-Z`P4uB;+y{F
z`u9}#eDwTpUbnn|?(*BYW9_`|si$8$x;)|d<afXJdp8}Q{LnMgt;Z)HJ)d9x=45{D
z2X9_r&gQ+{op)Wl{ovwlCzmg{;>R?vUMgqv!V7nP<7X<@{PgaI|KEgmKDrL#;orFO
zu4DA;br8!JA7!}?VqOnk2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+z{UdYoRob2vp@PwNtI!o`flIV*(J*xM`?a?y8P^w
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXFY$ednNy(l6T5c$*GK^E-?Yla=<kE?CQ<E$eAwYlt0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0^19;b5ip5_x|VeB~^xT
z>brecXO|pav94>9r6L3f5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV6Syfp$(xzIM-vM@y;<<J5QiuFh^*c5+?UBuhmI5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7e?
z_5$skl$`pf@Bed2m0_IvZr|0}CG*L3U9+6FpJ@RB0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBmF+Bqrt;XCT*OR5ax)OY)?
z&MvuhYV~Q7r6L3f5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV6Syfp$(xu6^tMpDd{|j8ot3yE?n%@btQ_NtTKbAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5;&?FHI7
zDY@Z^8$MG~Wf-Tv+jn(#%d#`;x+YmFLVy4P0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1hyAw=cMFI{devvsWOaH-|f3PyJSAI
zu4|Ul_A@OYK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pkNjoPc_uYQ}V<lCFaq7E$S7(=8s#c#SSt>$+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjZJ7ij0C<c{Hu
zkCjvz#;Nc2U7cNWxcn?>lBFU92oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkKcdx3UNN}lV!{)Lh%!#MTbzN@oamYrSKHOW#D
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyu)RP#Cne)c7al07GK^E-?Yla=WInsDYnIdYGc6!MfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C?J0~R%o&V4yB~^xT
z>brecXO~>Ma`kDFr6L3f5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV6Syfp$(xK7Q_&yGyDJ<J5QiuFftwylP$7BuhmI5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7e?
z_5$sklsxw2i?1oEGK^E-?Yla=W!brPU6U*oAwYlt0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0^19;b5io@>E0(xstn`Qcl)l+
zE}74*>zd`X{Y(o85FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7dX(#}cAEq8tS?vg6QIQ8AWtFucky<+uglBFU92oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkKcdx3UN
zN)DgB{aYnfhH>h<eOG6f9A3SyYm%iR1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZV0(dfPD)<<_WVFem0_IvZr|0}Ez8Qf
zu1S`P5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7csf$as_!=&U>H+}A~q{=W(eYfxG?2@^x>zZV#2mt~F2oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FoI%!1c?3SLXbyKJomqO9D<ET@sLM)@?T}uT4&U<SXAjRyea3*7ujI1&+#>bM$F-
zzWT%?4<0L@UJ6g2xLmkr`E_j$Z+rCKV}+}7E>Ayv;lZQI8@^cIeC4s{es|&KvoCu-
zzw}P#bNTIyC1>;A?#{a}-hRi$+fFXubMnXE^XjE?Hh=Z2Z~Didsa*4uix3X(SQ^*n
zbx%G0($QrI$0xk|wcoqx_=Ja^nQlEk;pn-YkM33&Z}|Cd{`CJiSnpO?KI|yV-3s%1
z@Irt90RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t7Y|Xy>Hlx&Qs<TS}@7<J5QigF3rpdE+R}PfnMgy%HcmfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+0D-Lp+Bqq?<4<q-
zpOPxWIQ8BBpw2G2bYk7qBuhmI5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7e?_5$sklstIhr5j7C4CB;y`-3{W<nW4hU6U*o
zAwYlt0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0^19;b5ios2QU0VNtI!o`fh(vXSXanxvp!Hr6L3f5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV6Syfp$(xPXFQ8PnT2~
z#;Nc22X%JId~#jaET`>fT0npR0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0tAwFPD+08s@rcYsWOaH-|Y|T?2=2TR-YzWDnft&
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0tB`fXy>Hlx|6^Afs!i2IQ8BBpw2EiJiV@KlBFU92oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkKcdx3UNN?!BAy>BV0GK^E-
z?GNhgmStzwbxpEVga82o1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72y8FV&PmCOKlkD{OR5ax)OY)XI=f^(v#x8F)AlnhAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0!ce3C5IpWrLm;SFiw59Kd7@yE>){flPnb>K!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk+Y7XFQgY`nocjHeD#JMS-Tt7?
zE;(F&mNdyy5ds7V5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAh5kaJ0~Td|Gn?OzNE@9PJOpOsIyy^on6;8$x;yl1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNB!y+AuB
zB@h4ciO-f)8OEva_6K!#$$WNQ*DR;)XIemj009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjY)c1}uu=eOSe(UK~|IQ8BBpw2G2
zbmi*PBuhmI5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N
z0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7e?_5$sklzig8@{N)z!#MTb{-Dk-IlO9J*Cb0t2oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+!1e;|oRmB|
zf9JnTstn`Qcl(1nyJgwAbzPGz6(K-?009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0Rr0#v~yDOCpX^ka7mS6oceBmP-mCS=hk)2
za@u~T1q28XAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyKp<)7q~ziU{^J`ZRfciuyZu3(U2^Fat51_G6(K-?009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0Rr0#v~yB&-;e53
zB~^xT>bw0xon3Nx^}4P}mWmJ{K!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZ
zfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&U
zAV7cs0RjXF5FkK+009C72oNAZfB=E*1==|&`O-80^4XFq!#MTb{-DloSyt9{O|n#k
z009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBly
zK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF
z5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk
z1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!5-N0t5&UAV7cs
z0RjXFY%kCrCM9qF!Rvp$q{=W(eYZcTvrFc(u4|H|A_NE!AV7cs0RjXF5FkK+009C7
z2oNAZfB*pk1PBlyK!5-N0t5&UAV7cs0RjXF5FkK+009C72oNAZfB*pk1PBlyK!Cv3
z0@p7CUYQTy`p*A4c1gggqe}vE&ARQT<+aHl{mKvj?pWc>T3Fv-t`;~dU(V5|)%nZ6
zeeU67<<m>y=@XX=_bk7z&HY!u`h&*`SLIxue)z(JN0o=3nQp!EWzT0{_I%X4E^nJ&
Hc<TQEiO|s7
literal 0
HcmV?d00001
diff --git a/tests/misc-tests/016-send-clone-src/test.sh b/tests/misc-tests/016-send-clone-src/test.sh
new file mode 100755
index 0000000..c6f0abc
--- /dev/null
+++ b/tests/misc-tests/016-send-clone-src/test.sh
@@ -0,0 +1,49 @@
+#!/bin/bash
+#
+# test for sending stream size of clone-src option
+
+source $TOP/tests/common
+
+check_prereq mkfs.btrfs
+check_prereq btrfs
+
+setup_root_helper
+prepare_test_dev 1g
+
+run_check $TOP/mkfs.btrfs -f $IMAGE
+run_check_mount_test_dev
+
+here=`pwd`
+cd "$TEST_MNT" || _fail "cannot chdir to TEST_MNT"
+
+run_check $SUDO_HELPER $TOP/btrfs subvolume create subv-parent1
+for i in 1 2 3; do
+ run_check $SUDO_HELPER dd if=/dev/zero of=subv-parent1/file1_$i bs=1M count=1
+ run_check $SUDO_HELPER $TOP/btrfs subvolume snapshot -r subv-parent1 subv-snap1_$i
+done
+
+run_check $SUDO_HELPER $TOP/btrfs subvolume create subv-parent2
+for i in 1 2 3; do
+ run_check $SUDO_HELPER dd if=/dev/zero of=subv-parent2/file2_$i bs=1M count=1
+ run_check $SUDO_HELPER $TOP/btrfs subvolume snapshot -r subv-parent2 subv-snap2_$i
+done
+
+truncate -s0 "$here"/send-stream.img
+chmod a+w "$here"/send-stream.img
+run_check $SUDO_HELPER $TOP/btrfs send -f "$here"/send-stream.img \
+ -c subv-snap1_1 -c subv-snap2_1 subv-snap1_[23] subv-snap2_[23]
+
+old_stream_size=`stat --format=%s "$here"/send-stream-v4.8.2.img`
+stream_size=`stat --format=%s "$here"/send-stream.img`
+
+if [ $old_stream_size -lt $stream_size ]; then
+ run_check ls -l "$here"/send-stream-v4.8.2.img "$here"/send-stream.img
+ _fail "sending stream size is bigger than old stream"
+fi
+
+run_check rm -f "$here"/send-stream.img
+
+cd "$here" || _fail "cannot chdir back to test directory"
+
+run_check_umount_test_dev
+
--
2.9.3
^ permalink raw reply related
* Re: BUG: Hung task timeouts in for-4.10/dio
From: Damien Le Moal @ 2016-11-09 1:25 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Jens Axboe, Logan Gunthorpe, linux-block, Mike Snitzer
In-Reply-To: <20161109010959.GA32126@lst.de>
On 11/9/16 10:09, Christoph Hellwig wrote:
> Ok, sounds like I'm really the one to blame. I'll see if I can
> find a reproducer. Damien, or you using device mapper on that
> system?
No LVM/md/dm used on boot. Mount is direct to the block device (SSDs
with ext4). The devices are simple SSDs, so no polling involved.
The hangs suspiciously look like they are either background write or
flush. So I was wondering if it is indeed related to FLUSH/FUA as Logan
suggested or the background write stuff, rather than the direct-IO
optimization & polling.
Will try again/bisect to see if I can get more info.
Cheers.
--
Damien Le Moal, Ph.D.
Sr. Manager, System Software Research Group,
Western Digital Corporation
Damien.LeMoal@wdc.com
(+81) 0466-98-3593 (ext. 513593)
1 kirihara-cho, Fujisawa,
Kanagawa, 252-0888 Japan
www.wdc.com, www.hgst.com
^ permalink raw reply
* Re: [PATCH 2/4] usb: musb: Fix sleeping function called from invalid context for hdrc glue
From: Tony Lindgren @ 2016-11-09 1: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: <20161108190331.GA14744@localhost>
* Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161108 12:03]:
> On Tue, Nov 08, 2016 at 10:34:13AM -0700, Tony Lindgren wrote:
> > * Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [161108 10:09]:
> > > On Mon, Nov 07, 2016 at 02:50:18PM -0700, Tony Lindgren wrote:
> > > > @@ -2604,6 +2669,9 @@ static int musb_resume(struct device *dev)
> > > > mask = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_FSDEV | MUSB_DEVCTL_LSDEV;
> > > > if ((devctl & mask) != (musb->context.devctl & mask))
> > > > musb->port1_status = 0;
> > > > +
> > > > + schedule_delayed_work(&musb->pending_resume_work, 0);
> > > > +
> > >
> > > The interactions with system suspend looks a bit suspicious. It seems
> > > you need to drain any pending resume work on suspend for example.
> > >
> > > And then the above should not be needed, right?
> >
> > Hmm that's an interesting idea. I think that would allow us to get
> > rid of the delayed work if we check the list both on resume and
> > suspend :)
>
> Note that I was referring to draining the runtime-resume work on system
> suspend above. I think we still want the delayed work considering that
> we could stay active for long periods of time.
It seems it's the delayed work causing these race issues, so I'd like
to avoid it. I think we can do it all from PM runtime resume and
checking at the end of musb_queue_resume_work(). We need to introduce
is_runtime_suspended though. This is along the lines of what we have
in Documentation/power/runtime_pm.txt if you search for completion
there.
Below is a version doing things without delayed work, care to check
again if you still see races there?
> > > In fact, the dsps timer must also be cancelled on suspend, or you could
> > > end up calling dsps_check_status() while suspended (it is currently not
> > > cancelled until the parent device is suspended, which could be too
> > > late).
> >
> > And then this should no longer be an issue either.
>
> It would still be an issue as a system-suspending device could already
> have been runtime-resumed so that dsps_check_status() would be called
> directly from the timer function.
The glue layers should do pm_runtime_get_sync(musb->controller) which
dsps glue already does. So that's the musb_core.c device instance. And
looks like we have dsps_suspend() call del_timer_sync(&glue->timer)
already. I think we're safe here.
Regards,
Tony
8< ----------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Date: Wed, 2 Nov 2016 19:59:05 -0700
Subject: [PATCH] usb: musb: Fix sleeping function called from invalid
context for hdrc glue
Commit 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
glue layer") wrongly added a call for pm_runtime_get_sync to otg_timer
that runs in softirq context. That causes a "BUG: sleeping function called
from invalid context" every time when polling the cable status:
[<c015ebb4>] (__might_sleep) from [<c0413d60>] (__pm_runtime_resume+0x9c/0xa0)
[<c0413d60>] (__pm_runtime_resume) from [<c04d0bc4>] (otg_timer+0x3c/0x254)
[<c04d0bc4>] (otg_timer) from [<c0191180>] (call_timer_fn+0xfc/0x41c)
[<c0191180>] (call_timer_fn) from [<c01915c0>] (expire_timers+0x120/0x210)
[<c01915c0>] (expire_timers) from [<c0191acc>] (run_timer_softirq+0xa4/0xdc)
[<c0191acc>] (run_timer_softirq) from [<c010168c>] (__do_softirq+0x12c/0x594)
I did not notice that as I did not have CONFIG_DEBUG_ATOMIC_SLEEP enabled.
And looks like also musb_gadget_queue() suffers from the same problem.
Let's fix the issue by using a list of delayed work then call it on
resume. Note that we want to do this only when musb core and it's
parent devices are awake as noted by Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>.
Later on we may be able to remove other delayed work in the musb driver
and just do it from pending_resume_work. But this should be done only
for delayed work that does not have other timing requirements beyond
just being run on resume.
Fixes: 65b3f50ed6fa ("usb: musb: Add PM runtime support for MUSB DSPS
glue layer")
Reported-by: Johan Hovold <johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
---
drivers/usb/musb/musb_core.c | 114 +++++++++++++++++++++++++++++++++++++++--
drivers/usb/musb/musb_core.h | 7 +++
drivers/usb/musb/musb_dsps.c | 31 +++++++----
drivers/usb/musb/musb_gadget.c | 21 ++++++--
4 files changed, 156 insertions(+), 17 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1969,6 +1969,7 @@ static struct musb *allocate_instance(struct device *dev,
INIT_LIST_HEAD(&musb->control);
INIT_LIST_HEAD(&musb->in_bulk);
INIT_LIST_HEAD(&musb->out_bulk);
+ INIT_LIST_HEAD(&musb->pending_list);
musb->vbuserr_retry = VBUSERR_RETRY_COUNT;
musb->a_wait_bcon = OTG_TIME_A_WAIT_BCON;
@@ -2018,6 +2019,87 @@ static void musb_free(struct musb *musb)
musb_host_free(musb);
}
+struct musb_pending_work {
+ int (*callback)(struct musb *musb, void *data);
+ void *data;
+ struct list_head node;
+};
+
+/*
+ * Called from musb_runtime_resume(), musb_resume(), and
+ * musb_queue_resume_work(). Callers must take musb->lock.
+ */
+static int musb_run_resume_work(struct musb *musb)
+{
+ struct musb_pending_work *w, *_w;
+ unsigned long flags;
+ int error = 0;
+
+ spin_lock_irqsave(&musb->list_lock, flags);
+ list_for_each_entry_safe(w, _w, &musb->pending_list, node) {
+ if (w->callback) {
+ error = w->callback(musb, w->data);
+ if (error < 0) {
+ dev_err(musb->controller,
+ "resume callback %p failed: %i\n",
+ w->callback, error);
+ }
+ }
+ list_del(&w->node);
+ devm_kfree(musb->controller, w);
+ }
+ spin_unlock_irqrestore(&musb->list_lock, flags);
+
+ return error;
+}
+
+/*
+ * Called to run work if device is active or else queue the work to happen
+ * on resume. Caller must take musb->lock.
+ *
+ * Note that we cowardly refuse queuing work after musb PM runtime
+ * resume is done calling musb_run_resume_work() and return -EINPROGRESS
+ * instead.
+ */
+int musb_queue_resume_work(struct musb *musb,
+ int (*callback)(struct musb *musb, void *data),
+ void *data)
+{
+ struct musb_pending_work *w;
+ unsigned long flags;
+ int error;
+
+ if (WARN_ON(!callback))
+ return -EINVAL;
+
+ if (pm_runtime_active(musb->controller))
+ return callback(musb, data);
+
+ w = devm_kzalloc(musb->controller, sizeof(*w), GFP_ATOMIC);
+ if (!w)
+ return -ENOMEM;
+
+ w->callback = callback;
+ w->data = data;
+ spin_lock_irqsave(&musb->list_lock, flags);
+ if (musb->is_runtime_suspended) {
+ list_add_tail(&w->node, &musb->pending_list);
+ error = 0;
+ } else {
+ dev_err(musb->controller, "could not add resume work %p\n",
+ callback);
+ devm_kfree(musb->controller, w);
+ error = -EINPROGRESS;
+ }
+ spin_unlock_irqrestore(&musb->list_lock, flags);
+
+ if (pm_runtime_active(musb->controller))
+ return musb_run_resume_work(musb);
+
+ return error;
+}
+EXPORT_SYMBOL_GPL(musb_queue_resume_work);
+
static void musb_deassert_reset(struct work_struct *work)
{
struct musb *musb;
@@ -2065,6 +2147,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
}
spin_lock_init(&musb->lock);
+ spin_lock_init(&musb->list_lock);
musb->board_set_power = plat->set_power;
musb->min_power = plat->min_power;
musb->ops = plat->platform_ops;
@@ -2556,6 +2639,7 @@ static int musb_suspend(struct device *dev)
struct musb *musb = dev_to_musb(dev);
unsigned long flags;
+ WARN_ON(!list_empty(&musb->pending_list));
musb_platform_disable(musb);
musb_generic_disable(musb);
@@ -2579,9 +2663,11 @@ static int musb_suspend(struct device *dev)
static int musb_resume(struct device *dev)
{
- struct musb *musb = dev_to_musb(dev);
- u8 devctl;
- u8 mask;
+ struct musb *musb = dev_to_musb(dev);
+ unsigned long flags;
+ int error;
+ u8 devctl;
+ u8 mask;
/*
* For static cmos like DaVinci, register values were preserved
@@ -2599,6 +2685,7 @@ static int musb_resume(struct device *dev)
mask = MUSB_DEVCTL_BDEVICE | MUSB_DEVCTL_FSDEV | MUSB_DEVCTL_LSDEV;
if ((devctl & mask) != (musb->context.devctl & mask))
musb->port1_status = 0;
+
if (musb->need_finish_resume) {
musb->need_finish_resume = 0;
schedule_delayed_work(&musb->finish_resume_work,
@@ -2615,6 +2702,13 @@ static int musb_resume(struct device *dev)
musb_start(musb);
+ spin_lock_irqsave(&musb->lock, flags);
+ error = musb_run_resume_work(musb);
+ if (error)
+ dev_err(musb->controller, "resume work failed with %i\n",
+ error);
+ spin_unlock_irqrestore(&musb->lock, flags);
+
return 0;
}
@@ -2622,14 +2716,18 @@ static int musb_runtime_suspend(struct device *dev)
{
struct musb *musb = dev_to_musb(dev);
+ WARN_ON(!list_empty(&musb->pending_list));
musb_save_context(musb);
+ musb->is_runtime_suspended = 1;
return 0;
}
static int musb_runtime_resume(struct device *dev)
{
- struct musb *musb = dev_to_musb(dev);
+ struct musb *musb = dev_to_musb(dev);
+ unsigned long flags;
+ int error;
/*
* When pm_runtime_get_sync called for the first time in driver
@@ -2651,6 +2749,14 @@ static int musb_runtime_resume(struct device *dev)
msecs_to_jiffies(USB_RESUME_TIMEOUT));
}
+ spin_lock_irqsave(&musb->lock, flags);
+ error = musb_run_resume_work(musb);
+ if (error)
+ dev_err(musb->controller, "resume work failed with %i\n",
+ error);
+ musb->is_runtime_suspended = 0;
+ spin_unlock_irqrestore(&musb->lock, flags);
+
return 0;
}
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -303,6 +303,7 @@ struct musb_context_registers {
struct musb {
/* device lock */
spinlock_t lock;
+ spinlock_t list_lock; /* resume work list lock */
struct musb_io io;
const struct musb_platform_ops *ops;
@@ -337,6 +338,7 @@ struct musb {
struct list_head control; /* of musb_qh */
struct list_head in_bulk; /* of musb_qh */
struct list_head out_bulk; /* of musb_qh */
+ struct list_head pending_list; /* pending work list */
struct timer_list otg_timer;
struct notifier_block nb;
@@ -386,6 +388,7 @@ struct musb {
unsigned long idle_timeout; /* Next timeout in jiffies */
unsigned is_initialized:1;
+ unsigned is_runtime_suspended:1;
/* active means connected and not suspended */
unsigned is_active:1;
@@ -542,6 +545,10 @@ extern irqreturn_t musb_interrupt(struct musb *);
extern void musb_hnp_stop(struct musb *musb);
+int musb_queue_resume_work(struct musb *musb,
+ int (*callback)(struct musb *musb, void *data),
+ void *data);
+
static inline void musb_platform_set_vbus(struct musb *musb, int is_on)
{
if (musb->ops->set_vbus)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -188,21 +188,15 @@ static void dsps_musb_disable(struct musb *musb)
musb_writeb(musb->mregs, MUSB_DEVCTL, 0);
}
-static void otg_timer(unsigned long _musb)
+/* Caller must take musb->lock */
+static int dsps_check_status(struct musb *musb, void *unused)
{
- struct musb *musb = (void *)_musb;
void __iomem *mregs = musb->mregs;
struct device *dev = musb->controller;
struct dsps_glue *glue = dev_get_drvdata(dev->parent);
const struct dsps_musb_wrapper *wrp = glue->wrp;
u8 devctl;
- unsigned long flags;
int skip_session = 0;
- int err;
-
- err = pm_runtime_get_sync(dev);
- if (err < 0)
- dev_err(dev, "Poll could not pm_runtime_get: %i\n", err);
/*
* We poll because DSPS IP's won't expose several OTG-critical
@@ -212,7 +206,6 @@ static void otg_timer(unsigned long _musb)
dev_dbg(musb->controller, "Poll devctl %02x (%s)\n", devctl,
usb_otg_state_string(musb->xceiv->otg->state));
- spin_lock_irqsave(&musb->lock, flags);
switch (musb->xceiv->otg->state) {
case OTG_STATE_A_WAIT_VRISE:
mod_timer(&glue->timer, jiffies +
@@ -245,8 +238,26 @@ static void otg_timer(unsigned long _musb)
default:
break;
}
- spin_unlock_irqrestore(&musb->lock, flags);
+ return 0;
+}
+
+static void otg_timer(unsigned long _musb)
+{
+ struct musb *musb = (void *)_musb;
+ struct device *dev = musb->controller;
+ unsigned long flags;
+ int err;
+
+ err = pm_runtime_get(dev);
+ if (err < 0)
+ dev_err(dev, "Poll could not pm_runtime_get: %i\n", err);
+
+ spin_lock_irqsave(&musb->lock, flags);
+ err = musb_queue_resume_work(musb, dsps_check_status, NULL);
+ if (err < 0)
+ dev_err(dev, "%s resume work: %i\n", __func__, err);
+ spin_unlock_irqrestore(&musb->lock, flags);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
}
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1222,6 +1222,15 @@ void musb_ep_restart(struct musb *musb, struct musb_request *req)
rxstate(musb, req);
}
+static int musb_ep_restart_resume_work(struct musb *musb, void *data)
+{
+ struct musb_request *req = data;
+
+ musb_ep_restart(musb, req);
+
+ return 0;
+}
+
static int musb_gadget_queue(struct usb_ep *ep, struct usb_request *req,
gfp_t gfp_flags)
{
@@ -1255,7 +1264,7 @@ static int musb_gadget_queue(struct usb_ep *ep, struct usb_request *req,
map_dma_buffer(request, musb, musb_ep);
- pm_runtime_get_sync(musb->controller);
+ pm_runtime_get(musb->controller);
spin_lock_irqsave(&musb->lock, lockflags);
/* don't queue if the ep is down */
@@ -1271,8 +1280,14 @@ static int musb_gadget_queue(struct usb_ep *ep, struct usb_request *req,
list_add_tail(&request->list, &musb_ep->req_list);
/* it this is the head of the queue, start i/o ... */
- if (!musb_ep->busy && &request->list == musb_ep->req_list.next)
- musb_ep_restart(musb, request);
+ if (!musb_ep->busy && &request->list == musb_ep->req_list.next) {
+ status = musb_queue_resume_work(musb,
+ musb_ep_restart_resume_work,
+ request);
+ if (status < 0)
+ dev_err(musb->controller, "%s resume work: %i\n",
+ __func__, status);
+ }
unlock:
spin_unlock_irqrestore(&musb->lock, lockflags);
--
2.10.2
--
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
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.