* Re: [PATCH v2] arm: dts: am335x-boneblack: add gpio-line-names
From: Tony Lindgren @ 2020-05-29 17:21 UTC (permalink / raw)
To: Drew Fustini
Cc: Linus Walleij, Grygorii Strashko, Benoît Cousson,
Rob Herring, Linux-OMAP, devicetree, linux-kernel, Jason Kridner,
Robert Nelson
In-Reply-To: <20200528131620.GA3126290@x1>
* Drew Fustini <drew@beagleboard.org> [200528 13:17]:
> FYI - Linus W. provided an Acked-by in related thread [0].
>
> Anyone else have any review comments?
Looks good to me thanks. But as the merge window is about
to open, let's do fixes only at this point and leave this
for v5.9.
Regards,
Tony
>
> [0] https://lore.kernel.org/linux-devicetree/CACRpkdZLRjcE0FGwVR-Q7a50aEmpB=xO4q6H8_EaV199fGr0OA@mail.gmail.com/
^ permalink raw reply
* [GIT PULL] arm64 fix for 5.7-rc8/final
From: Catalin Marinas @ 2020-05-29 17:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Will Deacon, linux-kernel, linux-arm-kernel
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 8cfb347ad0cffdbfc69c82506fb3be9429563211:
arm64: Add get_user() type annotation on the !access_ok() path (2020-05-22 16:59:49 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to ba051f097fc30b00f6b66044386901141351a557:
arm64/kernel: Fix return value when cpu_online() fails in __cpu_up() (2020-05-28 12:04:55 +0100)
----------------------------------------------------------------
Ensure __cpu_up() returns an error if cpu_online() is false after
waiting for completion on cpu_running.
----------------------------------------------------------------
Nobuhiro Iwamatsu (1):
arm64/kernel: Fix return value when cpu_online() fails in __cpu_up()
arch/arm64/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] arm64 fix for 5.7-rc8/final
From: Catalin Marinas @ 2020-05-29 17:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Will Deacon, linux-arm-kernel, linux-kernel
Hi Linus,
Please pull the arm64 fix below. Thanks.
The following changes since commit 8cfb347ad0cffdbfc69c82506fb3be9429563211:
arm64: Add get_user() type annotation on the !access_ok() path (2020-05-22 16:59:49 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
for you to fetch changes up to ba051f097fc30b00f6b66044386901141351a557:
arm64/kernel: Fix return value when cpu_online() fails in __cpu_up() (2020-05-28 12:04:55 +0100)
----------------------------------------------------------------
Ensure __cpu_up() returns an error if cpu_online() is false after
waiting for completion on cpu_running.
----------------------------------------------------------------
Nobuhiro Iwamatsu (1):
arm64/kernel: Fix return value when cpu_online() fails in __cpu_up()
arch/arm64/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 0/5] libceph: support for replica reads
From: Ilya Dryomov @ 2020-05-29 17:21 UTC (permalink / raw)
To: Jason Dillaman; +Cc: ceph-devel, Jeff Layton
In-Reply-To: <CA+aFP1D_povJnBfH5pT8E7OVK_WHWa0TtBwRCxB=OmscTjGf8Q@mail.gmail.com>
On Fri, May 29, 2020 at 6:57 PM Jason Dillaman <jdillama@redhat.com> wrote:
>
> lgtm -- couple questions:
>
> 1) the client adding the options will be responsible for determining if it's safe to enable read-from-replica/balanced reads (i.e. OSDs >= octopus)?
Yes, we can't easily check require_osd_release or similar in the
kernel. This is opt-in, and I'll add a warning together with the
description of the new options to the man page.
> 2) is there a way to determine if the kernel supports the new options (or will older kernels just ignore the options w/o complaining)? i.e. can ceph-csi safely add the argument regardless?
No, older kernels will error out. I think ceph-csi would handle
this the same way ceph quotas are handled (i.e. with the list of
known "good" kernel versions) or alternatively just attempt to map
with and then without crush_location and read_balance=localize
(probably less appealing given that the kernel version list
infrastructure is already in place).
Thanks,
Ilya
^ permalink raw reply
* Re: [PATCH net-next 11/11] net: dsa: ocelot: introduce driver for Seville VSC9953 switch
From: Alexandre Belloni @ 2020-05-29 17:20 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, David S. Miller, netdev, Vivien Didelot,
Florian Fainelli, Russell King - ARM Linux admin, Antoine Tenart,
Horatiu Vultur, Allan W. Nielsen, Microchip Linux Driver Support,
Alexandru Marginean, Claudiu Manoil, Madalin Bucur (OSS),
radu-andrei.bulie, fido_max
In-Reply-To: <CA+h21hqQmGTrhybFAvqN2A14ZU5KRvS8h2cgGYh185HevtfwWA@mail.gmail.com>
On 29/05/2020 18:42:47+0300, Vladimir Oltean wrote:
> On Fri, 29 May 2020 at 12:03, Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 29/05/2020 11:30:43+0300, Vladimir Oltean wrote:
> > > > As ocelot can be used in a DSA configuration (even if it is not
> > > > implemented yet), I don't think this would be correct. From my point of
> > > > view, felix and seville are part of the ocelot family.
> > > >
> > >
> > > In this case, there would be a third driver in
> > > drivers/net/dsa/ocelot/ocelot_vsc7511.c which uses the intermediate
> > > felix_switch_ops from felix.c to access the ocelot core
> > > implementation. Unless you have better naming suggestions?
> > >
> >
> > I don't. Maybe felix.c should have been ocelot.c from the beginning but
> > honestly, it doesn't matter that much.
> >
>
> Technically Seville is not part of the Ocelot family but part of
> Serval, but then again, it's just a marketing name, so it doesn't
> really mean anything..
When I submitted ocelot, I was thinking we would have different drivers
for jaguar, luton, ocelot, serval and serval-t. IIRC, ocelot is a subset
of serval or at least, it is similar enough to share the same driver.
> I am a bit reluctant to rename the DSA driver ops to "ocelot", since
> it would be even more confusing for everyone to have a function
> ocelot_dsa_set_ageing_time that calls ocelot_set_ageing_time. At least
> this way, there's going to be some learning curve figuring out that
> felix is an umbrella term for DSA ops, but there will be more naming
> predictability. (at least that's how I see it)
>
I'm fine with the current naming, I was certainly not suggesting to
change it.
> > BTW, maybe we should merge the VITESSE FELIX ETHERNET SWITCH DRIVER and
> > MICROSEMI ETHERNET SWITCH DRIVER entries in MAINTAINERS. You do much
> > more work in drivers/net/ethernet/mscc/ than I currently do.
> >
>
> How would you see the merged MAINTAINERS entry? Something like this?
>
> MICROSEMI ETHERNET SWITCH DRIVER
> M: Alexandre Belloni <alexandre.belloni@bootlin.com>
> M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
> M: Vladimir Oltean <vladimir.oltean@nxp.com>
You should probably be in the top position.
> M: Claudiu Manoil <claudiu.manoil@nxp.com>
> L: netdev@vger.kernel.org
> S: Maintained
I guess this could stay Supported unless you are not paid to work on
that.
> F: include/soc/mscc/ocelot*
> F: drivers/net/ethernet/mscc/
> F: drivers/net/dsa/ocelot/*
> F: net/dsa/tag_ocelot.c
>
> Any takers from Microchip, or is the internal mailing list enough?
It seems ok for now, we can always add/replace people later on.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] ath10k: Avoid override CE5 configuration for QCA99X0 chipsets
From: Sebastian Gottschall @ 2020-05-29 17:18 UTC (permalink / raw)
To: Kalle Valo; +Cc: Maharaja Kennadyrajan, linux-wireless, ath10k
In-Reply-To: <87ftbisqgf.fsf@codeaurora.org>
will check it
Am 29.05.2020 um 17:36 schrieb Kalle Valo:
> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> Am 05.05.2020 um 09:34 schrieb Kalle Valo:
>>
>>> Maharaja Kennadyrajan <mkenna@codeaurora.org> wrote:
>>>
>>>> As the exisiting CE configurations are defined in global, there
>>>> are the chances of QCA99X0 family chipsets CE configurations
>>>> are getting changed by the ath10k_pci_override_ce_config()
>>>> function.
>>>>
>>>> The override will be hit and CE5 configurations will be changed,
>>>> when the user bring up the QCA99X0 chipsets along with QCA6174
>>>> or QCA9377 chipset. (Bring up QCA99X0 family chipsets after
>>>> QCA6174 or QCA9377).
>>>>
>>>> Hence, fixing this issue by moving the global CE configuration
>>>> to radio specific CE configuration.
>>>>
>>>> Tested hardware: QCA9888 & QCA6174
>>>> Tested firmware: 10.4-3.10-00047 & WLAN.RM.4.4.1.c3-00058
>>>>
>>>> Signed-off-by: Maharaja Kennadyrajan <mkenna@codeaurora.org>
>>>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>>> Patch applied to ath-next branch of ath.git, thanks.
>>>
>>> 521fc37be3d8 ath10k: Avoid override CE5 configuration for QCA99X0 chipsets
>> this patch will crash on ipq4019 devices. i reverted it and it worked again
> Yeah, that patch is buggy but this should fix it:
>
> commit 32221df6765b3773ff1af37c77f8531ebc48f246
> Author: Arnd Bergmann <arnd@arndb.de>
> AuthorDate: Sat May 9 14:06:33 2020 +0200
> Commit: Kalle Valo <kvalo@codeaurora.org>
> CommitDate: Tue May 12 10:33:13 2020 +0300
>
> ath10k: fix ath10k_pci struct layout
>
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCH] ath10k: Avoid override CE5 configuration for QCA99X0 chipsets
From: Sebastian Gottschall @ 2020-05-29 17:18 UTC (permalink / raw)
To: Kalle Valo; +Cc: Maharaja Kennadyrajan, linux-wireless, ath10k
In-Reply-To: <87ftbisqgf.fsf@codeaurora.org>
will check it
Am 29.05.2020 um 17:36 schrieb Kalle Valo:
> Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
>
>> Am 05.05.2020 um 09:34 schrieb Kalle Valo:
>>
>>> Maharaja Kennadyrajan <mkenna@codeaurora.org> wrote:
>>>
>>>> As the exisiting CE configurations are defined in global, there
>>>> are the chances of QCA99X0 family chipsets CE configurations
>>>> are getting changed by the ath10k_pci_override_ce_config()
>>>> function.
>>>>
>>>> The override will be hit and CE5 configurations will be changed,
>>>> when the user bring up the QCA99X0 chipsets along with QCA6174
>>>> or QCA9377 chipset. (Bring up QCA99X0 family chipsets after
>>>> QCA6174 or QCA9377).
>>>>
>>>> Hence, fixing this issue by moving the global CE configuration
>>>> to radio specific CE configuration.
>>>>
>>>> Tested hardware: QCA9888 & QCA6174
>>>> Tested firmware: 10.4-3.10-00047 & WLAN.RM.4.4.1.c3-00058
>>>>
>>>> Signed-off-by: Maharaja Kennadyrajan <mkenna@codeaurora.org>
>>>> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
>>> Patch applied to ath-next branch of ath.git, thanks.
>>>
>>> 521fc37be3d8 ath10k: Avoid override CE5 configuration for QCA99X0 chipsets
>> this patch will crash on ipq4019 devices. i reverted it and it worked again
> Yeah, that patch is buggy but this should fix it:
>
> commit 32221df6765b3773ff1af37c77f8531ebc48f246
> Author: Arnd Bergmann <arnd@arndb.de>
> AuthorDate: Sat May 9 14:06:33 2020 +0200
> Commit: Kalle Valo <kvalo@codeaurora.org>
> CommitDate: Tue May 12 10:33:13 2020 +0300
>
> ath10k: fix ath10k_pci struct layout
>
^ permalink raw reply
* Re: [PATCH v2] fast-import: add new --date-format=raw-permissive format
From: Junio C Hamano @ 2020-05-29 17:19 UTC (permalink / raw)
To: Jeff King; +Cc: Elijah Newren via GitGitGadget, git, jrnieder, Elijah Newren
In-Reply-To: <20200529061346.GB1294228@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, May 28, 2020 at 08:40:37PM +0000, Elijah Newren via GitGitGadget wrote:
>
>> * Instead of just allowing such timezones outright, did it behind a
>> --date-format=raw-permissive as suggested by Jonathan
>
> Thanks, I like the safety this gives us against importer bugs. It does
> mean that people doing "export | filter | import" may have to manually
> loosen it, but it should be rare enough that this isn't a big burden
> (and if they're rewriting anyway, maybe it gives them a chance to decide
> how to fix it up).
>
>> fast-import.c | 15 ++++++++++++---
>> t/t9300-fast-import.sh | 30 ++++++++++++++++++++++++++++++
>
> Would we need a documentation update for "raw-permissive", too?
Good eyes. I somehow thought this was an internal option but it
does need to be known by end-users who use the fast-import tool.
>> @@ -1929,7 +1931,8 @@ static int validate_raw_date(const char *src, struct strbuf *result)
>> return -1;
>>
>> num = strtoul(src + 1, &endp, 10);
>> - if (errno || endp == src + 1 || *endp || 1400 < num)
>> + out_of_range_timezone = strict && (1400 < num);
>> + if (errno || endp == src + 1 || *endp || out_of_range_timezone)
>> return -1;
>
> It's a little funny to do computations on the result of a function
> before we've checked whether it produced an error. But since the result
> is just an integer, I don't think we'd do anything unexpected (we might
> just throw away the value, though I imagine an optimizing compiler might
> evaluate it lazily anyway).
True, but if it is easy to make it kosher, we should.
if (errno || endp == src + 1 || *endp || /* did not parse */
(strict && (1400 < num)) /* parsed a broken timezone */
)
perhaps?
>> +test_expect_success 'B: accept invalid timezone with raw-permissive' '
>> + cat >input <<-INPUT_END &&
>> + commit refs/heads/invalid-timezone
>> + committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1234567890 +051800
>> + data <<COMMIT
>> + empty commit
>> + COMMIT
>> + INPUT_END
>> +
>> + test_when_finished "git update-ref -d refs/heads/invalid-timezone
>> + git gc
>> + git prune" &&
>
> We check the exit code of when_finished commands, so this should be
> &&-chained as usual. And possibly indented like:
>
> test_when_finished "
> git update-ref -d refs/heads/invalid-timezone &&
> git gc &&
> git prune
> " &&
>
> but I see this all is copying another nearby test. So I'm OK with
> keeping it consistent for now and cleaning up the whole thing later.
> Though if you want to do that step now, I have no objection. :)
Sure. Another alternative is to make it right/modern for only this
added test---that makes the inconsistency stand out and gives
incentive to others for cleaning up after the dust settles when the
patch gets merged to the 'master' branch.
> I also also suspect this "gc" is not useful these days. For a small
> input like this, fast-import will write loose objects, since d9545c7f46
> (fast-import: implement unpack limit, 2016-04-25).
>
> TBH, I think it would be easier to understand as:
>
> ...
> git init invalid-timezone &&
> git -C invalid-timezone fast-import <input &&
> git -C invalid-timezone cat-file -p master >out &&
> ...
>
> and don't bother with the when_finished at all. Then you don't have to
> wonder whether the cleanup was sufficient, and it's fewer processes
> to boot (we'll leave the sub-repo cruft sitting around, but a single "rm
> -rf" at the end of the test script will wipe them all out).
Nice.
^ permalink raw reply
* [PATCH v3 2/2] drivers/irqchip: Use new macro ACPI_DECLARE_SUBTABLE_PROBE_ENTRY
From: Oscar Carter @ 2020-05-29 17:18 UTC (permalink / raw)
To: Kees Cook, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rafael J. Wysocki, Len Brown
Cc: Oscar Carter, kernel-hardening, linux-kernel, linux-acpi
In-Reply-To: <20200529171847.10267-1-oscar.carter@gmx.com>
In an effort to enable -Wcast-function-type in the top-level Makefile to
support Control Flow Integrity builds, there are the need to remove all
the function callback casts.
To do this, modify the IRQCHIP_ACPI_DECLARE macro to use the new defined
macro ACPI_DECLARE_SUBTABLE_PROBE_ENTRY instead of the macro
ACPI_DECLARE_PROBE_ENTRY. This is necessary to be able to initialize the
the acpi_probe_entry struct using the probe_subtbl field instead of the
probe_table field and avoid function cast mismatches.
Also, modify the prototype of the functions used by the invocation of the
IRQCHIP_ACPI_DECLARE macro to match all the parameters.
Co-developed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Oscar Carter <oscar.carter@gmx.com>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/irqchip/irq-gic.c | 2 +-
include/linux/irqchip.h | 5 +++--
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index d7006ef18a0d..3870e9d4d3a8 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -2117,7 +2117,7 @@ static void __init gic_acpi_setup_kvm_info(void)
}
static int __init
-gic_acpi_init(struct acpi_subtable_header *header, const unsigned long end)
+gic_acpi_init(union acpi_subtable_headers *header, const unsigned long end)
{
struct acpi_madt_generic_distributor *dist;
struct fwnode_handle *domain_handle;
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 30ab623343d3..fc431857ce90 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1593,7 +1593,7 @@ static void __init gic_acpi_setup_kvm_info(void)
gic_set_kvm_info(&gic_v2_kvm_info);
}
-static int __init gic_v2_acpi_init(struct acpi_subtable_header *header,
+static int __init gic_v2_acpi_init(union acpi_subtable_headers *header,
const unsigned long end)
{
struct acpi_madt_generic_distributor *dist;
diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
index 950e4b2458f0..447f22880a69 100644
--- a/include/linux/irqchip.h
+++ b/include/linux/irqchip.h
@@ -39,8 +39,9 @@
* @fn: initialization function
*/
#define IRQCHIP_ACPI_DECLARE(name, subtable, validate, data, fn) \
- ACPI_DECLARE_PROBE_ENTRY(irqchip, name, ACPI_SIG_MADT, \
- subtable, validate, data, fn)
+ ACPI_DECLARE_SUBTABLE_PROBE_ENTRY(irqchip, name, \
+ ACPI_SIG_MADT, subtable, \
+ validate, data, fn)
#ifdef CONFIG_IRQCHIP
void irqchip_init(void);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 5/5] libceph: read_policy option
From: Jeff Layton @ 2020-05-29 17:19 UTC (permalink / raw)
To: Ilya Dryomov, ceph-devel
In-Reply-To: <20200529151952.15184-6-idryomov@gmail.com>
On Fri, 2020-05-29 at 17:19 +0200, Ilya Dryomov wrote:
> Expose balanced and localized reads through read_policy=balance
> and read_policy=localize. The default is to read from primary.
>
> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
> ---
> include/linux/ceph/libceph.h | 2 ++
> net/ceph/ceph_common.c | 26 ++++++++++++++++++++++++++
> net/ceph/osd_client.c | 5 ++++-
> 3 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/ceph/libceph.h b/include/linux/ceph/libceph.h
> index 4733959f1ec7..0a9f807ceda6 100644
> --- a/include/linux/ceph/libceph.h
> +++ b/include/linux/ceph/libceph.h
> @@ -52,6 +52,8 @@ struct ceph_options {
> unsigned long osd_idle_ttl; /* jiffies */
> unsigned long osd_keepalive_timeout; /* jiffies */
> unsigned long osd_request_timeout; /* jiffies */
> + unsigned int osd_req_flags; /* CEPH_OSD_FLAG_*, applied to
> + each OSD request */
>
> /*
> * any type that can't be simply compared or doesn't need
> diff --git a/net/ceph/ceph_common.c b/net/ceph/ceph_common.c
> index 6d495685ee03..1a834cb0d04d 100644
> --- a/net/ceph/ceph_common.c
> +++ b/net/ceph/ceph_common.c
> @@ -265,6 +265,7 @@ enum {
> Opt_key,
> Opt_ip,
> Opt_crush_location,
> + Opt_read_policy,
> /* string args above */
> Opt_share,
> Opt_crc,
> @@ -274,6 +275,17 @@ enum {
> Opt_abort_on_full,
> };
>
> +enum {
> + Opt_read_policy_balance,
> + Opt_read_policy_localize,
> +};
> +
> +static const struct constant_table ceph_param_read_policy[] = {
> + {"balance", Opt_read_policy_balance},
> + {"localize", Opt_read_policy_localize},
> + {}
> +};
> +
> static const struct fs_parameter_spec ceph_parameters[] = {
> fsparam_flag ("abort_on_full", Opt_abort_on_full),
> fsparam_flag_no ("cephx_require_signatures", Opt_cephx_require_signatures),
> @@ -290,6 +302,8 @@ static const struct fs_parameter_spec ceph_parameters[] = {
> fsparam_u32 ("osdkeepalive", Opt_osdkeepalivetimeout),
> __fsparam (fs_param_is_s32, "osdtimeout", Opt_osdtimeout,
> fs_param_deprecated, NULL),
> + fsparam_enum ("read_policy", Opt_read_policy,
> + ceph_param_read_policy),
> fsparam_string ("secret", Opt_secret),
> fsparam_flag_no ("share", Opt_share),
> fsparam_flag_no ("tcp_nodelay", Opt_tcp_nodelay),
> @@ -470,6 +484,18 @@ int ceph_parse_param(struct fs_parameter *param, struct ceph_options *opt,
> return err;
> }
> break;
> + case Opt_read_policy:
> + switch (result.uint_32) {
> + case Opt_read_policy_balance:
> + opt->osd_req_flags |= CEPH_OSD_FLAG_BALANCE_READS;
> + break;
> + case Opt_read_policy_localize:
> + opt->osd_req_flags |= CEPH_OSD_FLAG_LOCALIZE_READS;
> + break;
> + default:
> + BUG();
> + }
> + break;
Suppose I specify "-o read_policy=balance,read_policy=localize".
Principle of least surprise says "last one wins", but you'll end up with
both flags set here, and I think the final result would still be
"balance". I think it'd probably be best to rework this so that the last
option specified is what you get.
I also think you want a way to explicitly set it back to default
behavior (read_policy=primary ?), as it's not uncommon for people to
specify mount options in fstab but then append to them on the command
line. e.g.:
# mount /mnt/cephfs -o read_policy=primary
...when fstab already has read_policy=balance.
> case Opt_osdtimeout:
> warn_plog(&log, "Ignoring osdtimeout");
> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
> index 15c3afa8089b..da7046db9fbe 100644
> --- a/net/ceph/osd_client.c
> +++ b/net/ceph/osd_client.c
> @@ -2425,11 +2425,14 @@ static void __submit_request(struct ceph_osd_request *req, bool wrlocked)
>
> static void account_request(struct ceph_osd_request *req)
> {
> + struct ceph_osd_client *osdc = req->r_osdc;
> +
> WARN_ON(req->r_flags & (CEPH_OSD_FLAG_ACK | CEPH_OSD_FLAG_ONDISK));
> WARN_ON(!(req->r_flags & (CEPH_OSD_FLAG_READ | CEPH_OSD_FLAG_WRITE)));
>
> req->r_flags |= CEPH_OSD_FLAG_ONDISK;
> - atomic_inc(&req->r_osdc->num_requests);
> + req->r_flags |= osdc->client->options->osd_req_flags;
> + atomic_inc(&osdc->num_requests);
>
> req->r_start_stamp = jiffies;
> req->r_start_latency = ktime_get();
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* [PATCH v3 1/2] drivers/irqchip: Add new macro ACPI_DECLARE_SUBTABLE_PROBE_ENTRY
From: Oscar Carter @ 2020-05-29 17:18 UTC (permalink / raw)
To: Kees Cook, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rafael J. Wysocki, Len Brown
Cc: Oscar Carter, kernel-hardening, linux-kernel, linux-acpi
In-Reply-To: <20200529171847.10267-1-oscar.carter@gmx.com>
In an effort to enable -Wcast-function-type in the top-level Makefile to
support Control Flow Integrity builds, there are the need to remove all
the function callback casts.
To do this, create a new macro called ACPI_DECLARE_SUBTABLE_PROBE_ENTRY
to initialize the acpi_probe_entry struct using the probe_subtbl field
instead of the probe_table field. This is a previous work to be able to
modify the IRQCHIP_ACPI_DECLARE macro to use this new defined macro.
Even though these two commented fields are part of a union, this is
necessary to avoid function cast mismatches. That is, due to the
IRQCHIP_ACPI_DECLARE invocations use as last parameter a function with
the protoype "int (*func)(struct acpi_subtable_header *, const unsigned
long)" it's necessary that this macro initialize the probe_subtbl field
of the acpi_probe_entry struct and not the probe_table field.
Co-developed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Oscar Carter <oscar.carter@gmx.com>
---
include/linux/acpi.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index d661cd0ee64d..cf74e044a570 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1154,6 +1154,17 @@ struct acpi_probe_entry {
.driver_data = data, \
}
+#define ACPI_DECLARE_SUBTABLE_PROBE_ENTRY(table, name, table_id, \
+ subtable, valid, data, fn) \
+ static const struct acpi_probe_entry __acpi_probe_##name \
+ __used __section(__##table##_acpi_probe_table) = { \
+ .id = table_id, \
+ .type = subtable, \
+ .subtable_valid = valid, \
+ .probe_subtbl = fn, \
+ .driver_data = data, \
+ }
+
#define ACPI_PROBE_TABLE(name) __##name##_acpi_probe_table
#define ACPI_PROBE_TABLE_END(name) __##name##_acpi_probe_table_end
--
2.20.1
^ permalink raw reply related
* [PATCH v3 0/2] drivers/irqchip: Remove function callback casts
From: Oscar Carter @ 2020-05-29 17:18 UTC (permalink / raw)
To: Kees Cook, Thomas Gleixner, Jason Cooper, Marc Zyngier,
Rafael J. Wysocki, Len Brown
Cc: Oscar Carter, kernel-hardening, linux-kernel, linux-acpi
In an effort to enable -Wcast-function-type in the top-level Makefile to
support Control Flow Integrity builds, there are the need to remove all
the function callback casts.
The first patch creates a macro called ACPI_DECLARE_SUBTABLE_PROBE_ENTRY
to initialize the acpi_probe_entry struct using the probe_subtbl field
instead of the probe_table field to avoid function cast mismatches.
The second patch modifies the IRQCHIP_ACPI_DECLARE macro to use the new
defined macro ACPI_DECLARE_SUBTABLE_PROBE_ENTRY instead of the macro
ACPI_DECLARE_PROBE_ENTRY. Also, modifies the prototype of the functions
used by the invocation of the IRQCHIP_ACPI_DECLARE macro to match all the
parameters.
Changelog v1->v2
- Add more details in the commit changelog to clarify the changes (Marc
Zyngier)
- Declare a new macro called ACPI_DECLARE_SUBTABLE_PROBE_ENTRY (Marc
Zyngier)
- In the IRQCHIP_ACPI_DECLARE use the new defined macro (Marc Zyngier)
Changelog v2->v3
- Remove the cast of the macro ACPI_DECLARE_SUBTABLE_PROBE_ENTRY (Marc
Zyngier)
- Change the prototype of the functions used by the invocation of the
macro IRQCHIP_ACPI_DECLARE (Marc Zyngier)
- Split the changes in two patches.
- Add these two lines, to give credit to Marc Zyngier
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Oscar Carter <oscar.carter@gmx.com>
Oscar Carter (2):
drivers/irqchip: Add new macro ACPI_DECLARE_SUBTABLE_PROBE_ENTRY
drivers/irqchip: Use new macro ACPI_DECLARE_SUBTABLE_PROBE_ENTRY
drivers/irqchip/irq-gic-v3.c | 2 +-
drivers/irqchip/irq-gic.c | 2 +-
include/linux/acpi.h | 11 +++++++++++
include/linux/irqchip.h | 5 +++--
4 files changed, 16 insertions(+), 4 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Enable shared interrupt support
From: Mark Brown @ 2020-05-29 17:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Ray Jui, Nicolas Saenz Julienne,
Scott Branden, Florian Fainelli
Cc: Martin Sperl, linux-kernel, linux-rpi-kernel, linux-arm-kernel,
linux-spi
In-Reply-To: <20200528185805.28991-1-nsaenzjulienne@suse.de>
On Thu, 28 May 2020 20:58:04 +0200, Nicolas Saenz Julienne wrote:
> bcm2711, Rasberry Pi 4's SoC, shares one interrupt for multiple
> instances of the bcm2835 SPI controller. So this enables shared
> interrupt support for them.
>
> The early bail out in the interrupt routine avoids messing with buffers
> of transfers being done by other means. Otherwise, the driver can handle
> receiving interrupts asserted by other controllers during an IRQ based
> transfer.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: bcm2835: Enable shared interrupt support
commit: ecfbd3cf3b8bb73ac6a80ddf430b5912fd4402a6
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] mwifiex: Add support for NL80211_ATTR_MAX_AP_ASSOC_STA
From: Pali Rohár @ 2020-05-29 17:19 UTC (permalink / raw)
To: Kalle Valo, Ganapathi Bhat
Cc: Amitkumar Karwar, Xinming Hu, David S. Miller, Marek Behún,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20200521123559.29028-1-pali@kernel.org>
On Thursday 21 May 2020 14:35:59 Pali Rohár wrote:
> SD8997 firmware sends TLV_TYPE_MAX_CONN with struct hw_spec_max_conn to
> inform kernel about maximum number of p2p connections and stations in AP
> mode.
>
> During initialization of SD8997 wifi chip kernel prints warning:
>
> mwifiex_sdio mmc0:0001:1: Unknown GET_HW_SPEC TLV type: 0x217
>
> This patch adds support for parsing TLV_TYPE_MAX_CONN (0x217) and sets
> appropriate cfg80211 member 'max_ap_assoc_sta' from retrieved structure.
>
> It allows userspace to retrieve NL80211_ATTR_MAX_AP_ASSOC_STA attribute.
>
> Signed-off-by: Pali Rohár <pali@kernel.org>
Hello Kalle and Ganapathi, could you please review this patch?
> ---
> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 5 +++++
> drivers/net/wireless/marvell/mwifiex/cmdevt.c | 12 ++++++++++++
> drivers/net/wireless/marvell/mwifiex/fw.h | 8 ++++++++
> drivers/net/wireless/marvell/mwifiex/main.h | 1 +
> 4 files changed, 26 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index 12bfd653a..7998e91c9 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -4339,6 +4339,11 @@ int mwifiex_register_cfg80211(struct mwifiex_adapter *adapter)
> wiphy->iface_combinations = &mwifiex_iface_comb_ap_sta;
> wiphy->n_iface_combinations = 1;
>
> + if (adapter->max_sta_conn > adapter->max_p2p_conn)
> + wiphy->max_ap_assoc_sta = adapter->max_sta_conn;
> + else
> + wiphy->max_ap_assoc_sta = adapter->max_p2p_conn;
> +
> /* Initialize cipher suits */
> wiphy->cipher_suites = mwifiex_cipher_suites;
> wiphy->n_cipher_suites = ARRAY_SIZE(mwifiex_cipher_suites);
> diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> index 589cc5eb1..d068b9075 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> @@ -1495,6 +1495,7 @@ int mwifiex_ret_get_hw_spec(struct mwifiex_private *priv,
> struct mwifiex_adapter *adapter = priv->adapter;
> struct mwifiex_ie_types_header *tlv;
> struct hw_spec_api_rev *api_rev;
> + struct hw_spec_max_conn *max_conn;
> u16 resp_size, api_id;
> int i, left_len, parsed_len = 0;
>
> @@ -1604,6 +1605,17 @@ int mwifiex_ret_get_hw_spec(struct mwifiex_private *priv,
> break;
> }
> break;
> + case TLV_TYPE_MAX_CONN:
> + max_conn = (struct hw_spec_max_conn *)tlv;
> + adapter->max_p2p_conn = max_conn->max_p2p_conn;
> + adapter->max_sta_conn = max_conn->max_sta_conn;
> + mwifiex_dbg(adapter, INFO,
> + "max p2p connections: %u\n",
> + adapter->max_p2p_conn);
> + mwifiex_dbg(adapter, INFO,
> + "max sta connections: %u\n",
> + adapter->max_sta_conn);
> + break;
> default:
> mwifiex_dbg(adapter, FATAL,
> "Unknown GET_HW_SPEC TLV type: %#x\n",
> diff --git a/drivers/net/wireless/marvell/mwifiex/fw.h b/drivers/net/wireless/marvell/mwifiex/fw.h
> index 6f86f5b96..8047e3078 100644
> --- a/drivers/net/wireless/marvell/mwifiex/fw.h
> +++ b/drivers/net/wireless/marvell/mwifiex/fw.h
> @@ -220,6 +220,7 @@ enum MWIFIEX_802_11_PRIVACY_FILTER {
> #define TLV_TYPE_BSS_MODE (PROPRIETARY_TLV_BASE_ID + 206)
> #define TLV_TYPE_RANDOM_MAC (PROPRIETARY_TLV_BASE_ID + 236)
> #define TLV_TYPE_CHAN_ATTR_CFG (PROPRIETARY_TLV_BASE_ID + 237)
> +#define TLV_TYPE_MAX_CONN (PROPRIETARY_TLV_BASE_ID + 279)
>
> #define MWIFIEX_TX_DATA_BUF_SIZE_2K 2048
>
> @@ -2388,4 +2389,11 @@ struct mwifiex_opt_sleep_confirm {
> __le16 action;
> __le16 resp_ctrl;
> } __packed;
> +
> +struct hw_spec_max_conn {
> + struct mwifiex_ie_types_header header;
> + u8 max_p2p_conn;
> + u8 max_sta_conn;
> +} __packed;
> +
> #endif /* !_MWIFIEX_FW_H_ */
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
> index afaffc325..5923c5c14 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -1022,6 +1022,7 @@ struct mwifiex_adapter {
> bool ext_scan;
> u8 fw_api_ver;
> u8 key_api_major_ver, key_api_minor_ver;
> + u8 max_p2p_conn, max_sta_conn;
> struct memory_type_mapping *mem_type_mapping_tbl;
> u8 num_mem_types;
> bool scan_chan_gap_enabled;
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCHv3 1/2] spi: dw: add reset control
From: Mark Brown @ 2020-05-29 17:19 UTC (permalink / raw)
To: linux-kernel, Dinh Nguyen
Cc: devicetree, linux-spi, Sergey.Semin, Liang Jin J, lars.povlsen,
andriy.shevchenko, fancer.lancer, robh+dt
In-Reply-To: <20200527204110.25676-1-dinguyen@kernel.org>
On Wed, 27 May 2020 15:41:09 -0500, Dinh Nguyen wrote:
> Add mechanism to get the reset control and deassert it in order to bring
> the IP out of reset.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/2] spi: dw: add reset control
commit: 7830c0ef26cb73b653c2db2f3ca7be08f44fa046
[2/2] dt-bindings: snps,dw-apb-ssi: add optional reset property
commit: 2604d48702fe14fb3e97701269dd5e66b392b904
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Implement shutdown callback
From: Mark Brown @ 2020-05-29 17:18 UTC (permalink / raw)
To: linux-kernel, Florian Fainelli
Cc: Scott Branden, Ray Jui, open list:SPI SUBSYSTEM,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528190605.24850-1-f.fainelli@gmail.com>
On Thu, 28 May 2020 12:06:05 -0700, Florian Fainelli wrote:
> Make sure we clear the FIFOs, stop the block, disable the clock and
> release the DMA channel.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: bcm2835: Implement shutdown callback
commit: 118eb0e52eb74b899053a0f46dfe7e178788d23b
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Enable shared interrupt support
From: Mark Brown @ 2020-05-29 17:18 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Ray Jui, Nicolas Saenz Julienne,
Scott Branden, Florian Fainelli
Cc: linux-spi, linux-arm-kernel, linux-rpi-kernel, linux-kernel,
Martin Sperl
In-Reply-To: <20200528185805.28991-1-nsaenzjulienne@suse.de>
On Thu, 28 May 2020 20:58:04 +0200, Nicolas Saenz Julienne wrote:
> bcm2711, Rasberry Pi 4's SoC, shares one interrupt for multiple
> instances of the bcm2835 SPI controller. So this enables shared
> interrupt support for them.
>
> The early bail out in the interrupt routine avoids messing with buffers
> of transfers being done by other means. Otherwise, the driver can handle
> receiving interrupts asserted by other controllers during an IRQ based
> transfer.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: bcm2835: Enable shared interrupt support
commit: ecfbd3cf3b8bb73ac6a80ddf430b5912fd4402a6
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Implement shutdown callback
From: Mark Brown @ 2020-05-29 17:18 UTC (permalink / raw)
To: linux-kernel, Florian Fainelli
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE, Ray Jui,
Nicolas Saenz Julienne,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Scott Branden,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:SPI SUBSYSTEM
In-Reply-To: <20200528190605.24850-1-f.fainelli@gmail.com>
On Thu, 28 May 2020 12:06:05 -0700, Florian Fainelli wrote:
> Make sure we clear the FIFOs, stop the block, disable the clock and
> release the DMA channel.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: bcm2835: Implement shutdown callback
commit: 118eb0e52eb74b899053a0f46dfe7e178788d23b
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCHv4 1/2] spi: dw: add reset control
From: Mark Brown @ 2020-05-29 17:18 UTC (permalink / raw)
To: linux-kernel, Dinh Nguyen
Cc: devicetree, linux-spi, liang.j.jin, Sergey.Semin, lars.povlsen,
andriy.shevchenko, fancer.lancer, robh+dt
In-Reply-To: <20200529155806.16758-1-dinguyen@kernel.org>
On Fri, 29 May 2020 10:58:05 -0500, Dinh Nguyen wrote:
> Add mechanism to get the reset control and deassert it in order to bring
> the IP out of reset.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/2] spi: dw: add reset control
commit: 7830c0ef26cb73b653c2db2f3ca7be08f44fa046
[2/2] dt-bindings: snps,dw-apb-ssi: add optional reset property
commit: 2604d48702fe14fb3e97701269dd5e66b392b904
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v6 00/16] spi: dw: Add generic DW DMA controller support
From: Mark Brown @ 2020-05-29 17:18 UTC (permalink / raw)
To: Serge Semin
Cc: Ekaterina Skachko, Feng Tang, devicetree, Thomas Bogendoerfer,
Georgy Vlasov, Pavel Parkhomenko, Alexey Kolotnikov, Serge Semin,
linux-spi, linux-kernel, Vadim Vlasov, Alexey Malahov, linux-mips,
Andy Shevchenko, Rob Herring, Ramil Zaripov, Arnd Bergmann,
Maxim Kaurkin
In-Reply-To: <20200529131205.31838-1-Sergey.Semin@baikalelectronics.ru>
On Fri, 29 May 2020 16:11:49 +0300, Serge Semin wrote:
> Baikal-T1 SoC provides a DW DMA controller to perform low-speed peripherals
> Mem-to-Dev and Dev-to-Mem transaction. This is also applicable to the DW
> APB SSI devices embedded into the SoC. Currently the DMA-based transfers
> are supported by the DW APB SPI driver only as a middle layer code for
> Intel MID/Elkhart PCI devices. Seeing the same code can be used for normal
> platform DMAC device we introduced a set of patches to fix it within this
> series.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[01/15] spi: dw: Set xfer effective_speed_hz
commit: de4c2875a5ff2c886df60f2086c6affca83f890a
[02/15] spi: dw: Return any value retrieved from the dma_transfer callback
commit: f0410bbf7d0fb80149e3b17d11d31f5b5197873e
[03/15] spi: dw: Locally wait for the DMA transfers completion
commit: bdbdf0f06337d3661b64c0288c291cb06624065e
[04/15] spi: dw: Add SPI Tx-done wait method to DMA-based transfer
commit: 1ade2d8a72f9240825f6be050f0d49c840f7daeb
[05/15] spi: dw: Add SPI Rx-done wait method to DMA-based transfer
commit: 33726eff3d98e643f7d7a0940f4024844b430c82
[06/15] spi: dw: Parameterize the DMA Rx/Tx burst length
commit: c534df9d6225314d1403e4330a22d68c35e0eb55
[07/15] spi: dw: Use DMA max burst to set the request thresholds
commit: 0b2b66514fc9971b3a6002ba038d74f77705fd34
[08/15] spi: dw: Fix Rx-only DMA transfers
commit: 46164fde6b7890e7a3982d54549947c8394c0192
[09/15] spi: dw: Add core suffix to the DW APB SSI core source file
commit: 77ccff803d27279ccc100dc906c6f456c8fa515c
[10/15] spi: dw: Move Non-DMA code to the DW PCIe-SPI driver
commit: 6c710c0cb6725bdbe647b958756685aed0295936
[11/15] spi: dw: Remove DW DMA code dependency from DW_DMAC_PCI
commit: 06cfadb8c51b05c6b91c2d43e0fe72b3d643dced
[12/15] spi: dw: Add DW SPI DMA/PCI/MMIO dependency on the DW SPI core
commit: ecb3a67edfd353837dc23b538fb250d1dfd88e7b
[13/15] spi: dw: Cleanup generic DW DMA code namings
commit: 57784411728ff4d72ae051fdbba1e54fcb1f8d6f
[14/15] spi: dw: Add DMA support to the DW SPI MMIO driver
commit: 0fdad596d46b28d5c3e39d1897c5e3878b64d9a2
[15/15] spi: dw: Use regset32 DebugFS method to create regdump file
commit: 8378449d1f79add31be77e77fc7df9f639878e9c
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 3/4] drm/i915/display: Implement HOBL
From: Souza, Jose @ 2020-05-29 17:17 UTC (permalink / raw)
To: ville.syrjala@linux.intel.com; +Cc: intel-gfx@lists.freedesktop.org
In-Reply-To: <20200529070017.GH6112@intel.com>
On Fri, 2020-05-29 at 10:00 +0300, Ville Syrjälä wrote:
> On Thu, May 28, 2020 at 01:03:55PM -0700, José Roberto de Souza wrote:
> > Hours Of Battery Life is a new GEN12+ power-saving feature that allows
> > supported motherboards to use a special voltage swing table for eDP
> > panels that uses less power.
> >
> > So here if supported by HW, OEM will set it in VBT and i915 will try
> > to train link with HOBL vswing table if link training fails it fall
> > back to the original table.
> >
> > Just not sure if DP compliance should also use this new voltage swing
> > table too, cced some folks that worked in DP compliance.
> >
> > BSpec: 49291
> > BSpec: 49399
> > Cc: Animesh Manna <animesh.manna@intel.com>
> > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 48 +++++++++++++++++--
> > .../drm/i915/display/intel_display_types.h | 2 +
> > .../drm/i915/display/intel_dp_link_training.c | 20 +++++++-
> > drivers/gpu/drm/i915/i915_drv.h | 2 +
> > drivers/gpu/drm/i915/i915_reg.h | 2 +
> > 5 files changed, 69 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index c100efc6a2c4..a44e190de79f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -692,6 +692,10 @@ static const struct cnl_ddi_buf_trans tgl_combo_phy_ddi_translations_dp_hbr2[] =
> > { 0x6, 0x7F, 0x3F, 0x00, 0x00 }, /* 900 900 0.0 */
> > };
> >
> > +static const struct cnl_ddi_buf_trans tgl_combo_phy_ddi_translations_edp_hbr2_hobl[] = {
> > + { 0x6, 0x7F, 0x3F, 0x00, 0x00 }
> > +};
>
> This doesn't seem to mesh well with the notion of "at least
> everything up to vswing 2/preemph 2 is mandatory", as laid
> out in https://patchwork.freedesktop.org/series/77198/
>
> Hmm. I was going to add some WARNs there to make sure
> .{voltage,preemph}_max() always return level 2 or level 3.
> But looks like I failed to actually do it.
Even if you had, intel_dp_voltage_max() is not aware of this new table and if/when it is executed is because the voltage 0 and preemph 0 of the
regular table also failed the link training.
>
> > +
> > static const struct ddi_buf_trans *
> > bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> > {
> > @@ -2297,14 +2301,51 @@ static void cnl_ddi_vswing_sequence(struct intel_encoder *encoder,
> > intel_de_write(dev_priv, CNL_PORT_TX_DW5_GRP(port), val);
> > }
> >
> > +/*
> > + * If supported return HOBL vswing table and set registers to enable HOBL
> > + * otherwise returns NULL and unset registers to enable HOBL.
> > + */
> > +static const struct cnl_ddi_buf_trans *
> > +hobl_get_combo_buf_trans(struct drm_i915_private *dev_priv,
> > + struct intel_encoder *encoder, int type, int rate,
> > + u32 level, int *n_entries)
> > +{
> > + const u32 hobl_en = EDP4K2K_MODE_OVRD_EN | EDP4K2K_MODE_OVRD_OPTIMIZED;
> > + enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> > + struct intel_dp *intel_dp;
> > +
> > + if (!HAS_HOBL(dev_priv) || type != INTEL_OUTPUT_EDP)
> > + return NULL;
> > +
> > + intel_dp = enc_to_intel_dp(encoder);
> > + if (!intel_dp->try_hobl || rate > 540000) {
> > + intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), hobl_en, 0);
> > + return NULL;
> > + }
> > +
> > + drm_dbg_kms(&dev_priv->drm, "Enabling HOBL in PHY %c\n", phy_name(phy));
> > + drm_WARN_ON_ONCE(&dev_priv->drm, level > 0);
> > +
> > + intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), hobl_en, hobl_en);
> > + /* Same table applies to TGL, RKL and DG1 */
> > + *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
> > + return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
> > +}
> > +
> > static void icl_ddi_combo_vswing_program(struct drm_i915_private *dev_priv,
> > - u32 level, enum phy phy, int type,
> > - int rate)
> > + struct intel_encoder *encoder,
> > + u32 level, enum phy phy, int type,
> > + int rate)
> > {
> > const struct cnl_ddi_buf_trans *ddi_translations = NULL;
> > u32 n_entries, val;
> > int ln;
> >
> > + ddi_translations = hobl_get_combo_buf_trans(dev_priv, encoder, type,
> > + rate, level, &n_entries);
> > + if (ddi_translations)
> > + goto hobl_found;
> > +
> > if (INTEL_GEN(dev_priv) >= 12)
> > ddi_translations = tgl_get_combo_buf_trans(dev_priv, type, rate,
> > &n_entries);
> > @@ -2317,6 +2358,7 @@ static void icl_ddi_combo_vswing_program(struct drm_i915_private *dev_priv,
> > if (!ddi_translations)
> > return;
> >
> > +hobl_found:
> > if (level >= n_entries) {
> > drm_dbg_kms(&dev_priv->drm,
> > "DDI translation not found for level %d. Using %d instead.",
> > @@ -2424,7 +2466,7 @@ static void icl_combo_phy_ddi_vswing_sequence(struct intel_encoder *encoder,
> > intel_de_write(dev_priv, ICL_PORT_TX_DW5_GRP(phy), val);
> >
> > /* 5. Program swing and de-emphasis */
> > - icl_ddi_combo_vswing_program(dev_priv, level, phy, type, rate);
> > + icl_ddi_combo_vswing_program(dev_priv, encoder, level, phy, type, rate);
> >
> > /* 6. Set training enable to trigger update */
> > val = intel_de_read(dev_priv, ICL_PORT_TX_DW5_LN0(phy));
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 30b2767578dc..9e7dbff7dd43 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -1365,6 +1365,8 @@ struct intel_dp {
> >
> > /* Display stream compression testing */
> > bool force_dsc_en;
> > +
> > + bool try_hobl;
> > };
> >
> > enum lspcon_vendor {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index e4f1843170b7..db078780542f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -37,12 +37,24 @@ intel_dp_dump_link_status(const u8 link_status[DP_LINK_STATUS_SIZE])
> > void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
> > const u8 link_status[DP_LINK_STATUS_SIZE])
> > {
> > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > u8 v = 0;
> > u8 p = 0;
> > int lane;
> > u8 voltage_max;
> > u8 preemph_max;
> >
> > + if (intel_dp->try_hobl) {
> > + /*
> > + * Do not adjust, try now with the regular table using VSwing 0
> > + * and pre-emp 0
> > + */
> > + intel_dp->try_hobl = false;
> > + drm_dbg_kms(&dev_priv->drm, "HOBL vswing table failed link "
> > + "training, switching back to regular table\n");
> > + return;
> > + }
> > +
> > for (lane = 0; lane < intel_dp->lane_count; lane++) {
> > u8 this_v = drm_dp_get_adjust_request_voltage(link_status, lane);
> > u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status, lane);
> > @@ -92,9 +104,13 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
> > }
> >
> > static bool
> > -intel_dp_reset_link_train(struct intel_dp *intel_dp,
> > - u8 dp_train_pat)
> > +intel_dp_reset_link_train(struct intel_dp *intel_dp, u8 dp_train_pat)
> > {
> > + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +
> > + if (intel_dp_is_edp(intel_dp) && dev_priv->vbt.edp.hobl)
> > + intel_dp->try_hobl = true;
> > +
> > memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
> > intel_dp_set_signal_levels(intel_dp);
> > return intel_dp_set_link_train(intel_dp, dp_train_pat);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index 1e060de3edc4..8c2fb4da70fd 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1678,6 +1678,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> > #define INTEL_DISPLAY_ENABLED(dev_priv) \
> > (drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)), !i915_modparams.disable_display)
> >
> > +#define HAS_HOBL(dev_priv) (INTEL_GEN(dev_priv) >= 12)
> > +
> > static inline bool intel_vtd_active(void)
> > {
> > #ifdef CONFIG_INTEL_IOMMU
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index e9d50fe0f375..a7a8d12fa49d 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1896,6 +1896,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
> > #define PWR_DOWN_LN_3_1_0 (0xb << 4)
> > #define PWR_DOWN_LN_MASK (0xf << 4)
> > #define PWR_DOWN_LN_SHIFT 4
> > +#define EDP4K2K_MODE_OVRD_EN (1 << 3)
> > +#define EDP4K2K_MODE_OVRD_OPTIMIZED (1 << 2)
> >
> > #define ICL_PORT_CL_DW12(phy) _MMIO(_ICL_PORT_CL_DW(12, phy))
> > #define ICL_LANE_ENABLE_AUX (1 << 0)
> > --
> > 2.26.2
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [BlueZ PATCH v3 4/4] fixing const decoration warnins on options.
From: Luiz Augusto von Dentz @ 2020-05-29 17:16 UTC (permalink / raw)
To: Alain Michaud; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20200529153814.213125-5-alainm@chromium.org>
Hi Alain,
On Fri, May 29, 2020 at 8:41 AM Alain Michaud <alainm@chromium.org> wrote:
>
> This changes fixes const decoration warnins on options.
What us this fixing?
> ---
>
> Changes in v3: None
> Changes in v2: None
>
> src/main.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/main.c b/src/main.c
> index ca27f313d..cea50a3d2 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -80,7 +80,7 @@ static enum {
> MPS_MULTIPLE,
> } mps = MPS_OFF;
>
> -static const char *supported_options[] = {
> +static const char * const supported_options[] = {
> "Name",
> "Class",
> "DiscoverableTimeout",
> @@ -129,7 +129,7 @@ static const char * const controller_options[] = {
> NULL
> };
>
> -static const char *policy_options[] = {
> +static const char * const policy_options[] = {
> "ReconnectUUIDs",
> "ReconnectAttempts",
> "ReconnectIntervals",
> @@ -137,7 +137,7 @@ static const char *policy_options[] = {
> NULL
> };
>
> -static const char *gatt_options[] = {
> +static const char * const gatt_options[] = {
> "Cache",
> "KeySize",
> "ExchangeMTU",
> @@ -146,8 +146,8 @@ static const char *gatt_options[] = {
> };
>
> static const struct group_table {
> - const char *name;
> - const char **options;
> + const char * const name;
> + const char * const * const options;
> } valid_groups[] = {
> { "General", supported_options },
> { "Controller", controller_options },
> @@ -243,7 +243,7 @@ static enum jw_repairing_t parse_jw_repairing(const char *jw_repairing)
>
>
> static void check_options(GKeyFile *config, const char *group,
> - const char **options)
> + const char * const * const options)
> {
> char **keys;
> int i;
> --
> 2.27.0.rc0.183.gde8f92d652-goog
>
I wonder how usufull is to tell it is a constant pointer to a constant
character given that is so rarely in the kernel and userspace,
something like const char * const * const would be very hard to keep
it readable.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] atmel: Use shared constant for rfc1042 header
From: Kalle Valo @ 2020-05-29 17:16 UTC (permalink / raw)
To: Pascal Terjan
Cc: Simon Kelley, David S. Miller, Jakub Kicinski, linux-wireless,
netdev, linux-kernel, Pascal Terjan
In-Reply-To: <20200523212735.32364-1-pterjan@google.com>
Pascal Terjan <pterjan@google.com> wrote:
> This is one of the 9 drivers redefining rfc1042_header.
>
> Signed-off-by: Pascal Terjan <pterjan@google.com>
Patch applied to wireless-drivers-next.git, thanks.
e78e5d18c653 atmel: Use shared constant for rfc1042 header
--
https://patchwork.kernel.org/patch/11567013/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] libertas: Use shared constant for rfc1042 header
From: Kalle Valo @ 2020-05-29 17:16 UTC (permalink / raw)
To: Pascal Terjan
Cc: David S. Miller, Jakub Kicinski, libertas-dev, linux-wireless,
netdev, linux-kernel, Pascal Terjan
In-Reply-To: <20200523212628.31526-1-pterjan@google.com>
Pascal Terjan <pterjan@google.com> wrote:
> This is one of the 9 drivers redefining rfc1042_header.
>
> Signed-off-by: Pascal Terjan <pterjan@google.com>
Patch applied to wireless-drivers-next.git, thanks.
729ef6b614a1 libertas: Use shared constant for rfc1042 header
--
https://patchwork.kernel.org/patch/11567011/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: CFLAGS overridden by distribution build system
From: William Roberts @ 2020-05-29 17:15 UTC (permalink / raw)
To: Stephen Smalley; +Cc: Laurent Bigonville, SElinux list
In-Reply-To: <CAEjxPJ5weFXrFpyjWdW7D4tgOnK+jHMyD37Zb4JFEzDt1rQ8Dw@mail.gmail.com>
On Fri, May 29, 2020 at 11:40 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Fri, May 29, 2020 at 12:05 PM William Roberts
> <bill.c.roberts@gmail.com> wrote:
> >
> > On Fri, May 29, 2020 at 8:31 AM Stephen Smalley
> > <stephen.smalley.work@gmail.com> wrote:
> > >
> > > On Sat, May 23, 2020 at 11:59 AM William Roberts
> > > <bill.c.roberts@gmail.com> wrote:
> > > >
> > > > On Sat, May 23, 2020 at 5:57 AM Laurent Bigonville <bigon@debian.org> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > The current build system of the userspace is setting a lot of CFLAGS,
> > > > > but most of these are overridden by the distributions when building.
> > > > >
> > > > > Today I received a bug report[0] from Christian Göttsche asking me to
> > > > > set -fno-semantic-interposition again in libsepol. I see also the same
> > > > > flag and also a lot of others set in libselinux and libsemanage build
> > > > > system.
> > > >
> > > > Why would it be again? The old DSO design made that option impotent.
> > > > Clang does it by default.
> > > >
> > > > >
> > > > > For what I understand some of these are just needed for code quality
> > > > > (-W) and could be controlled by distributions but others might actually
> > > > > need to be always set (-f?).
> > > >
> > > > If you look at the Makefiles overall in all the projects, you'll see hardening
> > > > flags, etc. Libsepol has a pretty minimal set compared to say libselinux, but
> > > > they all get overridden by build time CFLAGS if you want.
> > > >
> > > > >
> > > > > Shouldn't the flags that always need to be set (which ones?) be moved to
> > > > > a "override CFLAGS" directive to avoid these to be unset by distributions?
> > > >
> > > > If you we're cleaver with CFLAGS before, you could acually circumvent
> > > > the buildtime
> > > > DSO stuff. While i'm not opposed to adding it to immutable flag, if
> > > > you're setting
> > > > CFLAGS, you're on your own. At least with the current design.
> > > >
> > > > I have no issues with adding it to override, but we would have to
> > > > overhaul a bunch
> > > > of them and make them consistent.
> > >
> > > I'm inclined to agree with Laurent here - we should always set this
> > > flag in order to preserve the same behavior prior to the patches that
> > > removed hidden_def/hidden_proto and switched to relying on this
> > > instead.
> >
> > Theirs a lot of features that rely on particular cflags, consider hardening
> > options. A lot of the warnings/error stuff is not just a code hygiene, but also
> > spotting potential issues that could arise as security issues. If one starts
> > tinkering with cflags, you can really change the code quite a bit. This is why
> > some places only approve sanctioned builds of crypto libraries.
>
> I think the difference here is that we made a change in the source
> code (hidden_def/hidden_proto removal) that requires use of
> -fno-semantic-interposition to preserve existing behavior.
>
> > But one of the things to consider is that for clang builds, clang
> > doesn't support
> > this option, so we would need to move the compiler checking code into each
> > projects root makefile and ensure any consuming subordinate leafs add a
> > default, or move it to the global makefile and make sure each leaf that needs it
> > has a default.
>
> I think clang does support it now? https://reviews.llvm.org/D72724
Yeah but that bug is all 2020 stuff. It is in the clang-10 release. I
verified that
with a local build from here:
- https://apt.llvm.org/
So anything sub clang-10 won't support it, do you want to tie us to that
new of a clang?
^ 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.