* ✓ Fi.CI.BAT: success for drm/i915: cleanup use of INSTR_CLIENT_MASK
From: Patchwork @ 2016-11-14 23:15 UTC (permalink / raw)
To: Matthew Auld; +Cc: intel-gfx
In-Reply-To: <1479163174-29686-1-git-send-email-matthew.auld@intel.com>
== Series Details ==
Series: drm/i915: cleanup use of INSTR_CLIENT_MASK
URL : https://patchwork.freedesktop.org/series/15306/
State : success
== Summary ==
Series 15306v1 drm/i915: cleanup use of INSTR_CLIENT_MASK
https://patchwork.freedesktop.org/api/1.0/series/15306/revisions/1/mbox/
fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15
fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40
fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53
fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
fi-skl-6700hq total:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21
fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33
2f21978cfd8984c79e4cbd77ce63d9f73fe226ef drm-intel-nightly: 2016y-11m-14d-21h-23m-10s UTC integration manifest
ee0d578 drm/i915: cleanup use of INSTR_CLIENT_MASK
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2991/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] rmc: Fix compiling issue with musl
From: Khem Raj @ 2016-11-14 23:15 UTC (permalink / raw)
To: Jianxun Zhang; +Cc: openembedded-core
In-Reply-To: <D48DD72C-50E1-4475-9976-65C59A0705D3@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 2369 bytes --]
On 11/14/16 3:08 PM, Jianxun Zhang wrote:
>
>> On Nov 14, 2016, at 2:50 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>
>>
>> On 11/14/16 2:10 PM, Jianxun Zhang wrote:
>>> | src/rmcl/rmcl.c: In function 'query_policy_from_db':
>>> | src/rmcl/rmcl.c:254:25: error: unknown type name 'ssize_t'
>>> | ssize_t cmd_name_len = strlen((char *)&rmc_db[policy_idx]) + 1;
>>> | ^~~~~~~~
>>>
>>> The musl C lib provides ssize_t but we need to enable it
>>> with a macro.
>>>
>>> Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
>>> ---
>>> Before maintainer(s) push "merge" button, please read this short summary.
>>> I feel there could be a better syntax to do it. And We could need to get
>>> an ack from Hernandez, Alejandro who reported this issue and seems still
>>> have (other) compiling errors even with this patch.
>>>
>>> I submit this patch based on my thoughts and test out of tiny config.
>>>
>>> Tests:
>>> () Specify TCLIBC = "musl" in local.conf in my build dir.
>>> () Build quark
>>> () I can see this issue happens without the fix
>>> () With this patch and do clean builds for quark and corei7-64,
>>> Compiling passes. Boot test passed on RMC targets quark and Broxton-m.
>>>
>>> Thanks
>>>
>>>
>>> common/recipes-bsp/rmc/rmc.bb | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
>>> index aeaf12e..61a1bdb 100644
>>> --- a/common/recipes-bsp/rmc/rmc.bb
>>> +++ b/common/recipes-bsp/rmc/rmc.bb
>>> @@ -24,6 +24,8 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
>>>
>>> EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"'
>>>
>>> +EXTRA_OEMAKE_append_libc-musl = '" -D__NEED_ssize_t"'
>>
>> this is not right way to handle it. you should be doing something like
>> #include <sys/types.h> in your source file
> Khem,
> Thanks lot for your review even when I wrongly submit it here! I tried it first but didn’t succeed for some reason with the suggested change.
mostly, it could be the makefiles not respecting the compiler options passed
from bitbake. You have to make sure that, all the -I<dir> options are used
properly which are relative to sysroot.
>
> Let me try it again...
>
>>
>>
>>> +
>>> # from gnu-efi, we should align arch-mapping with it.
>>> def rmc_efi_arch(d):
>>> import re
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]
^ permalink raw reply
* Re: [PATCH v2 05/10] dt-bindings: add documentation for rk1108 pinctrl
From: Heiko Stuebner @ 2016-11-14 23:13 UTC (permalink / raw)
To: Andy Yan
Cc: shawn.lin, linux-rockchip, linus.walleij, linux-gpio, robh+dt,
mark.rutland, linux-kernel
In-Reply-To: <1479125393-24355-1-git-send-email-andy.yan@rock-chips.com>
Am Montag, 14. November 2016, 20:09:53 CET schrieb Andy Yan:
> This adds the dt-binding documentation for rk1108 pinctrl
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
pretty straight forward
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
I guess at some later point we should move the compatible list to one
compatible per line, similar to what the mshc mmc does, because as we're
seeing right now, soc numbering is not incremental :-) .
Heiko
^ permalink raw reply
* Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale
From: Linus Walleij @ 2016-11-14 23:12 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Jonathan Cameron, Eva Rachel Retuya, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, Michael Hennerich, Hartmut Knaack,
Peter Meerwald, Greg KH
In-Reply-To: <b59ff168-c82e-26ed-9192-a491d97c5d6d@metafoo.de>
On Mon, Nov 14, 2016 at 7:53 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> It's about figuring out the setting of a "GPIO" that can't be changed from
> software.
>
> Devices sometimes, instead of a configuration bus like I2C or SPI, use
> simple input pins, that can either be set to high or low, to allow software
> the state of the device. The GPIO API is typically used to configure these pins.
>
> This works fine as long as the pin is connected to a GPIO. But sometimes the
> system designer decides that a settings does not need to be configurable, in
> this case the pin will be tied to logic low or high directly on the PCB
> without any GPIO controller being involved.
>
> Sometimes a driver wants to know how the pin is wired up so it can report to
> userspace this part runs in the following mode and the mode can't be
> changed. In a sense it is like a reverse GPIO hog.
>
> Considering that this is a common usecase the question was how this can be
> implemented in a driver independent way to avoid code duplication and
> slightly different variations of what is effectively the same DT/ACPI binding.
>
> E.g. lets say for a configurable pin you use
>
> range-gpio = <&gpio ...>;
>
> and for a static pin
>
> range-gpio-fixed = <1>;
>
> Or something similar.
Aha I understand.
Usually I feel we need not shoehorn stuff into GPIO because it is convenient,
it might be best to leave the GPIO optional and if it is not there, look for
a custom attribute that represents the "hogging" to 0/1. I think trying
to extend GPIO bindings to cover it is overgeneralization, instead go
for a local binding for this kind of devices.
But mainly it is a question to the DT bindings maintainers.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3] platform/x86/asus-nb-wmi.c: Add X45U quirk
From: Marcos Paulo de Souza @ 2016-11-14 23:12 UTC (permalink / raw)
To: Andy Shevchenko
Cc: dvhart@infradead.org, Corentin Chary, acpi4asus-user,
platform-driver-x86, linux-kernel@vger.kernel.org, stable
In-Reply-To: <CAHp75Veu5EGVEP=xPoeqDAbzzQ5bhP+jpCBTRbRhAxda=whWLA@mail.gmail.com>
On Tue, Nov 15, 2016 at 12:05:30AM +0200, Andy Shevchenko wrote:
> On Mon, Nov 14, 2016 at 11:32 AM, Marcos Paulo de Souza
> <marcos.souza.org@gmail.com> wrote:
> > ping?
>
> Please, don't do empty pings especially in top posting.
> I will look at this as soon as I can.
Hi Andy, my apologies. Thanks a lot for checking my patch.
>
> >
> > On Mon, Nov 07, 2016 at 10:02:32PM -0200, Marcos Paulo de Souza wrote:
> >> Without this patch, the Asus X45U wireless card can't be turned
> >> on (hard-blocked), but after a suspend/resume it just starts working.
> >>
> >> Following this bug report[1], there are other cases like this one, but
> >> this Asus is the only model that I can test.
> >>
> >> [1] https://ubuntuforums.org/showthread.php?t=2181558
> >>
> >> Cc: stable@vger.kernel.org # 4.4.x-
> >> Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
> >>
> >> ---
> >> v2 -> v3:
> >> Add stable version in the CC line of stable email address
> >> v1 -> v2:
> >> Add stable copy and specify the stable version to apply this patch
> >>
> >> drivers/platform/x86/asus-nb-wmi.c | 9 +++++++++
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
> >> index 26e4cbc..6032b70 100644
> >> --- a/drivers/platform/x86/asus-nb-wmi.c
> >> +++ b/drivers/platform/x86/asus-nb-wmi.c
> >> @@ -175,6 +175,15 @@ static const struct dmi_system_id asus_quirks[] = {
> >> },
> >> {
> >> .callback = dmi_matched,
> >> + .ident = "ASUSTeK COMPUTER INC. X45U",
> >> + .matches = {
> >> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> >> + DMI_MATCH(DMI_PRODUCT_NAME, "X45U"),
> >> + },
> >> + .driver_data = &quirk_asus_wapf4,
> >> + },
> >> + {
> >> + .callback = dmi_matched,
> >> .ident = "ASUSTeK COMPUTER INC. X456UA",
> >> .matches = {
> >> DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> >> --
> >> 2.7.4
>
>
>
> --
> With Best Regards,
> Andy Shevchenko
^ permalink raw reply
* [PATCH] crypto: sha*-mb Fix total_len for correct hash when larger than 512MB
From: Greg Tucker @ 2016-11-14 23:11 UTC (permalink / raw)
To: herbert, linux-crypto; +Cc: megha.dey, tim.c.chen, xiaodong.liu, Greg Tucker
Current multi-buffer hash implementations have a restriction on the total
length of a hash job to 512MB. Hashing larger buffers will result in an
incorrect hash. This extends the limit to 2^62 - 1.
Signed-off-by: Greg Tucker <greg.b.tucker@intel.com>
---
arch/x86/crypto/sha1-mb/sha1_mb.c | 2 +-
arch/x86/crypto/sha1-mb/sha1_mb_ctx.h | 2 +-
arch/x86/crypto/sha256-mb/sha256_mb.c | 2 +-
arch/x86/crypto/sha256-mb/sha256_mb_ctx.h | 2 +-
arch/x86/crypto/sha512-mb/sha512_mb.c | 2 +-
arch/x86/crypto/sha512-mb/sha512_mb_ctx.h | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/crypto/sha1-mb/sha1_mb.c b/arch/x86/crypto/sha1-mb/sha1_mb.c
index 9e5b671..acf9fdf 100644
--- a/arch/x86/crypto/sha1-mb/sha1_mb.c
+++ b/arch/x86/crypto/sha1-mb/sha1_mb.c
@@ -114,7 +114,7 @@ static inline void sha1_init_digest(uint32_t *digest)
}
static inline uint32_t sha1_pad(uint8_t padblock[SHA1_BLOCK_SIZE * 2],
- uint32_t total_len)
+ uint64_t total_len)
{
uint32_t i = total_len & (SHA1_BLOCK_SIZE - 1);
diff --git a/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h b/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h
index 98a35bc..13590cc 100644
--- a/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h
+++ b/arch/x86/crypto/sha1-mb/sha1_mb_ctx.h
@@ -125,7 +125,7 @@ struct sha1_hash_ctx {
/* error flag */
int error;
- uint32_t total_length;
+ uint64_t total_length;
const void *incoming_buffer;
uint32_t incoming_buffer_length;
uint8_t partial_block_buffer[SHA1_BLOCK_SIZE * 2];
diff --git a/arch/x86/crypto/sha256-mb/sha256_mb.c b/arch/x86/crypto/sha256-mb/sha256_mb.c
index 6f97fb3..7926a22 100644
--- a/arch/x86/crypto/sha256-mb/sha256_mb.c
+++ b/arch/x86/crypto/sha256-mb/sha256_mb.c
@@ -115,7 +115,7 @@ inline void sha256_init_digest(uint32_t *digest)
}
inline uint32_t sha256_pad(uint8_t padblock[SHA256_BLOCK_SIZE * 2],
- uint32_t total_len)
+ uint64_t total_len)
{
uint32_t i = total_len & (SHA256_BLOCK_SIZE - 1);
diff --git a/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h b/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h
index edd252b..aabb303 100644
--- a/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h
+++ b/arch/x86/crypto/sha256-mb/sha256_mb_ctx.h
@@ -125,7 +125,7 @@ struct sha256_hash_ctx {
/* error flag */
int error;
- uint32_t total_length;
+ uint64_t total_length;
const void *incoming_buffer;
uint32_t incoming_buffer_length;
uint8_t partial_block_buffer[SHA256_BLOCK_SIZE * 2];
diff --git a/arch/x86/crypto/sha512-mb/sha512_mb.c b/arch/x86/crypto/sha512-mb/sha512_mb.c
index d210174..9c1bb6d 100644
--- a/arch/x86/crypto/sha512-mb/sha512_mb.c
+++ b/arch/x86/crypto/sha512-mb/sha512_mb.c
@@ -117,7 +117,7 @@ inline void sha512_init_digest(uint64_t *digest)
}
inline uint32_t sha512_pad(uint8_t padblock[SHA512_BLOCK_SIZE * 2],
- uint32_t total_len)
+ uint64_t total_len)
{
uint32_t i = total_len & (SHA512_BLOCK_SIZE - 1);
diff --git a/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h b/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
index 9d4b2c8..e4653f5 100644
--- a/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
+++ b/arch/x86/crypto/sha512-mb/sha512_mb_ctx.h
@@ -119,7 +119,7 @@ struct sha512_hash_ctx {
/* error flag */
int error;
- uint32_t total_length;
+ uint64_t total_length;
const void *incoming_buffer;
uint32_t incoming_buffer_length;
uint8_t partial_block_buffer[SHA512_BLOCK_SIZE * 2];
--
2.5.5
^ permalink raw reply related
* Re: [PATCH] netfilter: Update ip_route_me_harder to consider L3 domain
From: David Ahern @ 2016-11-14 23:04 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: kaber, kadlec, netfilter-devel
In-Reply-To: <20161114225920.GA9221@salvia>
On 11/14/16 3:59 PM, Pablo Neira Ayuso wrote:
> Does ip6_route_me_harder need an update too?
I have not hit a use case yet. Rather than blindly going through and adding l3mdev hooks I would like to tie the changes to known uses cases.
^ permalink raw reply
* Re: [PATCH 1/2] Btrfs: fix file extent corruption
From: Liu Bo @ 2016-11-14 23:11 UTC (permalink / raw)
To: Josef Bacik; +Cc: linux-btrfs, kernel-team
In-Reply-To: <1479150382-19273-1-git-send-email-jbacik@fb.com>
On Mon, Nov 14, 2016 at 02:06:21PM -0500, Josef Bacik wrote:
> In order to do hole punching we have a block reserve to hold the reservation we
> need to drop the extents in our range. Since we could end up dropping a lot of
> extents we set rsv->failfast so we can just loop around again and drop the
> remaining of the range. Unfortunately we unconditionally fill the hole extents
> in and start from the last extent we encountered, which we may or may not have
> dropped. So this can result in overlapping file extent entries, which can be
> tripped over in a variety of ways, either by hitting BUG_ON(!ret) in
> fill_holes() after the search, or in btrfs_set_item_key_safe() in
> btrfs_drop_extent() at a later time by an unrelated task. Fix this by only
> setting drop_end to the last extent we did actually drop. This way our holes
> are filled in properly for the range that we did drop, and the rest of the range
> that remains to be dropped is actually dropped. Thanks,
Can you pleaes share the reproducer?
Thanks,
-liubo
>
> Signed-off-by: Josef Bacik <jbacik@fb.com>
> ---
> fs/btrfs/file.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
> index cbefdc8..1c15a98 100644
> --- a/fs/btrfs/file.c
> +++ b/fs/btrfs/file.c
> @@ -706,6 +706,7 @@ int __btrfs_drop_extents(struct btrfs_trans_handle *trans,
> u64 num_bytes = 0;
> u64 extent_offset = 0;
> u64 extent_end = 0;
> + u64 last_end = 0;
> int del_nr = 0;
> int del_slot = 0;
> int extent_type;
> @@ -797,8 +798,10 @@ next_slot:
> * extent item in the call to setup_items_for_insert() later
> * in this function.
> */
> - if (extent_end == key.offset && extent_end >= search_start)
> + if (extent_end == key.offset && extent_end >= search_start) {
> + last_end = extent_end;
> goto delete_extent_item;
> + }
>
> if (extent_end <= search_start) {
> path->slots[0]++;
> @@ -861,6 +864,12 @@ next_slot:
> key.offset = start;
> }
> /*
> + * From here on out we will have actually dropped something, so
> + * last_end can be updated.
> + */
> + last_end = extent_end;
> +
> + /*
> * | ---- range to drop ----- |
> * | -------- extent -------- |
> */
> @@ -1010,7 +1019,7 @@ delete_extent_item:
> if (!replace_extent || !(*key_inserted))
> btrfs_release_path(path);
> if (drop_end)
> - *drop_end = found ? min(end, extent_end) : end;
> + *drop_end = found ? min(end, last_end) : end;
> return ret;
> }
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] EDAC, xgene: fix spelling mistake in error messages
From: Colin King @ 2016-11-14 23:11 UTC (permalink / raw)
To: Loc Ho, Borislav Petkov, Mauro Carvalho Chehab, linux-edac; +Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake "Mutilple" to "Multiple"
in error messages
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/edac/xgene_edac.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/xgene_edac.c
index bf19b6e..5569391 100644
--- a/drivers/edac/xgene_edac.c
+++ b/drivers/edac/xgene_edac.c
@@ -1602,16 +1602,16 @@ static void xgene_edac_pa_report(struct edac_device_ctl_info *edac_dev)
dev_err(edac_dev->dev, "IOB PA read data RAM error\n");
if (reg & IOBPA_M_RDATA_CORRUPT_MASK)
dev_err(edac_dev->dev,
- "Mutilple IOB PA read data RAM error\n");
+ "Multiple IOB PA read data RAM error\n");
if (reg & IOBPA_WDATA_CORRUPT_MASK)
dev_err(edac_dev->dev, "IOB PA write data RAM error\n");
if (reg & IOBPA_M_WDATA_CORRUPT_MASK)
dev_err(edac_dev->dev,
- "Mutilple IOB PA write data RAM error\n");
+ "Multiple IOB PA write data RAM error\n");
if (reg & IOBPA_TRANS_CORRUPT_MASK)
dev_err(edac_dev->dev, "IOB PA transaction error\n");
if (reg & IOBPA_M_TRANS_CORRUPT_MASK)
- dev_err(edac_dev->dev, "Mutilple IOB PA transaction error\n");
+ dev_err(edac_dev->dev, "Multiple IOB PA transaction error\n");
if (reg & IOBPA_REQIDRAM_CORRUPT_MASK)
dev_err(edac_dev->dev, "IOB PA transaction ID RAM error\n");
if (reg & IOBPA_M_REQIDRAM_CORRUPT_MASK)
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] ACPI: allow compilation with bare metal compilers
From: Al Stone @ 2016-11-14 23:10 UTC (permalink / raw)
To: linux-acpi, devel, linux-kernel
Cc: Rafael J . Wysocki, Len Brown, Robert Moore, Lv Zheng,
Will Deacon
In-Reply-To: <1479164926-1733-1-git-send-email-ahs3@redhat.com>
My bad.
Adding Will Deacon who originally reported the error.
On 11/14/2016 04:08 PM, Al Stone wrote:
> The ACPICA subsystem of the ACPI driver sets up a compilation environment
> for itself, adding in multiple typedefs unique to ACPICA that depend on
> where ACPICA will be used.
>
> The vast majority of such environments (Linux, QNX, ...) have an environment
> defined by the acenv.h header file. When using a Linaro compiler [1]
> specifically built to be used in an embedded environment with perhaps a
> kernel and an init process as the only things running, there is no
> environment defined for ACPICA so the typedefs it needs are not set up,
> causing compilation to fail badly unless ACPI is completely disabled.
> Since ACPI is enabled in the default config for the kernel, the compilation
> failure is fairly obvious.
>
> This may not be the optimal solution, but add in to the ACPI header file
> include/acpi/platform/acenv.h a default so that if GCC is being used, and
> all else fails, assume that we are going to be in a Linux-like environment
> and re-use the environment definition for Linux. This allows us to build
> a kernel using this compiler [1] with or without ACPI.
>
> [1] https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-elff/gcc-linaro-6.1.1-2016-08-x86_64_aarch64-elf.tar.xz
>
> Signed-off-by: Al Stone <ahs3@redhat.com>
> Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: Len Brown <lenb@kernel.org>
> Cc: Robert Moore <robert.moore@intel.com>
> Cc: Lv Zheng <lv.zheng@intel.com>
> ---
> include/acpi/platform/acenv.h | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
> index 34cce72..cdd1cd6 100644
> --- a/include/acpi/platform/acenv.h
> +++ b/include/acpi/platform/acenv.h
> @@ -234,6 +234,21 @@
> #elif defined(_AED_EFI) || defined(_GNU_EFI) || defined(_EDK2_EFI)
> #include "acefi.h"
>
> +/*
> + * Up to this point, we've been looking for specific environments. In
> + * some cases, there is no environment, and we're just working on bare
> + * metal. However, since we're compiling the Linux kernel, let's just
> + * pretend we're in a Linux environment.
> + */
> +#elif defined(__GNUC__) && !defined(__INTEL_COMPILER)
> +#if !defined(_LINUX)
> +#define _LINUX
> +#endif
> +#if !defined(__linux__)
> +#define __linux__
> +#endif
> +#include <acpi/platform/aclinux.h>
> +
> #else
>
> /* Unknown environment */
>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@redhat.com
-----------------------------------
^ permalink raw reply
* Re: [Devel] [PATCH] ACPI: allow compilation with bare metal compilers
From: Al Stone @ 2016-11-14 23:10 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]
My bad.
Adding Will Deacon who originally reported the error.
On 11/14/2016 04:08 PM, Al Stone wrote:
> The ACPICA subsystem of the ACPI driver sets up a compilation environment
> for itself, adding in multiple typedefs unique to ACPICA that depend on
> where ACPICA will be used.
>
> The vast majority of such environments (Linux, QNX, ...) have an environment
> defined by the acenv.h header file. When using a Linaro compiler [1]
> specifically built to be used in an embedded environment with perhaps a
> kernel and an init process as the only things running, there is no
> environment defined for ACPICA so the typedefs it needs are not set up,
> causing compilation to fail badly unless ACPI is completely disabled.
> Since ACPI is enabled in the default config for the kernel, the compilation
> failure is fairly obvious.
>
> This may not be the optimal solution, but add in to the ACPI header file
> include/acpi/platform/acenv.h a default so that if GCC is being used, and
> all else fails, assume that we are going to be in a Linux-like environment
> and re-use the environment definition for Linux. This allows us to build
> a kernel using this compiler [1] with or without ACPI.
>
> [1] https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-elff/gcc-linaro-6.1.1-2016-08-x86_64_aarch64-elf.tar.xz
>
> Signed-off-by: Al Stone <ahs3(a)redhat.com>
> Cc: Rafael J. Wysocki <rjw(a)rjwysocki.net>
> Cc: Len Brown <lenb(a)kernel.org>
> Cc: Robert Moore <robert.moore(a)intel.com>
> Cc: Lv Zheng <lv.zheng(a)intel.com>
> ---
> include/acpi/platform/acenv.h | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
> index 34cce72..cdd1cd6 100644
> --- a/include/acpi/platform/acenv.h
> +++ b/include/acpi/platform/acenv.h
> @@ -234,6 +234,21 @@
> #elif defined(_AED_EFI) || defined(_GNU_EFI) || defined(_EDK2_EFI)
> #include "acefi.h"
>
> +/*
> + * Up to this point, we've been looking for specific environments. In
> + * some cases, there is no environment, and we're just working on bare
> + * metal. However, since we're compiling the Linux kernel, let's just
> + * pretend we're in a Linux environment.
> + */
> +#elif defined(__GNUC__) && !defined(__INTEL_COMPILER)
> +#if !defined(_LINUX)
> +#define _LINUX
> +#endif
> +#if !defined(__linux__)
> +#define __linux__
> +#endif
> +#include <acpi/platform/aclinux.h>
> +
> #else
>
> /* Unknown environment */
>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
^ permalink raw reply
* Re: [PATCH v2 01/10] dt-bindings: rockchip-dw-mshc: add RK1108 dw-mshc description
From: Heiko Stuebner @ 2016-11-14 23:09 UTC (permalink / raw)
To: Andy Yan
Cc: shawn.lin, robh+dt, linux-rockchip, devicetree, ulf.hansson,
linux-mmc, linux-kernel, mark.rutland
In-Reply-To: <1479124865-24109-1-git-send-email-andy.yan@rock-chips.com>
Am Montag, 14. November 2016, 20:01:05 CET schrieb Andy Yan:
> From: Shawn Lin <shawn.lin@rock-chips.com>
>
> Add "rockchip,rk1108-dw-mshc", "rockchip,rk3288-dw-mshc" for
> dwmmc on rk1108 platform.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
applied to my dts32 branch with Rob's Ack taken from the unchanged v1.
Heiko
^ permalink raw reply
* Re: Long delays creating a netns after deleting one (possibly RCU related)
From: Eric Dumazet @ 2016-11-14 23:09 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Paul E. McKenney, Cong Wang, Rolf Neugebauer, LKML,
Linux Kernel Network Developers, Justin Cormack, Ian Campbell,
Eric Dumazet
In-Reply-To: <1479163571.8455.83.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 2016-11-14 at 14:46 -0800, Eric Dumazet wrote:
> On Mon, 2016-11-14 at 16:12 -0600, Eric W. Biederman wrote:
>
> > synchronize_rcu_expidited is not enough if you have multiple network
> > devices in play.
> >
> > Looking at the code it comes down to this commit, and it appears there
> > is a promise add rcu grace period combining by Eric Dumazet.
> >
> > Eric since people are hitting noticable stalls because of the rcu grace
> > period taking a long time do you think you could look at this code path
> > a bit more?
> >
> > commit 93d05d4a320cb16712bb3d57a9658f395d8cecb9
> > Author: Eric Dumazet <edumazet@google.com>
> > Date: Wed Nov 18 06:31:03 2015 -0800
>
> Absolutely, I will take a loop asap.
The worst offender should be fixed by the following patch.
busy poll needs to poll the physical device, not a virtual one...
diff --git a/include/net/gro_cells.h b/include/net/gro_cells.h
index d15214d673b2e8e08fd6437b572278fb1359f10d..2a1abbf8da74368cd01adc40cef6c0644e059ef2 100644
--- a/include/net/gro_cells.h
+++ b/include/net/gro_cells.h
@@ -68,6 +68,9 @@ static inline int gro_cells_init(struct gro_cells *gcells, struct net_device *de
struct gro_cell *cell = per_cpu_ptr(gcells->cells, i);
__skb_queue_head_init(&cell->napi_skbs);
+
+ set_bit(NAPI_STATE_NO_BUSY_POLL, &cell->napi.state);
+
netif_napi_add(dev, &cell->napi, gro_cell_poll, 64);
napi_enable(&cell->napi);
}
^ permalink raw reply related
* [PATCH] ACPI: allow compilation with bare metal compilers
From: Al Stone @ 2016-11-14 23:08 UTC (permalink / raw)
To: linux-acpi, devel, linux-kernel
Cc: Al Stone, Rafael J . Wysocki, Len Brown, Robert Moore, Lv Zheng
The ACPICA subsystem of the ACPI driver sets up a compilation environment
for itself, adding in multiple typedefs unique to ACPICA that depend on
where ACPICA will be used.
The vast majority of such environments (Linux, QNX, ...) have an environment
defined by the acenv.h header file. When using a Linaro compiler [1]
specifically built to be used in an embedded environment with perhaps a
kernel and an init process as the only things running, there is no
environment defined for ACPICA so the typedefs it needs are not set up,
causing compilation to fail badly unless ACPI is completely disabled.
Since ACPI is enabled in the default config for the kernel, the compilation
failure is fairly obvious.
This may not be the optimal solution, but add in to the ACPI header file
include/acpi/platform/acenv.h a default so that if GCC is being used, and
all else fails, assume that we are going to be in a Linux-like environment
and re-use the environment definition for Linux. This allows us to build
a kernel using this compiler [1] with or without ACPI.
[1] https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-elff/gcc-linaro-6.1.1-2016-08-x86_64_aarch64-elf.tar.xz
Signed-off-by: Al Stone <ahs3@redhat.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Lv Zheng <lv.zheng@intel.com>
---
include/acpi/platform/acenv.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
index 34cce72..cdd1cd6 100644
--- a/include/acpi/platform/acenv.h
+++ b/include/acpi/platform/acenv.h
@@ -234,6 +234,21 @@
#elif defined(_AED_EFI) || defined(_GNU_EFI) || defined(_EDK2_EFI)
#include "acefi.h"
+/*
+ * Up to this point, we've been looking for specific environments. In
+ * some cases, there is no environment, and we're just working on bare
+ * metal. However, since we're compiling the Linux kernel, let's just
+ * pretend we're in a Linux environment.
+ */
+#elif defined(__GNUC__) && !defined(__INTEL_COMPILER)
+#if !defined(_LINUX)
+#define _LINUX
+#endif
+#if !defined(__linux__)
+#define __linux__
+#endif
+#include <acpi/platform/aclinux.h>
+
#else
/* Unknown environment */
--
2.10.2
^ permalink raw reply related
* [Devel] [PATCH] ACPI: allow compilation with bare metal compilers
From: Al Stone @ 2016-11-14 23:08 UTC (permalink / raw)
To: devel
[-- Attachment #1: Type: text/plain, Size: 2338 bytes --]
The ACPICA subsystem of the ACPI driver sets up a compilation environment
for itself, adding in multiple typedefs unique to ACPICA that depend on
where ACPICA will be used.
The vast majority of such environments (Linux, QNX, ...) have an environment
defined by the acenv.h header file. When using a Linaro compiler [1]
specifically built to be used in an embedded environment with perhaps a
kernel and an init process as the only things running, there is no
environment defined for ACPICA so the typedefs it needs are not set up,
causing compilation to fail badly unless ACPI is completely disabled.
Since ACPI is enabled in the default config for the kernel, the compilation
failure is fairly obvious.
This may not be the optimal solution, but add in to the ACPI header file
include/acpi/platform/acenv.h a default so that if GCC is being used, and
all else fails, assume that we are going to be in a Linux-like environment
and re-use the environment definition for Linux. This allows us to build
a kernel using this compiler [1] with or without ACPI.
[1] https://releases.linaro.org/components/toolchain/binaries/latest/aarch64-elff/gcc-linaro-6.1.1-2016-08-x86_64_aarch64-elf.tar.xz
Signed-off-by: Al Stone <ahs3(a)redhat.com>
Cc: Rafael J. Wysocki <rjw(a)rjwysocki.net>
Cc: Len Brown <lenb(a)kernel.org>
Cc: Robert Moore <robert.moore(a)intel.com>
Cc: Lv Zheng <lv.zheng(a)intel.com>
---
include/acpi/platform/acenv.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h
index 34cce72..cdd1cd6 100644
--- a/include/acpi/platform/acenv.h
+++ b/include/acpi/platform/acenv.h
@@ -234,6 +234,21 @@
#elif defined(_AED_EFI) || defined(_GNU_EFI) || defined(_EDK2_EFI)
#include "acefi.h"
+/*
+ * Up to this point, we've been looking for specific environments. In
+ * some cases, there is no environment, and we're just working on bare
+ * metal. However, since we're compiling the Linux kernel, let's just
+ * pretend we're in a Linux environment.
+ */
+#elif defined(__GNUC__) && !defined(__INTEL_COMPILER)
+#if !defined(_LINUX)
+#define _LINUX
+#endif
+#if !defined(__linux__)
+#define __linux__
+#endif
+#include <acpi/platform/aclinux.h>
+
#else
/* Unknown environment */
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] rmc: Fix compiling issue with musl
From: Jianxun Zhang @ 2016-11-14 23:08 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-core
In-Reply-To: <41ae9aed-3c93-09dc-bdde-5553fe5d5fbc@gmail.com>
> On Nov 14, 2016, at 2:50 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>
>
> On 11/14/16 2:10 PM, Jianxun Zhang wrote:
>> | src/rmcl/rmcl.c: In function 'query_policy_from_db':
>> | src/rmcl/rmcl.c:254:25: error: unknown type name 'ssize_t'
>> | ssize_t cmd_name_len = strlen((char *)&rmc_db[policy_idx]) + 1;
>> | ^~~~~~~~
>>
>> The musl C lib provides ssize_t but we need to enable it
>> with a macro.
>>
>> Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
>> ---
>> Before maintainer(s) push "merge" button, please read this short summary.
>> I feel there could be a better syntax to do it. And We could need to get
>> an ack from Hernandez, Alejandro who reported this issue and seems still
>> have (other) compiling errors even with this patch.
>>
>> I submit this patch based on my thoughts and test out of tiny config.
>>
>> Tests:
>> () Specify TCLIBC = "musl" in local.conf in my build dir.
>> () Build quark
>> () I can see this issue happens without the fix
>> () With this patch and do clean builds for quark and corei7-64,
>> Compiling passes. Boot test passed on RMC targets quark and Broxton-m.
>>
>> Thanks
>>
>>
>> common/recipes-bsp/rmc/rmc.bb | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
>> index aeaf12e..61a1bdb 100644
>> --- a/common/recipes-bsp/rmc/rmc.bb
>> +++ b/common/recipes-bsp/rmc/rmc.bb
>> @@ -24,6 +24,8 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
>>
>> EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"'
>>
>> +EXTRA_OEMAKE_append_libc-musl = '" -D__NEED_ssize_t"'
>
> this is not right way to handle it. you should be doing something like
> #include <sys/types.h> in your source file
Khem,
Thanks lot for your review even when I wrongly submit it here! I tried it first but didn’t succeed for some reason with the suggested change.
Let me try it again...
>
>
>> +
>> # from gnu-efi, we should align arch-mapping with it.
>> def rmc_efi_arch(d):
>> import re
^ permalink raw reply
* RE: [PATCH 3/3] PCI: hv: delete the device earlier from hbus->children for hot-remove
From: KY Srinivasan @ 2016-11-14 23:08 UTC (permalink / raw)
To: Dexuan Cui, Bjorn Helgaas, linux-pci@vger.kernel.org,
devel@linuxdriverproject.org
Cc: gregkh@linuxfoundation.org, Haiyang Zhang, Stephen Hemminger,
Jake Oshins, Hadden Hoppert, Vitaly Kuznetsov,
jasowang@redhat.com, apw@canonical.com, olaf@aepfle.de,
linux-kernel@vger.kernel.org
In-Reply-To: <MWHPR03MB2669255256A616C62606216EBFB80@MWHPR03MB2669.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Dexuan Cui
> Sent: Wednesday, November 9, 2016 11:20 PM
> To: Bjorn Helgaas <bhelgaas@google.com>; linux-pci@vger.kernel.org;
> devel@linuxdriverproject.org
> Cc: gregkh@linuxfoundation.org; KY Srinivasan <kys@microsoft.com>;
> Haiyang Zhang <haiyangz@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; Jake Oshins <jakeo@microsoft.com>; Hadden
> Hoppert <haddenh@microsoft.com>; Vitaly Kuznetsov
> <vkuznets@redhat.com>; jasowang@redhat.com; apw@canonical.com;
> olaf@aepfle.de; linux-kernel@vger.kernel.org
> Subject: [PATCH 3/3] PCI: hv: delete the device earlier from hbus->children
> for hot-remove
>
> After we send a PCI_EJECTION_COMPLETE message to the host, the host will
> immediately send us a PCI_BUS_RELATIONS message with
> relations->device_count == 0, so pci_devices_present_work(), running on
> another thread, can find the being-ejected device, mark
> the hpdev->reported_missing to true, and run list_move_tail()/list_del()
> for the device -- this races hv_eject_device_work() -> list_del().
>
> The patch moves the list_del() in hv_eject_device_work() to an earlier
> place, i.e. before we send PCI_EJECTION_COMPLETE, so later the
> pci_devices_present_work() can't see the device.
>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> CC: Jake Oshins <jakeo@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>
> CC: Haiyang Zhang <haiyangz@microsoft.com>
> CC: Vitaly Kuznetsov <vkuznets@redhat.com>
Thanks Dexuan.
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> drivers/pci/host/pci-hyperv.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 7590ad0..fe5179d 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1582,6 +1582,10 @@ static void hv_eject_device_work(struct
> work_struct *work)
> pci_dev_put(pdev);
> }
>
> + spin_lock_irqsave(&hpdev->hbus->device_list_lock, flags);
> + list_del(&hpdev->list_entry);
> + spin_unlock_irqrestore(&hpdev->hbus->device_list_lock, flags);
> +
> memset(&ctxt, 0, sizeof(ctxt));
> ejct_pkt = (struct pci_eject_response *)&ctxt.pkt.message;
> ejct_pkt->message_type.type = PCI_EJECTION_COMPLETE;
> @@ -1590,10 +1594,6 @@ static void hv_eject_device_work(struct
> work_struct *work)
> sizeof(*ejct_pkt), (unsigned long)&ctxt.pkt,
> VM_PKT_DATA_INBAND, 0);
>
> - spin_lock_irqsave(&hpdev->hbus->device_list_lock, flags);
> - list_del(&hpdev->list_entry);
> - spin_unlock_irqrestore(&hpdev->hbus->device_list_lock, flags);
> -
> put_pcichild(hpdev, hv_pcidev_ref_childlist);
> put_pcichild(hpdev, hv_pcidev_ref_pnp);
> put_hvpcibus(hpdev->hbus);
> --
> 2.7.4
^ permalink raw reply
* RE: [PATCH 3/3] PCI: hv: delete the device earlier from hbus->children for hot-remove
From: KY Srinivasan @ 2016-11-14 23:08 UTC (permalink / raw)
To: Dexuan Cui, Bjorn Helgaas, linux-pci@vger.kernel.org,
devel@linuxdriverproject.org
Cc: gregkh@linuxfoundation.org, Haiyang Zhang, Stephen Hemminger,
Jake Oshins, Hadden Hoppert, Vitaly Kuznetsov,
jasowang@redhat.com, apw@canonical.com, olaf@aepfle.de,
linux-kernel@vger.kernel.org
In-Reply-To: <MWHPR03MB2669255256A616C62606216EBFB80@MWHPR03MB2669.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Dexuan Cui
> Sent: Wednesday, November 9, 2016 11:20 PM
> To: Bjorn Helgaas <bhelgaas@google.com>; linux-pci@vger.kernel.org;
> devel@linuxdriverproject.org
> Cc: gregkh@linuxfoundation.org; KY Srinivasan <kys@microsoft.com>;
> Haiyang Zhang <haiyangz@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; Jake Oshins <jakeo@microsoft.com>; Hadden
> Hoppert <haddenh@microsoft.com>; Vitaly Kuznetsov
> <vkuznets@redhat.com>; jasowang@redhat.com; apw@canonical.com;
> olaf@aepfle.de; linux-kernel@vger.kernel.org
> Subject: [PATCH 3/3] PCI: hv: delete the device earlier from hbus->childr=
en
> for hot-remove
>=20
> After we send a PCI_EJECTION_COMPLETE message to the host, the host will
> immediately send us a PCI_BUS_RELATIONS message with
> relations->device_count =3D=3D 0, so pci_devices_present_work(), running =
on
> another thread, can find the being-ejected device, mark
> the hpdev->reported_missing to true, and run list_move_tail()/list_del()
> for the device -- this races hv_eject_device_work() -> list_del().
>=20
> The patch moves the list_del() in hv_eject_device_work() to an earlier
> place, i.e. before we send PCI_EJECTION_COMPLETE, so later the
> pci_devices_present_work() can't see the device.
>=20
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> CC: Jake Oshins <jakeo@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>
> CC: Haiyang Zhang <haiyangz@microsoft.com>
> CC: Vitaly Kuznetsov <vkuznets@redhat.com>
Thanks Dexuan.
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> drivers/pci/host/pci-hyperv.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>=20
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.=
c
> index 7590ad0..fe5179d 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -1582,6 +1582,10 @@ static void hv_eject_device_work(struct
> work_struct *work)
> pci_dev_put(pdev);
> }
>=20
> + spin_lock_irqsave(&hpdev->hbus->device_list_lock, flags);
> + list_del(&hpdev->list_entry);
> + spin_unlock_irqrestore(&hpdev->hbus->device_list_lock, flags);
> +
> memset(&ctxt, 0, sizeof(ctxt));
> ejct_pkt =3D (struct pci_eject_response *)&ctxt.pkt.message;
> ejct_pkt->message_type.type =3D PCI_EJECTION_COMPLETE;
> @@ -1590,10 +1594,6 @@ static void hv_eject_device_work(struct
> work_struct *work)
> sizeof(*ejct_pkt), (unsigned long)&ctxt.pkt,
> VM_PKT_DATA_INBAND, 0);
>=20
> - spin_lock_irqsave(&hpdev->hbus->device_list_lock, flags);
> - list_del(&hpdev->list_entry);
> - spin_unlock_irqrestore(&hpdev->hbus->device_list_lock, flags);
> -
> put_pcichild(hpdev, hv_pcidev_ref_childlist);
> put_pcichild(hpdev, hv_pcidev_ref_pnp);
> put_hvpcibus(hpdev->hbus);
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH V4 1/2] PCI: hisi: Add ECAM support for devices that are not RC
From: Bjorn Helgaas @ 2016-11-14 23:07 UTC (permalink / raw)
To: Dongdong Liu
Cc: arnd, rafael, Lorenzo.Pieralisi, tn, wangzhou1, pratyush.anand,
linux-pci, linux-acpi, linux-kernel, jcm, gabriele.paoloni,
charles.chenxin, hanjun.guo, linuxarm, Jingoo Han
In-Reply-To: <1478682897-119874-2-git-send-email-liudongdong3@huawei.com>
[+cc Jingoo]
On Wed, Nov 09, 2016 at 05:14:56PM +0800, Dongdong Liu wrote:
> This patch modifies the current Hip05/Hip06 PCIe host
> controller driver to add support for 'almost ECAM'
> compliant platforms. Some controllers are ECAM compliant
> for all the devices of the hierarchy except the root
> complex; this patch adds support for such controllers.
>
> This is needed in preparation for the ACPI based driver
> to allow both DT and ACPI drivers to use the same BIOS
> (that configure the Designware iATUs).
> This commit doesn't break backward compatibility with
> previous non-ECAM platforms.
>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
> ---
> .../devicetree/bindings/pci/hisilicon-pcie.txt | 15 +++++---
> drivers/pci/host/Kconfig | 4 +-
> drivers/pci/host/pcie-designware.c | 4 +-
> drivers/pci/host/pcie-designware.h | 2 +
> drivers/pci/host/pcie-hisi.c | 45 ++++++++++++++++++++++
> 5 files changed, 60 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> index 59c2f47..87a597a 100644
> --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> @@ -9,10 +9,13 @@ Additional properties are described here:
>
> Required properties
> - compatible: Should contain "hisilicon,hip05-pcie" or "hisilicon,hip06-pcie".
> -- reg: Should contain rc_dbi, config registers location and length.
> -- reg-names: Must include the following entries:
> +- reg: Should contain rc_dbi and either config or ecam-cfg registers
> + location and length (it depends on the platform BIOS).
> +- reg-names: Must include
> "rc_dbi": controller configuration registers;
> - "config": PCIe configuration space registers.
> + and one of the following entries:
> + "config": PCIe configuration space registers for non-ECAM platforms.
> + "ecam-cfg": PCIe configuration space registers for ECAM platforms
> - msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
> - port-id: Should be 0, 1, 2 or 3.
>
> @@ -23,8 +26,10 @@ Optional properties:
> Hip05 Example (note that Hip06 is the same except compatible):
> pcie@0xb0080000 {
> compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
> - reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>;
> - reg-names = "rc_dbi", "config";
> + reg = <0 0xb0080000 0 0x10000>,
> + <0x220 0x00000000 0 0x2000>
> + /* or <0x220 0x00100000 0 0x0f00000> for ecam-cfg*/;
Add space before closing "*/".
> + reg-names = "rc_dbi", "config" /* or "ecam-cfg" */;
> bus-range = <0 15>;
> msi-parent = <&its_pcie>;
> #address-cells = <3>;
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index d7e7c0a..ae98644 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -219,13 +219,13 @@ config PCIE_ALTERA_MSI
>
> config PCI_HISI
> depends on OF && ARM64
> - bool "HiSilicon Hip05 and Hip06 SoCs PCIe controllers"
> + bool "HiSilicon Hip05 and Hip06 and Hip07 SoCs PCIe controllers"
> depends on PCI_MSI_IRQ_DOMAIN
> select PCIEPORTBUS
> select PCIE_DW
> help
> Say Y here if you want PCIe controller support on HiSilicon
> - Hip05 and Hip06 SoCs
> + Hip05 and Hip06 and Hip07 SoCs
>
> config PCIE_QCOM
> bool "Qualcomm PCIe controller"
> diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c
> index 035f50c..da11644 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -101,8 +101,6 @@
> #define PCIE_PHY_DEBUG_R1_LINK_UP (0x1 << 4)
> #define PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING (0x1 << 29)
>
> -static struct pci_ops dw_pcie_ops;
> -
> int dw_pcie_cfg_read(void __iomem *addr, int size, u32 *val)
> {
> if ((uintptr_t)addr & (size - 1)) {
> @@ -800,7 +798,7 @@ static int dw_pcie_wr_conf(struct pci_bus *bus, u32 devfn,
> return dw_pcie_wr_other_conf(pp, bus, devfn, where, size, val);
> }
>
> -static struct pci_ops dw_pcie_ops = {
> +struct pci_ops dw_pcie_ops = {
> .read = dw_pcie_rd_conf,
> .write = dw_pcie_wr_conf,
> };
> diff --git a/drivers/pci/host/pcie-designware.h b/drivers/pci/host/pcie-designware.h
> index a567ea2..30d228a 100644
> --- a/drivers/pci/host/pcie-designware.h
> +++ b/drivers/pci/host/pcie-designware.h
> @@ -83,4 +83,6 @@ struct pcie_host_ops {
> void dw_pcie_setup_rc(struct pcie_port *pp);
> int dw_pcie_host_init(struct pcie_port *pp);
>
> +extern struct pci_ops dw_pcie_ops;
> +
> #endif /* _PCIE_DESIGNWARE_H */
> diff --git a/drivers/pci/host/pcie-hisi.c b/drivers/pci/host/pcie-hisi.c
> index 56154c2..555c964 100644
> --- a/drivers/pci/host/pcie-hisi.c
> +++ b/drivers/pci/host/pcie-hisi.c
> @@ -43,6 +43,34 @@ struct hisi_pcie {
> struct pcie_soc_ops *soc_ops;
> };
>
> +static inline int hisi_rd_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
> + unsigned int devfn, int where, int size,
> + u32 *value)
> +{
> + return pci_generic_config_read(bus, devfn, where, size, value);
> +}
> +
> +static inline int hisi_wr_ecam_conf(struct pcie_port *pp, struct pci_bus *bus,
> + unsigned int devfn, int where, int size,
> + u32 value)
> +{
> + return pci_generic_config_write(bus, devfn, where, size, value);
> +}
> +
> +static void __iomem *hisi_pci_map_cfg_bus_cam(struct pci_bus *bus,
> + unsigned int devfn,
> + int where)
> +{
> + void __iomem *addr;
> + struct pcie_port *pp = bus->sysdata;
> +
> + addr = pp->va_cfg1_base - (pp->busn->start << 20) +
> + ((bus->number << 20) | (devfn << 12)) +
> + where;
> +
> + return addr;
> +}
> +
> /* HipXX PCIe host only supports 32-bit config access */
> static int hisi_pcie_cfg_read(struct pcie_port *pp, int where, int size,
> u32 *val)
> @@ -190,6 +218,23 @@ static int hisi_pcie_probe(struct platform_device *pdev)
> return PTR_ERR(pp->dbi_base);
> }
>
> + reg = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ecam-cfg");
> + if (reg) {
> + /* ECAM driver version */
> + hisi_pcie->pp.va_cfg0_base =
> + devm_ioremap_resource(&pdev->dev, reg);
> + if (IS_ERR(hisi_pcie->pp.va_cfg0_base)) {
> + dev_err(pp->dev, "cannot get ecam-cfg\n");
> + return PTR_ERR(hisi_pcie->pp.va_cfg0_base);
> + }
> + hisi_pcie->pp.va_cfg1_base = hisi_pcie->pp.va_cfg0_base;
> +
> + dw_pcie_ops.map_bus = hisi_pci_map_cfg_bus_cam;
I don't really like this part. We're scribbling on dw_pcie_ops, which this
driver does not own. That breaks the encapsulation and means that using
two different DW-based drivers in the same system (admittedly unlikely)
would fail mysteriously.
I wonder if this could be solved by allowing the DW-based drivers to supply
their own pci_ops. If we did that, it might let us get rid of the
rd_own_conf, wr_own_conf, rd_other_conf, and wr_other_conf function
pointers. I haven't worked through it, but it's possible the result would
be easier to read.
It's also possible it would be a lot of code churn for no real gain, and
breaking the encapsulation makes the most sense. What do you think?
> +
> + hisi_pcie_host_ops.rd_other_conf = hisi_rd_ecam_conf;
> + hisi_pcie_host_ops.wr_other_conf = hisi_wr_ecam_conf;
> + }
> +
> ret = hisi_add_pcie_port(hisi_pcie, pdev);
> if (ret)
> return ret;
> --
> 1.9.1
>
^ permalink raw reply
* Re: [RFC PATCH 2/2] ptr_ring_ll: pop/push multiple objects at once
From: Michael S. Tsirkin @ 2016-11-14 23:06 UTC (permalink / raw)
To: John Fastabend; +Cc: jasowang, netdev, linux-kernel
In-Reply-To: <20161111044432.1547.65342.stgit@john-Precision-Tower-5810>
On Thu, Nov 10, 2016 at 08:44:32PM -0800, John Fastabend wrote:
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
This will naturally reduce the cache line bounce
costs, but so will a _many API for ptr-ring,
doing lock-add many-unlock.
the number of atomics also scales better with the lock:
one per push instead of one per queue.
Also, when can qdisc use a _many operation?
> ---
> include/linux/ptr_ring_ll.h | 22 ++++++++++++++++------
> include/linux/skb_array.h | 11 +++++++++--
> net/sched/sch_generic.c | 2 +-
> 3 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/ptr_ring_ll.h b/include/linux/ptr_ring_ll.h
> index bcb11f3..5dc25f7 100644
> --- a/include/linux/ptr_ring_ll.h
> +++ b/include/linux/ptr_ring_ll.h
> @@ -45,9 +45,10 @@ struct ptr_ring_ll {
> /* Note: callers invoking this in a loop must use a compiler barrier,
> * for example cpu_relax(). Callers must hold producer_lock.
> */
> -static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
> +static inline int __ptr_ring_ll_produce_many(struct ptr_ring_ll *r,
> + void **ptr, int num)
> {
> - u32 ret, head, tail, next, slots, mask;
> + u32 ret, head, tail, next, slots, mask, i;
>
> do {
> head = READ_ONCE(r->prod_head);
> @@ -55,21 +56,30 @@ static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void *ptr)
> tail = READ_ONCE(r->cons_tail);
>
> slots = mask + tail - head;
> - if (slots < 1)
> + if (slots < num)
> + num = slots;
> +
> + if (unlikely(!num))
> return -ENOMEM;
>
> - next = head + 1;
> + next = head + num;
> ret = cmpxchg(&r->prod_head, head, next);
> } while (ret != head);
>
> - r->queue[head & mask] = ptr;
> + for (i = 0; i < num; i++)
> + r->queue[(head + i) & mask] = ptr[i];
> smp_wmb();
>
> while (r->prod_tail != head)
> cpu_relax();
>
> r->prod_tail = next;
> - return 0;
> + return num;
> +}
> +
> +static inline int __ptr_ring_ll_produce(struct ptr_ring_ll *r, void **ptr)
> +{
> + return __ptr_ring_ll_produce_many(r, ptr, 1);
> }
>
> static inline void *__ptr_ring_ll_consume(struct ptr_ring_ll *r)
> diff --git a/include/linux/skb_array.h b/include/linux/skb_array.h
> index 9b43dfd..de3c700 100644
> --- a/include/linux/skb_array.h
> +++ b/include/linux/skb_array.h
> @@ -48,9 +48,16 @@ static inline bool skb_array_full(struct skb_array *a)
> return ptr_ring_full(&a->ring);
> }
>
> -static inline int skb_array_ll_produce(struct skb_array_ll *a, struct sk_buff *skb)
> +static inline int skb_array_ll_produce_many(struct skb_array_ll *a,
> + struct sk_buff **skb, int num)
> {
> - return __ptr_ring_ll_produce(&a->ring, skb);
> + return __ptr_ring_ll_produce_many(&a->ring, (void **)skb, num);
> +}
> +
> +static inline int skb_array_ll_produce(struct skb_array_ll *a,
> + struct sk_buff **skb)
> +{
> + return __ptr_ring_ll_produce(&a->ring, (void **)skb);
> }
>
> static inline int skb_array_produce(struct skb_array *a, struct sk_buff *skb)
> diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
> index 4648ec8..58f2011 100644
> --- a/net/sched/sch_generic.c
> +++ b/net/sched/sch_generic.c
> @@ -571,7 +571,7 @@ static int pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc *qdisc,
> struct skb_array_ll *q = band2list(priv, band);
> int err;
>
> - err = skb_array_ll_produce(q, skb);
> + err = skb_array_ll_produce(q, &skb);
>
> if (unlikely(err)) {
> net_warn_ratelimited("drop a packet from fast enqueue\n");
I don't see a pop many operation here.
--
MST
^ permalink raw reply
* RE: [PATCH 2/3] PCI: hv: fix hv_pci_remove() for hot-remove
From: KY Srinivasan @ 2016-11-14 23:06 UTC (permalink / raw)
To: Dexuan Cui, Bjorn Helgaas, linux-pci@vger.kernel.org,
devel@linuxdriverproject.org
Cc: gregkh@linuxfoundation.org, Haiyang Zhang, Stephen Hemminger,
Jake Oshins, Hadden Hoppert, Vitaly Kuznetsov,
jasowang@redhat.com, apw@canonical.com, olaf@aepfle.de,
linux-kernel@vger.kernel.org
In-Reply-To: <MWHPR03MB2669BF0EB52B9289747F04E1BFB80@MWHPR03MB2669.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Dexuan Cui
> Sent: Wednesday, November 9, 2016 11:19 PM
> To: Bjorn Helgaas <bhelgaas@google.com>; linux-pci@vger.kernel.org;
> devel@linuxdriverproject.org
> Cc: gregkh@linuxfoundation.org; KY Srinivasan <kys@microsoft.com>;
> Haiyang Zhang <haiyangz@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; Jake Oshins <jakeo@microsoft.com>; Hadden
> Hoppert <haddenh@microsoft.com>; Vitaly Kuznetsov
> <vkuznets@redhat.com>; jasowang@redhat.com; apw@canonical.com;
> olaf@aepfle.de; linux-kernel@vger.kernel.org
> Subject: [PATCH 2/3] PCI: hv: fix hv_pci_remove() for hot-remove
>
> 1. We don't really need such a big on-stack buffer when sending
> the teardown_packet: vmbus_sendpacket() here only uses
> sizeof(struct pci_message).
>
> 2. In the hot-remove case (PCI_EJECT), after we send
> PCI_EJECTION_COMPLETE
> to the host, the host will send a RESCIND_CHANNEL message to us and the
> host won't access the per-channel ringbuffer any longer, so we needn't
> send PCI_RESOURCES_RELEASED/PCI_BUS_D0EXIT to the host, and we
> shouldn't
> expect the host's completion message of PCI_BUS_D0EXIT, which will never
> come.
>
> 3. We should send PCI_BUS_D0EXIT after hv_send_resources_released().
>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> CC: Jake Oshins <jakeo@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>
> CC: Haiyang Zhang <haiyangz@microsoft.com>
> CC: Vitaly Kuznetsov <vkuznets@redhat.com>
Thanks Dexuan.
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
>
> ---
>
> I made the patch based on discussions with Jake Oshins and others.
>
> drivers/pci/host/pci-hyperv.c | 53 +++++++++++++++++++++++++++--------
> --------
> 1 file changed, 33 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index 93ed64a..7590ad0 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -2266,24 +2266,32 @@ static int hv_pci_probe(struct hv_device *hdev,
> return ret;
> }
>
> -/**
> - * hv_pci_remove() - Remove routine for this VMBus channel
> - * @hdev: VMBus's tracking struct for this root PCI bus
> - *
> - * Return: 0 on success, -errno on failure
> - */
> -static int hv_pci_remove(struct hv_device *hdev)
> +static void hv_pci_bus_exit(struct hv_device *hdev)
> {
> - int ret;
> - struct hv_pcibus_device *hbus;
> - union {
> + struct hv_pcibus_device *hbus = hv_get_drvdata(hdev);
> + struct {
> struct pci_packet teardown_packet;
> - u8 buffer[0x100];
> + u8 buffer[sizeof(struct pci_message)];
> } pkt;
> struct pci_bus_relations relations;
> struct hv_pci_compl comp_pkt;
> + int ret;
>
> - hbus = hv_get_drvdata(hdev);
> + /*
> + * After the host sends the RESCIND_CHANNEL message, it doesn't
> + * access the per-channel ringbuffer any longer.
> + */
> + if (hdev->channel->rescind)
> + return;
> +
> + /* Delete any children which might still exist. */
> + memset(&relations, 0, sizeof(relations));
> + hv_pci_devices_present(hbus, &relations);
> +
> + ret = hv_send_resources_released(hdev);
> + if (ret)
> + dev_err(&hdev->device,
> + "Couldn't send resources released packet(s)\n");
>
> memset(&pkt.teardown_packet, 0, sizeof(pkt.teardown_packet));
> init_completion(&comp_pkt.host_event);
> @@ -2298,7 +2306,19 @@ static int hv_pci_remove(struct hv_device *hdev)
>
> VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> if (!ret)
> wait_for_completion_timeout(&comp_pkt.host_event, 10 *
> HZ);
> +}
> +
> +/**
> + * hv_pci_remove() - Remove routine for this VMBus channel
> + * @hdev: VMBus's tracking struct for this root PCI bus
> + *
> + * Return: 0 on success, -errno on failure
> + */
> +static int hv_pci_remove(struct hv_device *hdev)
> +{
> + struct hv_pcibus_device *hbus;
>
> + hbus = hv_get_drvdata(hdev);
> if (hbus->state == hv_pcibus_installed) {
> /* Remove the bus from PCI's point of view. */
> pci_lock_rescan_remove();
> @@ -2307,17 +2327,10 @@ static int hv_pci_remove(struct hv_device
> *hdev)
> pci_unlock_rescan_remove();
> }
>
> - ret = hv_send_resources_released(hdev);
> - if (ret)
> - dev_err(&hdev->device,
> - "Couldn't send resources released packet(s)\n");
> + hv_pci_bus_exit(hdev);
>
> vmbus_close(hdev->channel);
>
> - /* Delete any children which might still exist. */
> - memset(&relations, 0, sizeof(relations));
> - hv_pci_devices_present(hbus, &relations);
> -
> iounmap(hbus->cfg_addr);
> hv_free_config_window(hbus);
> pci_free_resource_list(&hbus->resources_for_children);
> --
> 2.7.4
^ permalink raw reply
* RE: [PATCH 2/3] PCI: hv: fix hv_pci_remove() for hot-remove
From: KY Srinivasan @ 2016-11-14 23:06 UTC (permalink / raw)
To: Dexuan Cui, Bjorn Helgaas, linux-pci@vger.kernel.org,
devel@linuxdriverproject.org
Cc: gregkh@linuxfoundation.org, Haiyang Zhang, Stephen Hemminger,
Jake Oshins, Hadden Hoppert, Vitaly Kuznetsov,
jasowang@redhat.com, apw@canonical.com, olaf@aepfle.de,
linux-kernel@vger.kernel.org
In-Reply-To: <MWHPR03MB2669BF0EB52B9289747F04E1BFB80@MWHPR03MB2669.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Dexuan Cui
> Sent: Wednesday, November 9, 2016 11:19 PM
> To: Bjorn Helgaas <bhelgaas@google.com>; linux-pci@vger.kernel.org;
> devel@linuxdriverproject.org
> Cc: gregkh@linuxfoundation.org; KY Srinivasan <kys@microsoft.com>;
> Haiyang Zhang <haiyangz@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; Jake Oshins <jakeo@microsoft.com>; Hadden
> Hoppert <haddenh@microsoft.com>; Vitaly Kuznetsov
> <vkuznets@redhat.com>; jasowang@redhat.com; apw@canonical.com;
> olaf@aepfle.de; linux-kernel@vger.kernel.org
> Subject: [PATCH 2/3] PCI: hv: fix hv_pci_remove() for hot-remove
>=20
> 1. We don't really need such a big on-stack buffer when sending
> the teardown_packet: vmbus_sendpacket() here only uses
> sizeof(struct pci_message).
>=20
> 2. In the hot-remove case (PCI_EJECT), after we send
> PCI_EJECTION_COMPLETE
> to the host, the host will send a RESCIND_CHANNEL message to us and the
> host won't access the per-channel ringbuffer any longer, so we needn't
> send PCI_RESOURCES_RELEASED/PCI_BUS_D0EXIT to the host, and we
> shouldn't
> expect the host's completion message of PCI_BUS_D0EXIT, which will never
> come.
>=20
> 3. We should send PCI_BUS_D0EXIT after hv_send_resources_released().
>=20
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
> CC: Jake Oshins <jakeo@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>
> CC: Haiyang Zhang <haiyangz@microsoft.com>
> CC: Vitaly Kuznetsov <vkuznets@redhat.com>
Thanks Dexuan.
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
>=20
> ---
>=20
> I made the patch based on discussions with Jake Oshins and others.
>=20
> drivers/pci/host/pci-hyperv.c | 53 +++++++++++++++++++++++++++--------
> --------
> 1 file changed, 33 insertions(+), 20 deletions(-)
>=20
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.=
c
> index 93ed64a..7590ad0 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -2266,24 +2266,32 @@ static int hv_pci_probe(struct hv_device *hdev,
> return ret;
> }
>=20
> -/**
> - * hv_pci_remove() - Remove routine for this VMBus channel
> - * @hdev: VMBus's tracking struct for this root PCI bus
> - *
> - * Return: 0 on success, -errno on failure
> - */
> -static int hv_pci_remove(struct hv_device *hdev)
> +static void hv_pci_bus_exit(struct hv_device *hdev)
> {
> - int ret;
> - struct hv_pcibus_device *hbus;
> - union {
> + struct hv_pcibus_device *hbus =3D hv_get_drvdata(hdev);
> + struct {
> struct pci_packet teardown_packet;
> - u8 buffer[0x100];
> + u8 buffer[sizeof(struct pci_message)];
> } pkt;
> struct pci_bus_relations relations;
> struct hv_pci_compl comp_pkt;
> + int ret;
>=20
> - hbus =3D hv_get_drvdata(hdev);
> + /*
> + * After the host sends the RESCIND_CHANNEL message, it doesn't
> + * access the per-channel ringbuffer any longer.
> + */
> + if (hdev->channel->rescind)
> + return;
> +
> + /* Delete any children which might still exist. */
> + memset(&relations, 0, sizeof(relations));
> + hv_pci_devices_present(hbus, &relations);
> +
> + ret =3D hv_send_resources_released(hdev);
> + if (ret)
> + dev_err(&hdev->device,
> + "Couldn't send resources released packet(s)\n");
>=20
> memset(&pkt.teardown_packet, 0, sizeof(pkt.teardown_packet));
> init_completion(&comp_pkt.host_event);
> @@ -2298,7 +2306,19 @@ static int hv_pci_remove(struct hv_device *hdev)
>=20
> VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> if (!ret)
> wait_for_completion_timeout(&comp_pkt.host_event, 10 *
> HZ);
> +}
> +
> +/**
> + * hv_pci_remove() - Remove routine for this VMBus channel
> + * @hdev: VMBus's tracking struct for this root PCI bus
> + *
> + * Return: 0 on success, -errno on failure
> + */
> +static int hv_pci_remove(struct hv_device *hdev)
> +{
> + struct hv_pcibus_device *hbus;
>=20
> + hbus =3D hv_get_drvdata(hdev);
> if (hbus->state =3D=3D hv_pcibus_installed) {
> /* Remove the bus from PCI's point of view. */
> pci_lock_rescan_remove();
> @@ -2307,17 +2327,10 @@ static int hv_pci_remove(struct hv_device
> *hdev)
> pci_unlock_rescan_remove();
> }
>=20
> - ret =3D hv_send_resources_released(hdev);
> - if (ret)
> - dev_err(&hdev->device,
> - "Couldn't send resources released packet(s)\n");
> + hv_pci_bus_exit(hdev);
>=20
> vmbus_close(hdev->channel);
>=20
> - /* Delete any children which might still exist. */
> - memset(&relations, 0, sizeof(relations));
> - hv_pci_devices_present(hbus, &relations);
> -
> iounmap(hbus->cfg_addr);
> hv_free_config_window(hbus);
> pci_free_resource_list(&hbus->resources_for_children);
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH 1/2] libselinux, libsemanage: fall back to gcc in exception.sh
From: William Roberts @ 2016-11-14 23:06 UTC (permalink / raw)
To: Nicolas Iooss; +Cc: selinux@tycho.nsa.gov
In-Reply-To: <CAJfZ7=nE0i60LuYs7+zU=-54LA8jLb=N8GUK5hNQVEX_65yqXw@mail.gmail.com>
On Mon, Nov 14, 2016 at 3:00 PM, Nicolas Iooss <nicolas.iooss@m4x.org> wrote:
> The SWIG wrapper already includes the header files using #include (look at
> the beginning of libselinux/src/selinuxswig_python.i [1] for example). The
> script exception.h reads the header files (through gcc -aux-info) to
> generate some SWIG code for almost every interface returning an integer
> (this code converts a negative return value to the raising of a Python
> OSError exception).
>
> In SWIG documentation [2] I have not found a way to automatically apply a
> %exception block to all functions matched by the pattern "it returns an
> integer". As you seem to believe I missed something,
I don't think you did.
could you please
> explain how you would proceed here?
Yeah that script is just generating a bunch of interface code, I would
just remove that script
and write it by hand. The only downfall is that you would have to add
a stub if you add something
to the header file, but I don't consider that a downside, I prefer to
be explicit. Especially
considering they already had to put a function in the script to skip.
I don't think the script provides
much value.
>
> Nicolas
>
> [1]
> https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/selinuxswig_python.i#L11
> [2] http://www.swig.org/Doc3.0/SWIGDocumentation.html
>
>
> On Mon, Nov 14, 2016 at 11:15 PM, William Roberts <bill.c.roberts@gmail.com>
> wrote:
>>
>> For a more long term solution, why not just give swig a header file
>> (you can ifdef on SWIG for anything to omit), or write the interface
>> file by hand. I ended up using a hybrid approach for one my projects
>> (the build system is a mess):
>>
>>
>> https://bitbucket.org/miniat/0x1-miniat/src/f84cb76ab0fbe645ee9c48d30221b29283745778/vm/src/miniat_python.i?at=master&fileviewer=file-view-default
>>
>>
>> On Mon, Nov 14, 2016 at 1:57 PM, Nicolas Iooss <nicolas.iooss@m4x.org>
>> wrote:
>> > clang does not support -aux-info option. When exception.sh is run with
>> > CC=clang, use gcc to build selinuxswig_python_exception.i and
>> > semanageswig_python_exception.i.
>> >
>> > This does not solve the issue of building libselinux and libsemanage
>> > Python wrappers on a system without gcc. However parsing the result of
>> > "gcc -aux-info" is easier than parsing the header files so stay with
>> > this command at least for now.
>> >
>> > Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
>> > ---
>> > libselinux/src/exception.sh | 6 +++++-
>> > libsemanage/src/exception.sh | 6 +++++-
>> > 2 files changed, 10 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/libselinux/src/exception.sh b/libselinux/src/exception.sh
>> > index a58bf3f45778..a3ff83235ced 100755
>> > --- a/libselinux/src/exception.sh
>> > +++ b/libselinux/src/exception.sh
>> > @@ -15,6 +15,10 @@ echo "
>> > ;;
>> > esac
>> > }
>> > -${CC:-gcc} -x c -c -I../include - -aux-info temp.aux <
>> > ../include/selinux/selinux.h
>> > +if ! ${CC:-gcc} -x c -c -I../include - -aux-info temp.aux <
>> > ../include/selinux/selinux.h
>> > +then
>> > + # clang does not support -aux-info so fall back to gcc
>> > + gcc -x c -c -I../include - -aux-info temp.aux <
>> > ../include/selinux/selinux.h
>> > +fi
>> > for i in `awk '/<stdin>.*extern int/ { print $6 }' temp.aux`; do except
>> > $i ; done
>> > rm -f -- temp.aux -.o
>> > diff --git a/libsemanage/src/exception.sh b/libsemanage/src/exception.sh
>> > index d18959cbe85d..a4095f4f8ba6 100644
>> > --- a/libsemanage/src/exception.sh
>> > +++ b/libsemanage/src/exception.sh
>> > @@ -9,6 +9,10 @@ echo "
>> > }
>> > "
>> > }
>> > -${CC:-gcc} -x c -c -I../include - -aux-info temp.aux <
>> > ../include/semanage/semanage.h
>> > +if ! ${CC:-gcc} -x c -c -I../include - -aux-info temp.aux <
>> > ../include/semanage/semanage.h
>> > +then
>> > + # clang does not support -aux-info so fall back to gcc
>> > + gcc -x c -c -I../include - -aux-info temp.aux <
>> > ../include/semanage/semanage.h
>> > +fi
>> > for i in `awk '/extern int/ { print $6 }' temp.aux`; do except $i ;
>> > done
>> > rm -f -- temp.aux -.o
>> > --
>> > 2.10.2
>> >
>> > _______________________________________________
>> > Selinux mailing list
>> > Selinux@tycho.nsa.gov
>> > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> > To get help, send an email containing "help" to
>> > Selinux-request@tycho.nsa.gov.
>>
>>
>>
>> --
>> Respectfully,
>>
>> William C Roberts
>
>
--
Respectfully,
William C Roberts
^ permalink raw reply
* [U-Boot] [U-Boot, v4, 05/14] efi: Makefile: Export variables for use with EFI
From: Alexander Graf @ 2016-11-14 23:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1478533636-17577-6-git-send-email-sjg@chromium.org>
> When building an EFI app we need three things:
>
> - start-up code
> - relocation code
> - link script
>
> These are all different for each architecture. We also need special
> compiler flags in some cases.
>
> Add top-level Makefile variables for these along with documentation.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
Thanks, applied to efi-next
Alex
^ permalink raw reply
* [U-Boot] [U-Boot, v4, 03/14] efi: Fix debug message address format
From: Alexander Graf @ 2016-11-14 23:06 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1478533636-17577-4-git-send-email-sjg@chromium.org>
> This should use U-Boot's standard format for hex address. Fix it.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
Thanks, applied to efi-next
Alex
^ 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.