[PATCH v3] arm64: dts: ls1028a: Add Audio DT nodes
This patch adds Audio DT nodes for LS1028ARDB and LS1028AQDS boards.
Signed-off-by: Alison Wang
---
Changes in v3:
- Sort EDMA node in unit-address.
Changes in v2:
- Modify some nodes' names.
- Use GIC_SPI and IRQ_TYPE_LEVEL_HIGH.
arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 62
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 63 +
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi| 57 +++
3 files changed, 182 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index 14c79f4..b359068 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -32,6 +32,49 @@
device_type = "memory";
reg = <0x0 0x8000 0x1 0x>;
};
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2500>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "Speaker Ext",
+ "Line", "Line In Jack";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "Microphone Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "Speaker Ext", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <>;
+ frame-master;
+ bitclock-master;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <>;
+ frame-master;
+ bitclock-master;
+ system-clock-frequency = <2500>;
+ };
+ };
};
{
@@ -89,5 +132,24 @@
reg = <0x57>;
};
};
+
+ i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x5>;
+
+ sgtl5000: audio-codec@a {
+ #sound-dai-cells = <0>;
+ compatible = "fsl,sgtl5000";
+ reg = <0xa>;
+ VDDA-supply = <_1p8v>;
+ VDDIO-supply = <_1p8v>;
+ clocks = <_mclk>;
+ };
+ };
};
};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index fdeb417..50ca51a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -28,6 +28,49 @@
device_type = "memory";
reg = <0x0 0x8000 0x1 0x000>;
};
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2500>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "Speaker Ext",
+ "Line", "Line In Jack";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "Microphone Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "Speaker Ext", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <>;
+ frame-master;
+ bitclock-master;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <>;
+
Re: [PATCH v4 4/7] vfio: ap: register IOMMU VFIO notifier
On 28.02.2019 17:55, Halil Pasic wrote: > On Thu, 28 Feb 2019 09:48:39 +0100 > Pierre Morel wrote: > >> On 28/02/2019 09:23, Christian Borntraeger wrote: >>> On 22.02.2019 16:29, Pierre Morel wrote: To be able to use the VFIO interface to facilitate the mediated device memory pining/unpining we need to register a notifier for IOMMU. >>> >>> You might want to add that while we start to pin one guest page for the >>> interrupt indicator byte in the next patch, this is still ok with ballooning >>> as this page will never be used by the guest virtio-balloon driver. So the >>> pinned page will never be freed. And even a broken guest does so, that would >>> not impact the host as the original page is still in control by vfio. >>> >> >> Thanks, I ll do. >> > > I recall a comment in qemu that says vfio-ap does not pin any pages. > That one needs to be fixed up as well. Yes, something along the line that we do pin the interrupt indicator pages but those do not change regularly and we stay in lockstep with the guest. At the same time the guest driver will keep that page allocate so virtio-balloon will not take them.
Re: [PATCH 4/4] soc/fsl/qe: qe.c: support fsl,qe-snums property
On 01/03/2019 04.36, Qiang Zhao wrote:
> On 2019年2月28日 18:31，Rasmus Villemoes wrote:
>
>> -Original Message-
>> From: Rasmus Villemoes
>> Sent: 2019年2月28日 18:31
>> To: Qiang Zhao ; Leo Li
>> Cc: Scott Wood ; linux-kernel@vger.kernel.org; Timur Tabi
>> ; Rasmus Villemoes
>> Subject: [PATCH 4/4] soc/fsl/qe: qe.c: support fsl,qe-snums property
>>
>> The current code assumes that the set of snum _values_ to populate the
>> snums[] array with is a function of the _number_ of snums alone. However,
>> reading table 4-30, and its footnotes, of the QUICC Engine Block Reference
>> Manual shows that that is a bit too naive.
>>
>> As an alternative, this introduces a new binding fsl,qe-snums, which
>> automatically encodes both the number of snums and the actual values to use.
>> Conveniently, of_property_read_variable_u8_array does exactly what we need.
>>
>> For example, for the MPC8309, one would specify the property as
>>
>>fsl,qe-snums = /bits/ 8 <
>>0x88 0x89 0x98 0x99 0xa8 0xa9 0xb8 0xb9
>>0xc8 0xc9 0xd8 0xd9 0xe8 0xe9>;
>>
>> Signed-off-by: Rasmus Villemoes
>> ---
>> .../devicetree/bindings/soc/fsl/cpm_qe/qe.txt | 8 +++-
>> drivers/soc/fsl/qe/qe.c| 14 +-
>> 2 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
>> b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
>> index d7afaff5faff..05f5f485562a 100644
>> --- a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
>> +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/qe.txt
>> @@ -18,7 +18,8 @@ Required properties:
>> - reg : offset and length of the device registers.
>> - bus-frequency : the clock frequency for QUICC Engine.
>> - fsl,qe-num-riscs: define how many RISC engines the QE has.
>> -- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use
>> for the
>> +- fsl,qe-snums: This property has to be specified as '/bits/ 8' value,
>> + defining the array of serial number (SNUM) values for the virtual
>>threads.
>>
>> Optional properties:
>> @@ -34,6 +35,11 @@ Recommended properties
>> - brg-frequency : the internal clock source frequency for baud-rate
>>generators in Hz.
>>
>> +Deprecated properties
>> +- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use
>> + for the threads. Use fsl,qe-snums instead to not only specify the
>> + number of snums, but also their values.
>> +
>> Example:
>> qe@e010 {
>> #address-cells = <1>;
>> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c index
>> 71beeb72eee4..049b36d6aeee 100644
>> --- a/drivers/soc/fsl/qe/qe.c
>> +++ b/drivers/soc/fsl/qe/qe.c
>> @@ -283,7 +283,6 @@ EXPORT_SYMBOL(qe_clock_source);
>> */
>> static void qe_snums_init(void)
>> {
>> -int i;
>> static const u8 snum_init_76[] = {
>> 0x04, 0x05, 0x0C, 0x0D, 0x14, 0x15, 0x1C, 0x1D,
>> 0x24, 0x25, 0x2C, 0x2D, 0x34, 0x35, 0x88, 0x89, @@ -304,9
>> +303,22 @@ static void qe_snums_init(void)
>> 0x28, 0x29, 0x38, 0x39, 0x48, 0x49, 0x58, 0x59,
>> 0x68, 0x69, 0x78, 0x79, 0x80, 0x81,
>> };
>> +struct device_node *qe;
>> const u8 *snum_init;
>> +int i;
>>
>> bitmap_zero(snum_state, QE_NUM_OF_SNUM);
>> +qe = qe_get_device_node();
>> +if (qe) {
>> +i = of_property_read_variable_u8_array(qe, "fsl,qe-snums",
>> + snums, 14,
>> QE_NUM_OF_SNUM);
>> +of_node_put(qe);
>> +if (i > 0) {
>> +qe_num_of_snum = i;
>> +return;
>> +}
>> +}
>> +
>> qe_num_of_snum = qe_get_num_of_snums();
>>
>> if (qe_num_of_snum == 76)
>
> So you define 14 snums for MPC8309, but there still be the comment "/* No QE
> ever has fewer than 28 SNUMs */" and it will check if
> The num_of_snums "is >28", it will cause confusion, so I suggest to modify 28
> to 14.
Sure, that needs updating. My thinking was that only legacy DTs would
use the fsl,qe-num-snums, and there would be no need to support lower
values than we used to, since the logic back in qe_snums_init wouldn't
handle such values appropriately anyway.
> I read the old version QUICC Engine Block Reference Manual, it said snums
> table is not available on MPC8306/MPC8306S/MPC8309,
> So I think the code it written long before with this version RM, and at that
> time, the snums is at least 28, and nobody modify the code later.
> And now with the new version RM, it support MPC8306/MPC8306S/MPC8309 with
> snums and have snums fewer then 28, so I think the minimum value should
> Be modified to 14.
Yes. I'll do an extra cleanup patch modifying the code comments
appropriately. But what do you think about the core idea behind this
change (and the preceding cleanup patches)?
Rasmus
Re: [PATCH] mm: hwpoison: fix thp split handing in soft_offline_in_use_page()
On 2019/3/1 15:29, Naoya Horiguchi wrote:
> On Tue, Feb 26, 2019 at 10:34:32PM +0800, zhong jiang wrote:
>> On 2019/2/26 21:51, Kirill A. Shutemov wrote:
>>> On Tue, Feb 26, 2019 at 07:18:00PM +0800, zhong jiang wrote:
From: zhongjiang
When soft_offline_in_use_page() runs on a thp tail page after pmd is plit,
>>> s/plit/split/
>>>
we trigger the following VM_BUG_ON_PAGE():
Memory failure: 0x3755ff: non anonymous thp
__get_any_page: 0x3755ff: unknown zero refcount page type 2f8000
Soft offlining pfn 0x34d805 at process virtual address 0x20fff000
page:ea000d360140 count:0 mapcount:0 mapping: index:0x1
flags: 0x2f8000()
raw: 002f8000 ea000d360108 ea000d360188
raw: 0001
page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
[ cut here ]
kernel BUG at ./include/linux/mm.h:519!
soft_offline_in_use_page() passed refcount and page lock from tail page to
head page, which is not needed because we can pass any subpage to
split_huge_page().
>>> I don't see a description of what is going wrong and why change will fixed
>>> it. From the description, it appears as it's cosmetic-only change.
>>>
>>> Please elaborate.
>> When soft_offline_in_use_page runs on a thp tail page after pmd is split,
>> and we pass the head page to split_huge_page, Unfortunately, the tail page
>> can be free or count turn into zero.
> I guess that you have the similar fix on memory_failure() in your mind:
>
> commit c3901e722b2975666f42748340df798114742d6d
> Author: Naoya Horiguchi
> Date: Thu Nov 10 10:46:23 2016 -0800
>
> mm: hwpoison: fix thp split handling in memory_failure()
>
> So it seems that I somehow missed fixing soft offline when I wrote commit
> c3901e722b29, and now you find and fix that. Thank you very much.
> If you resend the patch with fixing typo, can you add some reference to
> c3901e722b29 in the patch description to show the linkage?
> And you can add the following tags:
Yep, I find that that is a similar issue. hence I refer to that description in
the patch you
had mentioned.
I will add the above desprition you had mentioned in V2.
Thanks,
zhong jiang
> Fixes: 61f5d698cc97 ("mm: re-enable THP")
> Acked-by: Naoya Horiguchi
>
> Thanks,
> Naoya Horiguchi
>
> .
>
Re: [PATCH v4 1/9] staging: iio: ad7780: add gain & filter gpio support
On Fri, Mar 01, 2019 at 06:56:14AM +, Ardelean, Alexandru wrote:
> On Thu, 2019-02-28 at 11:23 -0300, Renato Lui Geh wrote:
> >
> >
> > Previously, the AD7780 driver only supported gpio for the 'powerdown'
> > pin. This commit adds suppport for the 'gain' and 'filter' pin.
> >
> > Signed-off-by: Renato Lui Geh
> > Signed-off-by: Giuliano Belinassi
> > Co-developed-by: Giuliano Belinassi
> > ---
> > Changes in v3:
> > - Renamed ad7780_chip_info's filter to odr
> > - Renamed ad778x_filter to ad778x_odr_avail
> > - Changed vref variable from unsigned int to unsigned long long to avoid
> >overflow
> > - Removed unnecessary AD_SD_CHANNEL macro
> > Changes in v4:
> > - Removed useless macro
> > - Added default case for switch to suppress warning
> > - Removed chunks belonging to filter reading, adding these as a
> >patch for itself
> >
> > drivers/staging/iio/adc/ad7780.c | 90 +---
> > 1 file changed, 84 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/staging/iio/adc/ad7780.c
> > b/drivers/staging/iio/adc/ad7780.c
> > index c4a85789c2db..87fbcf510d45 100644
> > --- a/drivers/staging/iio/adc/ad7780.c
> > +++ b/drivers/staging/iio/adc/ad7780.c
> > @@ -39,6 +39,12 @@
> > #define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
> > #define AD7170_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2)
> >
> > +#define AD7780_GAIN_MIDPOINT 64
> > +#define AD7780_FILTER_MIDPOINT 13350
> > +
> > +static const unsigned int ad778x_gain[2] = { 1, 128 };
> > +static const unsigned int ad778x_odr_avail[2] = { 1, 16700 };
>
> ad778x_odr_avail[2] is not used in this patch, so it should probably go
> into the next one
> (i.e. staging: iio: ad7780: add filter reading to ad778x )
>
> one good way of catching stuff like this is to do interactive rebase and
> compile your driver on each patch to see if the compiler catches this;
> i suspect the compiler would have thrown an error for this change
>
GCC (v7.3) doesn't complain about unused variables if they're const.
regards,
dan carpenter
Re: [PATCH v4 5/9] staging: iio: ad7780: move regulator to after GPIO init
On Thu, 2019-02-28 at 11:25 -0300, Renato Lui Geh wrote:
>
>
> To maintain consistency between ad7780_probe and ad7780_remove orders,
> regulator initialization has been moved to after GPIO initializations.
>
> Signed-off-by: Renato Lui Geh
> ---
> drivers/staging/iio/adc/ad7780.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index ad7617a3a141..12aef0f101bc 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -255,16 +255,6 @@ static int ad7780_probe(struct spi_device *spi)
>
> ad_sd_init(>sd, indio_dev, spi, _sigma_delta_info);
>
> - st->reg = devm_regulator_get(>dev, "avdd");
> - if (IS_ERR(st->reg))
> - return PTR_ERR(st->reg);
> -
> - ret = regulator_enable(st->reg);
> - if (ret) {
> - dev_err(>dev, "Failed to enable specified AVdd
> supply\n");
> - return ret;
> - }
> -
> st->chip_info =
> _chip_info_tbl[spi_get_device_id(spi)-
> >driver_data];
>
> @@ -284,7 +274,7 @@ static int ad7780_probe(struct spi_device *spi)
> ret = PTR_ERR(st->powerdown_gpio);
> dev_err(>dev, "Failed to request powerdown GPIO:
> %d\n",
> ret);
> - goto error_disable_reg;
> + return ret;
> }
>
> if (st->chip_info->is_ad778x) {
> @@ -295,7 +285,7 @@ static int ad7780_probe(struct spi_device *spi)
> ret = PTR_ERR(st->gain_gpio);
> dev_err(>dev, "Failed to request gain GPIO:
> %d\n",
> ret);
> - goto error_disable_reg;
> + return ret;
> }
>
> st->filter_gpio = devm_gpiod_get_optional(>dev,
> @@ -306,10 +296,20 @@ static int ad7780_probe(struct spi_device *spi)
> dev_err(>dev,
> "Failed to request filter GPIO: %d\n",
> ret);
> - goto error_disable_reg;
> + return ret;
> }
> }
>
> + st->reg = devm_regulator_get(>dev, "avdd");
> + if (IS_ERR(st->reg))
> + return PTR_ERR(st->reg);
> +
> + ret = regulator_enable(st->reg);
> + if (ret) {
> + dev_err(>dev, "Failed to enable specified AVdd
> supply\n");
> + return ret;
> + }
> +
I'm probably missing something, but other than the fact that this moves the
regulator init after the GPIOs init, it doesn't change much.
The order of the probe & remove is more-or-less the same.
The GPIOs will be free'd via devm_ API/stuff.
> ret = ad_sd_setup_buffer_and_trigger(indio_dev);
> if (ret)
> goto error_disable_reg;
> --
> 2.21.0
>
[PATCH] mm: vmscan: show zone type in kswapd tracepoints
If we want to know the zone type, we have to check whether
CONFIG_ZONE_DMA, CONFIG_ZONE_DMA32 and CONFIG_HIGHMEM are set or not,
that's not so convenient.
We'd better show the zone type directly.
Signed-off-by: Yafang Shao
---
include/trace/events/vmscan.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index a1cb913..4c8880b 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -73,7 +73,10 @@
__entry->order = order;
),
- TP_printk("nid=%d zid=%d order=%d", __entry->nid, __entry->zid,
__entry->order)
+ TP_printk("nid=%d zid=%-8s order=%d",
+ __entry->nid,
+ __print_symbolic(__entry->zid, ZONE_TYPE),
+ __entry->order)
);
TRACE_EVENT(mm_vmscan_wakeup_kswapd,
@@ -96,9 +99,9 @@
__entry->gfp_flags = gfp_flags;
),
- TP_printk("nid=%d zid=%d order=%d gfp_flags=%s",
+ TP_printk("nid=%d zid=%-8s order=%d gfp_flags=%s",
__entry->nid,
- __entry->zid,
+ __print_symbolic(__entry->zid, ZONE_TYPE),
__entry->order,
show_gfp_flags(__entry->gfp_flags))
);
--
1.8.3.1
[PATCH] f2fs: fix to do sanity check with inode.i_inline_xattr_size
As Paul Bandha reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=202709
When I run the poc on the mounted f2fs img I get a buffer overflow in
read_inline_xattr due to there being no sanity check on the value of
i_inline_xattr_size.
I created the img by just modifying the value of i_inline_xattr_size
in the inode:
i_name [test1.txt]
i_ext: fofs:0 blkaddr:0 len:0
i_extra_isize [0x 18 : 24]
i_inline_xattr_size [0x : 65535]
i_addr[ofs] [0x 0 : 0]
mkdir /mnt/f2fs
mount ./f2fs1.img /mnt/f2fs
gcc poc.c -o poc
./poc
int main() {
int y = syscall(SYS_listxattr, "/mnt/f2fs/test1.txt", NULL, 0);
printf("ret %d", y);
printf("errno: %d\n", errno);
}
BUG: KASAN: slab-out-of-bounds in read_inline_xattr+0x18f/0x260
Read of size 262140 at addr 88011035efd8 by task f2fs1poc/3263
CPU: 0 PID: 3263 Comm: f2fs1poc Not tainted 4.18.0-custom #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014
Call Trace:
dump_stack+0x71/0xab
print_address_description+0x83/0x250
kasan_report+0x213/0x350
memcpy+0x1f/0x50
read_inline_xattr+0x18f/0x260
read_all_xattrs+0xba/0x190
f2fs_listxattr+0x9d/0x3f0
listxattr+0xb2/0xd0
path_listxattr+0x93/0xe0
do_syscall_64+0x9d/0x220
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Let's add sanity check for inode.i_inline_xattr_size during f2fs_iget()
to avoid this issue.
Signed-off-by: Chao Yu
---
fs/f2fs/inode.c | 14 ++
fs/f2fs/super.c | 7 ++-
fs/f2fs/xattr.h | 9 +
3 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index bec52961630b..b132fe2ff779 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -14,6 +14,7 @@
#include "f2fs.h"
#include "node.h"
#include "segment.h"
+#include "xattr.h"
#include
@@ -248,6 +249,19 @@ static bool sanity_check_inode(struct inode *inode, struct
page *node_page)
return false;
}
+ if (f2fs_has_extra_attr(inode) &&
+ f2fs_sb_has_flexible_inline_xattr(sbi) &&
+ (fi->i_inline_xattr_size < MIN_INLINE_XATTR_SIZE ||
+ fi->i_inline_xattr_size > MAX_INLINE_XATTR_SIZE)) {
+ set_sbi_flag(sbi, SBI_NEED_FSCK);
+ f2fs_msg(sbi->sb, KERN_WARNING,
+ "%s: inode (ino=%lx) has corrupted "
+ "i_inline_xattr_size: %d, min: %zu, max: %zu",
+ __func__, inode->i_ino, fi->i_inline_xattr_size,
+ MIN_INLINE_XATTR_SIZE, MAX_INLINE_XATTR_SIZE);
+ return false;
+ }
+
if (F2FS_I(inode)->extent_tree) {
struct extent_info *ei = _I(inode)->extent_tree->largest;
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 42eb5c86330a..9184b7524c03 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -835,12 +835,9 @@ static int parse_options(struct super_block *sb, char
*options)
return -EINVAL;
}
if (F2FS_OPTION(sbi).inline_xattr_size <
- sizeof(struct f2fs_xattr_header) / sizeof(__le32) ||
+ MIN_INLINE_XATTR_SIZE ||
F2FS_OPTION(sbi).inline_xattr_size >
- DEF_ADDRS_PER_INODE -
- F2FS_TOTAL_EXTRA_ATTR_SIZE / sizeof(__le32) -
- DEF_INLINE_RESERVED_SIZE -
- MIN_INLINE_DENTRY_SIZE / sizeof(__le32)) {
+ MAX_INLINE_XATTR_SIZE) {
f2fs_msg(sb, KERN_ERR,
"inline xattr size is out of range");
return -EINVAL;
diff --git a/fs/f2fs/xattr.h b/fs/f2fs/xattr.h
index 67db134da0f5..94e8a5eeaae1 100644
--- a/fs/f2fs/xattr.h
+++ b/fs/f2fs/xattr.h
@@ -55,6 +55,8 @@ struct f2fs_xattr_entry {
#define XATTR_FIRST_ENTRY(ptr) (XATTR_ENTRY(XATTR_HDR(ptr) + 1))
#define XATTR_ROUND(3)
+#define XATTR_HDR_SIZE (sizeof(struct f2fs_xattr_header))
+
#define XATTR_ALIGN(size) (((size) + XATTR_ROUND) & ~XATTR_ROUND)
#define ENTRY_SIZE(entry) (XATTR_ALIGN(sizeof(struct f2fs_xattr_entry) + \
@@ -78,6 +80,13 @@ struct f2fs_xattr_entry {
sizeof(struct f2fs_xattr_header) - \
sizeof(struct f2fs_xattr_entry))
+#define MAX_INLINE_XATTR_SIZE (XATTR_HDR_SIZE / sizeof(__le32))
+#define MIN_INLINE_XATTR_SIZE \
+ (DEF_ADDRS_PER_INODE - \
+ F2FS_TOTAL_EXTRA_ATTR_SIZE / sizeof(__le32) - \
+ DEF_INLINE_RESERVED_SIZE - \
+ MIN_INLINE_DENTRY_SIZE / sizeof(__le32))
+
/*
* On-disk
RE: [PATCH v2] arm64: dts: ls1028a: Add Audio DT nodes
> On Wed, Feb 20, 2019 at 04:44:57PM +0800, Alison Wang wrote:
> > This patch adds Audio DT nodes for LS1028ARDB and LS1028AQDS boards.
> >
> > Signed-off-by: Alison Wang
> > ---
> > Changes in v2:
> > - Modify some nodes' names.
> > - Use GIC_SPI and IRQ_TYPE_LEVEL_HIGH.
> >
> > arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 62
>
> > arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 63
> +
> > arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi| 57
> +++
> > 3 files changed, 182 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > index a8cf92a..de590ec 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> > @@ -335,5 +335,62 @@
> > ,
> > IRQ_TYPE_LEVEL_HIGH>,
> > ,
> > IRQ_TYPE_LEVEL_HIGH>;
> > };
> > +
> > + edma0: dma-controller@22c {
>
> Please sort the node in unit-address.
>
[Alison] Ok, I will update it in v3. Thanks.
Best Regards,
Alison Wang
Re: [PATCH v2] dts: arm64: add CoreSight trace support for hi3660
Hi Wanglai,
On Thu, Feb 28, 2019 at 02:33:23PM +0800, Wanglai Shi wrote:
> This patch adds devicetree entries for the CoreSight trace
> components on hi3660.
>
> Signed-off-by: Wanglai Shi
> ---
> .../arm64/boot/dts/hisilicon/hi3660-coresight.dtsi | 429
> +
> arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 2 +
> 2 files changed, 431 insertions(+)
> create mode 100644 arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi
> new file mode 100644
> index 000..d651a8b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-coresight.dtsi
> @@ -0,0 +1,429 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * dtsi for Hisilicon Hi3660 Coresight
> + *
> + * Copyright (C) 2016-2018 Hisilicon Ltd.
> + *
> + * Author: Wanglai Shi
> + *
> + */
> +/ {
> + soc {
> + /* A53 cluster internals */
> + etm@ecc4 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0xecc4 0 0x1000>;
> + clocks = <_ctrl HI3660_PCLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> +
> + out-ports {
> + port {
> + etm0_out: endpoint {
> + remote-endpoint =
> + <_funnel_in0>;
> + };
> + };
> + };
> + };
> +
> + etm@ecd4 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0xecd4 0 0x1000>;
> + clocks = <_ctrl HI3660_PCLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> +
> + out-ports {
> + port {
> + etm1_out: endpoint {
> + remote-endpoint =
> + <_funnel_in1>;
> + };
> + };
> + };
> + };
> +
> + etm@ece4 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0xece4 0 0x1000>;
> + clocks = <_ctrl HI3660_PCLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> +
> + out-ports {
> + port {
> + etm2_out: endpoint {
> + remote-endpoint =
> + <_funnel_in2>;
> + };
> + };
> + };
> + };
> +
> + etm@ecf4 {
> + compatible = "arm,coresight-etm4x", "arm,primecell";
> + reg = <0 0xecf4 0 0x1000>;
> + clocks = <_ctrl HI3660_PCLK>;
> + clock-names = "apb_pclk";
> + cpu = <>;
> +
> + out-ports {
> + port {
> + etm3_out: endpoint {
> + remote-endpoint =
> + <_funnel_in3>;
> + };
> + };
> + };
> + };
> +
> + funnel@ec801000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0 0xec801000 0 0x1000>;
> + clocks = <_ctrl HI3660_PCLK>;
> + clock-names = "apb_pclk";
> +
> + out-ports {
> + port {
> + cluster0_funnel_out: endpoint {
> + remote-endpoint =
> + <_etf_in>;
> + };
> + };
> + };
> +
> + in-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + cluster0_funnel_in0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@1 {
> +
Re: [PATCH] mm: hwpoison: fix thp split handing in soft_offline_in_use_page()
On Tue, Feb 26, 2019 at 10:34:32PM +0800, zhong jiang wrote:
> On 2019/2/26 21:51, Kirill A. Shutemov wrote:
> > On Tue, Feb 26, 2019 at 07:18:00PM +0800, zhong jiang wrote:
> >> From: zhongjiang
> >>
> >> When soft_offline_in_use_page() runs on a thp tail page after pmd is plit,
> > s/plit/split/
> >
> >> we trigger the following VM_BUG_ON_PAGE():
> >>
> >> Memory failure: 0x3755ff: non anonymous thp
> >> __get_any_page: 0x3755ff: unknown zero refcount page type 2f8000
> >> Soft offlining pfn 0x34d805 at process virtual address 0x20fff000
> >> page:ea000d360140 count:0 mapcount:0 mapping: index:0x1
> >> flags: 0x2f8000()
> >> raw: 002f8000 ea000d360108 ea000d360188
> >> raw: 0001
> >> page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0)
> >> [ cut here ]
> >> kernel BUG at ./include/linux/mm.h:519!
> >>
> >> soft_offline_in_use_page() passed refcount and page lock from tail page to
> >> head page, which is not needed because we can pass any subpage to
> >> split_huge_page().
> > I don't see a description of what is going wrong and why change will fixed
> > it. From the description, it appears as it's cosmetic-only change.
> >
> > Please elaborate.
> When soft_offline_in_use_page runs on a thp tail page after pmd is split,
> and we pass the head page to split_huge_page, Unfortunately, the tail page
> can be free or count turn into zero.
I guess that you have the similar fix on memory_failure() in your mind:
commit c3901e722b2975666f42748340df798114742d6d
Author: Naoya Horiguchi
Date: Thu Nov 10 10:46:23 2016 -0800
mm: hwpoison: fix thp split handling in memory_failure()
So it seems that I somehow missed fixing soft offline when I wrote commit
c3901e722b29, and now you find and fix that. Thank you very much.
If you resend the patch with fixing typo, can you add some reference to
c3901e722b29 in the patch description to show the linkage?
And you can add the following tags:
Fixes: 61f5d698cc97 ("mm: re-enable THP")
Acked-by: Naoya Horiguchi
Thanks,
Naoya Horiguchi
Re: [PATCH 10/14] nios2: define syscall_get_arch()
On Wed, 2019-02-27 at 18:31 +0300, Dmitry V. Levin wrote:
> syscall_get_arch() is required to be implemented on all architectures
> in addition to already implemented syscall_get_nr(),
> syscall_get_arguments(), syscall_get_error(), and
> syscall_get_return_value() functions in order to extend the generic
> ptrace API with PTRACE_GET_SYSCALL_INFO request.
>
> Acked-by: Paul Moore
> Cc: Elvira Khabirova
> Cc: Eugene Syromyatnikov
> Cc: Ley Foon Tan
> Cc: Oleg Nesterov
> Cc: Andy Lutomirski
> Cc: nios2-...@lists.rocketboards.org
> Cc: linux-au...@redhat.com
> Signed-off-by: Dmitry V. Levin
Acked-by: Ley Foon Tan
Regards
Ley Foon
> ---
> This is just a gentle ping, the patch is unchanged.
>
> arch/nios2/include/asm/syscall.h | 6 ++
> include/uapi/linux/audit.h | 1 +
> 2 files changed, 7 insertions(+)
>
> diff --git a/arch/nios2/include/asm/syscall.h
> b/arch/nios2/include/asm/syscall.h
> index 9de220854c4a..cf35e210fc4d 100644
> --- a/arch/nios2/include/asm/syscall.h
> +++ b/arch/nios2/include/asm/syscall.h
> @@ -17,6 +17,7 @@
> #ifndef __ASM_NIOS2_SYSCALL_H__
> #define __ASM_NIOS2_SYSCALL_H__
>
> +#include
> #include
> #include
>
> @@ -135,4 +136,9 @@ static inline void syscall_set_arguments(struct
> task_struct *task,
> }
> }
>
> +static inline int syscall_get_arch(void)
> +{
> + return AUDIT_ARCH_NIOS2;
> +}
> +
> #endif
> diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> index 1568ddc1c945..efeb0bbd6c4d 100644
> --- a/include/uapi/linux/audit.h
> +++ b/include/uapi/linux/audit.h
> @@ -403,6 +403,7 @@ enum {
> __AUDIT_ARCH_CONVENTION_MIPS64_N32)
> #define AUDIT_ARCH_NDS32 (EM_NDS32|__AUDIT_ARCH_LE)
> #define AUDIT_ARCH_NDS32BE (EM_NDS32)
> +#define AUDIT_ARCH_NIOS2 (EM_ALTERA_NIOS2|__AUDIT_ARCH_LE)
> #define AUDIT_ARCH_OPENRISC(EM_OPENRISC)
> #define AUDIT_ARCH_PARISC (EM_PARISC)
> #define AUDIT_ARCH_PARISC64(EM_PARISC|__AUDIT_ARCH_64BIT)
> --
> ldv
>
>
>
> Confidentiality Notice.
> This message may contain information that is confidential or
> otherwise protected from disclosure. If you are not the intended
> recipient, you are hereby notified that any use, disclosure,
> dissemination, distribution, or copying of this message, or any
> attachments, is strictly prohibited. If you have received this
> message in error, please advise the sender by reply e-mail, and
> delete the message and any attachments. Thank you.
Re: [PATCH v2] mfd: cros_ec: instantiate properly CrOS ISH MCU device
On Fri, Mar 01, 2019 at 09:36:11AM +0530, Rushikesh S Kadam wrote: > Integrated Sensor Hub (ISH) is also a MCU running EC > having feature bit EC_FEATURE_ISH. Instantiate it as > a special CrOS EC device with device name 'cros_ish'. > v2 > - Addressed review comments to term the CrOS EC device as a generic > Integrated Sensor Hub. > + /* The MCU is an Intel Integrated Sensor Hub */ This has to be adjusted as well. Intel ISH is just one of the example of ISHs. > + EC_FEATURE_ISH = 40, -- With Best Regards, Andy Shevchenko
[PATCH v2] ARM: dts: imx6dl-yapp4: Use rgmii-id phy mode on the cpu port
Use rgmii-id phy mode for the CPU port (MAC0) of the QCA8334 switch
to add delays to both Tx and Rx clock.
It worked with the rgmii mode before because the qca8k driver
(incorrectly) enabled delays in that mode and rgmii-id was not
implemented at all.
Commit 5ecdd77c61c8 ("net: dsa: qca8k: disable delay for RGMII mode")
removed the delays from the RGMII mode and hence broke the networking.
To fix the problem, commit a968b5e9d587 ("net: dsa: qca8k: Enable delay
for RGMII_ID mode") was introduced.
Now the correct phy mode is available so use it.
Signed-off-by: Michal Vokáč
---
Changes in v2:
- Reworded commit message - added more details regarding the issue.
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
index b715ab0fa1ff..091d829f6b05 100644
--- a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
+++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
@@ -125,7 +125,7 @@
ethphy0: port@0 {
reg = <0>;
label = "cpu";
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
ethernet = <>;
fixed-link {
--
2.1.4
Re: [PATCH 2/2] mmc: sdhci-omap: Don't finish_mrq() on a command error during tuning
Hi Faiz, Thank you for the patch! Yet something to improve: [auto build test ERROR on ulf.hansson-mmc/next] [also build test ERROR on v5.0-rc8 next-20190228] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Faiz-Abbas/Fixes-for-command-errors-during-tuning/20190228-083200 base: git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 8.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=8.2.0 make.cross ARCH=ia64 All errors (new ones prefixed by >>): ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined! ERROR: "__sw_hweight8" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined! ERROR: "ia64_delay_loop" [drivers/net/phy/mdio-cavium.ko] undefined! >> ERROR: "sdhci_cmd_err" [drivers/mmc/host/sdhci-omap.ko] undefined! >> ERROR: "sdhci_finish_command" [drivers/mmc/host/sdhci-omap.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [RFC net-next 8/8] net/mlx5: Add subdev driver to bind to subdev devices
On Thu, Feb 28, 2019 at 11:37:52PM -0600, Parav Pandit wrote: > Add a subdev driver to probe the subdev devices and create fake > netdevice for it. So I'm guessing here is the "meat" of the whole goal here? You just want multiple netdevices per PCI device? Why can't you do that today in your PCI driver? What problem are you trying to solve that others also are having that requires all of this? Adding a new bus type and subsystem is fine, but usually we want more than just one user of it, as this does not really show how it is exercised very well. Ideally 3 users would be there as that is when it proves itself that it is flexible enough. Would just using the mfd subsystem work better for you? That provides core support for "multi-function" drivers/devices already. What is missing from that subsystem that does not work for you here? thanks, greg k-h
Re: [PATCH v4 4/9] staging:iio:ad7780: add chip ID values and mask
On Thu, 2019-02-28 at 11:24 -0300, Renato Lui Geh wrote: > > > The ad7780 supports both the ad778x and ad717x families. Each chip has > a corresponding ID. This patch provides a mask for extracting ID values > from the status bits and also macros for the correct values for the > ad7170, ad7171, ad7780 and ad7781. > > Signed-off-by: Renato Lui Geh > --- > drivers/staging/iio/adc/ad7780.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/iio/adc/ad7780.c > b/drivers/staging/iio/adc/ad7780.c > index 56c49e28f432..ad7617a3a141 100644 > --- a/drivers/staging/iio/adc/ad7780.c > +++ b/drivers/staging/iio/adc/ad7780.c > @@ -26,10 +26,14 @@ > #define AD7780_RDY BIT(7) > #define AD7780_FILTER BIT(6) > #define AD7780_ERR BIT(5) > -#define AD7780_ID1 BIT(4) > -#define AD7780_ID0 BIT(3) > #define AD7780_GAINBIT(2) > > +#define AD7170_ID 0 > +#define AD7171_ID 1 > +#define AD7780_ID 1 > +#define AD7781_ID 0 > + > +#define AD7780_ID_MASK (BIT(3) | BIT(4)) This also doesn't have any functionality change. The AD7170_ID, AD7171_ID, AD7780_ID & AD7781_ID IDs are also unused (maybe in a later patch they are ?). I would also leave the AD7780_ID1 & AD7780_ID0 definitions in place, since they're easier matched with the datasheet. > > #define AD7780_PATTERN_GOOD1 > #define AD7780_PATTERN_MASKGENMASK(1, 0) > -- > 2.21.0 >
Re: [RFC net-next 7/8] net/mlx5: Add devlink subdev life cycle command support
On Thu, Feb 28, 2019 at 11:37:51PM -0600, Parav Pandit wrote: > --- /dev/null > +++ b/drivers/net/ethernet/mellanox/mlx5/core/subdev.c > @@ -0,0 +1,55 @@ > +// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB For new stuff, just use GPL-2.0, no need to keep the mistake of the Linux-OpenIB license around :) thanks, greg k-h
Re: [PATCH v4 3/9] staging: iio: ad7780: set pattern values and masks directly
On Thu, 2019-02-28 at 11:24 -0300, Renato Lui Geh wrote:
>
>
> The AD7780 driver contains status pattern bits designed for checking
> whether serial transfers have been correctly performed. Pattern macros
> were previously generated through bit fields. This patch sets good
> pattern values directly and masks through GENMASK.
>
> Signed-off-by: Renato Lui Geh
> ---
> drivers/staging/iio/adc/ad7780.c | 20 +---
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index 7a68e90ddf14..56c49e28f432 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -28,16 +29,13 @@
> #define AD7780_ID1 BIT(4)
> #define AD7780_ID0 BIT(3)
> #define AD7780_GAINBIT(2)
> -#define AD7780_PAT1BIT(1)
> -#define AD7780_PAT0BIT(0)
I don't see a problem to leave the bitfields; they can be read & matched
easier with the datasheet.
>
> -#define AD7780_PATTERN (AD7780_PAT0)
> -#define AD7780_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1)
>
> -#define AD7170_PAT2BIT(2)
> +#define AD7780_PATTERN_GOOD1
It was also nice before that the PAT0..PAT2 bitfields were used to define a
good pattern, since it's easier to match with the datasheet.
> +#define AD7780_PATTERN_MASKGENMASK(1, 0)
I like the general usage of GENMASK, but I'm not sure in this case it's
worth doing. Maybe I missed a discussion somewhere, about doing this
change, but it is mostly a cosmetic without any functional change.
>
> -#define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
> -#define AD7170_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2)
> +#define AD7170_PATTERN_GOOD5
> +#define AD7170_PATTERN_MASKGENMASK(2, 0)
>
> #define AD7780_GAIN_MIDPOINT 64
> #define AD7780_FILTER_MIDPOINT 13350
> @@ -209,25 +207,25 @@ static const struct ad_sigma_delta_info
> ad7780_sigma_delta_info = {
> static const struct ad7780_chip_info ad7780_chip_info_tbl[] = {
> [ID_AD7170] = {
> .channel = AD7170_CHANNEL(12, 24),
> - .pattern = AD7170_PATTERN,
> + .pattern = AD7170_PATTERN_GOOD,
> .pattern_mask = AD7170_PATTERN_MASK,
> .is_ad778x = false,
> },
> [ID_AD7171] = {
> .channel = AD7170_CHANNEL(16, 24),
> - .pattern = AD7170_PATTERN,
> + .pattern = AD7170_PATTERN_GOOD,
> .pattern_mask = AD7170_PATTERN_MASK,
> .is_ad778x = false,
> },
> [ID_AD7780] = {
> .channel = AD7780_CHANNEL(24, 32),
> - .pattern = AD7780_PATTERN,
> + .pattern = AD7780_PATTERN_GOOD,
> .pattern_mask = AD7780_PATTERN_MASK,
> .is_ad778x = true,
> },
> [ID_AD7781] = {
> .channel = AD7780_CHANNEL(20, 32),
> - .pattern = AD7780_PATTERN,
> + .pattern = AD7780_PATTERN_GOOD,
> .pattern_mask = AD7780_PATTERN_MASK,
> .is_ad778x = true,
> },
> --
> 2.21.0
>
Re: [RFC net-next 1/8] subdev: Introducing subdev bus
On Thu, Feb 28, 2019 at 11:37:45PM -0600, Parav Pandit wrote: > Introduce a new subdev bus which holds sub devices created from a > primary device. These devices are named as 'subdev'. > A subdev is identified similarly to pci device using 16-bit vendor id > and device id. > Unlike PCI devices, scope of subdev is limited to Linux kernel. But these are limited to only PCI devices, right? This sounds a lot like that ARM proposal a week or so ago that asked for something like this, are you working with them to make sure your proposal works for them as well? (sorry, can't find where that was announced, it was online somewhere...) > A central entry that assigns unique subdev vendor and device id is: > include/linux/subdev_ids.h enums. Enum are chosen over define macro so > that two vendors do not end up with vendor id in kernel development > process. Why not just make it dynamic with on static ids? > subdev bus holds subdevices of multiple devices. A typical created > subdev for a PCI device in sysfs tree appears under their parent's > device as using core's default device naming scheme: > > subdev. > i.e. > subdev0 > subdev1 > > $ ls -l /sys/bus/pci/devices/:05:00.0 > [..] > drwxr-xr-x 4 root root0 Feb 13 15:57 subvdev0 > drwxr-xr-x 4 root root0 Feb 13 15:57 subvdev1 > > Device model view: > -- >+--++--+ +--+ >|subdev||subdev| |subdev| > -| 1 || 2 |---| 3 |-- > |+--|---++-|+ +--|---+ | > |--|---subdev bus--|-- > | | | >+--++-+ +---+---+ >|pcidev | |pcidev | > -| A |-| B |-- > |+---+ +---+ | > ---pci bus To be clear, "subdev bus" is just a logical grouping, there is no physical backing "bus" here at all, right? What is going to "bind" to subdev devices? PCI drivers? Or new types of drivers? > subdev are allocated and freed using subdev_alloc(), subdev_free() APIs. > A driver which wants to create actual class driver such as > net/block/infiniband need to use subdev_register_driver(), > subdev_unregister_driver() APIs. > > Signed-off-by: Parav Pandit > --- > drivers/Kconfig | 2 + > drivers/Makefile| 1 + > drivers/subdev/Kconfig | 12 > drivers/subdev/Makefile | 8 +++ > drivers/subdev/subdev_main.c| 153 > > include/linux/mod_devicetable.h | 12 > include/linux/subdev_bus.h | 63 + > include/linux/subdev_ids.h | 17 + > 8 files changed, 268 insertions(+) > create mode 100644 drivers/subdev/Kconfig > create mode 100644 drivers/subdev/Makefile > create mode 100644 drivers/subdev/subdev_main.c > create mode 100644 include/linux/subdev_bus.h > create mode 100644 include/linux/subdev_ids.h > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index 4f9f990..1818796 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -228,4 +228,6 @@ source "drivers/siox/Kconfig" > > source "drivers/slimbus/Kconfig" > > +source "drivers/subdev/Kconfig" > + > endmenu > diff --git a/drivers/Makefile b/drivers/Makefile > index e1ce029..a040e96 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -186,3 +186,4 @@ obj-$(CONFIG_MULTIPLEXER) += mux/ > obj-$(CONFIG_UNISYS_VISORBUS)+= visorbus/ > obj-$(CONFIG_SIOX) += siox/ > obj-$(CONFIG_GNSS) += gnss/ > +obj-$(CONFIG_SUBDEV) += subdev/ > diff --git a/drivers/subdev/Kconfig b/drivers/subdev/Kconfig > new file mode 100644 > index 000..8ce3acc > --- /dev/null > +++ b/drivers/subdev/Kconfig > @@ -0,0 +1,12 @@ > +# > +# subdev configuration > +# > + > +config SUBDEV > + tristate "subdev bus driver" > + help > + The subdev bus driver allows creating hardware based sub devices > + from a parent device. The subdev bus driver is required to create, > + discover devices and to attach device drivers to this subdev > + devices. These subdev devices are created using devlink tool by > + user. Your definition of the bus uses the name of the bus in the definition :) > diff --git a/drivers/subdev/Makefile b/drivers/subdev/Makefile > new file mode 100644 > index 000..405b74a > --- /dev/null > +++ b/drivers/subdev/Makefile > @@ -0,0 +1,8 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Makefile for subdev bus driver > +# > + > +obj-$(CONFIG_SUBDEV) += subdev.o > + > +subdev-y := subdev_main.o > diff --git a/drivers/subdev/subdev_main.c b/drivers/subdev/subdev_main.c > new file mode 100644 > index 000..4aabcaa > --- /dev/null > +++ b/drivers/subdev/subdev_main.c > @@ -0,0 +1,153 @@ >
RE: [PATCH] kbuild: [bin]deb-pkg: add DPKG_FLAGS variable
> -Original Message-
> From: Kacper Kołodziej [mailto:kac...@kolodziej.it]
> Sent: Tuesday, February 05, 2019 9:38 PM
> To: Yamada, Masahiro/山田 真弘 ;
> michal.l...@markovi.net
> Cc: linux-kbu...@vger.kernel.org; linux-kernel@vger.kernel.org;
> kac...@kolodziej.it
> Subject: [PATCH] kbuild: [bin]deb-pkg: add DPKG_FLAGS variable
>
> DPKG_FLAGS variable lets user to add more flags to dpkg-buildpackage
> command in deb-pkg and bindeb-pkg.
>
> Signed-off-by: Kacper Kołodziej
> ---
Applied to linux-kbuild.
Thanks.
> scripts/package/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/package/Makefile b/scripts/package/Makefile
> index 453fecee62f0..6963eacb323c 100644
> --- a/scripts/package/Makefile
> +++ b/scripts/package/Makefile
> @@ -72,11 +72,11 @@ deb-pkg: FORCE
> $(call cmd,src_tar,$(KDEB_SOURCENAME))
> origversion=$$(dpkg-parsechangelog -SVersion |sed
> 's/-[^-]*$$//');\
> mv
> $(KDEB_SOURCENAME).tar.gz ../$(KDEB_SOURCENAME)_$${origversion}.orig.t
> ar.gz
> - +dpkg-buildpackage -r$(KBUILD_PKG_ROOTCMD) -a$$(cat debian/arch)
> -i.git -us -uc
> + +dpkg-buildpackage -r$(KBUILD_PKG_ROOTCMD) -a$$(cat debian/arch)
> $(DPKG_FLAGS) -i.git -us -uc
>
> bindeb-pkg: FORCE
> $(CONFIG_SHELL) $(srctree)/scripts/package/mkdebian
> - +dpkg-buildpackage -r$(KBUILD_PKG_ROOTCMD) -a$$(cat debian/arch)
> -b -nc -uc
> + +dpkg-buildpackage -r$(KBUILD_PKG_ROOTCMD) -a$$(cat debian/arch)
> $(DPKG_FLAGS) -b -nc -uc
>
> intdeb-pkg: FORCE
> +$(CONFIG_SHELL) $(srctree)/scripts/package/builddeb
> --
> 2.20.1
[PATCH 3/3] kbuild: clean up scripts/gcc-version.sh
Now that the Kconfig is the only user of this script, we can drop
unneeded code.
Remove the -p option, and stop prepending the output with zero,
so that Kconfig can directly use the output from this script.
Signed-off-by: Masahiro Yamada
---
init/Kconfig| 2 +-
scripts/Kconfig.include | 2 +-
scripts/gcc-version.sh | 27 +++
3 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 1f05a88..74a0217 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -13,7 +13,7 @@ config CC_IS_GCC
config GCC_VERSION
int
- default $(shell,$(srctree)/scripts/gcc-version.sh -p $(CC) | sed
's/^0*//') if CC_IS_GCC
+ default $(shell,$(srctree)/scripts/gcc-version.sh $(CC)) if CC_IS_GCC
default 0
config CC_IS_CLANG
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index dad5583..87ff1dc 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -27,4 +27,4 @@ cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o
/dev/null)
ld-option = $(success,$(LD) -v $(1))
# gcc version including patch level
-gcc-version := $(shell,$(srctree)/scripts/gcc-version.sh -p $(CC) | sed
's/^0*//')
+gcc-version := $(shell,$(srctree)/scripts/gcc-version.sh $(CC))
diff --git a/scripts/gcc-version.sh b/scripts/gcc-version.sh
index 11bb909..ae35343 100755
--- a/scripts/gcc-version.sh
+++ b/scripts/gcc-version.sh
@@ -1,33 +1,20 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
#
-# gcc-version [-p] gcc-command
-#
-# Prints the gcc version of `gcc-command' in a canonical 4-digit form
-# such as `0295' for gcc-2.95, `0303' for gcc-3.3, etc.
-#
-# With the -p option, prints the patchlevel as well, for example `029503' for
-# gcc-2.95.3, `030301' for gcc-3.3.1, etc.
+# gcc-version gcc-command
#
-
-if [ "$1" = "-p" ] ; then
- with_patchlevel=1;
- shift;
-fi
+# Print the gcc version of `gcc-command' in a 5 or 6-digit form
+# such as `29503' for gcc-2.95.3, `30301' for gcc-3.3.1, etc.
compiler="$*"
if [ ${#compiler} -eq 0 ]; then
- echo "Error: No compiler specified."
- printf "Usage:\n\t$0 \n"
+ echo "Error: No compiler specified." >&2
+ printf "Usage:\n\t$0 \n" >&2
exit 1
fi
MAJOR=$(echo __GNUC__ | $compiler -E -x c - | tail -n 1)
MINOR=$(echo __GNUC_MINOR__ | $compiler -E -x c - | tail -n 1)
-if [ "x$with_patchlevel" != "x" ] ; then
- PATCHLEVEL=$(echo __GNUC_PATCHLEVEL__ | $compiler -E -x c - | tail -n 1)
- printf "%02d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
-else
- printf "%02d%02d\\n" $MAJOR $MINOR
-fi
+PATCHLEVEL=$(echo __GNUC_PATCHLEVEL__ | $compiler -E -x c - | tail -n 1)
+printf "%d%02d%02d\\n" $MAJOR $MINOR $PATCHLEVEL
--
2.7.4
Re: [PATCH v5 03/10] arm64: add sysfs vulnerability show for meltdown
Hi,
On 2/26/19 7:05 PM, Jeremy Linton wrote:
Display the mitigation status if active, otherwise
assume the cpu is safe unless it doesn't have CSV3
and isn't in our whitelist.
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/cpufeature.c | 47 ++
1 file changed, 37 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index f6d84e2c92fe..d31bd770acba 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -944,7 +944,7 @@ has_useable_cnp(const struct arm64_cpu_capabilities *entry,
int scope)
return has_cpuid_feature(entry, scope);
}
-#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+static bool __meltdown_safe = true;
static int __kpti_forced; /* 0: not forced, >0: forced on, <0: forced off */
static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities *entry,
@@ -963,6 +963,16 @@ static bool unmap_kernel_at_el0(const struct
arm64_cpu_capabilities *entry,
{ /* sentinel */ }
};
char const *str = "command line option";
+ bool meltdown_safe;
+
+ meltdown_safe = is_midr_in_range_list(read_cpuid_id(), kpti_safe_list);
+
+ /* Defer to CPU feature registers */
+ if (has_cpuid_feature(entry, scope))
+ meltdown_safe = true;
+
+ if (!meltdown_safe)
+ __meltdown_safe = false;
/*
* For reasons that aren't entirely clear, enabling KPTI on Cavium
@@ -974,6 +984,11 @@ static bool unmap_kernel_at_el0(const struct
arm64_cpu_capabilities *entry,
__kpti_forced = -1;
}
+ if (!IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0)) {
+ pr_info_once("kernel page table isolation disabled by
CONFIG\n");
+ return false;
+ }
+
/* Forced? */
if (__kpti_forced) {
pr_info_once("kernel page table isolation forced %s by %s\n",
@@ -985,14 +1000,10 @@ static bool unmap_kernel_at_el0(const struct
arm64_cpu_capabilities *entry,
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
return kaslr_offset() > 0;
- /* Don't force KPTI for CPUs that are not vulnerable */
- if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
- return false;
-
- /* Defer to CPU feature registers */
- return !has_cpuid_feature(entry, scope);
+ return !meltdown_safe;
}
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
static void
kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
{
@@ -1022,6 +1033,13 @@ kpti_install_ng_mappings(const struct
arm64_cpu_capabilities *__unused)
return;
}
+#else
+static void
+kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
+{
+}
+#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
+
static int __init parse_kpti(char *str)
{
@@ -1035,7 +1053,6 @@ static int __init parse_kpti(char *str)
return 0;
}
early_param("kpti", parse_kpti);
-#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
#ifdef CONFIG_ARM64_HW_AFDBM
static inline void __cpu_enable_hw_dbm(void)
@@ -1286,7 +1303,6 @@ static const struct arm64_cpu_capabilities
arm64_features[] = {
.field_pos = ID_AA64PFR0_EL0_SHIFT,
.min_field_value = ID_AA64PFR0_EL0_32BIT_64BIT,
},
-#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
{
.desc = "Kernel page table isolation (KPTI)",
.capability = ARM64_UNMAP_KERNEL_AT_EL0,
@@ -1302,7 +1318,6 @@ static const struct arm64_cpu_capabilities
arm64_features[] = {
.matches = unmap_kernel_at_el0,
.cpu_enable = kpti_install_ng_mappings,
},
-#endif
{
/* FP/SIMD is not implemented */
.capability = ARM64_HAS_NO_FPSIMD,
@@ -2063,3 +2078,15 @@ static int __init enable_mrs_emulation(void)
}
core_initcall(enable_mrs_emulation);
+
+ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ if (arm64_kernel_unmapped_at_el0())
+ return sprintf(buf, "Mitigation: KPTI\n");
+
+ if (__meltdown_safe)
+ return sprintf(buf, "Not affected\n");
Shall those two checks be swapped? So it doesn't report about a KPTI
mitigation if the CPU is safe, but we enable KPTI because of KASLR
having enabled it? Or is that a different knob?
Cheers,
Andre.
+
+ return sprintf(buf, "Vulnerable\n");
+}
[PATCH 2/3] kbuild: remove cc-version macro
There is no more direct user of this macro; it is only used by cc-ifversion. Calling this macro is not efficient since it invokes the compiler to get the compiler version. CONFIG_GCC_VERSION is already calculated in the Kconfig stage, so Makefile can reuse it. Here is a note about the slight difference between cc-version and CONFIG_GCC_VERSION: When using Clang, cc-version is evaluated to '0402' because Clang defines __GNUC__ and __GNUC__MINOR__, and looks like GCC 4.2 in the version point of view. On the other hand, CONFIG_GCC_VERSION=0 when $(CC) is clang. There are currently two users of cc-ifversion: arch/mips/loongson64/Platform arch/powerpc/Makefile They are not affected by this change. The format of cc-version is , while CONFIG_GCC_VERSION . I adjusted cc-ifversion for the difference of the number of digits. Signed-off-by: Masahiro Yamada --- Documentation/kbuild/makefiles.txt | 17 - scripts/Kbuild.include | 5 + 2 files changed, 1 insertion(+), 21 deletions(-) diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 48eab0b..f124be6 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -499,23 +499,6 @@ more details, with real examples. In the above example, -Wno-unused-but-set-variable will be added to KBUILD_CFLAGS only if gcc really accepts it. -cc-version - cc-version returns a numerical version of the $(CC) compiler version. - The format is where both are two digits. So for example - gcc 3.41 would return 0341. - cc-version is useful when a specific $(CC) version is faulty in one - area, for example -mregparm=3 was broken in some gcc versions - even though the option was accepted by gcc. - - Example: - #arch/x86/Makefile - cflags-y += $(shell \ - if [ $(cc-version) -ge 0300 ] ; then \ - echo "-mregparm=3"; fi ;) - - In the above example, -mregparm=3 is only used for gcc version greater - than or equal to gcc 3.0. - cc-ifversion cc-ifversion tests the version of $(CC) and equals the fourth parameter if version expression is true, or the fifth (if given) if the version diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include index d93250b..b59983e 100644 --- a/scripts/Kbuild.include +++ b/scripts/Kbuild.include @@ -138,12 +138,9 @@ cc-option-yn = $(call try-run,\ cc-disable-warning = $(call try-run,\ $(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -W$(strip $(1)) -c -x c /dev/null -o "$$TMP",-Wno-$(strip $(1))) -# cc-version -cc-version = $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC)) - # cc-ifversion # Usage: EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1) -cc-ifversion = $(shell [ $(cc-version) $(1) $(2) ] && echo $(3) || echo $(4)) +cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && echo $(3) || echo $(4)) # cc-ldoption # Usage: ldflags += $(call cc-ldoption, -Wl$(comma)--hash-style=both) -- 2.7.4
[PATCH 1/3] kbuild: update comment block of scripts/clang-version.sh
Commit 469cb7376c06 ("kconfig: add CC_IS_CLANG and CLANG_VERSION")
changed the code, but missed to update the comment block.
The -p option was gone, and the output is 5-digit (or 6-digit when
Clang 10 is released).
Update the comment now.
Signed-off-by: Masahiro Yamada
---
scripts/clang-version.sh | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/scripts/clang-version.sh b/scripts/clang-version.sh
index e65fbc3..6fabf06 100755
--- a/scripts/clang-version.sh
+++ b/scripts/clang-version.sh
@@ -1,14 +1,10 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
#
-# clang-version [-p] clang-command
-#
-# Prints the compiler version of `clang-command' in a canonical 4-digit form
-# such as `0500' for clang-5.0 etc.
-#
-# With the -p option, prints the patchlevel as well, for example `050001' for
-# clang-5.0.1 etc.
+# clang-version clang-command
#
+# Print the compiler version of `clang-command' in a 5 or 6-digit form
+# such as `50001' for clang-5.0.1 etc.
compiler="$*"
--
2.7.4
Re: [PATCH] perf c2c: Fix c2c report for empty numa node
On 2/28/19 9:52 PM, Jiri Olsa wrote:
> how about attached change (untested)?
LGTM. Would you mind sending a patch.
>
> but I wonder there are some other hidden
> bugs wrt empty node
>
> jirka
>
>
> ---
> diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
> index 4272763a5e96..9e6cc868bdb4 100644
> --- a/tools/perf/builtin-c2c.c
> +++ b/tools/perf/builtin-c2c.c
> @@ -2056,6 +2056,12 @@ static int setup_nodes(struct perf_session *session)
> if (!set)
> return -ENOMEM;
>
> + nodes[node] = set;
> +
> + /* empty node, skip */
> + if (cpu_map__empty(map))
> + continue;
> +
> for (cpu = 0; cpu < map->nr; cpu++) {
> set_bit(map->map[cpu], set);
>
> @@ -2064,8 +2070,6 @@ static int setup_nodes(struct perf_session *session)
>
> cpu2node[map->map[cpu]] = node;
> }
> -
> - nodes[node] = set;
> }
>
> setup_nodes_header();
>
Re: [PATCH] mfd: twl-core: disable irq while suspended
Hi,
On Sat, 23 Feb 2019 10:23:23 -0800
Tony Lindgren wrote:
> * Andreas Kemnade [190223 11:48]:
> > Since commit
> > 6e2bd956936 ("i2c: omap: Use noirq system sleep pm ops to idle device for
> > suspend")
> > on gta04 we have handle_twl4030_pih() called in situations where
> > pm_runtime_get()
> > in i2c-omap.c returns -EACCES.
> > [ 86.474365] Freezing remaining freezable tasks ... (elapsed 0.002
> > seconds) done.
> > [ 86.485473] printk: Suspending console(s) (use no_console_suspend to
> > debug)
> > [ 86.72] Disabling non-boot CPUs ...
> > [ 86.555664] Successfully put all powerdomains to target state
> > [ 86.563720] twl: Read failed (mod 1, reg 0x01 count 1)
> > [ 86.563751] twl4030: I2C error -13 reading PIH ISR
> > [ 86.563812] twl: Read failed (mod 1, reg 0x01 count 1)
> > [ 86.563812] twl4030: I2C error -13 reading PIH ISR
> > [ 86.563873] twl: Read failed (mod 1, reg 0x01 count 1)
> > [ 86.563903] twl4030: I2C error -13 reading PIH ISR
> >
> > This happens when we wakeup via something behing twl4030
> > (powerbutton or rtc alarm).
> > This goes on for minutes until the system is finally resumed.
> > Disable the irq on suspend and enable it on resume to avoid
> > having i2c access problems when the irq registers are checked.
>
> Thanks for fixing this, still works fine for me for rtcwake:
>
> Tested-by: Tony Lindgren
>
hmm, in which version we will see this regression fixed?
I consider this whole thing as a reminder to finally
improve my automated test facilities and finally add the suspend/power
consumption test scripts I have to it so I can catch such things earlier.
Regards,
Andreas
pgp6s9ib6PNT9.pgp
Description: OpenPGP digital signature
[PATCH v5 3/3] PCI: hv: Refactor hv_irq_unmask() to use cpumask_to_vpset()
Remove the duplicate implementation of cpumask_to_vpset() and use the
shared implementation. Export hv_max_vp_index, which is required by
cpumask_to_vpset().
Signed-off-by: Maya Nakamura
Reviewed-by: Michael Kelley
Reviewed-by: Vitaly Kuznetsov
Tested-by: Vitaly Kuznetsov
---
Changes in v5:
- Revise the commit message to clarify the changes based on feedback.
- Add the Reviewed-by and Tested-by tags.
Changes in v4:
- Replace GFP_KERNEL with GFP_ATOMIC for alloc_cpumask_var().
- Update the commit message.
Changes in v3:
- Modify to catch all failures from cpumask_to_vpset().
- Correct the v2 change log about the commit message.
Changes in v2:
- Remove unnecessary nr_bank initialization.
- Delete two unnecessary dev_err()'s.
- Unlock before returning.
- Update the commit message.
arch/x86/hyperv/hv_init.c | 1 +
drivers/pci/controller/pci-hyperv.c | 38 +
2 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 7abb09e2eeb8..7f2eed1fc81b 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -96,6 +96,7 @@ void __percpu **hyperv_pcpu_input_arg;
EXPORT_SYMBOL_GPL(hyperv_pcpu_input_arg);
u32 hv_max_vp_index;
+EXPORT_SYMBOL_GPL(hv_max_vp_index);
static int hv_cpu_init(unsigned int cpu)
{
diff --git a/drivers/pci/controller/pci-hyperv.c
b/drivers/pci/controller/pci-hyperv.c
index d71695db1ba0..95441a35eceb 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -391,8 +391,6 @@ struct hv_interrupt_entry {
u32 data;
};
-#define HV_VP_SET_BANK_COUNT_MAX 5 /* current implementation limit */
-
/*
* flags for hv_device_interrupt_target.flags
*/
@@ -908,12 +906,12 @@ static void hv_irq_unmask(struct irq_data *data)
struct retarget_msi_interrupt *params;
struct hv_pcibus_device *hbus;
struct cpumask *dest;
+ cpumask_var_t tmp;
struct pci_bus *pbus;
struct pci_dev *pdev;
unsigned long flags;
u32 var_size = 0;
- int cpu_vmbus;
- int cpu;
+ int cpu, nr_bank;
u64 res;
dest = irq_data_get_effective_affinity_mask(data);
@@ -953,29 +951,27 @@ static void hv_irq_unmask(struct irq_data *data)
*/
params->int_target.flags |=
HV_DEVICE_INTERRUPT_TARGET_PROCESSOR_SET;
- params->int_target.vp_set.valid_bank_mask =
- (1ull << HV_VP_SET_BANK_COUNT_MAX) - 1;
+
+ if (!alloc_cpumask_var(, GFP_ATOMIC)) {
+ res = 1;
+ goto exit_unlock;
+ }
+
+ cpumask_and(tmp, dest, cpu_online_mask);
+ nr_bank = cpumask_to_vpset(>int_target.vp_set, tmp);
+ free_cpumask_var(tmp);
+
+ if (nr_bank <= 0) {
+ res = 1;
+ goto exit_unlock;
+ }
/*
* var-sized hypercall, var-size starts after vp_mask (thus
* vp_set.format does not count, but vp_set.valid_bank_mask
* does).
*/
- var_size = 1 + HV_VP_SET_BANK_COUNT_MAX;
-
- for_each_cpu_and(cpu, dest, cpu_online_mask) {
- cpu_vmbus = hv_cpu_number_to_vp_number(cpu);
-
- if (cpu_vmbus >= HV_VP_SET_BANK_COUNT_MAX * 64) {
- dev_err(>hdev->device,
- "too high CPU %d", cpu_vmbus);
- res = 1;
- goto exit_unlock;
- }
-
- params->int_target.vp_set.bank_contents[cpu_vmbus / 64]
|=
- (1ULL << (cpu_vmbus & 63));
- }
+ var_size = 1 + nr_bank;
} else {
for_each_cpu_and(cpu, dest, cpu_online_mask) {
params->int_target.vp_mask |=
--
2.17.1
Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel
Hi Joel, On Thu, 28 Feb 2019 22:26:11 -0500 Joel Fernandes wrote: > On Fri, Mar 01, 2019 at 11:28:26AM +0900, Masami Hiramatsu wrote: > > Hi Joel, > > Hi Masami, > > > On Thu, 28 Feb 2019 10:00:54 -0500 > > Joel Fernandes wrote: > > > > > > Hmm, isn't it easier to add kernel-headers package on Android? > > > > > > I have already been down that road. In the Android ecosystem, the Android > > > teams only provide a "userspace system image" which goes on the system > > > partition of the flash (and a couple other images are also provided but > > > system is the main one). The system image cannot contain GPL source code. > > > It > > > is also not possible to put kernel headers for every kernel version on the > > > system images that ship and is not practical. Android boots on 1000s of > > > forked > > > kernels. It does not make sense to provide headers on the system image for > > > every kernel version and I already had many discussions on the subject > > > with > > > the teams, it is something that is just not done. Now for kernel modules, > > > there's another image called the "vendor image" which is flashed onto the > > > vendor parition, this is where kernel modules go. This vendor image is > > > not > > > provided by Google for non-Pixel devices. So we have no control over what > > > goes there BUT we do know that kernel modules that are enabled will go > > > there, > > > and we do have control over enforcing that certain kernel modules should > > > be > > > built and available as they are mandatory for Android to function > > > properly. > > > We would also possibly make it a built-in option as well. Anyway my point > > > is > > > keeping it in the kernel is really the easiest and the smartest choice > > > IMO. > > > > Sorry, I'm not convinced yet. This sounds like "because Android decided not > > to put the header files on vendor partition, but kernel module is OK" > > Why don't google ask vendors to put their kernel headers (or header tarball) > > on vendor partition instead? > > May be Google can do that, but I think you missed the point of the patches. > Making it a module is not mandatory, people can build it into the kernel as > well (CONFIG_IKHEADERS_PROC=y). In this case, the proc entry will be > available on boot without any dependency on the filesystem. If you go through > the other threads such as folks from ARM who replied, they just boot a kernel > image for debug purpose and want headers on device available without any > additional step of copying headers to the filesystem. And folks from Google > also said that they wanted a built-in option. Agreed. Making it built-in is reasonable, since it will not involves any other files. :) > There are many usecases for this, I have often run into issues with Linux > over the years not only with Android, but other distros, where I boot custom > kernels with no linux-headers package. This is quite painful. It is > convenient to have it as /proc file since the file is dependent on kernel > being booted up and this will work across all Linux distros and systems. I > feel that if you can keep an open mind about it, you will see that a lot of > people will use this feature if it is accepted and there is a lot of positive > feedback in earlier posts of this set. I don't complain about having headers for custom boot kernel. I agree with you that having kernel headers for debugging is always good. :) So google recommends built-in, it is reasonable. > > > > > The code to read the headers is based on /proc/config.gz code and uses > > > > > the same technique to embed the headers. > > > > > > > > > > To build a module, the below steps have been tested on an x86 machine: > > > > > modprobe kheaders > > > > > rm -rf $HOME/headers > > > > > mkdir -p $HOME/headers > > > > > tar -xvf /proc/kheaders.tar.xz -C $HOME/headers >/dev/null > > > > > cd my-kernel-module > > > > > make -C $HOME/headers M=$(pwd) modules > > > > > rmmod kheaders > > > > > > > > It seems a bit complex, but no difference from compared with carrying > > > > kheaders.tar.gz. I think we would better have a psudo filesystem > > > > which can mount this compressed header file directly :) Then it becomes > > > > simpler, like > > > > > > > > modprobe headerfs > > > > mkdir $HOME/headers > > > > mount -t headerfs $HOME/headers > > > > > > > > And this doesn't consume any disk-space. > > > > > > I felt using a compressed tar is really the easiest way because of all the > > > tools are already available. > > > > As I asked above, if the pure tarball is useful, you can simply ask vendors > > to put the header tarball on their vendor directory. I feel making it as > > a module is not a right way. > > I don't see what is the drawback of making it a module, it makes it well > integrated into kernel build and ecosystem. I also didn't see any > justification you're providing about why it cannot be a module. If you go > through this and earlier threads, a lot of people are Ok
Re: [PATCH v5 10/10] arm64: enable generic CPU vulnerabilites support
Hi, On 2/26/19 7:05 PM, Jeremy Linton wrote: From: Mian Yousaf Kaukab Enable CPU vulnerabilty show functions for spectre_v1, spectre_v2, meltdown and store-bypass. Signed-off-by: Mian Yousaf Kaukab Signed-off-by: Jeremy Linton Reviewed-by: Andre Przywara Thanks, Andre. --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index a4168d366127..be9872ee1d61 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -88,6 +88,7 @@ config ARM64 select GENERIC_CLOCKEVENTS select GENERIC_CLOCKEVENTS_BROADCAST select GENERIC_CPU_AUTOPROBE + select GENERIC_CPU_VULNERABILITIES select GENERIC_EARLY_IOREMAP select GENERIC_IDLE_POLL_SETUP select GENERIC_IRQ_MULTI_HANDLER
Re: [PATCH v5 09/10] arm64: add sysfs vulnerability show for speculative store bypass
Hi,
On 2/26/19 7:05 PM, Jeremy Linton wrote:
Return status based on ssbd_state and the arm64 SSBS feature. If
the mitigation is disabled, or the firmware isn't responding then
return the expected machine state based on a new blacklist of known
vulnerable cores.
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/cpu_errata.c | 43 ++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 5f5611d17dc1..e1b03f643799 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -279,6 +279,7 @@ static int detect_harden_bp_fw(void)
DEFINE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required);
int ssbd_state __read_mostly = ARM64_SSBD_KERNEL;
+static bool __ssb_safe = true;
static const struct ssbd_options {
const char *str;
@@ -387,6 +388,9 @@ static bool has_ssbd_mitigation(const struct
arm64_cpu_capabilities *entry,
WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
+ if (is_midr_in_range_list(read_cpuid_id(), entry->midr_range_list))
+ __ssb_safe = false;
Is that the only place where we set it to false?
What about if firmware reports that (at least one core) is vulnerable?
+
if (this_cpu_has_cap(ARM64_SSBS)) {
required = false;
goto out_printmsg;
@@ -420,6 +424,7 @@ static bool has_ssbd_mitigation(const struct
arm64_cpu_capabilities *entry,
ssbd_state = ARM64_SSBD_UNKNOWN;
return false;
+ /* machines with mixed mitigation requirements must not return this */
case SMCCC_RET_NOT_REQUIRED:
pr_info_once("%s mitigation not required\n", entry->desc);
ssbd_state = ARM64_SSBD_MITIGATED;
@@ -475,6 +480,16 @@ static bool has_ssbd_mitigation(const struct
arm64_cpu_capabilities *entry,
return required;
}
+/* known vulnerable cores */
+static const struct midr_range arm64_ssb_cpus[] = {
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_A76),
+ {},
+};
+
static void __maybe_unused
cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused)
{
@@ -770,6 +785,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
.capability = ARM64_SSBD,
.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
.matches = has_ssbd_mitigation,
+ .midr_range_list = arm64_ssb_cpus,
},
#ifdef CONFIG_ARM64_ERRATUM_1188873
{
@@ -808,3 +824,30 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct
device_attribute *attr,
return sprintf(buf, "Vulnerable\n");
}
+
+ssize_t cpu_show_spec_store_bypass(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ /*
+* Two assumptions: First, ssbd_state reflects the worse case
+* for hetrogenous machines, and that if SSBS is supported its
heterogeneous
Cheers,
Andre.
+* supported by all cores.
+*/
+ switch (ssbd_state) {
+ case ARM64_SSBD_MITIGATED:
+ return sprintf(buf, "Not affected\n");
+
+ case ARM64_SSBD_KERNEL:
+ case ARM64_SSBD_FORCE_ENABLE:
+ if (cpus_have_cap(ARM64_SSBS))
+ return sprintf(buf, "Not affected\n");
+ if (IS_ENABLED(CONFIG_ARM64_SSBD))
+ return sprintf(buf,
+ "Mitigation: Speculative Store Bypass disabled\n");
+ }
+
+ if (__ssb_safe)
+ return sprintf(buf, "Not affected\n");
+
+ return sprintf(buf, "Vulnerable\n");
+}
Re: [PATCH v5 08/10] arm64: Always enable ssb vulnerability detection
Hi,
On 2/26/19 7:05 PM, Jeremy Linton wrote:
The ssb detection logic is necessary regardless of whether
the vulnerability mitigation code is built into the kernel.
Break it out so that the CONFIG option only controls the
mitigation logic and not the vulnerability detection.
Signed-off-by: Jeremy Linton
---
arch/arm64/include/asm/cpufeature.h | 4
arch/arm64/kernel/cpu_errata.c | 11 +++
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index dfcfba725d72..c2b60a021437 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -628,11 +628,7 @@ static inline int arm64_get_ssbd_state(void)
#endif
}
-#ifdef CONFIG_ARM64_SSBD
void arm64_set_ssbd_mitigation(bool state);
-#else
-static inline void arm64_set_ssbd_mitigation(bool state) {}
-#endif
extern int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 0f6e8f5d67bc..5f5611d17dc1 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -276,7 +276,6 @@ static int detect_harden_bp_fw(void)
return 1;
}
-#ifdef CONFIG_ARM64_SSBD
DEFINE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required);
int ssbd_state __read_mostly = ARM64_SSBD_KERNEL;
@@ -347,6 +346,7 @@ void __init arm64_enable_wa2_handling(struct alt_instr *alt,
*updptr = cpu_to_le32(aarch64_insn_gen_nop());
}
+#ifdef CONFIG_ARM64_SSBD
void arm64_set_ssbd_mitigation(bool state)
{
if (this_cpu_has_cap(ARM64_SSBS)) {
@@ -371,6 +371,12 @@ void arm64_set_ssbd_mitigation(bool state)
break;
}
}
+#else
+void arm64_set_ssbd_mitigation(bool state)
+{
+ pr_info_once("SSBD, disabled by kernel configuration\n");
Is there a stray comma or is the continuation of some previous printout?
Regardless of that it looks good and compiles with both
CONFIG_ARM64_SSBD defined or not:
Reviewed-by: Andre Przywara
Cheers,
Andre.
+}
+#endif /* CONFIG_ARM64_SSBD */
static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
int scope)
@@ -468,7 +474,6 @@ static bool has_ssbd_mitigation(const struct
arm64_cpu_capabilities *entry,
return required;
}
-#endif /* CONFIG_ARM64_SSBD */
static void __maybe_unused
cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused)
@@ -760,14 +765,12 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
ERRATA_MIDR_RANGE_LIST(arm64_harden_el2_vectors),
},
#endif
-#ifdef CONFIG_ARM64_SSBD
{
.desc = "Speculative Store Bypass Disable",
.capability = ARM64_SSBD,
.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
.matches = has_ssbd_mitigation,
},
-#endif
#ifdef CONFIG_ARM64_ERRATUM_1188873
{
/* Cortex-A76 r0p0 to r2p0 */
Re: [PATCH v4 2/9] staging: iio: ad7780: add filter reading to ad778x
On Thu, 2019-02-28 at 11:24 -0300, Renato Lui Geh wrote:
>
>
> This patch adds the new feature of reading the filter odr value for
> ad778x chips. This value is stored in the chip's state struct whenever a
> read or write call is performed on the chip's driver.
>
> This feature requires sharing SAMP_FREQ. Since the ad717x does not have
> a filter option, the driver only shares the relevant info mask for the
> ad778x family.
>
> Signed-off-by: Renato Lui Geh
> ---
> Changes in v4:
> - As mentioned in the previous patch, this was originally as part of
>the 'add gain & filter gpio support' patch
>
This needs the ad778x_odr_avail[2] array to be moved to this patch.
Otherwise from what I can tell, this looks good.
> drivers/staging/iio/adc/ad7780.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index 87fbcf510d45..7a68e90ddf14 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -59,6 +59,7 @@ struct ad7780_state {
> struct gpio_desc*gain_gpio;
> struct gpio_desc*filter_gpio;
> unsigned intgain;
> + unsigned intodr;
> unsigned intint_vref_mv;
>
> struct ad_sigma_delta sd;
> @@ -121,6 +122,9 @@ static int ad7780_read_raw(struct iio_dev *indio_dev,
> case IIO_CHAN_INFO_OFFSET:
> *val = -(1 << (chan->scan_type.realbits - 1));
> return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + *val = st->odr;
> + return IIO_VAL_INT;
> default:
> break;
> }
> @@ -163,6 +167,7 @@ static int ad7780_write_raw(struct iio_dev
> *indio_dev,
> val = 0;
> else
> val = 1;
> + st->odr = ad778x_odr_avail[val];
> gpiod_set_value(st->filter_gpio, val);
> break;
> default:
> @@ -184,6 +189,7 @@ static int ad7780_postprocess_sample(struct
> ad_sigma_delta *sigma_delta,
>
> if (chip_info->is_ad778x) {
> st->gain = ad778x_gain[raw_sample & AD7780_GAIN];
> + st->odr = ad778x_odr_avail[raw_sample & AD7780_FILTER];
> }
>
> return 0;
> @@ -196,17 +202,19 @@ static const struct ad_sigma_delta_info
> ad7780_sigma_delta_info = {
> };
>
> #define AD7780_CHANNEL(bits, wordsize) \
> + AD_SD_CHANNEL(1, 0, 0, bits, 32, wordsize - bits)
> +#define AD7170_CHANNEL(bits, wordsize) \
> AD_SD_CHANNEL_NO_SAMP_FREQ(1, 0, 0, bits, 32, wordsize - bits)
>
> static const struct ad7780_chip_info ad7780_chip_info_tbl[] = {
> [ID_AD7170] = {
> - .channel = AD7780_CHANNEL(12, 24),
> + .channel = AD7170_CHANNEL(12, 24),
> .pattern = AD7170_PATTERN,
> .pattern_mask = AD7170_PATTERN_MASK,
> .is_ad778x = false,
> },
> [ID_AD7171] = {
> - .channel = AD7780_CHANNEL(16, 24),
> + .channel = AD7170_CHANNEL(16, 24),
> .pattern = AD7170_PATTERN,
> .pattern_mask = AD7170_PATTERN_MASK,
> .is_ad778x = false,
> --
> 2.21.0
>
[PATCH v5 2/3] PCI: hv: Replace hv_vp_set with hv_vpset
Remove a duplicate definition of VP set (hv_vp_set) and use the common
definition (hv_vpset) that is used in other places.
Change the order of the members in struct hv_pcibus_device so that the
declaration of retarget_msi_interrupt_params is the last member. Struct
hv_vpset, which contains a flexible array, is nested two levels deep in
struct hv_pcibus_device via retarget_msi_interrupt_params.
Add a comment that retarget_msi_interrupt_params should be the last
member of struct hv_pcibus_device.
Signed-off-by: Maya Nakamura
Reviewed-by: Michael Kelley
Reviewed-by: Vitaly Kuznetsov
Tested-by: Vitaly Kuznetsov
---
Changes in v5:
- Remove the code added in v4.
- Delete the v4 code change related comment from the commit message.
- Add the Reviewed-by and Tested-by tags.
Changes in v4:
- Add __aligned(8) to struct retarget_msi_interrupt.
- Update the commit message.
Change in v3:
- Correct the v2 change log.
Change in v2:
- Update the commit message.
drivers/pci/controller/pci-hyperv.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/controller/pci-hyperv.c
b/drivers/pci/controller/pci-hyperv.c
index 73862eef09ec..d71695db1ba0 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -393,12 +393,6 @@ struct hv_interrupt_entry {
#define HV_VP_SET_BANK_COUNT_MAX 5 /* current implementation limit */
-struct hv_vp_set {
- u64 format; /* 0 (HvGenericSetSparse4k) */
- u64 valid_banks;
- u64 masks[HV_VP_SET_BANK_COUNT_MAX];
-};
-
/*
* flags for hv_device_interrupt_target.flags
*/
@@ -410,7 +404,7 @@ struct hv_device_interrupt_target {
u32 flags;
union {
u64 vp_mask;
- struct hv_vp_set vp_set;
+ struct hv_vpset vp_set;
};
};
@@ -460,12 +454,16 @@ struct hv_pcibus_device {
struct msi_controller msi_chip;
struct irq_domain *irq_domain;
- /* hypercall arg, must not cross page boundary */
- struct retarget_msi_interrupt retarget_msi_interrupt_params;
-
spinlock_t retarget_msi_interrupt_lock;
struct workqueue_struct *wq;
+
+ /* hypercall arg, must not cross page boundary */
+ struct retarget_msi_interrupt retarget_msi_interrupt_params;
+
+ /*
+* Don't put anything here: retarget_msi_interrupt_params must be last
+*/
};
/*
@@ -955,12 +953,13 @@ static void hv_irq_unmask(struct irq_data *data)
*/
params->int_target.flags |=
HV_DEVICE_INTERRUPT_TARGET_PROCESSOR_SET;
- params->int_target.vp_set.valid_banks =
+ params->int_target.vp_set.valid_bank_mask =
(1ull << HV_VP_SET_BANK_COUNT_MAX) - 1;
/*
* var-sized hypercall, var-size starts after vp_mask (thus
-* vp_set.format does not count, but vp_set.valid_banks does).
+* vp_set.format does not count, but vp_set.valid_bank_mask
+* does).
*/
var_size = 1 + HV_VP_SET_BANK_COUNT_MAX;
@@ -974,7 +973,7 @@ static void hv_irq_unmask(struct irq_data *data)
goto exit_unlock;
}
- params->int_target.vp_set.masks[cpu_vmbus / 64] |=
+ params->int_target.vp_set.bank_contents[cpu_vmbus / 64]
|=
(1ULL << (cpu_vmbus & 63));
}
} else {
--
2.17.1
[PATCH] usb: introduce usb_ep_type_string() function
In some places, the code prints a human-readable USB endpoint
transfer type (e.g. "bulk"). This involves a switch statement
sometimes wrapped around in ({ ... }) block leading to code
repetition.
To make this scenario easier, here introduces usb_ep_type_string()
function, which returns a human-readable name of provided
endpoint type.
It also changes a few places switch was used to use this
new function.
Signed-off-by: Chunfeng Yun
---
drivers/usb/common/common.c | 16
drivers/usb/core/endpoint.c | 18 ++
drivers/usb/core/hcd.c | 17 ++---
drivers/usb/dwc3/debugfs.c | 23 ---
drivers/usb/gadget/udc/aspeed-vhub/epn.c | 6 +-
drivers/usb/gadget/udc/dummy_hcd.c | 16 +---
drivers/usb/host/xhci-trace.h| 19 ++-
include/linux/usb/ch9.h | 8
8 files changed, 36 insertions(+), 87 deletions(-)
diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index 48277bbc15e4..2174dd9ec176 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -16,6 +16,22 @@
#include
#include
+static const char *const ep_type_names[] = {
+ [USB_ENDPOINT_XFER_CONTROL] = "ctrl",
+ [USB_ENDPOINT_XFER_ISOC] = "isoc",
+ [USB_ENDPOINT_XFER_BULK] = "bulk",
+ [USB_ENDPOINT_XFER_INT] = "intr",
+};
+
+const char *usb_ep_type_string(int ep_type)
+{
+ if (ep_type < 0 || ep_type >= ARRAY_SIZE(ep_type_names))
+ return "unknown";
+
+ return ep_type_names[ep_type];
+}
+EXPORT_SYMBOL_GPL(usb_ep_type_string);
+
const char *usb_otg_state_string(enum usb_otg_state state)
{
static const char *const names[] = {
diff --git a/drivers/usb/core/endpoint.c b/drivers/usb/core/endpoint.c
index 1c2c04079676..afa43f9a47b2 100644
--- a/drivers/usb/core/endpoint.c
+++ b/drivers/usb/core/endpoint.c
@@ -60,23 +60,9 @@ static ssize_t type_show(struct device *dev, struct
device_attribute *attr,
char *buf)
{
struct ep_device *ep = to_ep_device(dev);
- char *type = "unknown";
+ int ep_type = usb_endpoint_type(ep->desc);
- switch (usb_endpoint_type(ep->desc)) {
- case USB_ENDPOINT_XFER_CONTROL:
- type = "Control";
- break;
- case USB_ENDPOINT_XFER_ISOC:
- type = "Isoc";
- break;
- case USB_ENDPOINT_XFER_BULK:
- type = "Bulk";
- break;
- case USB_ENDPOINT_XFER_INT:
- type = "Interrupt";
- break;
- }
- return sprintf(buf, "%s\n", type);
+ return sprintf(buf, "%s\n", usb_ep_type_string(ep_type));
}
static DEVICE_ATTR_RO(type);
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 015b126ce455..193ee92b2fdb 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1875,23 +1875,10 @@ void usb_hcd_flush_endpoint(struct usb_device *udev,
/* kick hcd */
unlink1(hcd, urb, -ESHUTDOWN);
dev_dbg (hcd->self.controller,
- "shutdown urb %pK ep%d%s%s\n",
+ "shutdown urb %pK ep%d%s-%s\n",
urb, usb_endpoint_num(>desc),
is_in ? "in" : "out",
- ({ char *s;
-
-switch (usb_endpoint_type(>desc)) {
-case USB_ENDPOINT_XFER_CONTROL:
- s = ""; break;
-case USB_ENDPOINT_XFER_BULK:
- s = "-bulk"; break;
-case USB_ENDPOINT_XFER_INT:
- s = "-intr"; break;
-default:
- s = "-iso"; break;
- };
- s;
- }));
+ usb_ep_type_string(usb_endpoint_type(>desc)));
usb_put_urb (urb);
/* list contents may have changed */
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 1c792710348f..d9e2a63835fe 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -750,28 +750,13 @@ static int dwc3_transfer_type_show(struct seq_file *s,
void *unused)
unsigned long flags;
spin_lock_irqsave(>lock, flags);
- if (!(dep->flags & DWC3_EP_ENABLED) ||
- !dep->endpoint.desc) {
- seq_printf(s, "--\n");
+ if (!(dep->flags & DWC3_EP_ENABLED) || !dep->endpoint.desc) {
+ seq_puts(s, "unknown\n");
goto out;
}
- switch (usb_endpoint_type(dep->endpoint.desc)) {
- case USB_ENDPOINT_XFER_CONTROL:
- seq_printf(s, "control\n");
-
Re: [PATCH v5 07/10] arm64: add sysfs vulnerability show for spectre v2
Hi,
On 2/26/19 7:05 PM, Jeremy Linton wrote:
Add code to track whether all the cores in the machine are
vulnerable, and whether all the vulnerable cores have been
mitigated.
Once we have that information we can add the sysfs stub and
provide an accurate view of what is known about the machine.
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/cpu_errata.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index a27e1ee750e1..0f6e8f5d67bc 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -513,6 +513,10 @@ cpu_enable_cache_maint_trap(const struct
arm64_cpu_capabilities *__unused)
.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM, \
CAP_MIDR_RANGE_LIST(midr_list)
+/* Track overall mitigation state. We are only mitigated if all cores are ok */
+static bool __hardenbp_enab = true;
+static bool __spectrev2_safe = true;
+
/*
* List of CPUs that do not need any Spectre-v2 mitigation at all.
*/
@@ -523,6 +527,10 @@ static const struct midr_range spectre_v2_safe_list[] = {
{ /* sentinel */ }
};
+/*
+ * Track overall bp hardening for all heterogeneous cores in the machine.
+ * We are only considered "safe" if all booted cores are known safe.
+ */
static bool __maybe_unused
check_branch_predictor(const struct arm64_cpu_capabilities *entry, int scope)
{
@@ -544,19 +552,25 @@ check_branch_predictor(const struct
arm64_cpu_capabilities *entry, int scope)
if (!need_wa)
return false;
+ __spectrev2_safe = false;
+
if (!IS_ENABLED(CONFIG_HARDEN_BRANCH_PREDICTOR)) {
pr_warn_once("spectrev2 mitigation disabled by
configuration\n");
+ __hardenbp_enab = false;
return false;
}
/* forced off */
if (__nospectre_v2) {
pr_info_once("spectrev2 mitigation disabled by command line
option\n");
+ __hardenbp_enab = false;
return false;
}
- if (need_wa < 0)
+ if (need_wa < 0) {
pr_warn_once("ARM_SMCCC_ARCH_WORKAROUND_1 missing from
firmware\n");
+ __hardenbp_enab = false;
+ }
return (need_wa > 0);
}
@@ -779,3 +793,15 @@ ssize_t cpu_show_spectre_v1(struct device *dev, struct
device_attribute *attr,
{
return sprintf(buf, "Mitigation: __user pointer sanitization\n");
}
+
+ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
+ char *buf)
w/s issue
Anyway:
Reviewed-by: Andre Przywara
Cheers,
Andre.
+{
+ if (__spectrev2_safe)
+ return sprintf(buf, "Not affected\n");
+
+ if (__hardenbp_enab)
+ return sprintf(buf, "Mitigation: Branch predictor hardening\n");
+
+ return sprintf(buf, "Vulnerable\n");
+}
Re: [PATCH v5 06/10] arm64: Always enable spectrev2 vulnerability detection
Hi,
On 2/26/19 7:05 PM, Jeremy Linton wrote:
The sysfs patches need to display machine vulnerability
status regardless of kernel config. Prepare for that
by breaking out the vulnerability/mitigation detection
code from the logic which implements the mitigation.
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/cpu_errata.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 77f021e78a28..a27e1ee750e1 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -109,12 +109,12 @@ cpu_enable_trap_ctr_access(const struct
arm64_cpu_capabilities *__unused)
atomic_t arm64_el2_vector_last_slot = ATOMIC_INIT(-1);
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
#include
#include
DEFINE_PER_CPU_READ_MOSTLY(struct bp_hardening_data, bp_hardening_data);
+
extra empty line
Apart from that picky and unimportant nit it looks alright and compiles
with and without CONFIG_HARDEN_BRANCH_PREDICTOR being defined.
Reviewed-by: Andre Przywara
Cheers,
Andre.
#ifdef CONFIG_KVM_INDIRECT_VECTORS
extern char __smccc_workaround_1_smc_start[];
extern char __smccc_workaround_1_smc_end[];
@@ -270,11 +270,11 @@ static int detect_harden_bp_fw(void)
((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR_V1))
cb = qcom_link_stack_sanitization;
- install_bp_hardening_cb(cb, smccc_start, smccc_end);
+ if (IS_ENABLED(CONFIG_HARDEN_BRANCH_PREDICTOR))
+ install_bp_hardening_cb(cb, smccc_start, smccc_end);
return 1;
}
-#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
#ifdef CONFIG_ARM64_SSBD
DEFINE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required);
@@ -513,7 +513,6 @@ cpu_enable_cache_maint_trap(const struct
arm64_cpu_capabilities *__unused)
.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM, \
CAP_MIDR_RANGE_LIST(midr_list)
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
/*
* List of CPUs that do not need any Spectre-v2 mitigation at all.
*/
@@ -545,6 +544,11 @@ check_branch_predictor(const struct arm64_cpu_capabilities
*entry, int scope)
if (!need_wa)
return false;
+ if (!IS_ENABLED(CONFIG_HARDEN_BRANCH_PREDICTOR)) {
+ pr_warn_once("spectrev2 mitigation disabled by
configuration\n");
+ return false;
+ }
+
/* forced off */
if (__nospectre_v2) {
pr_info_once("spectrev2 mitigation disabled by command line
option\n");
@@ -557,8 +561,6 @@ check_branch_predictor(const struct arm64_cpu_capabilities
*entry, int scope)
return (need_wa > 0);
}
-#endif
-
#ifdef CONFIG_HARDEN_EL2_VECTORS
static const struct midr_range arm64_harden_el2_vectors[] = {
@@ -732,13 +734,11 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
ERRATA_MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
},
#endif
-#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
{
.capability = ARM64_HARDEN_BRANCH_PREDICTOR,
.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
.matches = check_branch_predictor,
},
-#endif
#ifdef CONFIG_HARDEN_EL2_VECTORS
{
.desc = "EL2 vector hardening",
Re: [PATCH v5 05/10] arm64: Use firmware to detect CPUs that are not affected by Spectre-v2
Hi,
On 2/26/19 7:05 PM, Jeremy Linton wrote:
From: Marc Zyngier
The SMCCC ARCH_WORKAROUND_1 service can indicate that although the
firmware knows about the Spectre-v2 mitigation, this particular
CPU is not vulnerable, and it is thus not necessary to call
the firmware on this CPU.
Let's use this information to our benefit.
Yes, that matches the firmware interface description.
Signed-off-by: Marc Zyngier
Signed-off-by: Jeremy Linton
Reviewed-by: Andre Przywara
Cheers,
Andre.
---
arch/arm64/kernel/cpu_errata.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index c8972255b365..77f021e78a28 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -230,22 +230,36 @@ static int detect_harden_bp_fw(void)
case PSCI_CONDUIT_HVC:
arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
ARM_SMCCC_ARCH_WORKAROUND_1, );
- if ((int)res.a0 < 0)
+ switch ((int)res.a0) {
+ case 1:
+ /* Firmware says we're just fine */
+ return 0;
+ case 0:
+ cb = call_hvc_arch_workaround_1;
+ /* This is a guest, no need to patch KVM vectors */
+ smccc_start = NULL;
+ smccc_end = NULL;
+ break;
+ default:
return -1;
- cb = call_hvc_arch_workaround_1;
- /* This is a guest, no need to patch KVM vectors */
- smccc_start = NULL;
- smccc_end = NULL;
+ }
break;
case PSCI_CONDUIT_SMC:
arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
ARM_SMCCC_ARCH_WORKAROUND_1, );
- if ((int)res.a0 < 0)
+ switch ((int)res.a0) {
+ case 1:
+ /* Firmware says we're just fine */
+ return 0;
+ case 0:
+ cb = call_smc_arch_workaround_1;
+ smccc_start = __smccc_workaround_1_smc_start;
+ smccc_end = __smccc_workaround_1_smc_end;
+ break;
+ default:
return -1;
- cb = call_smc_arch_workaround_1;
- smccc_start = __smccc_workaround_1_smc_start;
- smccc_end = __smccc_workaround_1_smc_end;
+ }
break;
default:
Re: [PATCH v5 04/10] arm64: Advertise mitigation of Spectre-v2, or lack thereof
Hi,
On 2/26/19 7:05 PM, Jeremy Linton wrote:
From: Marc Zyngier
We currently have a list of CPUs affected by Spectre-v2, for which
we check that the firmware implements ARCH_WORKAROUND_1. It turns
out that not all firmwares do implement the required mitigation,
and that we fail to let the user know about it.
Instead, let's slightly revamp our checks, and rely on a whitelist
of cores that are known to be non-vulnerable, and let the user know
the status of the mitigation in the kernel log.
Signed-off-by: Marc Zyngier
[This makes more sense in front of the sysfs patch]
[Pick pieces of that patch into this and move it earlier]
Signed-off-by: Jeremy Linton
Indeed a whitelist is much better.
Reviewed-by: Andre Przywara
Cheers,
Andre.
---
arch/arm64/kernel/cpu_errata.c | 108 +
1 file changed, 56 insertions(+), 52 deletions(-)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index ad58958becb6..c8972255b365 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -131,9 +131,9 @@ static void __copy_hyp_vect_bpi(int slot, const char
*hyp_vecs_start,
__flush_icache_range((uintptr_t)dst, (uintptr_t)dst + SZ_2K);
}
-static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
- const char *hyp_vecs_start,
- const char *hyp_vecs_end)
+static void install_bp_hardening_cb(bp_hardening_cb_t fn,
+ const char *hyp_vecs_start,
+ const char *hyp_vecs_end)
{
static DEFINE_RAW_SPINLOCK(bp_lock);
int cpu, slot = -1;
@@ -177,23 +177,6 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
}
#endif/* CONFIG_KVM_INDIRECT_VECTORS */
-static void install_bp_hardening_cb(const struct arm64_cpu_capabilities *entry,
-bp_hardening_cb_t fn,
-const char *hyp_vecs_start,
-const char *hyp_vecs_end)
-{
- u64 pfr0;
-
- if (!entry->matches(entry, SCOPE_LOCAL_CPU))
- return;
-
- pfr0 = read_cpuid(ID_AA64PFR0_EL1);
- if (cpuid_feature_extract_unsigned_field(pfr0, ID_AA64PFR0_CSV2_SHIFT))
- return;
-
- __install_bp_hardening_cb(fn, hyp_vecs_start, hyp_vecs_end);
-}
-
#include
#include
#include
@@ -228,31 +211,27 @@ static int __init parse_nospectre_v2(char *str)
}
early_param("nospectre_v2", parse_nospectre_v2);
-static void
-enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry)
+/*
+ * -1: No workaround
+ * 0: No workaround required
+ * 1: Workaround installed
+ */
+static int detect_harden_bp_fw(void)
{
bp_hardening_cb_t cb;
void *smccc_start, *smccc_end;
struct arm_smccc_res res;
u32 midr = read_cpuid_id();
- if (!entry->matches(entry, SCOPE_LOCAL_CPU))
- return;
-
- if (__nospectre_v2) {
- pr_info_once("spectrev2 mitigation disabled by command line
option\n");
- return;
- }
-
if (psci_ops.smccc_version == SMCCC_VERSION_1_0)
- return;
+ return -1;
switch (psci_ops.conduit) {
case PSCI_CONDUIT_HVC:
arm_smccc_1_1_hvc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
ARM_SMCCC_ARCH_WORKAROUND_1, );
if ((int)res.a0 < 0)
- return;
+ return -1;
cb = call_hvc_arch_workaround_1;
/* This is a guest, no need to patch KVM vectors */
smccc_start = NULL;
@@ -263,23 +242,23 @@ enable_smccc_arch_workaround_1(const struct
arm64_cpu_capabilities *entry)
arm_smccc_1_1_smc(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
ARM_SMCCC_ARCH_WORKAROUND_1, );
if ((int)res.a0 < 0)
- return;
+ return -1;
cb = call_smc_arch_workaround_1;
smccc_start = __smccc_workaround_1_smc_start;
smccc_end = __smccc_workaround_1_smc_end;
break;
default:
- return;
+ return -1;
}
if (((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR) ||
((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR_V1))
cb = qcom_link_stack_sanitization;
- install_bp_hardening_cb(entry, cb, smccc_start, smccc_end);
+ install_bp_hardening_cb(cb, smccc_start, smccc_end);
- return;
+ return 1;
}
#endif/* CONFIG_HARDEN_BRANCH_PREDICTOR */
@@ -521,24 +500,49 @@ cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused)
CAP_MIDR_RANGE_LIST(midr_list)
#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
-
/*
- * List of CPUs where we need to issue a psci call
Re: + include-linux-typesh-use-unsigned-int-instead-of-unsigned.patch added to -mm tree
On Fri, Mar 01, 2019 at 09:13:27AM +0900, Masahiro Yamada wrote: > On Fri, Mar 1, 2019 at 7:08 AM Alexey Dobriyan wrote: > > > > On Thu, Feb 28, 2019 at 09:41:09AM -0800, a...@linux-foundation.org wrote: > > > --- > > > a/include/linux/types.h~include-linux-typesh-use-unsigned-int-instead-of-unsigned > > > +++ a/include/linux/types.h > > > @@ -155,9 +155,9 @@ typedef u64 dma_addr_t; > > > typedef u32 dma_addr_t; > > > #endif > > > > > > -typedef unsigned __bitwise gfp_t; > > > -typedef unsigned __bitwise slab_flags_t; > > > -typedef unsigned __bitwise fmode_t; > > > +typedef unsigned int __bitwise gfp_t; > > > +typedef unsigned int __bitwise slab_flags_t; > > > +typedef unsigned int __bitwise fmode_t; > > > > I don't know if this is desireable. Switching to "unsigned" is better: > > 1 less token and less 80 column pressure. > > > > See the following commit. Ah, checkpatch.pl, how could we live without it.
[PATCH v5 1/3] PCI: hv: Add __aligned(8) to struct retarget_msi_interrupt
Because Hyper-V requires that hypercall arguments be aligned on an 8
byte boundary, add __aligned(8) to struct retarget_msi_interrupt.
Link: https://lore.kernel.org/lkml/87k1hlqlby@vitty.brq.redhat.com/
Signed-off-by: Maya Nakamura
---
drivers/pci/controller/pci-hyperv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pci-hyperv.c
b/drivers/pci/controller/pci-hyperv.c
index 9ba4d12c179c..73862eef09ec 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -420,7 +420,7 @@ struct retarget_msi_interrupt {
struct hv_interrupt_entry int_entry;
u64 reserved2;
struct hv_device_interrupt_target int_target;
-} __packed;
+} __packed __aligned(8);
/*
* Driver specific state.
--
2.17.1
Re: [PATCH v4 1/9] staging: iio: ad7780: add gain & filter gpio support
On Thu, 2019-02-28 at 11:23 -0300, Renato Lui Geh wrote:
>
>
> Previously, the AD7780 driver only supported gpio for the 'powerdown'
> pin. This commit adds suppport for the 'gain' and 'filter' pin.
>
> Signed-off-by: Renato Lui Geh
> Signed-off-by: Giuliano Belinassi
> Co-developed-by: Giuliano Belinassi
> ---
> Changes in v3:
> - Renamed ad7780_chip_info's filter to odr
> - Renamed ad778x_filter to ad778x_odr_avail
> - Changed vref variable from unsigned int to unsigned long long to avoid
>overflow
> - Removed unnecessary AD_SD_CHANNEL macro
> Changes in v4:
> - Removed useless macro
> - Added default case for switch to suppress warning
> - Removed chunks belonging to filter reading, adding these as a
>patch for itself
>
> drivers/staging/iio/adc/ad7780.c | 90 +---
> 1 file changed, 84 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/iio/adc/ad7780.c
> b/drivers/staging/iio/adc/ad7780.c
> index c4a85789c2db..87fbcf510d45 100644
> --- a/drivers/staging/iio/adc/ad7780.c
> +++ b/drivers/staging/iio/adc/ad7780.c
> @@ -39,6 +39,12 @@
> #define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
> #define AD7170_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2)
>
> +#define AD7780_GAIN_MIDPOINT 64
> +#define AD7780_FILTER_MIDPOINT 13350
> +
> +static const unsigned int ad778x_gain[2] = { 1, 128 };
> +static const unsigned int ad778x_odr_avail[2] = { 1, 16700 };
ad778x_odr_avail[2] is not used in this patch, so it should probably go
into the next one
(i.e. staging: iio: ad7780: add filter reading to ad778x )
one good way of catching stuff like this is to do interactive rebase and
compile your driver on each patch to see if the compiler catches this;
i suspect the compiler would have thrown an error for this change
>
> struct ad7780_chip_info
> struct iio_chan_specchannel;
> unsigned intpattern_mask;
> @@ -50,7 +56,10 @@ struct ad7780_state {
> const struct ad7780_chip_info *chip_info;
> struct regulator*reg;
> struct gpio_desc*powerdown_gpio;
> - unsigned intgain;
> + struct gpio_desc*gain_gpio;
> + struct gpio_desc*filter_gpio;
> + unsigned intgain;
> + unsigned intint_vref_mv;
>
> struct ad_sigma_delta sd;
> };
> @@ -104,17 +113,65 @@ static int ad7780_read_raw(struct iio_dev
> *indio_dev,
> voltage_uv = regulator_get_voltage(st->reg);
> if (voltage_uv < 0)
> return voltage_uv;
> - *val = (voltage_uv / 1000) * st->gain;
> + voltage_uv /= 1000;
> + *val = voltage_uv * st->gain;
> *val2 = chan->scan_type.realbits - 1;
> + st->int_vref_mv = voltage_uv;
> return IIO_VAL_FRACTIONAL_LOG2;
> case IIO_CHAN_INFO_OFFSET:
> *val = -(1 << (chan->scan_type.realbits - 1));
> return IIO_VAL_INT;
> + default:
> + break;
The indentation of the break statement is inconsistent with other places.
Still, it does not add much value adding this change as-is, since it does
not change any behavior, and is not an element needed by this change (i.e.
adding gain & filter support via gpios)
> }
>
> return -EINVAL;
> }
>
> +static int ad7780_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val,
> + int val2,
> + long m)
> +{
> + struct ad7780_state *st = iio_priv(indio_dev);
> + const struct ad7780_chip_info *chip_info = st->chip_info;
> + unsigned long long vref;
> + unsigned int full_scale, gain;
> +
> + if (!chip_info->is_ad778x)
> + return 0;
> +
> + switch (m) {
> + case IIO_CHAN_INFO_SCALE:
> + if (val != 0)
> + return -EINVAL;
> +
> + vref = st->int_vref_mv * 100LL;
> + full_scale = 1 << (chip_info->channel.scan_type.realbits
> - 1);
> + gain = DIV_ROUND_CLOSEST(vref, full_scale);
> + gain = DIV_ROUND_CLOSEST(gain, val2);
> + st->gain = gain;
> + if (gain < AD7780_GAIN_MIDPOINT)
> + gain = 0;
> + else
> + gain = 1;
> + gpiod_set_value(st->gain_gpio, gain);
> + break;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + if (1000*val + val2/1000 < AD7780_FILTER_MIDPOINT)
> + val = 0;
> + else
> + val = 1;
> + gpiod_set_value(st->filter_gpio, val);
> + break;
> + default:
> + break;
> + }
> +
> + return 0;
> +}
> +
>
Re: [PATCH v5 02/10] arm64: add sysfs vulnerability show for spectre v1
Hi,
On 2/26/19 7:05 PM, Jeremy Linton wrote:
From: Mian Yousaf Kaukab
spectre v1, has been mitigated, and the mitigation is
always active.
Signed-off-by: Mian Yousaf Kaukab
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/cpu_errata.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index d2b2c69d31bb..ad58958becb6 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -755,3 +755,9 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
{
}
};
+
+ssize_t cpu_show_spectre_v1(struct device *dev, struct device_attribute *attr,
+ char *buf)
w/s issue, but it's not critical:
Reviewed-by: Andre Przywara
Cheers,
Andre
+{
+ return sprintf(buf, "Mitigation: __user pointer sanitization\n");
+}
[PATCH v5 0/3] PCI: hv: Refactor hv_irq_unmask() to use hv_vpset and cpumask_to_vpset()
This patchset removes a duplicate definition of VP set (hv_vp_set) and uses the common definition (hv_vpset) that is used in other places. It changes the order of the members in struct hv_pcibus_device due to flexible array in hv_vpset. It also removes the duplicate implementation of cpumask_to_vpset(), uses the shared implementation, and exports hv_max_vp_index, which is required by cpumask_to_vpset(). It adds __aligned(8) to struct retarget_msi_interrupt because Hyper-V requires that hypercall arguments be aligned on an 8 byte boundary. This is now a new patch, separate from one of the previous patches. Maya Nakamura (3): PCI: hv: Add __aligned(8) to struct retarget_msi_interrupt PCI: hv: Replace hv_vp_set with hv_vpset PCI: hv: Refactor hv_irq_unmask() to use cpumask_to_vpset() arch/x86/hyperv/hv_init.c | 1 + drivers/pci/controller/pci-hyperv.c | 61 + 2 files changed, 29 insertions(+), 33 deletions(-) -- 2.17.1
Re: [PATCH v5 01/10] arm64: Provide a command line to disable spectre_v2 mitigation
Hi,
On 2/26/19 7:05 PM, Jeremy Linton wrote:
There are various reasons, including bencmarking, to disable spectrev2
mitigation on a machine. Provide a command-line to do so.
Signed-off-by: Jeremy Linton
Reviewed-by: Andre Przywara
Cheers,
Andre.
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
Documentation/admin-guide/kernel-parameters.txt | 8
arch/arm64/kernel/cpu_errata.c | 13 +
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 858b6c0b9a15..4d4d6a9537ae 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2842,10 +2842,10 @@
check bypass). With this option data leaks are possible
in the system.
- nospectre_v2 [X86,PPC_FSL_BOOK3E] Disable all mitigations for the Spectre variant 2
- (indirect branch prediction) vulnerability. System may
- allow data leaks with this option, which is equivalent
- to spectre_v2=off.
+ nospectre_v2[X86,PPC_FSL_BOOK3E,ARM64] Disable all mitigations for
+ the Spectre variant 2 (indirect branch prediction)
+ vulnerability. System may allow data leaks with this
+ option.
nospec_store_bypass_disable
[HW] Disable all mitigations for the Speculative Store
Bypass vulnerability
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 9950bb0cbd52..d2b2c69d31bb 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -220,6 +220,14 @@ static void qcom_link_stack_sanitization(void)
: "=" (tmp));
}
+static bool __nospectre_v2;
+static int __init parse_nospectre_v2(char *str)
+{
+ __nospectre_v2 = true;
+ return 0;
+}
+early_param("nospectre_v2", parse_nospectre_v2);
+
static void
enable_smccc_arch_workaround_1(const struct arm64_cpu_capabilities *entry)
{
@@ -231,6 +239,11 @@ enable_smccc_arch_workaround_1(const struct
arm64_cpu_capabilities *entry)
if (!entry->matches(entry, SCOPE_LOCAL_CPU))
return;
+ if (__nospectre_v2) {
+ pr_info_once("spectrev2 mitigation disabled by command line
option\n");
+ return;
+ }
+
if (psci_ops.smccc_version == SMCCC_VERSION_1_0)
return;
Re: [PATCH v4 01/10] feature: implement libzstd check, LIBZSTD_DIR and NO_LIBZSTD defines
On 28.02.2019 23:11, Alexey Budankov wrote: > > On 28.02.2019 21:46, Arnaldo Carvalho de Melo wrote: >> Em Thu, Feb 28, 2019 at 11:59:01AM +0300, Alexey Budankov escreveu: >>> +++ b/tools/build/Makefile.feature >>> @@ -66,7 +66,8 @@ FEATURE_TESTS_BASIC := \ >>> sched_getcpu \ >>> sdt\ >>> setns \ >>> -libaio >>> +libaio \ >>> +libzstd >> >> Since you added this as a basic feature to test, add this when you >> resubmit, so that 'perf -vv' tells us that this basic feature is indeed >> present. > > Yes, will do. Actually came to similar idea when > observed your test report in pull requests: > > # perf version --build-options > perf version 5.0.rc5.gde667c >dwarf: [ on ] # HAVE_DWARF_SUPPORT > dwarf_getlocations: [ on ] # HAVE_DWARF_GETLOCATIONS_SUPPORT >glibc: [ on ] # HAVE_GLIBC_SUPPORT > gtk2: [ on ] # HAVE_GTK2_SUPPORT >syscall_table: [ on ] # HAVE_SYSCALL_TABLE_SUPPORT > libbfd: [ on ] # HAVE_LIBBFD_SUPPORT > libelf: [ on ] # HAVE_LIBELF_SUPPORT > libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT > numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT > libperl: [ on ] # HAVE_LIBPERL_SUPPORT >libpython: [ on ] # HAVE_LIBPYTHON_SUPPORT > libslang: [ on ] # HAVE_SLANG_SUPPORT >libcrypto: [ on ] # HAVE_LIBCRYPTO_SUPPORT >libunwind: [ on ] # HAVE_LIBUNWIND_SUPPORT > libdw-dwarf-unwind: [ on ] # HAVE_DWARF_SUPPORT > zlib: [ on ] # HAVE_ZLIB_SUPPORT > lzma: [ on ] # HAVE_LZMA_SUPPORT >get_cpuid: [ on ] # HAVE_AUXTRACE_SUPPORT > bpf: [ on ] # HAVE_LIBBPF_SUPPORT > > and it misses HAVE_ZSTD_SUPPORT define. implemented this: tools/perf/perf -vv perf version 4.13.rc5.g20492c dwarf: [ on ] # HAVE_DWARF_SUPPORT dwarf_getlocations: [ on ] # HAVE_DWARF_GETLOCATIONS_SUPPORT glibc: [ on ] # HAVE_GLIBC_SUPPORT gtk2: [ on ] # HAVE_GTK2_SUPPORT syscall_table: [ on ] # HAVE_SYSCALL_TABLE_SUPPORT libbfd: [ on ] # HAVE_LIBBFD_SUPPORT libelf: [ on ] # HAVE_LIBELF_SUPPORT libnuma: [ on ] # HAVE_LIBNUMA_SUPPORT numa_num_possible_cpus: [ on ] # HAVE_LIBNUMA_SUPPORT libperl: [ on ] # HAVE_LIBPERL_SUPPORT libpython: [ on ] # HAVE_LIBPYTHON_SUPPORT libslang: [ on ] # HAVE_SLANG_SUPPORT libcrypto: [ on ] # HAVE_LIBCRYPTO_SUPPORT libunwind: [ on ] # HAVE_LIBUNWIND_SUPPORT libdw-dwarf-unwind: [ on ] # HAVE_DWARF_SUPPORT zlib: [ on ] # HAVE_ZLIB_SUPPORT lzma: [ on ] # HAVE_LZMA_SUPPORT get_cpuid: [ on ] # HAVE_AUXTRACE_SUPPORT bpf: [ on ] # HAVE_LIBBPF_SUPPORT aio: [ on ] # HAVE_AIO_SUPPORT <= zstd: [ on ] # HAVE_ZSTD_SUPPORT<= ~Alexey > > Thanks, > Alexey > >> >> >> diff --git a/tools/perf/builtin-version.c b/tools/perf/builtin-version.c >> index 50df168be326..d41197fc8cef 100644 >> --- a/tools/perf/builtin-version.c >> +++ b/tools/perf/builtin-version.c >> @@ -78,6 +78,7 @@ static void library_status(void) >> STATUS(HAVE_LZMA_SUPPORT, lzma); >> STATUS(HAVE_AUXTRACE_SUPPORT, get_cpuid); >> STATUS(HAVE_LIBBPF_SUPPORT, bpf); >> +STATUS(HAVE_ZSTD_SUPPORT, bpf); >> } >> >> int cmd_version(int argc, const char **argv) >> >
[PATCH V5 1/2] watchdog: imx_sc: Add i.MX system controller watchdog support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and watchdog etc..
This patch adds i.MX system controller watchdog driver support,
watchdog operation needs to be done in secure EL3 mode via
ARM-Trusted-Firmware, using SMC call, CPU will trap into
ARM-Trusted-Firmware and then it will request system controller
to do watchdog operation via IPC.
Signed-off-by: Anson Huang
---
Changes since V4:
- change the module build dependency as depends on IMX_SCU and
HAVE_ARM_SMCCC, as this
driver is ONLY for i.MX SoC with SCU inside and it uses ARM SMC call.
---
drivers/watchdog/Kconfig | 14 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/imx_sc_wdt.c | 201 ++
3 files changed, 216 insertions(+)
create mode 100644 drivers/watchdog/imx_sc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 65c3c42..a6bfa54 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -625,6 +625,20 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config IMX_SC_WDT
+ tristate "IMX SC Watchdog"
+ depends on IMX_SCU
+ depends on HAVE_ARM_SMCCC
+ select WATCHDOG_CORE
+ help
+ This is the driver for the system controller watchdog
+ on the NXP i.MX SoCs with system controller inside.
+ If you have one of these processors and wish to have
+ watchdog support enabled, say Y, otherwise say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx_sc_wdt.
+
config UX500_WATCHDOG
tristate "ST-Ericsson Ux500 watchdog"
depends on MFD_DB8500_PRCMU
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 4e78a8c..0c9da63 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
diff --git a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c
new file mode 100644
index 000..50b49b2
--- /dev/null
+++ b/drivers/watchdog/imx_sc_wdt.c
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEFAULT_TIMEOUT 60
+/*
+ * Software timer tick implemented in scfw side, support 10ms to 0x ms
+ * in theory, but for normal case, 1s~128s is enough, you can change this max
+ * value in case it's not enough.
+ */
+#define MAX_TIMEOUT 128
+
+#define IMX_SIP_TIMER 0xC202
+#define IMX_SIP_TIMER_START_WDOG 0x01
+#define IMX_SIP_TIMER_STOP_WDOG0x02
+#define IMX_SIP_TIMER_SET_WDOG_ACT 0x03
+#define IMX_SIP_TIMER_PING_WDOG0x04
+#define IMX_SIP_TIMER_SET_TIMEOUT_WDOG 0x05
+#define IMX_SIP_TIMER_GET_WDOG_STAT0x06
+#define IMX_SIP_TIMER_SET_PRETIME_WDOG 0x07
+
+#define SC_TIMER_WDOG_ACTION_PARTITION 0
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, );
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static unsigned int timeout = DEFAULT_TIMEOUT;
+module_param(timeout, uint, );
+MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds (default="
+__MODULE_STRING(DEFAULT_TIMEOUT) ")");
+
+static struct platform_device *imx_sc_wdt_pdev;
+
+static int imx_sc_wdt_ping(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_PING_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+
+ return 0;
+}
+
+static int imx_sc_wdt_start(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_START_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+ if (res.a0)
+ return -EACCES;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_SET_WDOG_ACT,
+ SC_TIMER_WDOG_ACTION_PARTITION,
+ 0, 0, 0, 0, 0, );
+ return res.a0 ? -EACCES : 0;
+}
+
+static int imx_sc_wdt_stop(struct watchdog_device *wdog)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(IMX_SIP_TIMER, IMX_SIP_TIMER_STOP_WDOG,
+ 0, 0, 0, 0, 0, 0, );
+
+ return res.a0 ? -EACCES : 0;
+}
+
+static int imx_sc_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct
[PATCH V5 2/2] arm64: defconfig: add support for i.MX system controller watchdog
Enable CONFIG_IMX_SC_WDT as module to support i.MX system controller watchdog. Signed-off-by: Anson Huang --- No changes. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2d9c390..690f4ba 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -427,6 +427,7 @@ CONFIG_WATCHDOG=y CONFIG_ARM_SP805_WATCHDOG=y CONFIG_S3C2410_WATCHDOG=y CONFIG_IMX2_WDT=y +CONFIG_IMX_SC_WDT=m CONFIG_MESON_GXBB_WATCHDOG=m CONFIG_MESON_WATCHDOG=m CONFIG_RENESAS_WDT=y -- 2.7.4
Re: [PATCH v5 3/6] uaccess: Add non-pagefault user-space read functions
On 2/28/19 6:29 PM, Masami Hiramatsu wrote:
> Hi Yonghong,
>
> On Thu, 28 Feb 2019 22:49:43 +
> Yonghong Song wrote:
>
>>
>>
>> On 2/28/19 8:03 AM, Masami Hiramatsu wrote:
>>> Add probe_user_read(), strncpy_from_unsafe_user() and
>>> strnlen_unsafe_user() which allows caller to access user-space
>>> in IRQ context.
>>>
>>> Current probe_kernel_read() and strncpy_from_unsafe() are
>>> not available for user-space memory, because it sets
>>> KERNEL_DS while accessing data. On some arch, user address
>>> space and kernel address space can be co-exist, but others
>>> can not. In that case, setting KERNEL_DS means given
>>
>> Just curious. Given the list of arch's currently linux supports,
>> do you know which arch's fall into "user address space and
>> kernel address space" can co-exist, and which arch's cannot?
>
> As far as I can heard, (and based on probe_kernel_read() failure)
> sparc32 (and sparc64?), arm64, and s390 will not work.
> x86 works, but if user patch the 4G/4G, it shouldn't work.
Thanks for the info! Great to know the details.
>
> Thank you,
>
>>
>> Thanks!
>>
>> Yonghong
>>
>>
>>> address is treated as a kernel address space.
>>> Also strnlen_user() is only available from user context since
>>> it can sleep if pagefault is enabled.
>>>
>>> To access user-space memory without pagefault, we need
>>> these new functions which sets USER_DS while accessing
>>> the data.
>>>
>>> Signed-off-by: Masami Hiramatsu
>>> ---
>>> Changes in v5:
>>> - Simplify probe_user_read() (Thanks, Peter!)
>>> - Add strnlen_unsafe_user()
>>> Changes in v3:
>>> - Use user_access_ok() for probe_user_read().
>>> Changes in v2:
>>> - Simplify strncpy_from_unsafe_user() using strncpy_from_user()
>>>according to Linus's suggestion.
>>> - Simplify probe_user_read() not using intermediate function.
>>> ---
>>>include/linux/uaccess.h | 14 +
>>>mm/maccess.c| 122
>>> +--
>>>2 files changed, 130 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
>>> index 1afd9dfabe67..5be7f9adb418 100644
>>> --- a/include/linux/uaccess.h
>>> +++ b/include/linux/uaccess.h
>>> @@ -258,6 +258,17 @@ extern long probe_kernel_read(void *dst, const void
>>> *src, size_t size);
>>>extern long __probe_kernel_read(void *dst, const void *src, size_t size);
>>>
>>>/*
>>> + * probe_user_read(): safely attempt to read from a location in user space
>>> + * @dst: pointer to the buffer that shall take the data
>>> + * @src: address to read from
>>> + * @size: size of the data chunk
>>> + *
>>> + * Safely read from address @src to the buffer at @dst. If a kernel fault
>>> + * happens, handle that and return -EFAULT.
>>> + */
>>> +extern long probe_user_read(void *dst, const void __user *src, size_t
>>> size);
>>> +
>>> +/*
>>> * probe_kernel_write(): safely attempt to write to a location
>>> * @dst: address to write to
>>> * @src: pointer to the data that shall be written
>>> @@ -270,6 +281,9 @@ extern long notrace probe_kernel_write(void *dst, const
>>> void *src, size_t size);
>>>extern long notrace __probe_kernel_write(void *dst, const void *src,
>>> size_t size);
>>>
>>>extern long strncpy_from_unsafe(char *dst, const void *unsafe_addr, long
>>> count);
>>> +extern long strncpy_from_unsafe_user(char *dst, const void __user
>>> *unsafe_addr,
>>> +long count);
>>> +extern long strnlen_unsafe_user(const void __user *unsafe_addr, long
>>> count);
>>>
>>>/**
>>> * probe_kernel_address(): safely attempt to read from a location
>>> diff --git a/mm/maccess.c b/mm/maccess.c
>>> index ec00be51a24f..d1b2ec78d9ef 100644
>>> --- a/mm/maccess.c
>>> +++ b/mm/maccess.c
>>> @@ -5,8 +5,20 @@
>>>#include
>>>#include
>>>
>>> +static __always_inline long
>>> +probe_read_common(void *dst, const void __user *src, size_t size)
>>> +{
>>> + long ret;
>>> +
>>> + pagefault_disable();
>>> + ret = __copy_from_user_inatomic(dst, src, size);
>>> + pagefault_enable();
>>> +
>>> + return ret ? -EFAULT : 0;
>>> +}
>>> +
>>>/**
>>> - * probe_kernel_read(): safely attempt to read from a location
>>> + * probe_kernel_read(): safely attempt to read from a kernel-space location
>>> * @dst: pointer to the buffer that shall take the data
>>> * @src: address to read from
>>> * @size: size of the data chunk
>>> @@ -29,17 +41,45 @@ long __probe_kernel_read(void *dst, const void *src,
>>> size_t size)
>>> mm_segment_t old_fs = get_fs();
>>>
>>> set_fs(KERNEL_DS);
>>> - pagefault_disable();
>>> - ret = __copy_from_user_inatomic(dst,
>>> - (__force const void __user *)src, size);
>>> - pagefault_enable();
>>> + ret = probe_read_common(dst, (__force const void __user *)src, size);
>>> set_fs(old_fs);
>>>
>>> - return ret ? -EFAULT : 0;
>>> +
Re: [PATCH] ARM: dts: imx6dl-yapp4: Use rgmii-id phy mode on the cpu port
On 01. 03. 19 3:13, Shawn Guo wrote:
On Tue, Feb 19, 2019 at 02:37:00PM +0100, Michal Vokáč wrote:
The PHY must add delays to both Tx and Rx clock on the cpu port
to work propperly.
It worked with the rgmii mode before beacause the qca8k driver
(incorrecly) enabled delays in that mode.
Signed-off-by: Michal Vokáč
---
This imx6dl-yapp4 platform is currently waiting in linux-next.
Commit 5ecdd77c61c8 ("net: dsa: qca8k: disable delay for RGMII mode"), now
also in linux-next removed the delays from the RGMII mode so the networking
stopped working.
Recently Koul submitted a patch that implements the rgmii-id mode to fix
the issue [1].
As the networking is broken at this moment it does not matter which patch
goes in first. It is not neccessary to wait until the Koul's patch is
applied/merged if that should be the case.
[1] http://patchwork.ozlabs.org/patch/1044505/
Can we have such useful info in the commit log in some proper form?
Sure, I will transplant relevant parts of the message into the commit
log. I just thought that most of this info will be outdated immediately
after applying.
BTW the patch[1] from Vinod is already merged.
Michal
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
index b715ab0fa1ff..091d829f6b05 100644
--- a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
+++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
@@ -125,7 +125,7 @@
ethphy0: port@0 {
reg = <0>;
label = "cpu";
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
ethernet = <>;
fixed-link {
--
2.1.4
Zdravstvujte Vas interesuet parsing kontaktov?
Zdravstvujte Vas interesuet parsing kontaktov?
Re: [PATCH v3 1/2] Provide in-kernel headers for making it easy to extend the kernel
On Fri, Mar 1, 2019 at 12:06 AM Joel Fernandes wrote: > > On Thu, Feb 28, 2019 at 11:17:51AM +0900, Masahiro Yamada wrote: > > Hi Joel, > > > > > > On Thu, Feb 28, 2019 at 4:40 AM Joel Fernandes (Google) > > wrote: > > > > > > Introduce in-kernel headers and other artifacts which are made available > > > as an archive through proc (/proc/kheaders.tar.xz file). This archive > > > makes > > > it possible to build kernel modules, run eBPF programs, and other > > > tracing programs that need to extend the kernel for tracing purposes > > > without any dependency on the file system having headers and build > > > artifacts. > > > > > > On Android and embedded systems, it is common to switch kernels but not > > > have kernel headers available on the file system. Raw kernel headers > > > also cannot be copied into the filesystem like they can be on other > > > distros, due to licensing and other issues. There's no linux-headers > > > package on Android. Further once a different kernel is booted, any > > > headers stored on the file system will no longer be useful. By storing > > > the headers as a compressed archive within the kernel, we can avoid these > > > issues that have been a hindrance for a long time. > > > > > > The feature is also buildable as a module just in case the user desires > > > it not being part of the kernel image. This makes it possible to load > > > and unload the headers on demand. A tracing program, or a kernel module > > > builder can load the module, do its operations, and then unload the > > > module to save kernel memory. The total memory needed is 3.8MB. > > > > > > The code to read the headers is based on /proc/config.gz code and uses > > > the same technique to embed the headers. > > > > > > > > Please let me ask a question about the actual use-case. > > > > > > To build embedded systems including Android, > > I use an x86 build machine. > > > > In other words, I cross-compile vmlinux and in-tree modules. > > So, > > > > target-arch: arm64 > > host-arch: x86 > > > > > > > > > To build a module, the below steps have been tested on an x86 machine: > > > modprobe kheaders > > > rm -rf $HOME/headers > > > mkdir -p $HOME/headers > > > tar -xvf /proc/kheaders.tar.xz -C $HOME/headers >/dev/null > > > cd my-kernel-module > > > make -C $HOME/headers M=$(pwd) modules > > > rmmod kheaders > > > > I am guessing the user will run these commands > > on the target system. > > In other words, external modules are native-compiled. > > So, > > > > target-arch: arm64 > > host-arch: arm64 > > > > > > Is this correct? > > > > > > If I understood the assumed use-case correctly, > > kheaders.tar.xw will contain host-programs compiled for x86, > > which will not work on the target system. > > > > You are right, the above commands in the commit message work only if the > host/target are same arch due to scripts. > > However we can build with arm64 device connected to a host, like this (which > I tested): > > adb shell modprobe kheaders; adb pull /proc/kheaders.tar.xz > rm -rf $HOME/headers; mkdir -p $HOME/headers > tar -xvf /proc/kheaders.tar.xz -C $HOME/headers >/dev/null > cd my-kernel-module > make -C $HOME/headers M=$(pwd) ARCH=arm64 CROSS_COMPILE=aarch64- modules > adb push test.ko /data/; adb shell rmmod kheaders > > The other way we can make this work is using x86 usermode emulation inside a > chroot on the Android device which will make the earlier commands work. One > thing to note is that Android also runs on x86 hardware so the commands in > the commit message will work even for x86 Android targets already. > > Also note that this the "module building" part is really only one of the > usecases. eBPF is another which needs the headers - and the headers are vast > majority of the archive. Headers take 3.1MB out of 3.6MB of the archive on > arm64 builds. > > How do you want to proceed here, should I mention these points in the commit > message? I do not request a re-spin just for a matter of commit log, but this version produces an empty tarball. So, you will have a chance to update the patch anyway. In the next version, it would be nice to note that "external modules must be built on the same host arch as built vmlinux". Let me ask one more question. I guess this patch is motivated by how difficult to convey kernel headers from vendors to users. In that situation, how will the user find the right compiler to use for building external modules? Greg KH said: We don't ever support the system of loading a module built with anything other than the _exact_ same compiler than the kernel was. For the full context, see this: https://lore.kernel.org/patchwork/patch/836247/#1031547 -- Best Regards Masahiro Yamada
[PATCH v2] powernv: powercap: Add hard minimum powercap
In POWER9, OCC(On-Chip-Controller) provides for hard and soft system
powercapping range. The hard powercap range is guaranteed while soft
powercap may or may not be enforced by OCC due to various power-thermal
reasons based on system configuration and workloads. This patch adds
a sysfs file to export the hard minimum powercap limit to allow the
user to set the appropriate powercap value that can be managed by the
system.
Signed-off-by: Shilpasri G Bhat
---
Changes from V1:
- s/asserted/enforced by OCC
.../ABI/testing/sysfs-firmware-opal-powercap | 10
arch/powerpc/platforms/powernv/opal-powercap.c | 66 +-
2 files changed, 37 insertions(+), 39 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-firmware-opal-powercap
b/Documentation/ABI/testing/sysfs-firmware-opal-powercap
index c9b66ec..e37d43e 100644
--- a/Documentation/ABI/testing/sysfs-firmware-opal-powercap
+++ b/Documentation/ABI/testing/sysfs-firmware-opal-powercap
@@ -29,3 +29,13 @@ Description: System powercap directory and attributes
applicable for
creates a request for setting a new-powercap. The
powercap requested must be between powercap-min
and powercap-max.
+
+What: /sys/firmware/opal/powercap/system-powercap/powercap-hard-min
+Date: March 2019
+Contact: Linux for PowerPC mailing list
+Description: Hard minimum powercap
+
+ This file provides the hard minimum powercap limit in Watts.
+ The powercap value above hard minimum limit is guaranteed to be
+ enforced by OCC and the powercap value below this limit may or
+ may not be guaranteed.
diff --git a/arch/powerpc/platforms/powernv/opal-powercap.c
b/arch/powerpc/platforms/powernv/opal-powercap.c
index d90ee4f..38408e7 100644
--- a/arch/powerpc/platforms/powernv/opal-powercap.c
+++ b/arch/powerpc/platforms/powernv/opal-powercap.c
@@ -139,10 +139,24 @@ static void powercap_add_attr(int handle, const char
*name,
attr->handle = handle;
sysfs_attr_init(>attr.attr);
attr->attr.attr.name = name;
- attr->attr.attr.mode = 0444;
+
+ if (!strncmp(name, "powercap-current", strlen(name))) {
+ attr->attr.attr.mode = 0664;
+ attr->attr.store = powercap_store;
+ } else {
+ attr->attr.attr.mode = 0444;
+ }
+
attr->attr.show = powercap_show;
}
+static const char * const powercap_strs[] = {
+ "powercap-max",
+ "powercap-min",
+ "powercap-current",
+ "powercap-hard-min",
+};
+
void __init opal_powercap_init(void)
{
struct device_node *powercap, *node;
@@ -167,60 +181,34 @@ void __init opal_powercap_init(void)
i = 0;
for_each_child_of_node(powercap, node) {
- u32 cur, min, max;
- int j = 0;
- bool has_cur = false, has_min = false, has_max = false;
+ u32 id;
+ int j, count = 0;
- if (!of_property_read_u32(node, "powercap-min", )) {
- j++;
- has_min = true;
- }
-
- if (!of_property_read_u32(node, "powercap-max", )) {
- j++;
- has_max = true;
- }
+ for (j = 0; j < ARRAY_SIZE(powercap_strs); j++)
+ if (!of_property_read_u32(node, powercap_strs[j], ))
+ count++;
- if (!of_property_read_u32(node, "powercap-current", )) {
- j++;
- has_cur = true;
- }
-
- pcaps[i].pattrs = kcalloc(j, sizeof(struct powercap_attr),
+ pcaps[i].pattrs = kcalloc(count, sizeof(struct powercap_attr),
GFP_KERNEL);
if (!pcaps[i].pattrs)
goto out_pcaps_pattrs;
- pcaps[i].pg.attrs = kcalloc(j + 1, sizeof(struct attribute *),
+ pcaps[i].pg.attrs = kcalloc(count + 1,
+ sizeof(struct attribute *),
GFP_KERNEL);
if (!pcaps[i].pg.attrs) {
kfree(pcaps[i].pattrs);
goto out_pcaps_pattrs;
}
- j = 0;
pcaps[i].pg.name = kasprintf(GFP_KERNEL, "%pOFn", node);
- if (has_min) {
- powercap_add_attr(min, "powercap-min",
- [i].pattrs[j]);
- pcaps[i].pg.attrs[j] = [i].pattrs[j].attr.attr;
- j++;
- }
-
- if (has_max) {
- powercap_add_attr(max, "powercap-max",
- [i].pattrs[j]);
- pcaps[i].pg.attrs[j] = [i].pattrs[j].attr.attr;
-
[PATCH] regulator: lp87565: Convert to use regulator_set/get_current_limit_regmap
Use regulator_set/get_current_limit_regmap helpers to save some code.
Signed-off-by: Axel Lin
---
drivers/regulator/lp87565-regulator.c | 47 ---
1 file changed, 7 insertions(+), 40 deletions(-)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 0418e478c6dc..81eb4b890c0c 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -34,6 +34,10 @@
.ramp_delay = _delay, \
.linear_ranges = _lr, \
.n_linear_ranges= ARRAY_SIZE(_lr), \
+ .curr_table = lp87565_buck_uA, \
+ .n_current_limits = ARRAY_SIZE(lp87565_buck_uA),\
+ .csel_reg = (_cr), \
+ .csel_mask = LP87565_BUCK_CTRL_2_ILIM, \
}, \
.ctrl2_reg = _cr, \
}
@@ -102,44 +106,7 @@ static int lp87565_buck_set_ramp_delay(struct
regulator_dev *rdev,
return 0;
}
-static int lp87565_buck_set_current_limit(struct regulator_dev *rdev,
- int min_uA, int max_uA)
-{
- int id = rdev_get_id(rdev);
- struct lp87565 *lp87565 = rdev_get_drvdata(rdev);
- int i;
-
- for (i = ARRAY_SIZE(lp87565_buck_uA) - 1; i >= 0; i--) {
- if (lp87565_buck_uA[i] >= min_uA &&
- lp87565_buck_uA[i] <= max_uA)
- return regmap_update_bits(lp87565->regmap,
- regulators[id].ctrl2_reg,
- LP87565_BUCK_CTRL_2_ILIM,
- i <<
__ffs(LP87565_BUCK_CTRL_2_ILIM));
- }
-
- return -EINVAL;
-}
-
-static int lp87565_buck_get_current_limit(struct regulator_dev *rdev)
-{
- int id = rdev_get_id(rdev);
- struct lp87565 *lp87565 = rdev_get_drvdata(rdev);
- int ret;
- unsigned int val;
-
- ret = regmap_read(lp87565->regmap, regulators[id].ctrl2_reg, );
- if (ret)
- return ret;
-
- val = (val & LP87565_BUCK_CTRL_2_ILIM) >>
- __ffs(LP87565_BUCK_CTRL_2_ILIM);
-
- return (val < ARRAY_SIZE(lp87565_buck_uA)) ?
- lp87565_buck_uA[val] : -EINVAL;
-}
-
-/* Operations permitted on BUCK0, BUCK1 */
+/* Operations permitted on BUCKs */
static const struct regulator_ops lp87565_buck_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = regulator_enable_regmap,
@@ -150,8 +117,8 @@ static const struct regulator_ops lp87565_buck_ops = {
.map_voltage= regulator_map_voltage_linear_range,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_ramp_delay = lp87565_buck_set_ramp_delay,
- .set_current_limit = lp87565_buck_set_current_limit,
- .get_current_limit = lp87565_buck_get_current_limit,
+ .set_current_limit = regulator_set_current_limit_regmap,
+ .get_current_limit = regulator_get_current_limit_regmap,
};
static const struct lp87565_regulator regulators[] = {
--
2.17.1
[PATCH v2] mm: vmscan: add tracepoints for node reclaim
In the page alloc fast path, it may do node reclaim, which may cause
latency spike.
We should add tracepoint for this event, and also measure the latency
it causes.
So bellow two tracepoints are introduced,
mm_vmscan_node_reclaim_begin
mm_vmscan_node_reclaim_end
Signed-off-by: Yafang Shao
---
include/trace/events/vmscan.h | 32
mm/vmscan.c | 6 ++
2 files changed, 38 insertions(+)
diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index a1cb913..c1ddf28 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -465,6 +465,38 @@
__entry->ratio,
show_reclaim_flags(__entry->reclaim_flags))
);
+
+TRACE_EVENT(mm_vmscan_node_reclaim_begin,
+
+ TP_PROTO(int nid, int order, gfp_t gfp_flags),
+
+ TP_ARGS(nid, order, gfp_flags),
+
+ TP_STRUCT__entry(
+ __field(int, nid)
+ __field(int, order)
+ __field(gfp_t, gfp_flags)
+ ),
+
+ TP_fast_assign(
+ __entry->nid = nid;
+ __entry->order = order;
+ __entry->gfp_flags = gfp_flags;
+ ),
+
+ TP_printk("nid=%d order=%d gfp_flags=%s",
+ __entry->nid,
+ __entry->order,
+ show_gfp_flags(__entry->gfp_flags))
+);
+
+DEFINE_EVENT(mm_vmscan_direct_reclaim_end_template, mm_vmscan_node_reclaim_end,
+
+ TP_PROTO(unsigned long nr_reclaimed),
+
+ TP_ARGS(nr_reclaimed)
+);
+
#endif /* _TRACE_VMSCAN_H */
/* This part must be outside protection */
diff --git a/mm/vmscan.c b/mm/vmscan.c
index ac4806f..2bee5d1 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4241,6 +4241,9 @@ static int __node_reclaim(struct pglist_data *pgdat,
gfp_t gfp_mask, unsigned in
.reclaim_idx = gfp_zone(gfp_mask),
};
+ trace_mm_vmscan_node_reclaim_begin(pgdat->node_id, order,
+ sc.gfp_mask);
+
cond_resched();
fs_reclaim_acquire(sc.gfp_mask);
/*
@@ -4267,6 +4270,9 @@ static int __node_reclaim(struct pglist_data *pgdat,
gfp_t gfp_mask, unsigned in
current->flags &= ~PF_SWAPWRITE;
memalloc_noreclaim_restore(noreclaim_flag);
fs_reclaim_release(sc.gfp_mask);
+
+ trace_mm_vmscan_node_reclaim_end(sc.nr_reclaimed);
+
return sc.nr_reclaimed >= nr_pages;
}
--
1.8.3.1
[PATCH] mm: vmscan: drop may_writepage and classzone_idx from direct reclaim begin template
There are three tracepoints using this template, which are
mm_vmscan_direct_reclaim_begin,
mm_vmscan_memcg_reclaim_begin,
mm_vmscan_memcg_softlimit_reclaim_begin.
Regarding mm_vmscan_direct_reclaim_begin,
sc.may_writepage is !laptop_mode, that's a static setting, and
reclaim_idx is derived from gfp_mask which is already show in this
tracepoint.
Regarding mm_vmscan_memcg_reclaim_begin,
may_writepage is !laptop_mode too, and reclaim_idx is (MAX_NR_ZONES-1),
which are both static value.
mm_vmscan_memcg_softlimit_reclaim_begin is the same with
mm_vmscan_memcg_reclaim_begin.
So we can drop them all.
Signed-off-by: Yafang Shao
---
include/trace/events/vmscan.h | 26 ++
mm/vmscan.c | 14 +++---
2 files changed, 13 insertions(+), 27 deletions(-)
diff --git a/include/trace/events/vmscan.h b/include/trace/events/vmscan.h
index a1cb913..153d90c 100644
--- a/include/trace/events/vmscan.h
+++ b/include/trace/events/vmscan.h
@@ -105,51 +105,45 @@
DECLARE_EVENT_CLASS(mm_vmscan_direct_reclaim_begin_template,
- TP_PROTO(int order, int may_writepage, gfp_t gfp_flags, int
classzone_idx),
+ TP_PROTO(int order, gfp_t gfp_flags),
- TP_ARGS(order, may_writepage, gfp_flags, classzone_idx),
+ TP_ARGS(order, gfp_flags),
TP_STRUCT__entry(
__field(int,order )
- __field(int,may_writepage )
__field(gfp_t, gfp_flags )
- __field(int,classzone_idx )
),
TP_fast_assign(
__entry->order = order;
- __entry->may_writepage = may_writepage;
__entry->gfp_flags = gfp_flags;
- __entry->classzone_idx = classzone_idx;
),
- TP_printk("order=%d may_writepage=%d gfp_flags=%s classzone_idx=%d",
+ TP_printk("order=%d gfp_flags=%s",
__entry->order,
- __entry->may_writepage,
- show_gfp_flags(__entry->gfp_flags),
- __entry->classzone_idx)
+ show_gfp_flags(__entry->gfp_flags))
);
DEFINE_EVENT(mm_vmscan_direct_reclaim_begin_template,
mm_vmscan_direct_reclaim_begin,
- TP_PROTO(int order, int may_writepage, gfp_t gfp_flags, int
classzone_idx),
+ TP_PROTO(int order, gfp_t gfp_flags),
- TP_ARGS(order, may_writepage, gfp_flags, classzone_idx)
+ TP_ARGS(order, gfp_flags)
);
#ifdef CONFIG_MEMCG
DEFINE_EVENT(mm_vmscan_direct_reclaim_begin_template,
mm_vmscan_memcg_reclaim_begin,
- TP_PROTO(int order, int may_writepage, gfp_t gfp_flags, int
classzone_idx),
+ TP_PROTO(int order, gfp_t gfp_flags),
- TP_ARGS(order, may_writepage, gfp_flags, classzone_idx)
+ TP_ARGS(order, gfp_flags)
);
DEFINE_EVENT(mm_vmscan_direct_reclaim_begin_template,
mm_vmscan_memcg_softlimit_reclaim_begin,
- TP_PROTO(int order, int may_writepage, gfp_t gfp_flags, int
classzone_idx),
+ TP_PROTO(int order, gfp_t gfp_flags),
- TP_ARGS(order, may_writepage, gfp_flags, classzone_idx)
+ TP_ARGS(order, gfp_flags)
);
#endif /* CONFIG_MEMCG */
diff --git a/mm/vmscan.c b/mm/vmscan.c
index ac4806f..cdc0305 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -3304,10 +3304,7 @@ unsigned long try_to_free_pages(struct zonelist
*zonelist, int order,
if (throttle_direct_reclaim(sc.gfp_mask, zonelist, nodemask))
return 1;
- trace_mm_vmscan_direct_reclaim_begin(order,
- sc.may_writepage,
- sc.gfp_mask,
- sc.reclaim_idx);
+ trace_mm_vmscan_direct_reclaim_begin(order, sc.gfp_mask);
nr_reclaimed = do_try_to_free_pages(zonelist, );
@@ -3338,9 +3335,7 @@ unsigned long mem_cgroup_shrink_node(struct mem_cgroup
*memcg,
(GFP_HIGHUSER_MOVABLE & ~GFP_RECLAIM_MASK);
trace_mm_vmscan_memcg_softlimit_reclaim_begin(sc.order,
- sc.may_writepage,
- sc.gfp_mask,
- sc.reclaim_idx);
+ sc.gfp_mask);
/*
* NOTE: Although we can get the priority field, using it
@@ -3389,10 +3384,7 @@ unsigned long try_to_free_mem_cgroup_pages(struct
mem_cgroup *memcg,
zonelist = _DATA(nid)->node_zonelists[ZONELIST_FALLBACK];
- trace_mm_vmscan_memcg_reclaim_begin(0,
- sc.may_writepage,
- sc.gfp_mask,
- sc.reclaim_idx);
+ trace_mm_vmscan_memcg_reclaim_begin(0, sc.gfp_mask);
psi_memstall_enter();
noreclaim_flag = memalloc_noreclaim_save();
--
1.8.3.1
Re: [PATCH v6 3/6] arm64/kvm: context-switch ptrauth registers
On 2/21/19 9:21 PM, Dave Martin wrote: On Thu, Feb 21, 2019 at 12:29:42PM +, Mark Rutland wrote: On Tue, Feb 19, 2019 at 02:54:28PM +0530, Amit Daniel Kachhap wrote: From: Mark Rutland When pointer authentication is supported, a guest may wish to use it. This patch adds the necessary KVM infrastructure for this to work, with a semi-lazy context switch of the pointer auth state. Pointer authentication feature is only enabled when VHE is built in the kernel and present into CPU implementation so only VHE code paths are modified. Nit: s/into/in the/ When we schedule a vcpu, we disable guest usage of pointer authentication instructions and accesses to the keys. While these are disabled, we avoid context-switching the keys. When we trap the guest trying to use pointer authentication functionality, we change to eagerly context-switching the keys, and enable the feature. The next time the vcpu is scheduled out/in, we start again. However the host key registers are saved in vcpu load stage as they remain constant for each vcpu schedule. Pointer authentication consists of address authentication and generic authentication, and CPUs in a system might have varied support for either. Where support for either feature is not uniform, it is hidden from guests via ID register emulation, as a result of the cpufeature framework in the host. Unfortunately, address authentication and generic authentication cannot be trapped separately, as the architecture provides a single EL2 trap covering both. If we wish to expose one without the other, we cannot prevent a (badly-written) guest from intermittently using a feature which is not uniformly supported (when scheduled on a physical CPU which supports the relevant feature). Hence, this patch expects both type of authentication to be present in a cpu. Signed-off-by: Mark Rutland [Only VHE, key switch from from assembly, kvm_supports_ptrauth checks, save host key in vcpu_load] Hmm, why do we need to do the key switch in assembly, given it's not used in-kernel right now? Is that in preparation for in-kernel pointer auth usage? If so, please call that out in the commit message. [...] Huh, so we're actually doing the switch in C code... # KVM code is run at a different exception code with a different map, so # compiler instrumentation that inserts callbacks or checks into the code may diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S index 675fdc1..b78cc15 100644 --- a/arch/arm64/kvm/hyp/entry.S +++ b/arch/arm64/kvm/hyp/entry.S @@ -64,6 +64,12 @@ ENTRY(__guest_enter) add x18, x0, #VCPU_CONTEXT +#ifdef CONFIG_ARM64_PTR_AUTH + // Prepare parameter for __ptrauth_switch_to_guest(vcpu, host, guest). + mov x2, x18 + bl __ptrauth_switch_to_guest +#endif ... and conditionally *calling* that switch code from assembly ... + // Restore guest regs x0-x17 ldp x0, x1, [x18, #CPU_XREG_OFFSET(0)] ldp x2, x3, [x18, #CPU_XREG_OFFSET(2)] @@ -118,6 +124,17 @@ ENTRY(__guest_exit) get_host_ctxt x2, x3 +#ifdef CONFIG_ARM64_PTR_AUTH + // Prepare parameter for __ptrauth_switch_to_host(vcpu, guest, host). + // Save x0, x2 which are used later in callee saved registers. + mov x19, x0 + mov x20, x2 + sub x0, x1, #VCPU_CONTEXT + ldr x29, [x2, #CPU_XREG_OFFSET(29)] + bl __ptrauth_switch_to_host + mov x0, x19 + mov x2, x20 +#endif ... which adds a load of boilerplate for no immediate gain. Do we really need to do this in assembly today? If we will need to move this to assembly when we add in-kernel ptrauth support, it may be best to have it in assembly from the start, to reduce unnecessary churn. But having a mix of C and assembly is likely to make things more complicated: we should go with one or the other IMHO. ok, I will check on this. Thanks, Amit D Cheers ---Dave
[PATCH RFT] regulator: lp87565: Fix missing register for LP87565_BUCK_0
LP87565_BUCK_0 is missed, fix it.
Fixes: f0168a9bf ("regulator: lp87565: Add support for lp87565 PMIC regulators")
Signed-off-by: Axel Lin
---
Hi J Keerthy,
While reading the code, it seems strange that LP87565_BUCK_0 is never used.
So current code only register 3 BUCKs for lp87565-regulator.
Can you confirm if this fix is correct or not?
Thanks,
Axel
drivers/regulator/lp87565-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/lp87565-regulator.c
b/drivers/regulator/lp87565-regulator.c
index 4ed41731a5b1..0418e478c6dc 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -193,7 +193,7 @@ static int lp87565_regulator_probe(struct platform_device
*pdev)
struct lp87565 *lp87565 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = { };
struct regulator_dev *rdev;
- int i, min_idx = LP87565_BUCK_1, max_idx = LP87565_BUCK_3;
+ int i, min_idx = LP87565_BUCK_0, max_idx = LP87565_BUCK_3;
platform_set_drvdata(pdev, lp87565);
--
2.17.1
Re: [PATCH net-next] net: dsa: Do not configure VLAN ID 0
On 01.03.2019 00:49, Florian Fainelli wrote:
> Because we skip the prepare phase, we would not get a chance to have the
> port_vlan_prepare() callback return -EOPNOTSUPP and tell us about that.
> This causes problems with mv88e6xxx which specifically checks for VLAN
> ID = 0. Turns out we do not actually need to program that VLAN ID since
> it should be the default one for switches anyway.
>
> Reported-by: Heiner Kallweit
> Fixes: 061f6a505ac3 ("net: dsa: Add ndo_vlan_rx_{add, kill}_vid
> implementation")
> Signed-off-by: Florian Fainelli
> ---
> net/dsa/slave.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 1808a2cd6872..ec54d579645a 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -996,6 +996,9 @@ static int dsa_slave_vlan_rx_add_vid(struct net_device
> *dev, __be16 proto,
> struct bridge_vlan_info info;
> int ret;
>
> + if (vid == 0)
> + return 0;
> +
> /* Check for a possible bridge VLAN entry now since there is no
>* need to emulate the switchdev prepare + commit phase.
>*/
> @@ -1029,6 +1032,9 @@ static int dsa_slave_vlan_rx_kill_vid(struct net_device
> *dev, __be16 proto,
> struct bridge_vlan_info info;
> int ret;
>
> + if (vid == 0)
> + return 0;
> +
> /* Check for a possible bridge VLAN entry now since there is no
>* need to emulate the switchdev prepare + commit phase.
>*/
>
Tested-by: Heiner Kallweit
The error has gone. New with the original patch is just the following
message in syslog when bringing the device up. I'm not sure there is
benefit in it (at least for VLAN 0 because it's a no-op).
8021q: adding VLAN 0 to HW filter on device eth_cu_1000_2
Re: [PATCH v6 2/6] arm64/kvm: preserve host MDCR_EL2 value
Hi,
On 2/21/19 9:21 PM, Dave Martin wrote:
On Tue, Feb 19, 2019 at 02:54:27PM +0530, Amit Daniel Kachhap wrote:
Save host MDCR_EL2 value during kvm HYP initialisation and restore
after every switch from host to guest. There should not be any
change in functionality due to this.
The value of mdcr_el2 is now stored in struct kvm_cpu_context as
both host and guest can now use this field in a common way.
Is MDCR_EL2 somehow relevant to pointer auth?
It's not entirely clear why this patch is here.
If this is a cleanup to align the handling of this register with
how HCR_EL2 is handled, it would be good to explain that in the commit
message.
Agreed I will more information in commit message.
Signed-off-by: Amit Daniel Kachhap
Cc: Marc Zyngier
Cc: Mark Rutland
Cc: Christoffer Dall
Cc: kvm...@lists.cs.columbia.edu
---
arch/arm/include/asm/kvm_host.h | 1 -
arch/arm64/include/asm/kvm_host.h | 6 ++
arch/arm64/kvm/debug.c| 28 ++--
arch/arm64/kvm/hyp/switch.c | 17 -
arch/arm64/kvm/hyp/sysreg-sr.c| 6 ++
virt/kvm/arm/arm.c| 1 -
6 files changed, 18 insertions(+), 41 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 05706b4..704667e 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -294,7 +294,6 @@ static inline void kvm_arch_vcpu_uninit(struct kvm_vcpu
*vcpu) {}
static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {}
static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
-static inline void kvm_arm_init_debug(void) {}
static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 1b2e05b..2f1bb86 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -205,6 +205,8 @@ struct kvm_cpu_context {
/* HYP host/guest configuration */
u64 hcr_el2;
+ u32 mdcr_el2;
+
ARMv8-A says MDCR_EL2 is a 64-bit register.
Bits [63:20] are currently RES0, so this is probably not a big deal.
But it would be better to make this 64-bit to prevent future accidents.
It may be better to make that change in a separate patch.
Yes this a potential issue. I will fix it in a separate patch.
Thanks,
Amit D
This is probably non-urgent, since this is clearly not causing problems
for anyone today.
[...]
Cheers
---Dave
A quesiton about commit 3a63f70bf4c3
Hi Chao,
I am back porting this commit to our distrols from tip.
3a63f70bf4c3 x86/boot: Early parse RSDP and save it in boot_params
Findind out those SRAT handling related declarations are out of
BOOT_COMPRESSED_MISC_H ifdeffery. Is this made on purpose?
Saw "misc.h" is included in several places, shouldn't be changed like
below? Please correct me if I was wrong.
Thanks
Baoquan
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index fd13655..252091b 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -120,8 +120,6 @@ static inline void console_init(void)
void set_sev_encryption_mask(void);
-#endif
-
/* acpi.c */
#ifdef CONFIG_ACPI
acpi_physical_address get_rsdp_addr(void);
@@ -135,3 +133,4 @@ int count_immovable_mem_regions(void);
#else
static inline int count_immovable_mem_regions(void) { return 0; }
#endif
+#endif
linux-next: manual merge of the nvdimm tree with the xen-tip tree
Hi all,
[Thanks, Dan for the heads up and resolution.]
Today's linux-next merge of the nvdimm tree got a conflict in:
mm/memory_hotplug.c
between commit:
357b4da50a62 ("x86: respect memory size limiting via mem= parameter")
from the xen-tip tree and commit:
2794129e902d ("mm/memory-hotplug: Allow memory resources to be children")
from the nvdimm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc mm/memory_hotplug.c
index 1f678568ce5c,d2c44146473f..b96a3121b5e9
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@@ -101,28 -99,21 +101,24 @@@ u64 max_mem_size = U64_MAX
/* add this memory to iomem resource */
static struct resource *register_memory_resource(u64 start, u64 size)
{
- struct resource *res, *conflict;
+ struct resource *res;
+ unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
+ char *resource_name = "System RAM";
+ if (start + size > max_mem_size)
+ return ERR_PTR(-E2BIG);
+
- res = kzalloc(sizeof(struct resource), GFP_KERNEL);
- if (!res)
- return ERR_PTR(-ENOMEM);
-
- res->name = "System RAM";
- res->start = start;
- res->end = start + size - 1;
- res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
- conflict = request_resource_conflict(_resource, res);
- if (conflict) {
- if (conflict->desc == IORES_DESC_DEVICE_PRIVATE_MEMORY) {
- pr_debug("Device unaddressable memory block "
-"memory hotplug at %#010llx !\n",
-(unsigned long long)start);
- }
- pr_debug("System RAM resource %pR cannot be added\n", res);
- kfree(res);
+ /*
+* Request ownership of the new memory range. This might be
+* a child of an existing resource that was present but
+* not marked as busy.
+*/
+ res = __request_region(_resource, start, size,
+ resource_name, flags);
+
+ if (!res) {
+ pr_debug("Unable to reserve System RAM region:
%016llx->%016llx\n",
+ start, start + size);
return ERR_PTR(-EEXIST);
}
return res;
pgpIHC7ohLxUK.pgp
Description: OpenPGP digital signature
[PATCH] netfilter: nf_ct_helper: Fix possible panic when nf_conntrack_helper_unregister is used in an unloadable module
From: Su Yanjun Because nf_conntrack_helper_unregister maybe used in an unloadable module, it uses 'synchronize_rcu' which may cause kernel panic. According to the artical: RCU and Unloadable Modules https://lwn.net/Articles/217484/ When we have a heavy rcu callback load, then some of the callbacks might be deferred in order to allow other processing to proceed. sychnorize_rcu does not wait rcu callback complete and module may be unloaded before callback done. This patch uses rcu_barrier instead of synchronize_rcu will prevent this situation. Signed-off-by: Su Yanjun --- net/netfilter/nf_conntrack_helper.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/net/netfilter/nf_conntrack_helper.c b/net/netfilter/nf_conntrack_helper.c index 274baf1..0ee9378 100644 --- a/net/netfilter/nf_conntrack_helper.c +++ b/net/netfilter/nf_conntrack_helper.c @@ -397,8 +397,15 @@ void nf_conntrack_helper_unregister(struct nf_conntrack_helper *me) /* Make sure every nothing is still using the helper unless its a * connection in the hash. +* +* 'synchronize_rcu' may have problem when rcu callback function +* is used in unloadable modules. Use rcu_barrier instead, so that +* it will wait until rcu callback completes before modules are +* unloaded. +* More detail about rcu_barrier please see: +* https://lwn.net/Articles/217484/ */ - synchronize_rcu(); + rcu_barrier(); nf_ct_expect_iterate_destroy(expect_iter_me, NULL); nf_ct_iterate_destroy(unhelp, me); @@ -406,7 +413,7 @@ void nf_conntrack_helper_unregister(struct nf_conntrack_helper *me) /* Maybe someone has gotten the helper already when unhelp above. * So need to wait it. */ - synchronize_rcu(); + rcu_barrier(); } EXPORT_SYMBOL_GPL(nf_conntrack_helper_unregister); -- 2.7.4
Re: [PATCH v6 1/6] arm64/kvm: preserve host HCR_EL2 value
Hi,
On 2/21/19 9:19 PM, Dave Martin wrote:
On Tue, Feb 19, 2019 at 02:54:26PM +0530, Amit Daniel Kachhap wrote:
From: Mark Rutland
When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
is a constant value. This works today, as the host HCR_EL2 value is
always the same, but this will get in the way of supporting extensions
that require HCR_EL2 bits to be set conditionally for the host.
To allow such features to work without KVM having to explicitly handle
every possible host feature combination, this patch has KVM save/restore
for the host HCR when switching to/from a guest HCR. The saving of the
register is done once during cpu hypervisor initialization state and is
just restored after switch from guest.
For fetching HCR_EL2 during kvm initialisation, a hyp call is made using
kvm_call_hyp and is helpful in NHVE case.
Minor nit: NVHE misspelled. This looks a bit like it's naming an arch
feature rather than a kernel implementation detail though. Maybe write
"non-VHE".
yes.
For the hyp TLB maintenance code, __tlb_switch_to_host_vhe() is updated
to toggle the TGE bit with a RMW sequence, as we already do in
__tlb_switch_to_guest_vhe().
The value of hcr_el2 is now stored in struct kvm_cpu_context as both host
and guest can now use this field in a common way.
Signed-off-by: Mark Rutland
[Added __cpu_copy_hyp_conf, hcr_el2 field in struct kvm_cpu_context]
Signed-off-by: Amit Daniel Kachhap
Cc: Marc Zyngier
Cc: Christoffer Dall
Cc: kvm...@lists.cs.columbia.edu
---
arch/arm/include/asm/kvm_host.h | 2 ++
arch/arm64/include/asm/kvm_asm.h | 2 ++
arch/arm64/include/asm/kvm_emulate.h | 22 +++---
arch/arm64/include/asm/kvm_host.h| 13 -
arch/arm64/include/asm/kvm_hyp.h | 2 +-
arch/arm64/kvm/guest.c | 2 +-
arch/arm64/kvm/hyp/switch.c | 23 +--
arch/arm64/kvm/hyp/sysreg-sr.c | 21 -
arch/arm64/kvm/hyp/tlb.c | 6 +-
virt/kvm/arm/arm.c | 1 +
10 files changed, 68 insertions(+), 26 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index ca56537..05706b4 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -273,6 +273,8 @@ static inline void __cpu_init_stage2(void)
kvm_call_hyp(__init_stage2_translation);
}
+static inline void __cpu_copy_hyp_conf(void) {}
+
static inline int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, long ext)
{
return 0;
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index f5b79e9..8acd73f 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -80,6 +80,8 @@ extern void __vgic_v3_init_lrs(void);
extern u32 __kvm_get_mdcr_el2(void);
+extern void __kvm_populate_host_regs(void);
+
/* Home-grown __this_cpu_{ptr,read} variants that always work at HYP */
#define __hyp_this_cpu_ptr(sym)
\
({ \
diff --git a/arch/arm64/include/asm/kvm_emulate.h
b/arch/arm64/include/asm/kvm_emulate.h
index 506386a..0dbe795 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -50,25 +50,25 @@ void kvm_inject_pabt32(struct kvm_vcpu *vcpu, unsigned long
addr);
static inline bool vcpu_el1_is_32bit(struct kvm_vcpu *vcpu)
{
- return !(vcpu->arch.hcr_el2 & HCR_RW);
+ return !(vcpu->arch.ctxt.hcr_el2 & HCR_RW);
Putting hcr_el2 into struct kvm_cpu_context creates a lot of splatter
here, and I'm wondering whether it's really necessary. Otherwise,
we could just put the per-vcpu guest HCR_EL2 value in struct
kvm_vcpu_arch.
I did like that in V4 version [1] but comments were raised that this was
repetition of hcr_el2 field in 2 places and may be avoided.
[1]: https://lkml.org/lkml/2019/1/4/433
Is the *host* hcr_el2 value really different per-vcpu? That looks
odd. I would have thought this is fixed across the system at KVM
startup time.
Having a single global host hcr_el2 would also avoid the need for
__kvm_populate_host_regs(): instead, we just decide what HCR_EL2 is to
be ahead of time and set a global variable that we map into Hyp.
Or does the host HCR_EL2 need to vary at runtime for some reason I've
missed?
This patch basically makes host hcr_el2 not to use fixed values like
HCR_HOST_NVHE_FLAGS/HCR_HOST_VHE_FLAGS during context switch and hence
saves those values at boot time. This patch is just preparation to
configure host hcr_el2 dynamically. However currently it is same for all
cpus.
I suppose it is better to have host hcr_el2 as percpu to take care of
heterogeneous systems. Currently even host mdcr_el2 is stored on percpu
basis(arch/arm64/kvm/debug.c).
[...]
+void __hyp_text __kvm_populate_host_regs(void)
+{
+ struct kvm_cpu_context
Re: [linux-sunxi] [PATCH v2 00/10] Allwinner sunxi message box support
On Thu, Feb 28, 2019 at 11:29:37PM -0600, Samuel Holland wrote: > This series adds support for the "hardware message box" in sun8i, sun9i, > and sun50i SoCs, used for communication with the ARISC management > processor (the platform's equivalent of the ARM SCP). The end goal is to > use the arm_scpi driver as a client, communicating with firmware running > on the ARISC CPU, or to use the mailbox to forward NMIs that the > firmware picks up from R_INTC. > > Changes from v1: > - Marked message box clocks as critical instead of hacks in the driver > - 8 unidirectional channels instead of 4 bidirectional pairs > - Use per-SoC compatible strings and an A31 fallback compatible > - Dropped the mailbox framework patch > - Include DT patches for SoCs that document the message box > > Samuel Holland (10): > clk: sunxi-ng: sun8i: Mark the msgbox clock as critical > clk: sunxi-ng: sun9i: Mark the msgbox clock as critical > clk: sunxi-ng: sun50i: Mark the msgbox clock as critical > dt-bindings: mailbox: Add a sunxi message box binding > mailbox: sunxi-msgbox: Add a new mailbox driver > ARM: dts: sunxi: a80: Add msgbox node > ARM: dts: sunxi: a83t: Add msgbox node > ARM: dts: sunxi: h3/h5: Add msgbox node > arm64: dts: allwinner: a64: Add msgbox node > arm64: dts: allwinner: h6: Add msgbox node > > .../bindings/mailbox/sunxi-msgbox.txt | 44 +++ > arch/arm/boot/dts/sun8i-a83t.dtsi | 10 + > arch/arm/boot/dts/sun9i-a80.dtsi | 10 + > arch/arm/boot/dts/sunxi-h3-h5.dtsi| 10 + > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 + > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 + > drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 +- > drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 2 +- > drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 2 +- > drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 2 +- > drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 2 +- > drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 2 +- > drivers/clk/sunxi-ng/ccu-sun9i-a80.c | 2 +- > drivers/mailbox/Kconfig | 11 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/sunxi-msgbox.c| 315 ++ > 16 files changed, 429 insertions(+), 7 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mailbox/sunxi-msgbox.txt > create mode 100644 drivers/mailbox/sunxi-msgbox.c Hello Appart from applying/compiling/booting, does it exists some way to test it ? check it works ? Regards
Re: [PATCH] drm/virtio: Allow userspace to mmap() framebuffer
On Thu, Feb 28, 2019 at 10:47:41AM -0600, Joshua Watt wrote: > Reports the size of the virtgpu framebuffer to userspace and installs > the deferred I/O handlers so that userspace can mmap() and write to it. Fixed already, as side effect of switching virtio to the generic fbdev emulation. Patches are in the drm-misc-next branch and should land upstream in the 5.1 merge window. cheers, Gerd
[git pull] drm fixes for 5.0 final
Hi Linus, Three final fixes, one for a feature that is new in this kernel, one bochs fix for qemu riscv and one atomic modesetting fix. I've left a few of the other late fixes until next as I didn't want to throw in anything that wasn't really necessary. Dave. drm-fixes-2019-03-01: drm amdgfx, bochs and one core fix The following changes since commit 5908e6b738e3357af42c10e1183753c70a0117a9: Linux 5.0-rc8 (2019-02-24 16:46:45 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-03-01 for you to fetch changes up to 17fb465f16027ea5b282295f5b8af19992e0: drm/bochs: Fix the ID mismatch error (2019-02-28 14:05:33 +1000) drm amdgfx, bochs and one core fix Alistair Francis (1): drm/bochs: Fix the ID mismatch error Dave Airlie (1): Merge branch 'drm-fixes-5.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Mario Kleiner (1): drm/amd/display: Use vrr friendly pageflip throttling in DC. Nicholas Kazlauskas (1): drm: Block fb changes for async plane updates drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 27 +++ drivers/gpu/drm/bochs/bochs_drv.c | 4 drivers/gpu/drm/drm_atomic_helper.c | 9 4 files changed, 37 insertions(+), 4 deletions(-)
Re: [PATCH] jbd2: jbd2_get_transaction does not need to return a value
On Tue, Feb 26, 2019 at 05:35:04PM +0100, Jan Kara wrote: > On Wed 27-02-19 00:07:27, Liu Song wrote: > > In jbd2_get_transaction, a new transaction is initialized, > > and set to the j_running_transaction. No need for a return > > value, so remove it. > > Also, adjust some comments to match the actual operation > > of this function. > > > > Signed-off-by: Liu Song > > Looks good. You can add: > > Reviewed-by: Jan Kara Thanks, applied. - Ted
RE: [PATCH net-next 0/8] Introducing subdev bus and devlink extension
> -Original Message- > From: Parav Pandit > Sent: Thursday, February 28, 2019 11:36 PM > To: net...@vger.kernel.org; linux-kernel@vger.kernel.org; > michal.l...@markovi.net; da...@davemloft.net; > gre...@linuxfoundation.org; Jiri Pirko > Cc: Parav Pandit > Subject: [PATCH net-next 0/8] Introducing subdev bus and devlink extension Please discard this one email which was sent out as PATCH. Sending it RFC shortly.
[RFC net-next 2/8] subdev: Introduce pm callbacks
Keep power management callbacks in place to optionally notify drivers
who register them.
Signed-off-by: Parav Pandit
---
drivers/subdev/subdev_main.c | 59
1 file changed, 59 insertions(+)
diff --git a/drivers/subdev/subdev_main.c b/drivers/subdev/subdev_main.c
index 4aabcaa..e213331 100644
--- a/drivers/subdev/subdev_main.c
+++ b/drivers/subdev/subdev_main.c
@@ -23,10 +23,69 @@ static int subdev_bus_match(struct device *dev, struct
device_driver *drv)
return 0;
}
+static int subdev_pm_prepare(struct device *dev)
+{
+ if (dev->driver->pm && dev->driver->pm->prepare)
+ return dev->driver->pm->prepare(dev);
+ return 0;
+}
+
+static void subdev_pm_complete(struct device *dev)
+{
+ if (dev->driver->pm && dev->driver->pm->complete)
+ dev->driver->pm->complete(dev);
+}
+
+static int subdev_pm_suspend(struct device *dev)
+{
+ if (dev->driver->pm && dev->driver->pm->suspend)
+ return dev->driver->pm->suspend(dev);
+ return 0;
+}
+
+static int subdev_pm_suspend_late(struct device *dev)
+{
+ if (dev->driver->pm && dev->driver->pm->suspend_late)
+ return dev->driver->pm->suspend_late(dev);
+ return 0;
+}
+
+static int subdev_pm_resume(struct device *dev)
+{
+ if (dev->driver->pm && dev->driver->pm->resume)
+ return dev->driver->pm->resume(dev);
+ return 0;
+}
+
+static int subdev_pm_freeze(struct device *dev)
+{
+ if (dev->driver->pm && dev->driver->pm->freeze)
+ return dev->driver->pm->freeze(dev);
+ return 0;
+}
+
+static int subdev_pm_freeze_late(struct device *dev)
+{
+ if (dev->driver->pm && dev->driver->pm->freeze_late)
+ return dev->driver->pm->freeze_late(dev);
+ return 0;
+}
+
+static const struct dev_pm_ops subdev_dev_pm_ops = {
+ .prepare = subdev_pm_prepare,
+ .complete = subdev_pm_complete,
+ .suspend = subdev_pm_suspend,
+ .suspend_late = subdev_pm_suspend_late,
+ .resume = subdev_pm_resume,
+ .freeze = subdev_pm_freeze,
+ .freeze_late = subdev_pm_freeze_late,
+};
+
static struct bus_type subdev_bus_type = {
.dev_name = "subdev",
.name = "subdev",
.match = subdev_bus_match,
+ .pm = _dev_pm_ops,
};
int __subdev_register_driver(struct subdev_driver *drv, struct module *owner,
--
1.8.3.1
[RFC net-next 3/8] modpost: Add support for subdev device id table
Add support to parse subdev module device id table.
Signed-off-by: Parav Pandit
---
scripts/mod/devicetable-offsets.c | 4
scripts/mod/file2alias.c | 15 +++
2 files changed, 19 insertions(+)
diff --git a/scripts/mod/devicetable-offsets.c
b/scripts/mod/devicetable-offsets.c
index 2930044..77f6b6e 100644
--- a/scripts/mod/devicetable-offsets.c
+++ b/scripts/mod/devicetable-offsets.c
@@ -225,5 +225,9 @@ int main(void)
DEVID_FIELD(typec_device_id, svid);
DEVID_FIELD(typec_device_id, mode);
+ DEVID(subdev_id);
+ DEVID_FIELD(subdev_id, vendor_id);
+ DEVID_FIELD(subdev_id, device_id);
+
return 0;
}
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index a37af7d..be89e8e 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1287,6 +1287,20 @@ static int do_typec_entry(const char *filename, void
*symval, char *alias)
return 1;
}
+/* Looks like: subdev:vNdN. */
+static int do_subdev_entry(const char *filename, void *symval, char *alias)
+{
+ DEF_FIELD(symval, subdev_id, vendor_id);
+ DEF_FIELD(symval, subdev_id, device_id);
+
+ strcpy(alias, "subdev:");
+ ADD(alias, "v", 1, vendor_id);
+ ADD(alias, "d", 1, device_id);
+
+ add_wildcard(alias);
+ return 1;
+}
+
/* Does namelen bytes of name exactly match the symbol? */
static bool sym_is(const char *name, unsigned namelen, const char *symbol)
{
@@ -1357,6 +1371,7 @@ static void do_table(void *symval, unsigned long size,
{"fslmc", SIZE_fsl_mc_device_id, do_fsl_mc_entry},
{"tbsvc", SIZE_tb_service_id, do_tbsvc_entry},
{"typec", SIZE_typec_device_id, do_typec_entry},
+ {"subdev", SIZE_subdev_id, do_subdev_entry},
};
/* Create MODULE_ALIAS() statements.
--
1.8.3.1
[RFC net-next 5/8] devlink: Add variant of devlink_register/unregister
Add variants of devlink_register and devlink_unregister which doesn't
explicitly acquire/release devlink_mutex lock, but requires that caller
hold the devlink_mutex lock.
This is required to create child devlink devices while working on
parent devlink device.
Change-Id: I74417158144b28ff51ecfb2d1105c83ebefdf985
Signed-off-by: Parav Pandit
---
include/net/devlink.h | 15 ++-
net/core/devlink.c| 36 +++-
2 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index ae5e0e6..9a067b1 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -545,7 +545,9 @@ static inline struct devlink *priv_to_devlink(void *priv)
void devlink_init(struct devlink *devlink, const struct devlink_ops *ops);
void devlink_cleanup(struct devlink *devlink);
struct devlink *devlink_alloc(const struct devlink_ops *ops, size_t priv_size);
+void __devlink_register(struct devlink *devlink, struct device *dev);
int devlink_register(struct devlink *devlink, struct device *dev);
+void __devlink_unregister(struct devlink *devlink);
void devlink_unregister(struct devlink *devlink);
void devlink_free(struct devlink *devlink);
int devlink_port_register(struct devlink *devlink,
@@ -713,6 +715,7 @@ int devlink_health_report(struct devlink_health_reporter
*reporter,
static inline void devlink_init(struct devlink *devlink,
const struct devlink_ops *ops)
+{
}
static inline void devlink_cleanup(struct devlink *devlink)
@@ -725,11 +728,21 @@ static inline struct devlink *devlink_alloc(const struct
devlink_ops *ops,
return kzalloc(sizeof(struct devlink) + priv_size, GFP_KERNEL);
}
-static inline int devlink_register(struct devlink *devlink, struct device *dev)
+static inline void __devlink_register(struct devlink *devlink,
+ struct device *dev)
+{
+}
+
+static inline int devlink_register(struct devlink *devlink,
+ struct device *dev)
{
return 0;
}
+static inline void __devlink_unregister(struct devlink *devlink)
+{
+}
+
static inline void devlink_unregister(struct devlink *devlink)
{
}
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 25492c6..cfbad2c 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -5262,22 +5262,49 @@ struct devlink *devlink_alloc(const struct devlink_ops
*ops, size_t priv_size)
EXPORT_SYMBOL_GPL(devlink_alloc);
/**
- * devlink_register - Register devlink instance
+ * __devlink_register - Register devlink instance
+ * Caller must hold devlink_mutex.
*
* @devlink: devlink
*/
-int devlink_register(struct devlink *devlink, struct device *dev)
+void __devlink_register(struct devlink *devlink, struct device *dev)
{
- mutex_lock(_mutex);
+ lockdep_assert_held(_mutex);
devlink->dev = dev;
list_add_tail(>list, _list);
devlink_notify(devlink, DEVLINK_CMD_NEW);
+}
+EXPORT_SYMBOL_GPL(__devlink_register);
+
+/**
+ * devlink_register - Register devlink instance
+ *
+ * @devlink: devlink
+ */
+int devlink_register(struct devlink *devlink, struct device *dev)
+{
+ mutex_lock(_mutex);
+ __devlink_register(devlink, dev);
mutex_unlock(_mutex);
return 0;
}
EXPORT_SYMBOL_GPL(devlink_register);
/**
+ * __devlink_unregister - Unregister devlink instance
+ * Caller must hold the devlink_mutex while invoking this API.
+ *
+ * @devlink: devlink
+ */
+void __devlink_unregister(struct devlink *devlink)
+{
+ lockdep_assert_held(_mutex);
+ devlink_notify(devlink, DEVLINK_CMD_DEL);
+ list_del(>list);
+}
+EXPORT_SYMBOL_GPL(__devlink_unregister);
+
+/**
* devlink_unregister - Unregister devlink instance
*
* @devlink: devlink
@@ -5285,8 +5312,7 @@ int devlink_register(struct devlink *devlink, struct
device *dev)
void devlink_unregister(struct devlink *devlink)
{
mutex_lock(_mutex);
- devlink_notify(devlink, DEVLINK_CMD_DEL);
- list_del(>list);
+ __devlink_unregister(devlink);
mutex_unlock(_mutex);
}
EXPORT_SYMBOL_GPL(devlink_unregister);
--
1.8.3.1
[RFC net-next 1/8] subdev: Introducing subdev bus
Introduce a new subdev bus which holds sub devices created from a
primary device. These devices are named as 'subdev'.
A subdev is identified similarly to pci device using 16-bit vendor id
and device id.
Unlike PCI devices, scope of subdev is limited to Linux kernel.
A central entry that assigns unique subdev vendor and device id is:
include/linux/subdev_ids.h enums. Enum are chosen over define macro so
that two vendors do not end up with vendor id in kernel development
process.
subdev bus holds subdevices of multiple devices. A typical created
subdev for a PCI device in sysfs tree appears under their parent's
device as using core's default device naming scheme:
subdev.
i.e.
subdev0
subdev1
$ ls -l /sys/bus/pci/devices/:05:00.0
[..]
drwxr-xr-x 4 root root0 Feb 13 15:57 subvdev0
drwxr-xr-x 4 root root0 Feb 13 15:57 subvdev1
Device model view:
--
+--++--+ +--+
|subdev||subdev| |subdev|
-| 1 || 2 |---| 3 |--
|+--|---++-|+ +--|---+ |
|--|---subdev bus--|--
| | |
+--++-+ +---+---+
|pcidev | |pcidev |
-| A |-| B |--
|+---+ +---+ |
---pci bus
subdev are allocated and freed using subdev_alloc(), subdev_free() APIs.
A driver which wants to create actual class driver such as
net/block/infiniband need to use subdev_register_driver(),
subdev_unregister_driver() APIs.
Signed-off-by: Parav Pandit
---
drivers/Kconfig | 2 +
drivers/Makefile| 1 +
drivers/subdev/Kconfig | 12
drivers/subdev/Makefile | 8 +++
drivers/subdev/subdev_main.c| 153
include/linux/mod_devicetable.h | 12
include/linux/subdev_bus.h | 63 +
include/linux/subdev_ids.h | 17 +
8 files changed, 268 insertions(+)
create mode 100644 drivers/subdev/Kconfig
create mode 100644 drivers/subdev/Makefile
create mode 100644 drivers/subdev/subdev_main.c
create mode 100644 include/linux/subdev_bus.h
create mode 100644 include/linux/subdev_ids.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 4f9f990..1818796 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -228,4 +228,6 @@ source "drivers/siox/Kconfig"
source "drivers/slimbus/Kconfig"
+source "drivers/subdev/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index e1ce029..a040e96 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -186,3 +186,4 @@ obj-$(CONFIG_MULTIPLEXER) += mux/
obj-$(CONFIG_UNISYS_VISORBUS) += visorbus/
obj-$(CONFIG_SIOX) += siox/
obj-$(CONFIG_GNSS) += gnss/
+obj-$(CONFIG_SUBDEV) += subdev/
diff --git a/drivers/subdev/Kconfig b/drivers/subdev/Kconfig
new file mode 100644
index 000..8ce3acc
--- /dev/null
+++ b/drivers/subdev/Kconfig
@@ -0,0 +1,12 @@
+#
+# subdev configuration
+#
+
+config SUBDEV
+ tristate "subdev bus driver"
+ help
+ The subdev bus driver allows creating hardware based sub devices
+ from a parent device. The subdev bus driver is required to create,
+ discover devices and to attach device drivers to this subdev
+ devices. These subdev devices are created using devlink tool by
+ user.
diff --git a/drivers/subdev/Makefile b/drivers/subdev/Makefile
new file mode 100644
index 000..405b74a
--- /dev/null
+++ b/drivers/subdev/Makefile
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for subdev bus driver
+#
+
+obj-$(CONFIG_SUBDEV) += subdev.o
+
+subdev-y := subdev_main.o
diff --git a/drivers/subdev/subdev_main.c b/drivers/subdev/subdev_main.c
new file mode 100644
index 000..4aabcaa
--- /dev/null
+++ b/drivers/subdev/subdev_main.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+#include
+
+static DEFINE_XARRAY_FLAGS(subdev_ids, XA_FLAGS_ALLOC);
+
+static int subdev_bus_match(struct device *dev, struct device_driver *drv)
+{
+ struct subdev_driver *subdev_drv = to_subdev_driver(drv);
+ const struct subdev_id *ids = subdev_drv->id_table;
+ const struct subdev *subdev = to_subdev_device(dev);
+
+ while (ids) {
+ if (ids->vendor_id == subdev->dev_id.vendor_id &&
+ ids->device_id == subdev->dev_id.device_id)
+ return 1;
+
+ ids++;
+ }
+ return 0;
+}
+
+static struct bus_type subdev_bus_type = {
+ .dev_name = "subdev",
+ .name = "subdev",
+ .match = subdev_bus_match,
+};
+
+int __subdev_register_driver(struct subdev_driver *drv, struct module *owner,
+
[RFC net-next 6/8] devlink: Add support for devlink subdev lifecycle
Add support for creating and deleting devlink subdevices.
For every subdev created on subdev bus, has corresponding devlink device.
This devlink device serves the control point for any internal device
configuration which is usually required before setting up the protocol
specific devices such as netdev, block or infiniband devices.
devlink subdev are created using iproute2 devlink tool command such as:
(a) create devlink subdev
$devlink dev add DEV
output: subdev/subdev0
(b) delete a devlink subdev
$devlink dev del DEV
$devlink dev del subdev/subdev0
Signed-off-by: Parav Pandit
---
include/net/devlink.h| 6 ++-
include/uapi/linux/devlink.h | 3 ++
net/core/devlink.c | 97 ++--
3 files changed, 102 insertions(+), 4 deletions(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 9a067b1..3265508 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -36,6 +36,7 @@ struct devlink {
struct device *dev;
possible_net_t _net;
struct mutex lock;
+ struct devlink *parent; /* optional if this is child devlink device */
char priv[0] __aligned(NETDEV_ALIGN);
};
@@ -524,6 +525,8 @@ struct devlink_ops {
int (*flash_update)(struct devlink *devlink, const char *file_name,
const char *component,
struct netlink_ext_ack *extack);
+ struct devlink* (*dev_add)(struct devlink *devlink);
+ void (*dev_del)(struct devlink *del_dev);
};
static inline void *devlink_priv(struct devlink *devlink)
@@ -545,7 +548,8 @@ static inline struct devlink *priv_to_devlink(void *priv)
void devlink_init(struct devlink *devlink, const struct devlink_ops *ops);
void devlink_cleanup(struct devlink *devlink);
struct devlink *devlink_alloc(const struct devlink_ops *ops, size_t priv_size);
-void __devlink_register(struct devlink *devlink, struct device *dev);
+int __devlink_register(struct devlink *devlink, struct device *dev,
+ struct devlink *parent);
int devlink_register(struct devlink *devlink, struct device *dev);
void __devlink_unregister(struct devlink *devlink);
void devlink_unregister(struct devlink *devlink);
diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
index 53de880..233f5bc 100644
--- a/include/uapi/linux/devlink.h
+++ b/include/uapi/linux/devlink.h
@@ -105,6 +105,9 @@ enum devlink_command {
DEVLINK_CMD_FLASH_UPDATE,
+ DEVLINK_CMD_DEV_ADD,
+ DEVLINK_CMD_DEV_DEL,
+
/* add new commands above here */
__DEVLINK_CMD_MAX,
DEVLINK_CMD_MAX = __DEVLINK_CMD_MAX - 1
diff --git a/net/core/devlink.c b/net/core/devlink.c
index cfbad2c..3b5c961 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -3759,6 +3759,57 @@ static int devlink_nl_cmd_region_read_dumpit(struct
sk_buff *skb,
return err;
}
+static int
+devlink_nl_cmd_dev_add_doit(struct sk_buff *skb, struct genl_info *info)
+{
+ struct devlink *devlink = info->user_ptr[0];
+ struct devlink *new_devlink;
+ struct sk_buff *msg;
+ int err;
+
+ if (!devlink->ops->dev_add || !devlink->ops->dev_del)
+ return -EOPNOTSUPP;
+
+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+ if (!msg)
+ return -ENOMEM;
+
+ new_devlink = devlink->ops->dev_add(devlink);
+ if (IS_ERR(new_devlink)) {
+ err = PTR_ERR(new_devlink);
+ goto dev_err;
+ }
+
+ err = devlink_nl_put_handle(msg, new_devlink);
+ if (err)
+ goto put_err;
+
+ return genlmsg_reply(msg, info);
+
+put_err:
+ devlink->ops->dev_del(new_devlink);
+dev_err:
+ nlmsg_free(msg);
+ return err;
+}
+
+static int
+devlink_nl_cmd_dev_del_doit(struct sk_buff *skb, struct genl_info *info)
+{
+ struct devlink *devlink;
+ struct devlink *parent;
+
+ devlink = devlink_get_from_info(info);
+ if (!devlink)
+ return -ENODEV;
+ parent = devlink->parent;
+ if (!parent)
+ return -EOPNOTSUPP;
+
+ parent->ops->dev_del(devlink);
+ return 0;
+}
+
struct devlink_info_req {
struct sk_buff *msg;
};
@@ -5201,6 +5252,20 @@ static int
devlink_nl_cmd_health_reporter_dump_get_doit(struct sk_buff *skb,
.flags = GENL_ADMIN_PERM,
.internal_flags = DEVLINK_NL_FLAG_NEED_DEVLINK,
},
+ {
+ .cmd = DEVLINK_CMD_DEV_ADD,
+ .doit = devlink_nl_cmd_dev_add_doit,
+ .policy = devlink_nl_policy,
+ .flags = GENL_ADMIN_PERM,
+ .internal_flags = DEVLINK_NL_FLAG_NEED_DEVLINK,
+ },
+ {
+ .cmd = DEVLINK_CMD_DEV_DEL,
+ .doit = devlink_nl_cmd_dev_del_doit,
+ .policy = devlink_nl_policy,
+ .flags = GENL_ADMIN_PERM,
+ .internal_flags =
[RFC net-next 7/8] net/mlx5: Add devlink subdev life cycle command support
Implement devlink device add/del command which cretes dummy subdev
devices that actual driver can bind to using standard device driver
model.
Signed-off-by: Parav Pandit
---
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 1 +
drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ++
.../net/ethernet/mellanox/mlx5/core/mlx5_core.h| 4 ++
drivers/net/ethernet/mellanox/mlx5/core/subdev.c | 55 ++
4 files changed, 64 insertions(+)
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/subdev.c
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
index 82d636b..f218789 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
@@ -16,6 +16,7 @@ mlx5_core-y :=main.o cmd.o debugfs.o fw.o eq.o uar.o
pagealloc.o \
transobj.o vport.o sriov.o fs_cmd.o fs_core.o \
fs_counters.o rl.o lag.o dev.o events.o wq.o lib/gid.o \
lib/devcom.o diag/fs_tracepoint.o diag/fw_tracer.o
+mlx5_core-$(CONFIG_SUBDEV) += subdev.o
#
# Netdev basic
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 40d591c..5f8cf0d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1213,6 +1213,10 @@ static int mlx5_unload_one(struct mlx5_core_dev *dev,
struct mlx5_priv *priv,
.eswitch_encap_mode_set = mlx5_devlink_eswitch_encap_mode_set,
.eswitch_encap_mode_get = mlx5_devlink_eswitch_encap_mode_get,
#endif
+#if IS_ENABLED(CONFIG_SUBDEV)
+ .dev_add = mlx5_devlink_dev_add,
+ .dev_del = mlx5_devlink_dev_del,
+#endif
};
#define MLX5_IB_MOD "mlx5_ib"
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
b/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
index 9529cf9..2a54148 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
@@ -202,4 +202,8 @@ enum {
u8 mlx5_get_nic_state(struct mlx5_core_dev *dev);
void mlx5_set_nic_state(struct mlx5_core_dev *dev, u8 state);
+
+struct devlink *mlx5_devlink_dev_add(struct devlink *devlink);
+void mlx5_devlink_dev_del(struct devlink *devlink);
+
#endif /* __MLX5_CORE_H__ */
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/subdev.c
b/drivers/net/ethernet/mellanox/mlx5/core/subdev.c
new file mode 100644
index 000..9e78ea01
--- /dev/null
+++ b/drivers/net/ethernet/mellanox/mlx5/core/subdev.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB
+// Copyright (c) 2018-19 Mellanox Technologies
+
+#include
+#include
+#include
+#include
+
+#include "mlx5_core.h"
+
+struct mlx5_subdev {
+ struct subdev subdev;
+ struct devlink dl;
+};
+
+struct devlink *mlx5_devlink_dev_add(struct devlink *devlink)
+{
+ struct mlx5_subdev *subdev;
+ int ret;
+
+ subdev = subdev_alloc_dev(mlx5_subdev, subdev);
+ if (!subdev)
+ return ERR_PTR(-ENOMEM);
+
+ devlink_init(>dl, NULL);
+
+ ret = subdev_add_dev(>subdev, devlink->dev,
+SUBDEV_VENDOR_ID_MELLANOX,
+SUBDEV_DEVICE_ID_MELLANOX_SF);
+ if (ret)
+ goto add_err;
+
+ ret = __devlink_register(>dl, >subdev.dev, devlink);
+ if (ret)
+ goto reg_err;
+
+ return >dl;
+
+reg_err:
+ devlink_cleanup(>dl);
+add_err:
+ subdev_free_dev(>subdev);
+ return ERR_PTR(ret);
+}
+
+void mlx5_devlink_dev_del(struct devlink *devlink)
+{
+ struct mlx5_subdev *subdev =
+ container_of(devlink, struct mlx5_subdev, dl);
+
+ __devlink_unregister(devlink);
+ devlink_cleanup(devlink);
+ subdev_delete_dev(>subdev);
+ subdev_free_dev(>subdev);
+}
--
1.8.3.1
[RFC net-next 8/8] net/mlx5: Add subdev driver to bind to subdev devices
Add a subdev driver to probe the subdev devices and create fake
netdevice for it.
Signed-off-by: Parav Pandit
---
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 8 +-
.../net/ethernet/mellanox/mlx5/core/mlx5_core.h| 3 +
.../ethernet/mellanox/mlx5/core/subdev_driver.c| 93 ++
4 files changed, 104 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/subdev_driver.c
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
index f218789..c8aeaf1 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Makefile
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Makefile
@@ -16,7 +16,7 @@ mlx5_core-y :=main.o cmd.o debugfs.o fw.o eq.o uar.o
pagealloc.o \
transobj.o vport.o sriov.o fs_cmd.o fs_core.o \
fs_counters.o rl.o lag.o dev.o events.o wq.o lib/gid.o \
lib/devcom.o diag/fs_tracepoint.o diag/fw_tracer.o
-mlx5_core-$(CONFIG_SUBDEV) += subdev.o
+mlx5_core-$(CONFIG_SUBDEV) += subdev.o subdev_driver.o
#
# Netdev basic
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index 5f8cf0d..7dfa8c4 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1548,7 +1548,11 @@ static int __init init(void)
mlx5e_init();
#endif
- return 0;
+ err = subdev_register_driver(_subdev_driver);
+ if (err)
+ pci_unregister_driver(_core_driver);
+
+ return err;
err_debug:
mlx5_unregister_debugfs();
@@ -1557,6 +1561,8 @@ static int __init init(void)
static void __exit cleanup(void)
{
+ subdev_unregister_driver(_subdev_driver);
+
#ifdef CONFIG_MLX5_CORE_EN
mlx5e_cleanup();
#endif
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
b/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
index 2a54148..1b733c7 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
@@ -41,12 +41,15 @@
#include
#include
#include
+#include
#define DRIVER_NAME "mlx5_core"
#define DRIVER_VERSION "5.0-0"
extern uint mlx5_core_debug_mask;
+extern struct subdev_driver mlx5_subdev_driver;
+
#define mlx5_core_dbg(__dev, format, ...) \
dev_dbg(&(__dev)->pdev->dev, "%s:%d:(pid %d): " format, \
__func__, __LINE__, current->pid, \
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/subdev_driver.c
b/drivers/net/ethernet/mellanox/mlx5/core/subdev_driver.c
new file mode 100644
index 000..880aa4f
--- /dev/null
+++ b/drivers/net/ethernet/mellanox/mlx5/core/subdev_driver.c
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018-19 Mellanox Technologies
+
+#include
+#include
+#include
+#include
+#include
+
+struct mlx5_subdev_ndev {
+ struct net_device ndev;
+};
+
+static void mlx5_dma_test(struct device *dev)
+{
+ dma_addr_t pa;
+ void *va;
+
+ va = dma_alloc_coherent(dev, 4096, , GFP_KERNEL);
+ if (va)
+ dma_free_coherent(dev, 4096, va, pa);
+}
+
+static struct net_device *ndev;
+
+static int mlx5e_subdev_open(struct net_device *netdev)
+{
+ return 0;
+}
+
+static int mlx5e_subdev_close(struct net_device *netdev)
+{
+ return 0;
+}
+
+static netdev_tx_t
+mlx5e_subdev_xmit(struct sk_buff *skb, struct net_device *netdev)
+{
+ return NETDEV_TX_BUSY;
+}
+
+const struct net_device_ops mlx5e_subdev_netdev_ops = {
+ .ndo_open= mlx5e_subdev_open,
+ .ndo_stop= mlx5e_subdev_close,
+ .ndo_start_xmit = mlx5e_subdev_xmit,
+};
+
+static int mlx5_subdev_probe(struct device *dev)
+{
+ int err;
+
+ mlx5_dma_test(dev);
+ /* Only one device supported in rfc */
+ if (ndev)
+ return 0;
+
+ ndev = alloc_etherdev_mqs(sizeof(struct mlx5_subdev_ndev), 1, 1);
+ if (!ndev)
+ return -ENOMEM;
+
+ SET_NETDEV_DEV(ndev, dev);
+ ndev->netdev_ops = _subdev_netdev_ops;
+ err = register_netdev(ndev);
+ if (err) {
+ free_netdev(ndev);
+ ndev = NULL;
+ }
+ return err;
+}
+
+static int mlx5_subdev_remove(struct device *dev)
+{
+ if (ndev) {
+ unregister_netdev(ndev);
+ free_netdev(ndev);
+ ndev = NULL;
+ }
+ return 0;
+}
+
+static const struct subdev_id mlx5_subdev_id_table[] = {
+ { .vendor_id = SUBDEV_VENDOR_ID_MELLANOX,
+ .device_id = SUBDEV_DEVICE_ID_MELLANOX_SF },
+ { 0, }
+};
+MODULE_DEVICE_TABLE(subdev, mlx5_subdev_id_table);
+
+struct subdev_driver mlx5_subdev_driver = {
+ .id_table = mlx5_subdev_id_table,
+ .driver.name =
[RFC net-next 4/8] devlink: Introduce and use devlink_init/cleanup() in alloc/free
There is usecase to allocate devlink instance along with other structure
instance.
This is case when struct devlink and struct device are desired to be
part of single structure instance whose life cycle is driven by the life
cycle of the core device.
To support it, have more grandular init/cleanup APIs and reuse them in
existing alloc/free APIs.
Signed-off-by: Parav Pandit
---
include/net/devlink.h | 10 ++
net/core/devlink.c| 50 +-
2 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index a2da49d..ae5e0e6 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -542,6 +542,8 @@ static inline struct devlink *priv_to_devlink(void *priv)
#if IS_ENABLED(CONFIG_NET_DEVLINK)
+void devlink_init(struct devlink *devlink, const struct devlink_ops *ops);
+void devlink_cleanup(struct devlink *devlink);
struct devlink *devlink_alloc(const struct devlink_ops *ops, size_t priv_size);
int devlink_register(struct devlink *devlink, struct device *dev);
void devlink_unregister(struct devlink *devlink);
@@ -709,6 +711,14 @@ int devlink_health_report(struct devlink_health_reporter
*reporter,
#else
+static inline void devlink_init(struct devlink *devlink,
+ const struct devlink_ops *ops)
+}
+
+static inline void devlink_cleanup(struct devlink *devlink)
+{
+}
+
static inline struct devlink *devlink_alloc(const struct devlink_ops *ops,
size_t priv_size)
{
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 04d9855..25492c6 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -5218,21 +5218,16 @@ static int
devlink_nl_cmd_health_reporter_dump_get_doit(struct sk_buff *skb,
};
/**
- * devlink_alloc - Allocate new devlink instance resources
+ * devlink_init - Initialize devlink instance
*
- * @ops: ops
- * @priv_size: size of user private data
+ * @devlink: devlink pointer, which is not allocated using devlink_alloc().
*
- * Allocate new devlink instance resources, including devlink index
- * and name.
+ * When user wants to allocate devlink object along with other objects
+ * in driver such as refcounted using struct device, it is useful to
+ * just init the devlink instance without allocating.
*/
-struct devlink *devlink_alloc(const struct devlink_ops *ops, size_t priv_size)
+void devlink_init(struct devlink *devlink, const struct devlink_ops *ops)
{
- struct devlink *devlink;
-
- devlink = kzalloc(sizeof(*devlink) + priv_size, GFP_KERNEL);
- if (!devlink)
- return NULL;
devlink->ops = ops;
devlink_net_set(devlink, _net);
INIT_LIST_HEAD(>port_list);
@@ -5243,6 +5238,25 @@ struct devlink *devlink_alloc(const struct devlink_ops
*ops, size_t priv_size)
INIT_LIST_HEAD(>region_list);
INIT_LIST_HEAD(>reporter_list);
mutex_init(>lock);
+}
+EXPORT_SYMBOL_GPL(devlink_init);
+
+/**
+ * devlink_alloc - Allocate new devlink instance resources
+ *
+ * @ops: ops
+ * @priv_size: size of user private data
+ *
+ * Allocate new devlink instance resources, including devlink index
+ * and name.
+ */
+struct devlink *devlink_alloc(const struct devlink_ops *ops, size_t priv_size)
+{
+ struct devlink *devlink;
+
+ devlink = kzalloc(sizeof(*devlink) + priv_size, GFP_KERNEL);
+ if (devlink)
+ devlink_init(devlink, ops);
return devlink;
}
EXPORT_SYMBOL_GPL(devlink_alloc);
@@ -5278,11 +5292,11 @@ void devlink_unregister(struct devlink *devlink)
EXPORT_SYMBOL_GPL(devlink_unregister);
/**
- * devlink_free - Free devlink instance resources
+ * devlink_cleanup - Cleanup devlink instance resources
*
* @devlink: devlink
*/
-void devlink_free(struct devlink *devlink)
+void devlink_cleanup(struct devlink *devlink)
{
WARN_ON(!list_empty(>reporter_list));
WARN_ON(!list_empty(>region_list));
@@ -5291,7 +5305,17 @@ void devlink_free(struct devlink *devlink)
WARN_ON(!list_empty(>dpipe_table_list));
WARN_ON(!list_empty(>sb_list));
WARN_ON(!list_empty(>port_list));
+}
+EXPORT_SYMBOL_GPL(devlink_cleanup);
+/**
+ * devlink_free - Free devlink instance resources
+ *
+ * @devlink: devlink
+ */
+void devlink_free(struct devlink *devlink)
+{
+ devlink_cleanup(devlink);
kfree(devlink);
}
EXPORT_SYMBOL_GPL(devlink_free);
--
1.8.3.1
[RFC net-next 0/8] Introducing subdev bus and devlink extension
Use case: - A user wants to create/delete hardware linked sub devices without using SR-IOV. These devices for a pci device can be netdev (optional rdma device) or other devices. Such sub devices share some of the PCI device resources and also have their own dedicated resources. Few examples are: 1. netdev having its own txq(s), rq(s) and/or hw offload parameters. 2. netdev with switchdev mode using netdev representor 3. rdma device with IB link layer and IPoIB netdev 4. rdma/RoCE device and a netdev 5. rdma device with multiple ports Requirements for above use cases: 1. We need a generic user interface & core APIs to create sub devices from a parent pci device but should be generic enough for other parent devices 2. Interface should be vendor agnostic 3. User should be able to set device params at creation time 4. In future if needed, tool should be able to create passthrough device to map to a virtual machine 5. A device can have multiple ports 6. An orchestration software wants to know how many such sub devices can be created from a parent device so that it can manage them in global cluster resources. So how is it done? -- (a) user in control To address above requirements, a generic tool iproute2/devlink is extended for sub device's life cycle. However a devlink tool and its kernel counter part is not sufficient to create protocol agnostic devices on a existing PCI bus. (b) subdev bus A given bus defines well defined addressing scheme. Creating sub devices on existing PCI bus with a different naming scheme is just weird. So, creating well named devices on appropriate bus is desired. Hence a new 'subdev' bus is created. User adds/removes new sub devices subdev on this bus via a devlink tool. devlink tool instructs hardware driver to create/remove/configure such devices. Hardware vendor driver places devices on the bus. Another or same vendor driver matches based on vendor-id, device-id scheme and run through classic device driver model. Given that, these are user created devices for a given hardware and in absence of a central entity like PCISIG to assign vendor and device ids, A unique vendor and device id are maintained as enum in include/linux/subdev_ids.h. subdev bus device names follow default device naming scheme of Linux kernel. It is done as 'subdev' such as, subdev0, subdev3. subdev device inherits its parent's DMA parameters. subdev will follow rich power management infrastructure of core kernel/ So that every vendor driver doesn't have to iterate over its child devices, invent a locking and device anchoring scheme. Patchset summary: - Patch-1, 2 introduces a subdev bus and interface for subdev life cycle. Patch-3 extends modpost tool for module device id table. Patch-4,5,6 implements a devlink vendor driver to add/remove devices. Patch-7 mlx5 driver implements subdev devices and places them on subdev bus. Patch-8 match against the subdev for mlx5 vendor, device id and creates fake netdevice. All patches are only a reference implementation to see RFC in works at devlink, sysfs and device model level. Once RFC looks good, more solid upstreamable version of the implementation will be done. All patches are functional except the last two patches, which just create fake subdev devices and fake netdevice. System example view: $ devlink dev show pci/:05:00.0 $ devlink dev add pci/:05:00.0 $ devlink dev show pci/:05:00.0 subdev/subdev0 sysfs view with subdev: $ ls -l /sys/bus/pci/devices/:05:00.0 [..] drwxr-xr-x 3 root root0 Feb 13 15:57 infiniband -rw-r--r-- 1 root root 4096 Feb 13 15:57 msi_bus drwxr-xr-x 3 root root0 Feb 13 15:57 net drwxr-xr-x 2 root root0 Feb 13 15:57 power drwxr-xr-x 3 root root0 Feb 13 15:57 ptp drwxr-xr-x 4 root root0 Feb 13 15:57 subdev0 $ ls -l /sys/bus/pci/devices/:05:00.0/subdev0 lrwxrwxrwx 1 root root0 Feb 13 15:58 driver -> ../../../../../bus/subdev/drivers/mlx5_core drwxr-xr-x 3 root root0 Feb 13 15:58 net drwxr-xr-x 2 root root0 Feb 13 15:58 power lrwxrwxrwx 1 root root0 Feb 13 15:58 subsystem -> ../../../../../bus/subdev -rw-r--r-- 1 root root 4096 Feb 13 15:58 uevent $ ls -l /sys/bus/pci/devices/:05:00.0/subdev0/net/ drwxr-xr-x 5 root root 0 Feb 13 15:58 eth0 Software view: - Some of you if you prefer to see in picture, below diagram tries to show software modules in bus/device hierarchy. devlink user (iproute2/devlink) -- | | ++ | devlink module | | doit() | +--+ || | | vendor driver | +|---+ | (mlx5) | --+-> subdev_ops() | +|-+ | +-|--+ +---+ +--+ | subdev bus
[PATCH net-next 0/8] Introducing subdev bus and devlink extension
Use case: - A user wants to create/delete hardware linked sub devices without using SR-IOV. These devices for a pci device can be netdev (optional rdma device) or other devices. Such sub devices share some of the PCI device resources and also have their own dedicated resources. Few examples are: 1. netdev having its own txq(s), rq(s) and/or hw offload parameters. 2. netdev with switchdev mode using netdev representor 3. rdma device with IB link layer and IPoIB netdev 4. rdma/RoCE device and a netdev 5. rdma device with multiple ports Requirements for above use cases: 1. We need a generic user interface & core APIs to create sub devices from a parent pci device but should be generic enough for other parent devices 2. Interface should be vendor agnostic 3. User should be able to set device params at creation time 4. In future if needed, tool should be able to create passthrough device to map to a virtual machine 5. A device can have multiple ports 6. An orchestration software wants to know how many such sub devices can be created from a parent device so that it can manage them in global cluster resources. So how is it done? -- (a) user in control To address above requirements, a generic tool iproute2/devlink is extended for sub device's life cycle. However a devlink tool and its kernel counter part is not sufficient to create protocol agnostic devices on a existing PCI bus. (b) subdev bus A given bus defines well defined addressing scheme. Creating sub devices on existing PCI bus with a different naming scheme is just weird. So, creating well named devices on appropriate bus is desired. Hence a new 'subdev' bus is created. User adds/removes new sub devices subdev on this bus via a devlink tool. devlink tool instructs hardware driver to create/remove/configure such devices. Hardware vendor driver places devices on the bus. Another or same vendor driver matches based on vendor-id, device-id scheme and run through classic device driver model. Given that, these are user created devices for a given hardware and in absence of a central entity like PCISIG to assign vendor and device ids, A unique vendor and device id are maintained as enum in include/linux/subdev_ids.h. subdev bus device names follow default device naming scheme of Linux kernel. It is done as 'subdev' such as, subdev0, subdev3. subdev device inherits its parent's DMA parameters. subdev will follow rich power management infrastructure of core kernel/ So that every vendor driver doesn't have to iterate over its child devices, invent a locking and device anchoring scheme. Patchset summary: - Patch-1, 2 introduces a subdev bus and interface for subdev life cycle. Patch-3 extends modpost tool for module device id table. Patch-4,5,6 implements a devlink vendor driver to add/remove devices. Patch-7 mlx5 driver implements subdev devices and places them on subdev bus. Patch-8 match against the subdev for mlx5 vendor, device id and creates fake netdevice. All patches are only a reference implementation to see RFC in works at devlink, sysfs and device model level. Once RFC looks good, more solid upstreamable version of the implementation will be done. All patches are functional except the last two patches, which just create fake subdev devices and fake netdevice. System example view: $ devlink dev show pci/:05:00.0 $ devlink dev add pci/:05:00.0 $ devlink dev show pci/:05:00.0 subdev/subdev0 sysfs view with subdev: $ ls -l /sys/bus/pci/devices/:05:00.0 [..] drwxr-xr-x 3 root root0 Feb 13 15:57 infiniband -rw-r--r-- 1 root root 4096 Feb 13 15:57 msi_bus drwxr-xr-x 3 root root0 Feb 13 15:57 net drwxr-xr-x 2 root root0 Feb 13 15:57 power drwxr-xr-x 3 root root0 Feb 13 15:57 ptp drwxr-xr-x 4 root root0 Feb 13 15:57 subdev0 $ ls -l /sys/bus/pci/devices/:05:00.0/subdev0 lrwxrwxrwx 1 root root0 Feb 13 15:58 driver -> ../../../../../bus/subdev/drivers/mlx5_core drwxr-xr-x 3 root root0 Feb 13 15:58 net drwxr-xr-x 2 root root0 Feb 13 15:58 power lrwxrwxrwx 1 root root0 Feb 13 15:58 subsystem -> ../../../../../bus/subdev -rw-r--r-- 1 root root 4096 Feb 13 15:58 uevent $ ls -l /sys/bus/pci/devices/:05:00.0/subdev0/net/ drwxr-xr-x 5 root root 0 Feb 13 15:58 eth0 Software view: - Some of you if you prefer to see in picture, below diagram tries to show software modules in bus/device hierarchy. devlink user (iproute2/devlink) -- | | ++ | devlink module | | doit() | +--+ || | | vendor driver | +|---+ | (mlx5) | --+-> subdev_ops() | +|-+ | +-|--+ +---+ +--+ | subdev bus
[PATCH v2 04/10] dt-bindings: mailbox: Add a sunxi message box binding
This mailbox hardware is present in Allwinner sun8i, sun9i, and sun50i
SoCs. Add a device tree binding for it.
Signed-off-by: Samuel Holland
---
.../bindings/mailbox/sunxi-msgbox.txt | 44 +++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/sunxi-msgbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/sunxi-msgbox.txt
b/Documentation/devicetree/bindings/mailbox/sunxi-msgbox.txt
new file mode 100644
index ..4560ab8efeca
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/sunxi-msgbox.txt
@@ -0,0 +1,44 @@
+Allwinner sun6i Message Box
+===
+
+The hardware message box on sun6i and newer sunxi SoCs is a two-user mailbox
+controller containing 8 unidirectional FIFOs. An interrupt is raised for
+received messages, but software must poll to know when a transmitted message
has
+been acknowledged by the remote user.
+
+Refer to ./mailbox.txt for generic information about mailbox device-tree
+bindings.
+
+Mailbox Device Node:
+
+
+Required properties:
+
+- compatible: Must contain at least "allwinner,sun6i-a31-msgbox".
+ Should also contain another SoC-specific string when
+ used on other SoCs which are compatible, e.g.
+ - allwinner,sun6i-a31-msgbox
+ - allwinner,sun8i-a83t-msgbox,
allwinner,sun6i-a31-msgbox
+ - allwinner,sun8i-h3-msgbox, allwinner,sun6i-a31-msgbox
+ - allwinner,sun9i-a80-msgbox, allwinner,sun6i-a31-msgbox
+ - allwinner,sun50i-a64-msgbox,
allwinner,sun6i-a31-msgbox
+ - allwinner,sun50i-h6-msgbox, allwinner,sun6i-a31-msgbox
+- reg: Contains the mailbox register address range (base
+ address and length).
+- clocks: phandle for the bus clock controller and specifier.
+- resets: phandle for the bus reset controller and specifier.
+- interrupts: Contains interrupt information for the mailbox.
+- #mbox-cells: Must be 1.
+
+Example:
+
+
+ msgbox: mailbox@1c17000 {
+ compatible = "allwinner,sun8i-h3-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x01c17000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
--
2.19.2
[PATCH v2 01/10] clk: sunxi-ng: sun8i: Mark the msgbox clock as critical
The msgbox clock is critical because the hardware is shared between Linux and system firmware. The message box may be used by the EL3 secure monitor's PSCI implementation. On 64-bit sunxi SoCs, this is provided by ARM TF-A; 32-bit SoCs use a different implementation. The secure monitor uses the message box to forward requests to power management firmware running on a separate CPU. It is not enough for the secure monitor to enable the clock each time Linux performs a SMC into EL3, as both the firmware and Linux can run concurrently on separate CPUs. So it is never safe for Linux to turn this clock off, and it should be marked as critical. At this time, such power management firmware only exists for the H5. However, it makes sense to take care of all CCU drivers now for consistency, and to ease the transition in the future, once firmware is ported to the other SoCs. Signed-off-by: Samuel Holland --- drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 2 +- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 2 +- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 2 +- drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c index a4fa2945f230..22d09cb20326 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c @@ -263,7 +263,7 @@ static SUNXI_CCU_GATE(bus_de_fe_clk,"bus-de-fe", "ahb1", static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu", "ahb1", 0x064, BIT(20), 0); static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "ahb1", - 0x064, BIT(21), 0); + 0x064, BIT(21), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1", 0x064, BIT(22), 0); static SUNXI_CCU_GATE(bus_drc_clk, "bus-drc", "ahb1", diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c index c7bf814dfd2b..6d25b7a1c81e 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c @@ -275,7 +275,7 @@ static SUNXI_CCU_GATE(bus_de_fe_clk,"bus-de-fe", "ahb1", static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu", "ahb1", 0x064, BIT(20), 0); static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "ahb1", - 0x064, BIT(21), 0); + 0x064, BIT(21), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1", 0x064, BIT(22), 0); static SUNXI_CCU_GATE(bus_drc_clk, "bus-drc", "ahb1", diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c index 2d6555d73170..85809c454b1f 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c @@ -347,7 +347,7 @@ static SUNXI_CCU_GATE(bus_de_clk, "bus-de", "ahb1", static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu", "ahb1", 0x064, BIT(20), 0); static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "ahb1", - 0x064, BIT(21), 0); + 0x064, BIT(21), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1", 0x064, BIT(22), 0); diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c index e71e2451c2e3..d09629688fd4 100644 --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c @@ -281,7 +281,7 @@ static SUNXI_CCU_GATE(bus_de_clk, "bus-de", "ahb1", static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu", "ahb1", 0x064, BIT(20), 0); static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "ahb1", - 0x064, BIT(21), 0); + 0x064, BIT(21), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1", 0x064, BIT(22), 0); -- 2.19.2
[PATCH v2 02/10] clk: sunxi-ng: sun9i: Mark the msgbox clock as critical
The msgbox clock is critical because the hardware is shared between Linux and system firmware. The message box may be used by the EL3 secure monitor's PSCI implementation. On 64-bit sunxi SoCs, this is provided by ARM TF-A; 32-bit SoCs use a different implementation. The secure monitor uses the message box to forward requests to power management firmware running on a separate CPU. It is not enough for the secure monitor to enable the clock each time Linux performs a SMC into EL3, as both the firmware and Linux can run concurrently on separate CPUs. So it is never safe for Linux to turn this clock off, and it should be marked as critical. At this time, such power management firmware does not exist for the A80. However, it makes sense to take care of all CCU drivers now for consistency, and to ease the transition in the future, once firmware is ported to this SoC. Signed-off-by: Samuel Holland --- drivers/clk/sunxi-ng/ccu-sun9i-a80.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun9i-a80.c b/drivers/clk/sunxi-ng/ccu-sun9i-a80.c index 8936ef87652c..f9309782e7d8 100644 --- a/drivers/clk/sunxi-ng/ccu-sun9i-a80.c +++ b/drivers/clk/sunxi-ng/ccu-sun9i-a80.c @@ -756,7 +756,7 @@ static SUNXI_CCU_GATE(bus_usb_clk, "bus-usb", "ahb1", static SUNXI_CCU_GATE(bus_gmac_clk,"bus-gmac", "ahb1", 0x584, BIT(17), 0); static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "ahb1", - 0x584, BIT(21), 0); + 0x584, BIT(21), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1", 0x584, BIT(22), 0); static SUNXI_CCU_GATE(bus_hstimer_clk, "bus-hstimer", "ahb1", -- 2.19.2
[PATCH v2 10/10] arm64: dts: allwinner: h6: Add msgbox node
The H6 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index d93a7add67e7..950681b2f7d9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -189,6 +189,16 @@
#interrupt-cells = <3>;
};
+ msgbox: mailbox@3003000 {
+ compatible = "allwinner,sun50i-h6-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x03003000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
pio: pinctrl@300b000 {
compatible = "allwinner,sun50i-h6-pinctrl";
reg = <0x0300b000 0x400>;
--
2.19.2
[PATCH v2 03/10] clk: sunxi-ng: sun50i: Mark the msgbox clock as critical
The msgbox clock is critical because the hardware is shared between Linux and system firmware. The message box may be used by the EL3 secure monitor's PSCI implementation. On 64-bit sunxi SoCs, this is provided by ARM TF-A; 32-bit SoCs use a different implementation. The secure monitor uses the message box to forward requests to power management firmware running on a separate CPU. It is not enough for the secure monitor to enable the clock each time Linux performs a SMC into EL3, as both the firmware and Linux can run concurrently on separate CPUs. So it is never safe for Linux to turn this clock off, and it should be marked as critical. At this time, such power management firmware only exists for the A64. However, it makes sense to take care of all CCU drivers now for consistency, and to ease the transition in the future, once firmware is ported to the other SoCs. Signed-off-by: Samuel Holland --- drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 +- drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c index 932836d26e2b..7780e855c56f 100644 --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c @@ -350,7 +350,7 @@ static SUNXI_CCU_GATE(bus_de_clk, "bus-de", "ahb1", static SUNXI_CCU_GATE(bus_gpu_clk, "bus-gpu", "ahb1", 0x064, BIT(20), 0); static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "ahb1", - 0x064, BIT(21), 0); + 0x064, BIT(21), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk,"bus-spinlock", "ahb1", 0x064, BIT(22), 0); diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c index 139e8389615c..a7fee407a1c8 100644 --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6.c +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6.c @@ -340,7 +340,7 @@ static SUNXI_CCU_GATE(bus_dma_clk, "bus-dma", "psi-ahb1-ahb2", 0x70c, BIT(0), 0); static SUNXI_CCU_GATE(bus_msgbox_clk, "bus-msgbox", "psi-ahb1-ahb2", - 0x71c, BIT(0), 0); + 0x71c, BIT(0), CLK_IS_CRITICAL); static SUNXI_CCU_GATE(bus_spinlock_clk, "bus-spinlock", "psi-ahb1-ahb2", 0x72c, BIT(0), 0); -- 2.19.2
[PATCH v2 09/10] arm64: dts: allwinner: a64: Add msgbox node
The A64 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 2abb335145a6..29ee8f0f833a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -447,6 +447,16 @@
reg = <0x1c14000 0x400>;
};
+ msgbox: mailbox@1c17000 {
+ compatible = "allwinner,sun50i-a64-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x01c17000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
usb_otg: usb@1c19000 {
compatible = "allwinner,sun8i-a33-musb";
reg = <0x01c19000 0x0400>;
--
2.19.2
[PATCH v2 00/10] Allwinner sunxi message box support
This series adds support for the "hardware message box" in sun8i, sun9i, and sun50i SoCs, used for communication with the ARISC management processor (the platform's equivalent of the ARM SCP). The end goal is to use the arm_scpi driver as a client, communicating with firmware running on the ARISC CPU, or to use the mailbox to forward NMIs that the firmware picks up from R_INTC. Changes from v1: - Marked message box clocks as critical instead of hacks in the driver - 8 unidirectional channels instead of 4 bidirectional pairs - Use per-SoC compatible strings and an A31 fallback compatible - Dropped the mailbox framework patch - Include DT patches for SoCs that document the message box Samuel Holland (10): clk: sunxi-ng: sun8i: Mark the msgbox clock as critical clk: sunxi-ng: sun9i: Mark the msgbox clock as critical clk: sunxi-ng: sun50i: Mark the msgbox clock as critical dt-bindings: mailbox: Add a sunxi message box binding mailbox: sunxi-msgbox: Add a new mailbox driver ARM: dts: sunxi: a80: Add msgbox node ARM: dts: sunxi: a83t: Add msgbox node ARM: dts: sunxi: h3/h5: Add msgbox node arm64: dts: allwinner: a64: Add msgbox node arm64: dts: allwinner: h6: Add msgbox node .../bindings/mailbox/sunxi-msgbox.txt | 44 +++ arch/arm/boot/dts/sun8i-a83t.dtsi | 10 + arch/arm/boot/dts/sun9i-a80.dtsi | 10 + arch/arm/boot/dts/sunxi-h3-h5.dtsi| 10 + arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 + arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 10 + drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 2 +- drivers/clk/sunxi-ng/ccu-sun50i-h6.c | 2 +- drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 2 +- drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 2 +- drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 2 +- drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 2 +- drivers/clk/sunxi-ng/ccu-sun9i-a80.c | 2 +- drivers/mailbox/Kconfig | 11 + drivers/mailbox/Makefile | 2 + drivers/mailbox/sunxi-msgbox.c| 315 ++ 16 files changed, 429 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/sunxi-msgbox.txt create mode 100644 drivers/mailbox/sunxi-msgbox.c -- 2.19.2
[PATCH v2 07/10] ARM: dts: sunxi: a83t: Add msgbox node
The A83T SoC contains a message box that can be used to send messages
and interrupts back and forth between the ARM application CPUs and the
ARISC coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index b099d2fbb5cd..c80c4f942439 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -546,6 +546,16 @@
reg = <0x1c14000 0x400>;
};
+ msgbox: mailbox@1c17000 {
+ compatible = "allwinner,sun8i-a83t-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x01c17000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
usb_otg: usb@1c19000 {
compatible = "allwinner,sun8i-a83t-musb",
"allwinner,sun8i-a33-musb";
--
2.19.2
[PATCH v2 05/10] mailbox: sunxi-msgbox: Add a new mailbox driver
Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
used for communication between the ARM CPUs and the ARISC management
coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
Add a driver for it, so it can be used for SCPI or other communication
protocols.
Signed-off-by: Samuel Holland
---
drivers/mailbox/Kconfig| 11 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/sunxi-msgbox.c | 315 +
3 files changed, 328 insertions(+)
create mode 100644 drivers/mailbox/sunxi-msgbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 3eeb12e93e98..6309e755d04a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -205,4 +205,15 @@ config MTK_CMDQ_MBOX
mailbox driver. The CMDQ is used to help read/write registers with
critical time limitation, such as updating display configuration
during the vblank.
+
+config SUNXI_MSGBOX
+ tristate "Allwinner sunxi Message Box"
+ depends on ARCH_SUNXI || COMPILE_TEST
+ default ARCH_SUNXI
+ help
+ Mailbox implementation for the hardware message box present in
+ Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
+ used for communication between the application CPUs and the power
+ management coprocessor.
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c818b5d011ae..f29a119a3fac 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -44,3 +44,5 @@ obj-$(CONFIG_TEGRA_HSP_MBOX) += tegra-hsp.o
obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
obj-$(CONFIG_MTK_CMDQ_MBOX)+= mtk-cmdq-mailbox.o
+
+obj-$(CONFIG_SUNXI_MSGBOX) += sunxi-msgbox.o
diff --git a/drivers/mailbox/sunxi-msgbox.c b/drivers/mailbox/sunxi-msgbox.c
new file mode 100644
index ..fb0d733dd3b4
--- /dev/null
+++ b/drivers/mailbox/sunxi-msgbox.c
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2017-2019 Samuel Holland
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define NUM_CHANS 8
+
+#define CTRL_REG(n)(0x + 0x4 * ((n) / 4))
+#define CTRL_RX(n) BIT(0 + 8 * ((n) % 4))
+#define CTRL_TX(n) BIT(4 + 8 * ((n) % 4))
+
+#define REMOTE_IRQ_EN_REG 0x0040
+#define REMOTE_IRQ_STATUS_REG 0x0050
+#define LOCAL_IRQ_EN_REG 0x0060
+#define LOCAL_IRQ_STATUS_REG 0x0070
+
+#define RX_IRQ(n) BIT(0 + 2 * (n))
+#define RX_IRQ_MASK0x
+#define TX_IRQ(n) BIT(1 + 2 * (n))
+#define TX_IRQ_MASK0x
+
+#define FIFO_STATUS_REG(n) (0x0100 + 0x4 * (n))
+#define FIFO_STATUS_MASK BIT(0)
+
+#define MSG_STATUS_REG(n) (0x0140 + 0x4 * (n))
+#define MSG_STATUS_MASKGENMASK(2, 0)
+
+#define MSG_DATA_REG(n)(0x0180 + 0x4 * (n))
+
+#define mbox_dbg(mbox, ...)dev_dbg((mbox)->controller.dev, __VA_ARGS__)
+
+struct sunxi_msgbox {
+ struct mbox_controller controller;
+ struct clk *clk;
+ spinlock_t lock;
+ void __iomem *regs;
+};
+
+static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
+static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
+
+static inline int channel_number(struct mbox_chan *chan)
+{
+ return chan - chan->mbox->chans;
+}
+
+static inline struct sunxi_msgbox *channel_to_msgbox(struct mbox_chan *chan)
+{
+ return (struct sunxi_msgbox *)chan->con_priv;
+}
+
+static irqreturn_t sunxi_msgbox_irq(int irq, void *dev_id)
+{
+ struct mbox_chan *chan;
+ struct sunxi_msgbox *mbox = dev_id;
+ int n;
+ uint32_t msg, status;
+
+ status = readl(mbox->regs + LOCAL_IRQ_STATUS_REG);
+ if (!(status & RX_IRQ_MASK))
+ return IRQ_NONE;
+
+ for (n = 0; n < NUM_CHANS; ++n) {
+ if (!(status & RX_IRQ(n)))
+ continue;
+ chan = >controller.chans[n];
+ while (sunxi_msgbox_peek_data(chan)) {
+ msg = readl(mbox->regs + MSG_DATA_REG(n));
+ mbox_dbg(mbox, "Channel %d received 0x%08x\n", n, msg);
+ mbox_chan_received_data(chan, );
+ }
+ /* The IRQ can be cleared only when the FIFO is empty. */
+ writel(RX_IRQ(n), mbox->regs + LOCAL_IRQ_STATUS_REG);
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int sunxi_msgbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct sunxi_msgbox *mbox = channel_to_msgbox(chan);
+ int n = channel_number(chan);
+ uint32_t msg = *(uint32_t *)data;
+
+ /* Using a channel backwards gets the hardware into a bad state. */
+ if (WARN_ON_ONCE(!(readl(mbox->regs + CTRL_REG(n)) & CTRL_TX(n
+ return 0;
+
+ /* We cannot post a new
[PATCH v2 06/10] ARM: dts: sunxi: a80: Add msgbox node
The A80 SoC contains a message box that can be used to send messages and
interrupts back and forth between the ARM application CPUs and the ARISC
coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sun9i-a80.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi b/arch/arm/boot/dts/sun9i-a80.dtsi
index d9532fb1ef65..10e878f94fc0 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -283,6 +283,16 @@
};
};
+ msgbox: mailbox@803000 {
+ compatible = "allwinner,sun9i-a80-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x00803000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <1>;
+ };
+
ehci0: usb@a0 {
compatible = "allwinner,sun9i-a80-ehci", "generic-ehci";
reg = <0x00a0 0x100>;
--
2.19.2
[PATCH v2 08/10] ARM: dts: sunxi: h3/h5: Add msgbox node
The H3 and H5 SoCs contain a message box that can be used to send
messages and interrupts back and forth between the ARM application CPUs
and the ARISC coprocessor. Add a device tree node for it.
Signed-off-by: Samuel Holland
---
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
index a4c757c0b741..a42fd3f9739e 100644
--- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
+++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
@@ -227,6 +227,16 @@
#size-cells = <0>;
};
+ msgbox: mailbox@1c17000 {
+ compatible = "allwinner,sun8i-h3-msgbox",
+"allwinner,sun6i-a31-msgbox";
+ reg = <0x01c17000 0x1000>;
+ clocks = < CLK_BUS_MSGBOX>;
+ resets = < RST_BUS_MSGBOX>;
+ interrupts = ;
+ #mbox-cells = <2>;
+ };
+
usb_otg: usb@1c19000 {
compatible = "allwinner,sun8i-h3-musb";
reg = <0x01c19000 0x400>;
--
2.19.2
[PATCH v2 5/5] PCI: dwc: Save root bus for driver remove
Currently dwc host doesn't support the remove, but nothing prevent us
from supporting it. Save the root bus for clean up work in driver
remove code path.
After this patch, the dwc host users could implement its remove as:
static int foo_pcie_remove(struct platform_device *pdev)
{
...
pci_stop_root_bus(pp->root_bus);
pci_remove_root_bus(pp->root_bus);
dw_pcie_free_msi(pp);
...
}
Signed-off-by: Jisheng Zhang
---
drivers/pci/controller/dwc/pcie-designware-host.c | 1 +
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
b/drivers/pci/controller/dwc/pcie-designware-host.c
index 4831c12fee93..ca45a4471ca0 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -496,6 +496,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
goto err_free_msi;
bus = bridge->bus;
+ pp->root_bus = bus;
if (pp->ops->scan_bus)
pp->ops->scan_bus(pp);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h
b/drivers/pci/controller/dwc/pcie-designware.h
index 3be7ca9f1fc3..cd92ded606c6 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -182,6 +182,7 @@ struct pcie_port {
struct page *msi_page;
u32 num_vectors;
u32 irq_mask[MAX_MSI_CTRLS];
+ struct pci_bus *root_bus;
raw_spinlock_t lock;
DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
};
--
2.20.1
[PATCH v2 4/5] PCI: dwc: Use devm_pci_alloc_host_bridge() to simplify the code
Use devm_pci_alloc_host_bridge() to simplify the error code path.
Signed-off-by: Jisheng Zhang
---
.../pci/controller/dwc/pcie-designware-host.c | 21 +++
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
b/drivers/pci/controller/dwc/pcie-designware-host.c
index 66569d0f3ab9..4831c12fee93 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -357,7 +357,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
dev_err(dev, "Missing *config* reg space\n");
}
- bridge = pci_alloc_host_bridge(0);
+ bridge = devm_pci_alloc_host_bridge(dev, 0);
if (!bridge)
return -ENOMEM;
@@ -368,7 +368,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
ret = devm_request_pci_bus_resources(dev, >windows);
if (ret)
- goto error;
+ return ret;
/* Get the I/O and memory ranges from DT */
resource_list_for_each_entry_safe(win, tmp, >windows) {
@@ -412,8 +412,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
resource_size(pp->cfg));
if (!pci->dbi_base) {
dev_err(dev, "Error with ioremap\n");
- ret = -ENOMEM;
- goto error;
+ return -ENOMEM;
}
}
@@ -424,8 +423,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->cfg0_base, pp->cfg0_size);
if (!pp->va_cfg0_base) {
dev_err(dev, "Error with ioremap in function\n");
- ret = -ENOMEM;
- goto error;
+ return -ENOMEM;
}
}
@@ -435,8 +433,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->cfg1_size);
if (!pp->va_cfg1_base) {
dev_err(dev, "Error with ioremap\n");
- ret = -ENOMEM;
- goto error;
+ return -ENOMEM;
}
}
@@ -459,14 +456,14 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->num_vectors == 0) {
dev_err(dev,
"Invalid number of vectors\n");
- goto error;
+ return -EINVAL;
}
}
if (!pp->ops->msi_host_init) {
ret = dw_pcie_allocate_domains(pp);
if (ret)
- goto error;
+ return ret;
if (pp->msi_irq)
irq_set_chained_handler_and_data(pp->msi_irq,
@@ -475,7 +472,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
} else {
ret = pp->ops->msi_host_init(pp);
if (ret < 0)
- goto error;
+ return ret;
}
}
@@ -515,8 +512,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
err_free_msi:
if (IS_ENABLED(CONFIG_PCI_MSI) && !pp->ops->msi_host_init)
dw_pcie_free_msi(pp);
-error:
- pci_free_host_bridge(bridge);
return ret;
}
--
2.20.1
[PATCH v2 3/5] PCI: dwc: Free MSI in the error code path of dw_pcie_host_init()
If we ever did some msi related initializations, we need to call
dw_pcie_free_msi() in the error code path.
Signed-off-by: Jisheng Zhang
---
drivers/pci/controller/dwc/pcie-designware-host.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
b/drivers/pci/controller/dwc/pcie-designware-host.c
index abe3ff5f0867..66569d0f3ab9 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -482,7 +482,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
if (pp->ops->host_init) {
ret = pp->ops->host_init(pp);
if (ret)
- goto error;
+ goto err_free_msi;
}
pp->root_bus_nr = pp->busn->start;
@@ -496,7 +496,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
ret = pci_scan_root_bus_bridge(bridge);
if (ret)
- goto error;
+ goto err_free_msi;
bus = bridge->bus;
@@ -512,6 +512,9 @@ int dw_pcie_host_init(struct pcie_port *pp)
pci_bus_add_devices(bus);
return 0;
+err_free_msi:
+ if (IS_ENABLED(CONFIG_PCI_MSI) && !pp->ops->msi_host_init)
+ dw_pcie_free_msi(pp);
error:
pci_free_host_bridge(bridge);
return ret;
--
2.20.1
[PATCH v2 2/5] PCI: dwc: Free the page for MSI IRQ in dw_pcie_free_msi()
To avoid memory leak, we need to free the page for MSI in
dw_pcie_free_msi().
Signed-off-by: Jisheng Zhang
---
drivers/pci/controller/dwc/pcie-designware-host.c | 3 +++
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
b/drivers/pci/controller/dwc/pcie-designware-host.c
index a94d3530b694..abe3ff5f0867 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -305,6 +305,8 @@ void dw_pcie_free_msi(struct pcie_port *pp)
irq_domain_remove(pp->msi_domain);
irq_domain_remove(pp->irq_domain);
+
+ __free_page(pp->msi_page);
}
void dw_pcie_msi_init(struct pcie_port *pp)
@@ -322,6 +324,7 @@ void dw_pcie_msi_init(struct pcie_port *pp)
return;
}
msi_target = (u64)pp->msi_data;
+ pp->msi_page = page;
/* Program the msi_data */
dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4,
diff --git a/drivers/pci/controller/dwc/pcie-designware.h
b/drivers/pci/controller/dwc/pcie-designware.h
index f6fb65a40f10..3be7ca9f1fc3 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -179,6 +179,7 @@ struct pcie_port {
struct irq_domain *irq_domain;
struct irq_domain *msi_domain;
dma_addr_t msi_data;
+ struct page *msi_page;
u32 num_vectors;
u32 irq_mask[MAX_MSI_CTRLS];
raw_spinlock_t lock;
--
2.20.1
[PATCH v2 1/5] PCI: dwc: Fix dw_pcie_free_msi() if msi_irq is invalid
We should check msi_irq before calling irq_set_chained_handler() and
irq_set_handler_data().
Signed-off-by: Jisheng Zhang
---
drivers/pci/controller/dwc/pcie-designware-host.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
b/drivers/pci/controller/dwc/pcie-designware-host.c
index 0c18ab63811f..a94d3530b694 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -298,8 +298,10 @@ int dw_pcie_allocate_domains(struct pcie_port *pp)
void dw_pcie_free_msi(struct pcie_port *pp)
{
- irq_set_chained_handler(pp->msi_irq, NULL);
- irq_set_handler_data(pp->msi_irq, NULL);
+ if (pp->msi_irq) {
+ irq_set_chained_handler(pp->msi_irq, NULL);
+ irq_set_handler_data(pp->msi_irq, NULL);
+ }
irq_domain_remove(pp->msi_domain);
irq_domain_remove(pp->irq_domain);
--
2.20.1
[PATCH v2 0/5] PCI: dwc: Support remove
Currently, the PCI dwc host users don't support the remove, but nothing prevent us from supporting it. To achieve this goal, we need to ensure we can do necessary clean up work. Changes since v1: - address Bjorn's comments, I.E Capitalize, s/irq/IRQ/, s/msi/MSI/ Jisheng Zhang (5): PCI: dwc: Fix dw_pcie_free_msi() if msi_irq is invalid PCI: dwc: Free the page for MSI IRQ in dw_pcie_free_msi() PCI: dwc: Free MSI in the error code path of dw_pcie_host_init() PCI: dwc: Use devm_pci_alloc_host_bridge() to simplify the code PCI: dwc: Save root bus for driver remove .../pci/controller/dwc/pcie-designware-host.c | 38 ++- drivers/pci/controller/dwc/pcie-designware.h | 2 + 2 files changed, 23 insertions(+), 17 deletions(-) -- 2.20.1
[PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
In the present driver outbound window configuration is done to map above
32-bit address I/O regions with corresponding PCI memory range given in
ranges DT property.
This patch add outbound window configuration to map below 32-bit I/O range
with corresponding PCI memory, which helps to access I/O region in ARM
32-bit and one to one mapping of I/O region to PCI memory.
Ex:
1. ranges DT property given for current driver is,
ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>;
I/O region address is 0x4
2. ranges DT property can be given after this patch,
ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>;
I/O region address is 0x4200
Signed-off-by: Srinath Mannam
Signed-off-by: Abhishek Shah
Signed-off-by: Ray Jui
---
drivers/pci/controller/pcie-iproc.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index b882255..080f142 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -955,8 +955,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie *pcie,
u64 axi_addr,
resource_size_t window_size =
ob_map->window_sizes[size_idx] * SZ_1M;
- if (size < window_size)
- continue;
+ /*
+* Keep iterating until we reach the last window and
+* with the minimal window size at index zero. In this
+* case, we take a compromise by mapping it using the
+* minimum window size that can be supported
+*/
+ if (size < window_size) {
+ if (size_idx > 0 || window_idx > 0)
+ continue;
+
+ /*
+* For the corner case of reaching the minimal
+* window size that can be supported on the
+* last window
+*/
+ axi_addr = ALIGN_DOWN(axi_addr, window_size);
+ pci_addr = ALIGN_DOWN(pci_addr, window_size);
+ size = window_size;
+ }
if (!IS_ALIGNED(axi_addr, window_size) ||
!IS_ALIGNED(pci_addr, window_size)) {
--
2.7.4
[PATCH v4 0/2] Add IPROC PCIe new features
This patch set extends support of new IPROC PCIe host controller features - Add CRS check using controller register status flags - Add outbound window mapping configuration for 32-bit I/O region This patch set is based on Linux-5.0-rc2. Changes from v3: - Addressed Lorenzo Pieralisi comments. Changes from v2: - Based on Lorenzo Pieralisi comments, commit logs are expanded. Changes from v1: - Addressed Bjorn Helgaas comments. - Removed set order mode patch from patchset. Srinath Mannam (2): PCI: iproc: Add CRS check in config read PCI: iproc: Add outbound configuration for 32-bit I/O region drivers/pci/controller/pcie-iproc.c | 44 + 1 file changed, 40 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH v4 1/2] PCI: iproc: Add CRS check in config read
In the current implementation, config read output data 0x0001 is
assumed as CRS completion. But sometimes 0x0001 can be a valid data.
IPROC PCIe host controller PAXB v2 has a register to show config read
status flags like SC, UR, CRS and CA. So that extra check is added to
confirm the CRS using status flags before reissue config read.
Signed-off-by: Srinath Mannam
---
drivers/pci/controller/pcie-iproc.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index c20fd6b..b882255 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -60,6 +60,10 @@
#define APB_ERR_EN_SHIFT 0
#define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
+#define CFG_RD_SUCCESS 0
+#define CFG_RD_UR 1
+#define CFG_RD_CRS 2
+#define CFG_RD_CA 3
#define CFG_RETRY_STATUS 0x0001
#define CFG_RETRY_STATUS_TIMEOUT_US50 /* 500 milliseconds */
@@ -289,6 +293,9 @@ enum iproc_pcie_reg {
IPROC_PCIE_IARR4,
IPROC_PCIE_IMAP4,
+ /* config read status */
+ IPROC_PCIE_CFG_RD_STATUS,
+
/* link status */
IPROC_PCIE_LINK_STATUS,
@@ -350,6 +357,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_IMAP3] = 0xe08,
[IPROC_PCIE_IARR4] = 0xe68,
[IPROC_PCIE_IMAP4] = 0xe70,
+ [IPROC_PCIE_CFG_RD_STATUS] = 0xee0,
[IPROC_PCIE_LINK_STATUS]= 0xf0c,
[IPROC_PCIE_APB_ERR_EN] = 0xf40,
};
@@ -474,10 +482,12 @@ static void __iomem *iproc_pcie_map_ep_cfg_reg(struct
iproc_pcie *pcie,
return (pcie->base + offset);
}
-static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+static unsigned int iproc_pcie_cfg_retry(struct iproc_pcie *pcie,
+void __iomem *cfg_data_p)
{
int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
unsigned int data;
+ u32 status;
/*
* As per PCIe spec r3.1, sec 2.3.2, CRS Software Visibility only
@@ -498,6 +508,15 @@ static unsigned int iproc_pcie_cfg_retry(void __iomem
*cfg_data_p)
*/
data = readl(cfg_data_p);
while (data == CFG_RETRY_STATUS && timeout--) {
+ /*
+* CRS state is set in CFG_RD status register
+* This will handle the case where CFG_RETRY_STATUS is
+* valid config data.
+*/
+ status = iproc_pcie_read_reg(pcie, IPROC_PCIE_CFG_RD_STATUS);
+ if (status != CFG_RD_CRS)
+ return data;
+
udelay(1);
data = readl(cfg_data_p);
}
@@ -576,7 +595,7 @@ static int iproc_pcie_config_read(struct pci_bus *bus,
unsigned int devfn,
if (!cfg_data_p)
return PCIBIOS_DEVICE_NOT_FOUND;
- data = iproc_pcie_cfg_retry(cfg_data_p);
+ data = iproc_pcie_cfg_retry(pcie, cfg_data_p);
*val = data;
if (size <= 2)
--
2.7.4
RE: [PATCH V4 1/2] watchdog: imx_sc: Add i.MX system controller watchdog support
Hi, Guenter Best Regards! Anson Huang > -Original Message- > From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter > Roeck > Sent: 2019年3月1日 12:21 > To: Anson Huang ; catalin.mari...@arm.com; > will.dea...@arm.com; w...@linux-watchdog.org; shawn...@kernel.org; > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com; > Andy Gross ; he...@sntech.de; > horms+rene...@verge.net.au; a...@arndb.de; o...@lixom.net; > ja...@amarulasolutions.com; bjorn.anders...@linaro.org; > enric.balle...@collabora.com; marc.w.gonza...@free.fr; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux- > watch...@vger.kernel.org > Cc: dl-linux-imx > Subject: Re: [PATCH V4 1/2] watchdog: imx_sc: Add i.MX system controller > watchdog support > > On 2/28/19 7:46 PM, Anson Huang wrote: > > Hi, Guenter > > > > Best Regards! > > Anson Huang > > > >> -Original Message- > >> From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter > >> Roeck > >> Sent: 2019年2月28日 22:58 > >> To: Anson Huang ; catalin.mari...@arm.com; > >> will.dea...@arm.com; w...@linux-watchdog.org; shawn...@kernel.org; > >> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com; > >> Andy Gross ; he...@sntech.de; > >> horms+rene...@verge.net.au; a...@arndb.de; o...@lixom.net; > >> ja...@amarulasolutions.com; bjorn.anders...@linaro.org; > >> enric.balle...@collabora.com; marc.w.gonza...@free.fr; linux-arm- > >> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux- > >> watch...@vger.kernel.org > >> Cc: dl-linux-imx > >> Subject: Re: [PATCH V4 1/2] watchdog: imx_sc: Add i.MX system > >> controller watchdog support > >> > >> On 2/27/19 11:59 PM, Anson Huang wrote: > >>> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller > >>> inside, the system controller is in charge of controlling power, > >>> clock and watchdog etc.. > >>> > >>> This patch adds i.MX system controller watchdog driver support, > >>> watchdog operation needs to be done in secure EL3 mode via > >>> ARM-Trusted-Firmware, using SMC call, CPU will trap into > >>> ARM-Trusted-Firmware and then it will request system controller to > >>> do watchdog operation via IPC. > >>> > >>> Signed-off-by: Anson Huang > >>> --- > >>> Changes since V3: > >>> - add ARM64 dependency for this driver; > >>> - change SPDX license to GPL-2.0 to match module license; > >>> - register platform device in driver instead of getting from > >>> dts; > >>> - return linux error code instead of system controller firmware > >>> error > >> code for watchdog operation > >>> failed case. > >>> --- > >>>drivers/watchdog/Kconfig | 13 +++ > >>>drivers/watchdog/Makefile | 1 + > >>>drivers/watchdog/imx_sc_wdt.c | 201 > >> ++ > >>>3 files changed, 215 insertions(+) > >>>create mode 100644 drivers/watchdog/imx_sc_wdt.c > >>> > >>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > >>> index 65c3c42..8c6575e 100644 > >>> --- a/drivers/watchdog/Kconfig > >>> +++ b/drivers/watchdog/Kconfig > >>> @@ -625,6 +625,19 @@ config IMX2_WDT > >>> To compile this driver as a module, choose M here: the > >>> module will be called imx2_wdt. > >>> > >>> +config IMX_SC_WDT > >>> + tristate "IMX SC Watchdog" > >>> + depends on (ARCH_MXC && ARM64) || COMPILE_TEST > >>> + select WATCHDOG_CORE > >>> + help > >>> + This is the driver for the system controller watchdog > >>> + on the NXP i.MX SoCs with system controller inside. > >>> + If you have one of these processors and wish to have > >>> + watchdog support enabled, say Y, otherwise say N. > >>> + > >>> + To compile this driver as a module, choose M here: the > >>> + module will be called imx_sc_wdt. > >>> + > >> > >> With this patch applied, alpha:allmodconfig and almost all other > >> allmodconfig/allyesconfig builds fail with: > >> > >> ERROR: "__arm_smccc_smc" [drivers/watchdog/imx_sc_wdt.ko] > undefined! > >> scripts/Makefile.modpost:92: recipe for target '__modpost' failed > >> make[1]: *** [__modpost] Error 1 > >> Makefile:1260: recipe for target 'modules' failed > >> > >> as I told you before would happen. For the future, please consider > >> that forcing me to "prove" such failures does take a significant > >> amount of time, which is not always readily available. > > > > Sorry for wasting your time, it is just because I misunderstand your > > point, NOT that I did NOT force you to prove it. > > > > I am a little confuse, since this is new to me about these configs, I > > looked into other drivers which also use arm_smccc_smc, they do NOT > > add special config dependency for the failure build cause as you said, > > can you be more detail about this build issue, I tried below build, > > but the failure I met is other, so could you please advise how to fix > > such dependency issue, adding dummy function looks like NOT a good way > > since
