Re: [PATCH net] tcp: avoid bogus gcc-7 array-bounds warning
From: Arnd Bergmann Date: Fri, 28 Jul 2017 16:41:37 +0200 > When using CONFIG_UBSAN_SANITIZE_ALL, the TCP code produces a > false-positive warning: > > net/ipv4/tcp_output.c: In function 'tcp_connect': > net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds > [-Werror=array-bounds] >tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start; > ^~ > net/ipv4/tcp_output.c:2207:40: error: array subscript is below array bounds > [-Werror=array-bounds] >tp->chrono_stat[tp->chrono_type - 1] += now - tp->chrono_start; >~^ > > I have opened a gcc bug for this, but distros have already shipped > compilers with this problem, and it's not clear yet whether there is > a way for gcc to avoid the warning. As the problem is related to the > bitfield access, this introduces a temporary variable to store the old > enum value. > > I did not notice this warning earlier, since UBSAN is disabled when > building with COMPILE_TEST, and that was always turned on in both > allmodconfig and randconfig tests. > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81601 > Signed-off-by: Arnd Bergmann Applied, thanks Arnd.
Re: [PATCH net] Revert "vhost: cache used event for better performance"
On Wed, 2017-07-26 at 19:08 +0300, Michael S. Tsirkin wrote: > On Wed, Jul 26, 2017 at 09:37:15PM +0800, Jason Wang wrote: > > > > > > On 2017年07月26日 21:18, Jason Wang wrote: > > > > > > > > > On 2017年07月26日 20:57, Michael S. Tsirkin wrote: > > > > On Wed, Jul 26, 2017 at 04:03:17PM +0800, Jason Wang wrote: > > > > > This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it > > > > > was reported to break vhost_net. We want to cache used event and use > > > > > it to check for notification. We try to valid cached used event by > > > > > checking whether or not it was ahead of new, but this is not correct > > > > > all the time, it could be stale and there's no way to know about this. > > > > > > > > > > Signed-off-by: Jason Wang > > > > > > > > Could you supply a bit more data here please? How does it get stale? > > > > What does guest need to do to make it stale? This will be helpful if > > > > anyone wants to bring it back, or if we want to extend the protocol. > > > > > > > > > > The problem we don't know whether or not guest has published a new used > > > event. The check vring_need_event(vq->last_used_event, new + vq->num, > > > new) is not sufficient to check for this. > > > > > > Thanks > > > > More notes, the previous assumption is that we don't move used event back, > > but this could happen in fact if idx is wrapper around. > > You mean if the 16 bit index wraps around after 64K entries. > Makes sense. > > > Will repost and add > > this into commit log. > > > > Thanks Hi, I am just curious but I have got a question: AFAIU, if you wanted to keep the caching mechanism alive in the code base, the following two changes could clear off the issue, or not?: (1) Always fetch the latest event value from guest when signalled_used event is invalid, which includes last_used_idx wraps-around case. Otherwise we might need changes which would complicate too much the logic to properly decide whether or not to skip signalling in the next vhost_notify round. (2) On top of that, split the signal-postponing logic to three cases like: * if the interval of vq.num is [2^16, UINT_MAX]: any cached event is in should-postpone-signalling interval, so paradoxically must always do signalling. * else if the interval of vq.num is [2^15, 2^16): the logic in the original patch (809ecb9bca6a9) suffices * else (= less than 2^15) (optional): checking only (vring_need_event(vq->last_used_event, new + vq->num, new) would suffice. Am I missing something, or is this irrelevant? I would appreciate if you could elaborate a bit more how the situation where event idx wraps around and moves back would make trouble. Thanks.
Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.
Hi Maxime, Yong,
On Fri, Jul 28, 2017 at 06:02:33PM +0200, Maxime Ripard wrote:
> Hi,
>
> Thanks for the second iteration!
>
> On Thu, Jul 27, 2017 at 01:01:35PM +0800, Yong Deng wrote:
> > Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> > and CSI1 is used for parallel interface. This is not documented in
> > datasheet but by testing and guess.
> >
> > This patch implement a v4l2 framework driver for it.
> >
> > Currently, the driver only support the parallel interface. MIPI-CSI2,
> > ISP's support are not included in this patch.
> >
> > Signed-off-by: Yong Deng
[...]
> > +#ifdef DEBUG
> > +static void sun6i_csi_dump_regs(struct sun6i_csi_dev *sdev)
> > +{
> > + struct regmap *regmap = sdev->regmap;
> > + u32 val;
> > +
> > + regmap_read(regmap, CSI_EN_REG, &val);
> > + printk("CSI_EN_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_IF_CFG_REG, &val);
> > + printk("CSI_IF_CFG_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CAP_REG, &val);
> > + printk("CSI_CAP_REG=0x%x\n",val);
> > + regmap_read(regmap, CSI_SYNC_CNT_REG, &val);
> > + printk("CSI_SYNC_CNT_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_FIFO_THRS_REG, &val);
> > + printk("CSI_FIFO_THRS_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_PTN_LEN_REG, &val);
> > + printk("CSI_PTN_LEN_REG=0x%x\n",val);
> > + regmap_read(regmap, CSI_PTN_ADDR_REG, &val);
> > + printk("CSI_PTN_ADDR_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_VER_REG, &val);
> > + printk("CSI_VER_REG=0x%x\n",val);
> > + regmap_read(regmap, CSI_CH_CFG_REG, &val);
> > + printk("CSI_CH_CFG_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_SCALE_REG, &val);
> > + printk("CSI_CH_SCALE_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_F0_BUFA_REG, &val);
> > + printk("CSI_CH_F0_BUFA_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_F1_BUFA_REG, &val);
> > + printk("CSI_CH_F1_BUFA_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_F2_BUFA_REG, &val);
> > + printk("CSI_CH_F2_BUFA_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_STA_REG, &val);
> > + printk("CSI_CH_STA_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_INT_EN_REG, &val);
> > + printk("CSI_CH_INT_EN_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_INT_STA_REG, &val);
> > + printk("CSI_CH_INT_STA_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_FLD1_VSIZE_REG, &val);
> > + printk("CSI_CH_FLD1_VSIZE_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_HSIZE_REG, &val);
> > + printk("CSI_CH_HSIZE_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_VSIZE_REG, &val);
> > + printk("CSI_CH_VSIZE_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_BUF_LEN_REG, &val);
> > + printk("CSI_CH_BUF_LEN_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_FLIP_SIZE_REG, &val);
> > + printk("CSI_CH_FLIP_SIZE_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_FRM_CLK_CNT_REG, &val);
> > + printk("CSI_CH_FRM_CLK_CNT_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_ACC_ITNL_CLK_CNT_REG, &val);
> > + printk("CSI_CH_ACC_ITNL_CLK_CNT_REG=0x%x\n",val);
> > + regmap_read(regmap, CSI_CH_FIFO_STAT_REG, &val);
> > + printk("CSI_CH_FIFO_STAT_REG=0x%x\n", val);
> > + regmap_read(regmap, CSI_CH_PCLK_STAT_REG, &val);
> > + printk("CSI_CH_PCLK_STAT_REG=0x%x\n", val);
> > +}
> > +#endif
>
> You can already dump a regmap through debugfs, that's redundant.
The advantage of in-code registers dump routine is the ability to synchronize
the snapshot with the driver code execution. This is particularly important
for the capture statistics registers. I have found it useful here.
[...]
> > +static int update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
> > +{
> > + struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
> > + /* transform physical address to bus address */
> > + dma_addr_t bus_addr = addr - 0x4000;
>
> Like Baruch noticed, you should use PHYS_OFFSET here. The A80 for
> example has a different RAM base address.
>
> > +
> > + regmap_write(sdev->regmap, CSI_CH_F0_BUFA_REG,
> > +(bus_addr + sdev->planar_offset[0]) >> 2);
Why do you need the bit shift? Does that work for you?
The User Manuals of both the V3s and the and the A33 (AKA R16) state that the
BUFA field size in this register is 31:00, that is 32bit. I have found no
indication of this bit shift in the Olimex provided sunxi-vfe[1] driver. On
the A33 I have found that only after removing the bit-shift, (some sort of)
data started to appear in the buffer.
[1]
https://github.com/hehopmajieh/a33_linux/tree/master/drivers/media/video/sunxi-vfe
[...]
> > +static irqreturn_t sun6i_csi_isr(int irq, void *dev_id)
> > +{
> > + struct sun6i_csi_dev *sdev = (struct sun6i_csi_dev *)dev_id;
> > + struct regmap *regmap = sdev->regmap;
> > + u32 status;
> > +
> > +
Re: Yes you have standing to sue GRSecurity
On Sat, 29 Jul 2017, Paul G. Allen wrote: It's not even clear that there is infringement. The GPL merely requires that people who have been distributed copies of GPL'ed code must not be restricted from further redistribution of the code. It does not require that that someone who is distributing it must available on a public FTP/HTTP server. what I have seen reported is that they are adding additional restrictions, that if any of their customers redistribute the source, their contract with grsecurity is terminated. If there is something to this (that GRSecurity is somehow in violation of the GPL), then it would probably be a very good idea for someone (the community, Red Hat, etc.) to protect the kernel. From my understanding, at least in America, protections under any license or contract (especially dealing with copyright and trademark infringement) are only enforceable as long as the party with the rights enforce the license/contract/agreement. You are thinking of Trademarks, they must be defended or you loose them. Contracts and Licenses do not need to be defended at every chance or risk loosing them. There is also something in law called "setting a precedent" and if the violating of the Linux license agreement is left unchecked, then quite possibly a precedent could be set to allow an entire upstream kernel to be co-opted. This is a potential problem. David Lang
RE: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG
On Sunday, July 30, 2017 12:23 PM, Michael S. Tsirkin wrote: > On Sat, Jul 29, 2017 at 08:47:08PM +0800, Wei Wang wrote: > > On 07/29/2017 07:08 AM, Michael S. Tsirkin wrote: > > > On Thu, Jul 27, 2017 at 10:50:11AM +0800, Wei Wang wrote: > > > > > > > OK I thought this over. While we might need these new APIs > > > > > > > in the future, I think that at the moment, there's a way to > > > > > > > implement this feature that is significantly simpler. Just > > > > > > > add each s/g as a separate input buffer. > > > > > > Should it be an output buffer? > > > > > Hypervisor overwrites these pages with zeroes. Therefore it is > > > > > writeable by device: DMA_FROM_DEVICE. > > > > Why would the hypervisor need to zero the buffer? > > > The page is supplied to hypervisor and can lose the value that is > > > there. That is the definition of writeable by device. > > > > I think for the free pages, it should be clear that they will be added > > as output buffer to the device, because (as we discussed) they are > > just hints, and some of them may be used by the guest after the report_ API > > is > invoked. > > The device/hypervisor should not use or discard them. > > Discarding contents is exactly what you propose doing if migration is going > on, > isn't it? That's actually a different concept. Please let me explain it with this example: The hypervisor receives the hint saying the guest PageX is a free page, but as we know, after that report_ API exits, the guest kernel may take PageX to use, so PageX is not free page any more. At this time, if the hypervisor writes to the page, that would crash the guest. So, I think the cornerstone of this work is that the hypervisor should not touch the reported pages. Best, Wei
[PATCH] pinctrl: sunxi: rename R_PIO i2c pin function name
The I2C pin functions in R_PIO used to be named "s_twi".
As we usually use the name "i2c" instead of "twi" in the mainline
kernel, change these names to "s_i2c" for consistency.
The "s_twi" functions are not yet referenced by any device trees in
mainline kernel so I think it's safe to change the name.
Signed-off-by: Icenowy Zheng
---
drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c | 4 ++--
drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c | 4 ++--
drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c
b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c
index a22bd88a1f03..c96a3610a178 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c
@@ -25,12 +25,12 @@ static const struct sunxi_desc_pin sun6i_a31_r_pins[] = {
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "s_twi"), /* SCK */
+ SUNXI_FUNCTION(0x2, "s_i2c"), /* SCK */
SUNXI_FUNCTION(0x3, "s_p2wi")), /* SCK */
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "s_twi"), /* SDA */
+ SUNXI_FUNCTION(0x2, "s_i2c"), /* SDA */
SUNXI_FUNCTION(0x3, "s_p2wi")), /* SDA */
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
SUNXI_FUNCTION(0x0, "gpio_in"),
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c
b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c
index 2292e05a397b..5789e9ecbae1 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c
@@ -29,13 +29,13 @@ static const struct sunxi_desc_pin sun8i_a23_r_pins[] = {
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */
- SUNXI_FUNCTION(0x3, "s_twi"), /* SCK */
+ SUNXI_FUNCTION(0x3, "s_i2c"), /* SCK */
SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 0)), /* PL_EINT0 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */
- SUNXI_FUNCTION(0x3, "s_twi"), /* SDA */
+ SUNXI_FUNCTION(0x3, "s_i2c"), /* SDA */
SUNXI_FUNCTION_IRQ_BANK(0x4, 0, 1)), /* PL_EINT1 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
SUNXI_FUNCTION(0x0, "gpio_in"),
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
index 686ec212120b..ebfd9a26628c 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c
@@ -20,12 +20,12 @@ static const struct sunxi_desc_pin sun8i_h3_r_pins[] = {
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "s_twi"), /* SCK */
+ SUNXI_FUNCTION(0x2, "s_i2c"), /* SCK */
SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PL_EINT0 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "s_twi"), /* SDA */
+ SUNXI_FUNCTION(0x2, "s_i2c"), /* SDA */
SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PL_EINT1 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
SUNXI_FUNCTION(0x0, "gpio_in"),
--
2.13.0
Re: [PATCH v3 0/2] Last step to working Allwinner R40 pinctrl
在 2017-07-22 10:50，Icenowy Zheng 写道： This patchset contains only two patches. The first one is a minor fix for the A10 pinctrl driver, add a function of a pin, which used to be missing in A10/A20 pinctrl driver. Thanks for Chen-Yu for discovering it when reviewing my R40 pinctrl patchset. The second one is the real R40 pinctrl part, with fixes suggested by Chen-Yu and Maxime. Icenowy Zheng (2): pinctrl: sunxi: add a missing function of A10/A20 pinctrl driver pinctrl: sunxi: add support of R40 to A10 pinctrl driver Ping... Can anyone process this patchset? drivers/pinctrl/sunxi/Kconfig | 2 +- drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c | 274 +- 2 files changed, 197 insertions(+), 79 deletions(-)
[PATCH 1/4] misc: pch_phub: constify pci_device_id.
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/misc/pch_phub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/pch_phub.c b/drivers/misc/pch_phub.c
index e42bdc9..2ffacda 100644
--- a/drivers/misc/pch_phub.c
+++ b/drivers/misc/pch_phub.c
@@ -891,7 +891,7 @@ static int pch_phub_resume(struct pci_dev *pdev)
#define pch_phub_resume NULL
#endif /* CONFIG_PM */
-static struct pci_device_id pch_phub_pcidev_id[] = {
+static const struct pci_device_id pch_phub_pcidev_id[] = {
{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PCH1_PHUB), 1, },
{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ROHM_ML7213_PHUB), 2, },
{ PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ROHM_ML7223_mPHUB), 3, },
--
2.7.4
[PATCH 3/4] misc: tifm: constify pci_device_id.
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
checkpatch ERROR: space prohibited before open square bracket '['
Signed-off-by: Arvind Yadav
---
drivers/misc/tifm_7xx1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/tifm_7xx1.c b/drivers/misc/tifm_7xx1.c
index a37a42f..e5f1087 100644
--- a/drivers/misc/tifm_7xx1.c
+++ b/drivers/misc/tifm_7xx1.c
@@ -415,7 +415,7 @@ static void tifm_7xx1_remove(struct pci_dev *dev)
tifm_free_adapter(fm);
}
-static struct pci_device_id tifm_7xx1_pci_tbl [] = {
+static const struct pci_device_id tifm_7xx1_pci_tbl[] = {
{ PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_XX21_XX11_FM, PCI_ANY_ID,
PCI_ANY_ID, 0, 0, 0 }, /* xx21 - the one I have */
{ PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_XX12_FM, PCI_ANY_ID,
--
2.7.4
[PATCH 2/4] misc: hpilo: constify pci_device_id.
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/misc/hpilo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/hpilo.c b/drivers/misc/hpilo.c
index fea8ff4..097e309 100644
--- a/drivers/misc/hpilo.c
+++ b/drivers/misc/hpilo.c
@@ -857,7 +857,7 @@ static int ilo_probe(struct pci_dev *pdev,
return error;
}
-static struct pci_device_id ilo_devices[] = {
+static const struct pci_device_id ilo_devices[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_COMPAQ, 0xB204) },
{ PCI_DEVICE(PCI_VENDOR_ID_HP, 0x3307) },
{ }
--
2.7.4
[PATCH 0/4] constify misc pci_device_id.
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Arvind Yadav (4): [PATCH 1/4] misc: pch_phub: constify pci_device_id. [PATCH 2/4] misc: hpilo: constify pci_device_id. [PATCH 3/4] misc: tifm: constify pci_device_id. [PATCH 4/4] misc: ioc4: constify pci_device_id. drivers/misc/hpilo.c | 2 +- drivers/misc/ioc4.c | 2 +- drivers/misc/pch_phub.c | 2 +- drivers/misc/tifm_7xx1.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH 4/4] misc: ioc4: constify pci_device_id.
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav
---
drivers/misc/ioc4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/ioc4.c b/drivers/misc/ioc4.c
index 8758d03..ec083227 100644
--- a/drivers/misc/ioc4.c
+++ b/drivers/misc/ioc4.c
@@ -454,7 +454,7 @@ ioc4_remove(struct pci_dev *pdev)
kfree(idd);
}
-static struct pci_device_id ioc4_id_table[] = {
+static const struct pci_device_id ioc4_id_table[] = {
{PCI_VENDOR_ID_SGI, PCI_DEVICE_ID_SGI_IOC4, PCI_ANY_ID,
PCI_ANY_ID, 0x0b4000, 0xFF},
{0}
--
2.7.4
Re: blk-mq breaks suspend even with runtime PM patch
On Sat, 2017-07-29 at 17:27 +0200, Oleksandr Natalenko wrote: > Hello Jens, Christoph. > > Unfortunately, even with "block: disable runtime-pm for blk-mq" patch applied > blk-mq breaks suspend to RAM for me. It is reproducible on my laptop as well > as in a VM. > > I use complex disk layout involving MD, LUKS and LVM, and managed to get > these > warnings from VM via serial console when suspend fails: > > === > [ 245.516573] INFO: task kworker/0:1:49 blocked for more than 120 seconds. > [ 245.520025] Not tainted 4.12.0-pf4 #1 FWIW, first thing I'd do is update that 4.12.0 to 4.12.4, and see if stable fixed it. If not, I'd find these two commits irresistible. 5f042e7cbd9eb blk-mq: Include all present CPUs in the default queue mapping 4b855ad37194f blk-mq: Create hctx for each present CPU 'course applying random upstream bits does come with some risk, trying a kernel already containing them has less "entertainment" potential. -Mike
Re: [PATCH v1 5/5] [media] stm32-dcmi: g_/s_selection crop support
Hi Hugues,
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.13-rc2 next-20170728]
[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/Hugues-Fruchet/STM32-DCMI-camera-interface-crop-support/20170730-114803
base: git://linuxtv.org/media_tree.git master
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/media//platform/stm32/stm32-dcmi.c: In function
'dcmi_graph_notify_complete':
>> drivers/media//platform/stm32/stm32-dcmi.c:1445:5: warning: 'ret' may be
>> used uninitialized in this function [-Wmaybe-uninitialized]
if (ret) {
^
vim +/ret +1445 drivers/media//platform/stm32/stm32-dcmi.c
1431
1432 static int dcmi_graph_notify_complete(struct v4l2_async_notifier
*notifier)
1433 {
1434 struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
1435 int ret;
1436
1437 dcmi->vdev->ctrl_handler = dcmi->entity.subdev->ctrl_handler;
1438 ret = dcmi_formats_init(dcmi);
1439 if (ret) {
1440 dev_err(dcmi->dev, "No supported mediabus format
found\n");
1441 return ret;
1442 }
1443
1444 ret = dcmi_framesizes_init(dcmi);
> 1445 if (ret) {
1446 dev_err(dcmi->dev, "Could not initialize framesizes\n");
1447 return ret;
1448 }
1449
1450 ret = dcmi_get_sensor_bounds(dcmi, &dcmi->sd_bounds);
1451 if (ret) {
1452 dev_err(dcmi->dev, "Could not get sensor bounds\n");
1453 return ret;
1454 }
1455
1456 ret = dcmi_set_default_fmt(dcmi);
1457 if (ret) {
1458 dev_err(dcmi->dev, "Could not set default format\n");
1459 return ret;
1460 }
1461
1462 ret = video_register_device(dcmi->vdev, VFL_TYPE_GRABBER, -1);
1463 if (ret) {
1464 dev_err(dcmi->dev, "Failed to register video device\n");
1465 return ret;
1466 }
1467
1468 dev_dbg(dcmi->dev, "Device registered as %s\n",
1469 video_device_node_name(dcmi->vdev));
1470 return 0;
1471 }
1472
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG
On Sat, Jul 29, 2017 at 08:47:08PM +0800, Wei Wang wrote: > On 07/29/2017 07:08 AM, Michael S. Tsirkin wrote: > > On Thu, Jul 27, 2017 at 10:50:11AM +0800, Wei Wang wrote: > > > > > > OK I thought this over. While we might need these new APIs in > > > > > > the future, I think that at the moment, there's a way to implement > > > > > > this feature that is significantly simpler. Just add each s/g > > > > > > as a separate input buffer. > > > > > Should it be an output buffer? > > > > Hypervisor overwrites these pages with zeroes. Therefore it is > > > > writeable by device: DMA_FROM_DEVICE. > > > Why would the hypervisor need to zero the buffer? > > The page is supplied to hypervisor and can lose the value that > > is there. That is the definition of writeable by device. > > I think for the free pages, it should be clear that they will be added as > output buffer to the device, because (as we discussed) they are just hints, > and some of them may be used by the guest after the report_ API is invoked. > The device/hypervisor should not use or discard them. Discarding contents is exactly what you propose doing if migration is going on, isn't it? > For the balloon pages, I kind of agree with the existing implementation > (e.g. inside tell_host()), which uses virtqueue_add_outbuf (instead of > _add_inbuf()). This is because it does not pass SGs, it passes weirdly formatted PA within the buffer. > I think inbuf should be a buffer which will be written by the device and > read by the > driver. If hypervisor can change it, it's an inbuf. Should not matter whether driver reads it. > The cmd buffer put on the vq for the device to send commands can be > an > inbuf, I think. > > > > > > > I think it may only > > > need to read out the info(base,size). > > And then do what? > > > For the free pages, the info will be used to clear the corresponding "1" in > the dirty bitmap. > For balloon pages, they will be made DONTNEED and given to other host > processes to > use (the device won't write them, so no need to set "write" when > virtqueue_map_desc() in > the device). > > > > > > > I think it should be like this: > > > the cmd hdr buffer: input, because the hypervisor would write it to > > > send a cmd to the guest > > > the payload buffer: output, for the hypervisor to read the info > > These should be split. > > > > We have: > > > > 1. request that hypervisor sends to guest, includes ID: input > > 2. synchronisation header with ID sent by guest: output > > 3. list of pages: input > > > > 2 and 3 must be on the same VQ. 1 can come on any VQ - reusing stats VQ > > might make sense. > > I would prefer to make the above item 1 come on the the free page vq, > because the existing stat_vq doesn't support the cmd hdr. > Now, I think it is also not necessary to move the existing stat_vq > implementation to > a new implementation under the cmd hdr, because > that new support doesn't make a difference for stats, it will still use its > stat_vq (the free > page vq will be used for reporting free pages only) > > What do you think? > > > Best, > Wei
Re: [PATCH v2] x86/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask
On Thu, Jul 27, 2017 at 08:52:35PM -0500, Suravee Suthikulpanit wrote: > For system with X86_FEATURE_TOPOEXT, current logic use APIC ID to > calculate shared_cpu_map. However, since APIC IDs are not guaranteed > to be contiguous for cores across different L3 (e.g. family17h system > w/ downcore configuration). This breaks the logic, and results in > incorrect L3 shared_cpu_map. > > Instead, always use the previously calculated cpu_llc_shared_mask of > each cpu to derive L3 shared_cpu_map. This has been tested on > family15h and family17h systems, which has L3 and support > X86_FEATURE_TOPOEXT. > > Signed-off-by: Suravee Suthikulpanit > --- > arch/x86/kernel/cpu/intel_cacheinfo.c | 32 ++-- > 1 file changed, 18 insertions(+), 14 deletions(-) Applied, thanks. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --
[PATCH] printk: Clean up do_syslog() error handling
The error variable in do_syslog() is preemptively set to the error code
before the error condition is checked, and then set to 0 if the error
condition is not encountered. This is not necessary, as it is likely
simpler to return immediately upon encountering the error condition. A
redundant set of the error variable to 0 is also removed.
This patch has been build-tested on x86_64, but not tested for
functionality.
Signed-off-by: Nikitas Angelinas
---
kernel/printk/printk.c | 35 ---
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 87f1a8f4e0f9..cfd9ab1b80c5 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1435,7 +1435,7 @@ int do_syslog(int type, char __user *buf, int len, int
source)
error = check_syslog_permissions(type, source);
if (error)
- goto out;
+ return error;
switch (type) {
case SYSLOG_ACTION_CLOSE: /* Close log */
@@ -1443,20 +1443,16 @@ int do_syslog(int type, char __user *buf, int len, int
source)
case SYSLOG_ACTION_OPEN:/* Open log */
break;
case SYSLOG_ACTION_READ:/* Read from log */
- error = -EINVAL;
if (!buf || len < 0)
- goto out;
- error = 0;
+ return -EINVAL;
if (!len)
- goto out;
- if (!access_ok(VERIFY_WRITE, buf, len)) {
- error = -EFAULT;
- goto out;
- }
+ return 0;
+ if (!access_ok(VERIFY_WRITE, buf, len))
+ return -EFAULT;
error = wait_event_interruptible(log_wait,
syslog_seq != log_next_seq);
if (error)
- goto out;
+ return error;
error = syslog_print(buf, len);
break;
/* Read/clear last kernel messages */
@@ -1465,16 +1461,12 @@ int do_syslog(int type, char __user *buf, int len, int
source)
/* FALL THRU */
/* Read last kernel messages */
case SYSLOG_ACTION_READ_ALL:
- error = -EINVAL;
if (!buf || len < 0)
- goto out;
- error = 0;
+ return -EINVAL;
if (!len)
- goto out;
- if (!access_ok(VERIFY_WRITE, buf, len)) {
- error = -EFAULT;
- goto out;
- }
+ return 0;
+ if (!access_ok(VERIFY_WRITE, buf, len))
+ return -EFAULT;
error = syslog_print_all(buf, len, clear);
break;
/* Clear ring buffer */
@@ -1496,15 +1488,13 @@ int do_syslog(int type, char __user *buf, int len, int
source)
break;
/* Set level of messages printed to console */
case SYSLOG_ACTION_CONSOLE_LEVEL:
- error = -EINVAL;
if (len < 1 || len > 8)
- goto out;
+ return -EINVAL;
if (len < minimum_console_loglevel)
len = minimum_console_loglevel;
console_loglevel = len;
/* Implicitly re-enable logging to console */
saved_console_loglevel = LOGLEVEL_DEFAULT;
- error = 0;
break;
/* Number of chars in the log buffer */
case SYSLOG_ACTION_SIZE_UNREAD:
@@ -1526,7 +1516,6 @@ int do_syslog(int type, char __user *buf, int len, int
source)
u64 seq = syslog_seq;
u32 idx = syslog_idx;
- error = 0;
while (seq < log_next_seq) {
struct printk_log *msg = log_from_idx(idx);
@@ -1546,7 +1535,7 @@ int do_syslog(int type, char __user *buf, int len, int
source)
error = -EINVAL;
break;
}
-out:
+
return error;
}
--
2.11.1
Re: [PATCH 1/1] usb: xhci: Add debugfs interface for xHCI driver
Hi Greg,
On 07/29/2017 09:34 PM, Greg KH wrote:
> On Sat, Jul 29, 2017 at 04:18:03PM +0800, Lu Baolu wrote:
>> +static void xhci_debugfs_create_files(struct xhci_hcd *xhci,
>> + struct xhci_file_map *files,
>> + size_t nentries, void *data,
>> + struct dentry *parent,
>> + const struct file_operations *fops)
>> +{
>> +int i;
>> +struct dentry *file;
>> +
>> +for (i = 0; i < nentries; i++) {
>> +file = debugfs_create_file(files[i].name, 0444,
>> + parent, data, fops);
>> +if (IS_ERR_OR_NULL(file))
>> +break;
> There's no need to ever check the return value of a debugfs_ function,
> there's nothing you can do here, just keep calling it :)
>
> And you will not get an error, you will only get NULL if there is an
> error, as the only error you would get is if debugfs was not enabled.
>
>> +static struct dentry *xhci_debugfs_create_ring_dir(struct xhci_hcd *xhci,
>> + struct xhci_ring *ring,
>> + const char *name,
>> + struct dentry *parent)
>> +{
>> +struct dentry *dir;
>> +
>> +dir = debugfs_create_dir(name, parent);
>> +if (IS_ERR_OR_NULL(dir))
>> +return NULL;
> Same here. Just keep going, you don't care about the return value, but
> you can use it safely no matter what.
>
>
> Same for other places in this patch as well.
Thanks for review. I will correct them in a v2 patch.
Best regards,
Lu Baolu
Re: [PATCH -tip v7 1/2] irq: Make irqentry text section unconditional
On Sat, 29 Jul 2017 19:11:23 +0800 kbuild test robot wrote: > Hi Masami, > > [auto build test ERROR on tip/x86/core] > [also build test ERROR on v4.13-rc2 next-20170728] > [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/Masami-Hiramatsu/irq-Make-irqentry-text-section-unconditional/20170729-170710 > config: h8300-h8300h-sim_defconfig (attached as .config) > compiler: h8300-linux-gcc (GCC) 6.2.0 > reproduce: > wget > https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=h8300 > > All errors (new ones prefixed by >>): > >In file included from arch/h8300/kernel/process.c:45:0: > >> arch/h8300/include/asm/traps.h:36:21: error: conflicting types for '_etext' > extern char _start, _etext; > ^~ >In file included from ./arch/h8300/include/generated/asm/sections.h:1:0, > from include/linux/interrupt.h:21, > from arch/h8300/kernel/process.c:38: >include/asm-generic/sections.h:33:32: note: previous declaration of > '_etext' was here > extern char _text[], _stext[], _etext[]; >^~ OK, it is like opening a pandra's box, but I would like to fix arch/h8300/kernel/process.c because include/asm-generic/sections.h is a generic header and will be used anywhere. Thanks, > > vim +/_etext +36 arch/h8300/include/asm/traps.h > > d2a5f499 Yoshinori Sato 2015-05-11 35 > d2a5f499 Yoshinori Sato 2015-05-11 @36 extern char _start, _etext; > d2a5f499 Yoshinori Sato 2015-05-11 37 #define check_kernel_text(addr) \ > d2a5f499 Yoshinori Sato 2015-05-11 38((addr >= (unsigned > long)(&_start)) && \ > bf24eec3 Yoshinori Sato 2016-01-15 39 (addr < (unsigned > long)(&_etext)) && !(addr & 1)) > d2a5f499 Yoshinori Sato 2015-05-11 40 > > :: The code at line 36 was first introduced by commit > :: d2a5f4999f6c211adf30d9788349e13988d6f2a7 h8300: Assembly headers > > :: TO: Yoshinori Sato > :: CC: Yoshinori Sato > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation -- Masami Hiramatsu
fs/binfmt_flat.c:828:9: error: void value not ignored as it ought to be
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0a07b238e5f488b459b6113a62e06b6aab017f71
commit: 468138d78510688fb5476f98d23f11ac6a63229a binfmt_flat:
flat_{get,put}_addr_from_rp() should be able to fail
date: 4 weeks ago
config: m32r-oaks32r_defconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 468138d78510688fb5476f98d23f11ac6a63229a
# save the attached .config to linux build tree
make.cross ARCH=m32r
All errors (new ones prefixed by >>):
In file included from include/linux/kernel.h:13:0,
from fs/binfmt_flat.c:20:
fs/binfmt_flat.c: In function 'load_flat_file':
include/linux/kern_levels.h:4:18: warning: format '%ld' expects argument of
type 'long int', but argument 2 has type 'u32 {aka unsigned int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/printk.h:136:11: note: in definition of macro 'no_printk'
printk(fmt, ##__VA_ARGS__); \
^~~
include/linux/kern_levels.h:14:20: note: in expansion of macro 'KERN_SOH'
#define KERN_DEBUG KERN_SOH "7" /* debug-level messages */
^~~~
include/linux/printk.h:339:12: note: in expansion of macro 'KERN_DEBUG'
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
^~
fs/binfmt_flat.c:577:3: note: in expansion of macro 'pr_debug'
pr_debug("Allocated data+bss+stack (%ld bytes): %lx\n",
^~~~
>> fs/binfmt_flat.c:828:9: error: void value not ignored as it ought to be
ret = flat_put_addr_at_rp(rp, addr, relval);
^
vim +828 fs/binfmt_flat.c
506
507 /*
508 * Check initial limits. This avoids letting people circumvent
509 * size limits imposed on them by creating programs with large
510 * arrays in the data or bss.
511 */
512 rlim = rlimit(RLIMIT_DATA);
513 if (rlim >= RLIM_INFINITY)
514 rlim = ~0;
515 if (data_len + bss_len > rlim) {
516 ret = -ENOMEM;
517 goto err;
518 }
519
520 /* Flush all traces of the currently running executable */
521 if (id == 0) {
522 ret = flush_old_exec(bprm);
523 if (ret)
524 goto err;
525
526 /* OK, This is the point of no return */
527 set_personality(PER_LINUX_32BIT);
528 setup_new_exec(bprm);
529 }
530
531 /*
532 * calculate the extra space we need to map in
533 */
534 extra = max_t(unsigned long, bss_len + stack_len,
535 relocs * sizeof(unsigned long));
536
537 /*
538 * there are a couple of cases here, the separate code/data
539 * case, and then the fully copied to RAM case which lumps
540 * it all together.
541 */
542 if (!IS_ENABLED(CONFIG_MMU) && !(flags &
(FLAT_FLAG_RAM|FLAT_FLAG_GZIP))) {
543 /*
544 * this should give us a ROM ptr, but if it doesn't we
don't
545 * really care
546 */
547 pr_debug("ROM mapping of file (we hope)\n");
548
549 textpos = vm_mmap(bprm->file, 0, text_len,
PROT_READ|PROT_EXEC,
550MAP_PRIVATE|MAP_EXECUTABLE, 0);
551 if (!textpos || IS_ERR_VALUE(textpos)) {
552 ret = textpos;
553 if (!textpos)
554 ret = -ENOMEM;
555 pr_err("Unable to mmap process text, errno
%d\n", ret);
556 goto err;
557 }
558
559 len = data_len + extra + MAX_SHARED_LIBS *
sizeof(unsigned long);
560 len = PAGE_ALIGN(len);
561 realdatastart = vm_mmap(NULL, 0, len,
562 PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 0);
563
564 if (realdatastart == 0 || IS_ERR_VALUE(realdatastart)) {
565 ret = realdatastart;
566 if (!realdatastart)
567 ret = -ENOMEM;
568 pr_err("Unable to allocate RAM for process
data, "
569 "errno %d\n", ret);
570 vm_munmap(textpos, text_len);
571 g
[PATCH] ipmi: fix unsigned long underflow
From: Corey Minyard
When I set the timeout to a specific value such as 500ms, the timeout
event will not happen in time due to the overflow in function
check_msg_timeout:
...
ent->timeout -= timeout_period;
if (ent->timeout > 0)
return;
...
The type of timeout_period is long, but ent->timeout is unsigned long.
This patch makes the type consistent.
Reported-by: Weilong Chen
Signed-off-by: Corey Minyard
---
I like to keep things consistent (though I obviously messed up here)
and keep variables that should be positive unsigned.
But you are right, there is a bug here and some inconsistency.
This patch changes timeout_period to be unsigned and fixes the
check. Can you try this out?
drivers/char/ipmi/ipmi_msghandler.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/char/ipmi/ipmi_msghandler.c
b/drivers/char/ipmi/ipmi_msghandler.c
index 810b138..c82d9fd 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -4030,7 +4030,8 @@ smi_from_recv_msg(ipmi_smi_t intf, struct ipmi_recv_msg
*recv_msg,
}
static void check_msg_timeout(ipmi_smi_t intf, struct seq_table *ent,
- struct list_head *timeouts, long timeout_period,
+ struct list_head *timeouts,
+ unsigned long timeout_period,
int slot, unsigned long *flags,
unsigned int *waiting_msgs)
{
@@ -4043,8 +4044,8 @@ static void check_msg_timeout(ipmi_smi_t intf, struct
seq_table *ent,
if (!ent->inuse)
return;
- ent->timeout -= timeout_period;
- if (ent->timeout > 0) {
+ if (timeout_period < ent->timeout) {
+ ent->timeout -= timeout_period;
(*waiting_msgs)++;
return;
}
@@ -4110,7 +4111,8 @@ static void check_msg_timeout(ipmi_smi_t intf, struct
seq_table *ent,
}
}
-static unsigned int ipmi_timeout_handler(ipmi_smi_t intf, long timeout_period)
+static unsigned int ipmi_timeout_handler(ipmi_smi_t intf,
+unsigned long timeout_period)
{
struct list_head timeouts;
struct ipmi_recv_msg *msg, *msg2;
--
2.7.4
GOOD DAY
Please Whoever this email meets i need your co-operation and to introduce myself i am Mr Richard Water and i work with an intermediary bank by name Exodus bank Group , i discovered from my bank data assessment as the bank auditor general that a deceased customer left in one of his accounts 580 million United States Dollars and no one is aware of this for the past one year and 2 months . I am in search of anyone who can allow me file in His/Her name as the benefactor with 0.00 percent risk free after which we can split the money 50/40 and then 10% goes to the lawyer in charge . I await your response if interested . Kind Regards Richard Water Auditor
[PATCH] of: Update Moxa vendor prefix description
Update vendor description to be the full name of the corporate entity with this prefix reference: [1]: http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4806:26uh56.2.5 Signed-off-by: SZ Lin --- Documentation/devicetree/bindings/vendor-prefixes.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index daf465bef758..cfc9d9f631db 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -206,7 +206,7 @@ miramemsMiraMEMS Sensing Technology Co., Ltd. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. motorola Motorola, Inc. -moxa Moxa +moxa Moxa Inc. mplMPL AG mqmakermqmaker Inc. msiMicro-Star International Co. Ltd. -- 2.13.3
[PATCH v2] usb: gadget: add RNDIS configfs options for class/subclass/protocol
This adds 3 new options to the RNDIS gadget function configs. It allows
overriding the default USB interface class/subclass/protocol.
The motivation for this is that if you set the values to "ef" (Misc),
"04" (RNDIS), "01" (Ethernet) respectively, then the device will be
recognized by the rndiscmp.inf file in Windows Vista and newer and will
cause Windows to load the correct RNDIS driver without the need for a
custom (signed) .inf file.
Signed-off-by: David Lechner
---
This is a revision of "usb: gadget: add RNDIS configfs option for Windows
rndiscmp.inf compatibility"[1] using more generic options.
[1]: https://patchwork.kernel.org/patch/9597007/
.../ABI/testing/configfs-usb-gadget-rndis | 3 ++
drivers/usb/gadget/function/f_rndis.c | 20 +
drivers/usb/gadget/function/u_ether_configfs.h | 35 ++
drivers/usb/gadget/function/u_rndis.h | 4 +++
4 files changed, 62 insertions(+)
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-rndis
b/Documentation/ABI/testing/configfs-usb-gadget-rndis
index e32879b..1373990 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-rndis
+++ b/Documentation/ABI/testing/configfs-usb-gadget-rndis
@@ -12,3 +12,6 @@ Description:
Ethernet over USB link
dev_addr- MAC address of device's end of this
Ethernet over USB link
+ class - USB interface class, default is 02 (hex)
+ subclass- USB interface subclass, default is 06 (hex)
+ protocol- USB interface protocol, default is 00 (hex)
diff --git a/drivers/usb/gadget/function/f_rndis.c
b/drivers/usb/gadget/function/f_rndis.c
index 16562e4..e1d5853 100644
--- a/drivers/usb/gadget/function/f_rndis.c
+++ b/drivers/usb/gadget/function/f_rndis.c
@@ -691,6 +691,10 @@ rndis_bind(struct usb_configuration *c, struct
usb_function *f)
f->os_desc_table[0].os_desc = &rndis_opts->rndis_os_desc;
}
+ rndis_iad_descriptor.bFunctionClass = rndis_opts->class;
+ rndis_iad_descriptor.bFunctionSubClass = rndis_opts->subclass;
+ rndis_iad_descriptor.bFunctionProtocol = rndis_opts->protocol;
+
/*
* in drivers/usb/gadget/configfs.c:configfs_composite_bind()
* configurations are bound in sequence with list_for_each_entry,
@@ -866,11 +870,23 @@ USB_ETHERNET_CONFIGFS_ITEM_ATTR_QMULT(rndis);
/* f_rndis_opts_ifname */
USB_ETHERNET_CONFIGFS_ITEM_ATTR_IFNAME(rndis);
+/* f_rndis_opts_class */
+USB_ETHER_CONFIGFS_ITEM_ATTR_U8_RW(rndis, class);
+
+/* f_rndis_opts_subclass */
+USB_ETHER_CONFIGFS_ITEM_ATTR_U8_RW(rndis, subclass);
+
+/* f_rndis_opts_protocol */
+USB_ETHER_CONFIGFS_ITEM_ATTR_U8_RW(rndis, protocol);
+
static struct configfs_attribute *rndis_attrs[] = {
&rndis_opts_attr_dev_addr,
&rndis_opts_attr_host_addr,
&rndis_opts_attr_qmult,
&rndis_opts_attr_ifname,
+ &rndis_opts_attr_class,
+ &rndis_opts_attr_subclass,
+ &rndis_opts_attr_protocol,
NULL,
};
@@ -916,6 +932,10 @@ static struct usb_function_instance *rndis_alloc_inst(void)
}
INIT_LIST_HEAD(&opts->rndis_os_desc.ext_prop);
+ opts->class = rndis_iad_descriptor.bFunctionClass;
+ opts->subclass = rndis_iad_descriptor.bFunctionSubClass;
+ opts->protocol = rndis_iad_descriptor.bFunctionProtocol;
+
descs[0] = &opts->rndis_os_desc;
names[0] = "rndis";
config_group_init_type_name(&opts->func_inst.group, "",
diff --git a/drivers/usb/gadget/function/u_ether_configfs.h
b/drivers/usb/gadget/function/u_ether_configfs.h
index c71133d..e4c3f84a 100644
--- a/drivers/usb/gadget/function/u_ether_configfs.h
+++ b/drivers/usb/gadget/function/u_ether_configfs.h
@@ -153,4 +153,39 @@ out:
\
\
CONFIGFS_ATTR_RO(_f_##_opts_, ifname)
+#define USB_ETHER_CONFIGFS_ITEM_ATTR_U8_RW(_f_, _n_) \
+ static ssize_t _f_##_opts_##_n_##_show(struct config_item *item,\
+ char *page) \
+ { \
+ struct f_##_f_##_opts *opts = to_f_##_f_##_opts(item); \
+ int ret;\
+ \
+ mutex_lock(&opts->lock);\
+ ret = sprintf(page, "%02x\n", opts->_n_); \
+ mutex_unlock(&opts->lock); \
+ \
+ return ret; \
+ }
Re: [RFC v6 21/62] powerpc: introduce execute-only pkey
On Fri, Jul 28, 2017 at 07:17:13PM -0300, Thiago Jung Bauermann wrote:
>
> Ram Pai writes:
> > --- a/arch/powerpc/mm/pkeys.c
> > +++ b/arch/powerpc/mm/pkeys.c
> > @@ -97,3 +97,60 @@ int __arch_set_user_pkey_access(struct task_struct *tsk,
> > int pkey,
> > init_iamr(pkey, new_iamr_bits);
> > return 0;
> > }
> > +
> > +static inline bool pkey_allows_readwrite(int pkey)
> > +{
> > + int pkey_shift = pkeyshift(pkey);
> > +
> > + if (!(read_uamor() & (0x3UL << pkey_shift)))
> > + return true;
> > +
> > + return !(read_amr() & ((AMR_RD_BIT|AMR_WR_BIT) << pkey_shift));
> > +}
> > +
> > +int __execute_only_pkey(struct mm_struct *mm)
> > +{
> > + bool need_to_set_mm_pkey = false;
> > + int execute_only_pkey = mm->context.execute_only_pkey;
> > + int ret;
> > +
> > + /* Do we need to assign a pkey for mm's execute-only maps? */
> > + if (execute_only_pkey == -1) {
> > + /* Go allocate one to use, which might fail */
> > + execute_only_pkey = mm_pkey_alloc(mm);
> > + if (execute_only_pkey < 0)
> > + return -1;
> > + need_to_set_mm_pkey = true;
> > + }
> > +
> > + /*
> > +* We do not want to go through the relatively costly
> > +* dance to set AMR if we do not need to. Check it
> > +* first and assume that if the execute-only pkey is
> > +* readwrite-disabled than we do not have to set it
> > +* ourselves.
> > +*/
> > + if (!need_to_set_mm_pkey &&
> > + !pkey_allows_readwrite(execute_only_pkey))
^
Here uamor and amr is read once each.
> > + return execute_only_pkey;
> > +
> > + /*
> > +* Set up AMR so that it denies access for everything
> > +* other than execution.
> > +*/
> > + ret = __arch_set_user_pkey_access(current, execute_only_pkey,
> > + (PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE));
^^^
here amr and iamr are written once each if the
the function returns successfully.
> > + /*
> > +* If the AMR-set operation failed somehow, just return
> > +* 0 and effectively disable execute-only support.
> > +*/
> > + if (ret) {
> > + mm_set_pkey_free(mm, execute_only_pkey);
^^^
here only if __arch_set_user_pkey_access() fails
amr and iamr and uamor will be written once each.
> > + return -1;
> > + }
> > +
> > + /* We got one, store it and use it from here on out */
> > + if (need_to_set_mm_pkey)
> > + mm->context.execute_only_pkey = execute_only_pkey;
> > + return execute_only_pkey;
> > +}
>
> If you follow the code flow in __execute_only_pkey, the AMR and UAMOR
> are read 3 times in total, and AMR is written twice. IAMR is read and
> written twice. Since they are SPRs and access to them is slow (or isn't
> it?), is it worth it to read them once in __execute_only_pkey and pass
> down their values to the callees, and then write them once at the end of
> the function?
If my calculations are right:
uamor may be read once and may be written once.
amr may be read once and is written once.
iamr is written once.
So not that bad, i think.
RP
Re: [RFC v6 27/62] powerpc: helper to validate key-access permissions of a pte
On Fri, Jul 28, 2017 at 06:00:02PM -0300, Thiago Jung Bauermann wrote:
>
> Ram Pai writes:
> > --- a/arch/powerpc/mm/pkeys.c
> > +++ b/arch/powerpc/mm/pkeys.c
> > @@ -201,3 +201,36 @@ int __arch_override_mprotect_pkey(struct
> > vm_area_struct *vma, int prot,
> > */
> > return vma_pkey(vma);
> > }
> > +
> > +static bool pkey_access_permitted(int pkey, bool write, bool execute)
> > +{
> > + int pkey_shift;
> > + u64 amr;
> > +
> > + if (!pkey)
> > + return true;
> > +
> > + pkey_shift = pkeyshift(pkey);
> > + if (!(read_uamor() & (0x3UL << pkey_shift)))
> > + return true;
> > +
> > + if (execute && !(read_iamr() & (IAMR_EX_BIT << pkey_shift)))
> > + return true;
> > +
> > + if (!write) {
> > + amr = read_amr();
> > + if (!(amr & (AMR_RD_BIT << pkey_shift)))
> > + return true;
> > + }
> > +
> > + amr = read_amr(); /* delay reading amr uptil absolutely needed */
>
> Actually, this is causing amr to be read twice in case control enters
> the "if (!write)" block above but doesn't enter the other if block nested
> in it.
>
> read_amr should be called only once, right before "if (!write)".
the code can be simplified without having to read amr twice.
will fix it.
thanks,
RP
>
> --
> Thiago Jung Bauermann
> IBM Linux Technology Center
--
Ram Pai
Re: [RFC v6 15/62] powerpc: helper functions to initialize AMR, IAMR and UMOR registers
On Thu, Jul 27, 2017 at 05:40:44PM -0300, Thiago Jung Bauermann wrote:
>
> Ram Pai writes:
>
> > Introduce helper functions that can initialize the bits in the AMR,
> > IAMR and UMOR register; the bits that correspond to the given pkey.
> >
> > Signed-off-by: Ram Pai
>
> s/UMOR/UAMOR/ here and in the subject as well.
yes. fixed it.
>
> > --- a/arch/powerpc/mm/pkeys.c
> > +++ b/arch/powerpc/mm/pkeys.c
> > @@ -16,3 +16,47 @@
> > #include /* PKEY_* */
> >
> > bool pkey_inited;
> > +#define pkeyshift(pkey) ((arch_max_pkey()-pkey-1) * AMR_BITS_PER_PKEY)
> > +
> > +static inline void init_amr(int pkey, u8 init_bits)
> > +{
> > + u64 new_amr_bits = (((u64)init_bits & 0x3UL) << pkeyshift(pkey));
> > + u64 old_amr = read_amr() & ~((u64)(0x3ul) << pkeyshift(pkey));
> > +
> > + write_amr(old_amr | new_amr_bits);
> > +}
> > +
> > +static inline void init_iamr(int pkey, u8 init_bits)
> > +{
> > + u64 new_iamr_bits = (((u64)init_bits & 0x3UL) << pkeyshift(pkey));
> > + u64 old_iamr = read_iamr() & ~((u64)(0x3ul) << pkeyshift(pkey));
> > +
> > + write_amr(old_iamr | new_iamr_bits);
> > +}
>
> init_iamr should call write_iamr, not write_amr.
excellent catch. thanks.
RP
Re: [PATCH] memory: mtk-smi: Use of_device_get_match_data helper
Hi Honghui,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc2 next-20170728]
[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/honghui-zhang-mediatek-com/memory-mtk-smi-Use-of_device_get_match_data-helper/20170728-161812
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
drivers//memory/mtk-smi.c: In function 'mtk_smi_common_probe':
>> drivers//memory/mtk-smi.c:341:10: error: incompatible types when assigning
>> to type 'enum mtk_smi_gen' from type 'const void *'
smi_gen = of_device_get_match_data(dev);
^
vim +341 drivers//memory/mtk-smi.c
311
312 static int mtk_smi_common_probe(struct platform_device *pdev)
313 {
314 struct device *dev = &pdev->dev;
315 struct mtk_smi *common;
316 struct resource *res;
317 enum mtk_smi_gen smi_gen;
318
319 if (!dev->pm_domain)
320 return -EPROBE_DEFER;
321
322 common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
323 if (!common)
324 return -ENOMEM;
325 common->dev = dev;
326
327 common->clk_apb = devm_clk_get(dev, "apb");
328 if (IS_ERR(common->clk_apb))
329 return PTR_ERR(common->clk_apb);
330
331 common->clk_smi = devm_clk_get(dev, "smi");
332 if (IS_ERR(common->clk_smi))
333 return PTR_ERR(common->clk_smi);
334
335 /*
336 * for mtk smi gen 1, we need to get the ao(always on) base to
config
337 * m4u port, and we need to enable the aync clock for transform
the smi
338 * clock into emi clock domain, but for mtk smi gen2, there's
no smi ao
339 * base.
340 */
> 341 smi_gen = of_device_get_match_data(dev);
342 if (smi_gen == MTK_SMI_GEN1) {
343 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
344 common->smi_ao_base = devm_ioremap_resource(dev, res);
345 if (IS_ERR(common->smi_ao_base))
346 return PTR_ERR(common->smi_ao_base);
347
348 common->clk_async = devm_clk_get(dev, "async");
349 if (IS_ERR(common->clk_async))
350 return PTR_ERR(common->clk_async);
351
352 clk_prepare_enable(common->clk_async);
353 }
354 pm_runtime_enable(dev);
355 platform_set_drvdata(pdev, common);
356 return 0;
357 }
358
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot
Hi
On Mon, Jul 24, 2017 at 12:53:27PM +0300, Felipe Balbi wrote:
Hi,
gustavo panizzo writes:
On Wed, Jul 12, 2017 at 02:08:04PM +0800, Baolin Wang wrote:
Hi,
On 12 July 2017 at 11:52, gustavo panizzo wrote:
The dwc3 could not release resources when the module is built-in
because this module does not have shutdown method. This causes the USB
3.0 hub is not able to detect after warm boot.
Original patch by Brian Kim, updated and submitted upstream by gustavo
panizzo.
Also see https://bugs.debian.org/843448
Signed-off-by: Brian Kim
Signed-off-by: gustavo panizzo
---
drivers/usb/dwc3/core.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 326b302fc440..f92dfe213d89 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1259,6 +1259,38 @@ static int dwc3_probe(struct platform_device
*pdev)
return ret;
}
+static void dwc3_shutdown(struct platform_device *pdev)
+{
+ struct dwc3 *dwc = platform_get_drvdata(pdev);
+ struct resource *res = platform_get_resource(pdev,
IORESOURCE_MEM, 0);
+
+ pm_runtime_get_sync(&pdev->dev);
+ /*
+* restore res->start back to its original value so that, in case
the
+* probe is deferred, we don't end up getting error in request
the
+* memory region the next time probe is called.
+*/
+ res->start -= DWC3_GLOBALS_REGS_START;
+
+ dwc3_debugfs_exit(dwc);
+ dwc3_core_exit_mode(dwc);
+ dwc3_event_buffers_cleanup(dwc);
What about dwc3_event_buffers_cleanup? should I remove it from
dwc3_shutdown()?
It is already in dwc3_core_exit()
I think so. We should avoid duplicate code.
+ dwc3_free_event_buffers(dwc);
+
+ usb_phy_set_suspend(dwc->usb2_phy, 1);
+ usb_phy_set_suspend(dwc->usb3_phy, 1);
+
+ phy_power_off(dwc->usb2_generic_phy);
+ phy_power_off(dwc->usb3_generic_phy);
We've done these in dwc3_core_exit().
This is the patch after testing on a Odroid XU4, on top of linux-next
964bcc1b4f57028d56dace7d9bc5924f2eb43f36 which translates to
4.13.0-rc1-next-20170717+
I tested this patch for a week without problems with heavy USB and NIC usage.
Please consider merging it
Author: gustavo panizzo
Date: Wed Jul 12 11:26:55 2017 +0800
usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot
The dwc3 could not release resources when the module is built-in
because this module does not have shutdown method. This causes the USB
3.0 hub is not able to detect after warm boot.
Original patch by Brian Kim, updated and submitted upstream by gustavo
panizzo.
if the original patch is from Brian, then 'Author' should be
Brian. Please fix it.
sure, i just didn't want to attribute something he didn't write
I also don't get why all of a sudden we need to implement
->shutdown(). Why is it that we never needed it before and we need it now?
Commit c499ff71ff2a281366c6ec7a904c547d806cbcd1 broke USB3 for the
Odroid XU4, this 2 patches fix the USB3
https://github.com/hardkernel/linux/commit/74b9605e5587b30912d6b6093e9d7fb06d043c33
https://github.com/hardkernel/linux/commit/2166ffd004e04a61887eb2a39f8639dc12140c58
Hardkernel didn't upstreamed them, after investigation in Debian #843448
the 2 patches were identified.
The first patch is being upstreamed by Jochen Sprickerhof
http://marc.info/?l=linux-usb&m=149945465112440&w=2
I'm taking care of the second patch
Care to bisect to find the first commit which started causing this
problem?
c499ff71ff2a281366c6ec7a904c547d806cbcd1
--
balbi
--
IRC: gfa
GPG: 0X44BB1BA79F6C6333
Re: [RFC v6 20/62] powerpc: store and restore the pkey state across context switches
On Thu, Jul 27, 2017 at 02:32:59PM -0300, Thiago Jung Bauermann wrote: > > Ram Pai writes: > > > Store and restore the AMR, IAMR and UMOR register state of the task > > before scheduling out and after scheduling in, respectively. > > > > Signed-off-by: Ram Pai > > s/UMOR/UAMOR/ > > > diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c > > index 2ad725e..9429361 100644 > > --- a/arch/powerpc/kernel/process.c > > +++ b/arch/powerpc/kernel/process.c > > @@ -1096,6 +1096,11 @@ static inline void save_sprs(struct thread_struct *t) > > t->tar = mfspr(SPRN_TAR); > > } > > #endif > > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > > + t->amr = mfspr(SPRN_AMR); > > + t->iamr = mfspr(SPRN_IAMR); > > + t->uamor = mfspr(SPRN_UAMOR); > > +#endif > > } > > > > static inline void restore_sprs(struct thread_struct *old_thread, > > @@ -1131,6 +1136,14 @@ static inline void restore_sprs(struct thread_struct > > *old_thread, > > mtspr(SPRN_TAR, new_thread->tar); > > } > > #endif > > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > > + if (old_thread->amr != new_thread->amr) > > + mtspr(SPRN_AMR, new_thread->amr); > > + if (old_thread->iamr != new_thread->iamr) > > + mtspr(SPRN_IAMR, new_thread->iamr); > > + if (old_thread->uamor != new_thread->uamor) > > + mtspr(SPRN_UAMOR, new_thread->uamor); > > +#endif > > } > > Shouldn't the saving and restoring of the SPRs be guarded by a check for > whether memory protection keys are enabled? What happens when trying to > access these registers on a CPU which doesn't have them? Good point. need to guard it. However; i think, these registers have been available since power6. RP
undefined reference to `_GLOBAL_OFFSET_TABLE_'
Hi Nicholas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 0a07b238e5f488b459b6113a62e06b6aab017f71
commit: 799c43415442414b1032580c47684cb709dfed6d kbuild: thin archives make
default for all archs
date: 4 weeks ago
config: microblaze-allnoconfig (attached as .config)
compiler: microblaze-linux-gcc (GCC) 6.2.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 799c43415442414b1032580c47684cb709dfed6d
# save the attached .config to linux build tree
make.cross ARCH=microblaze
All errors (new ones prefixed by >>):
mm/slub.o: In function `__slab_free.isra.13':
>> (.text+0x1038): undefined reference to `_GLOBAL_OFFSET_TABLE_'
scripts/link-vmlinux.sh: line 93: 21303 Segmentation fault ${LD}
${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} ${objects}
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC v6 19/62] powerpc: ability to create execute-disabled pkeys
On Thu, Jul 27, 2017 at 11:54:31AM -0300, Thiago Jung Bauermann wrote:
>
> Ram Pai writes:
>
> > --- a/arch/powerpc/include/asm/pkeys.h
> > +++ b/arch/powerpc/include/asm/pkeys.h
> > @@ -2,6 +2,18 @@
> > #define _ASM_PPC64_PKEYS_H
> >
> > extern bool pkey_inited;
> > +/* override any generic PKEY Permission defines */
> > +#undef PKEY_DISABLE_ACCESS
> > +#define PKEY_DISABLE_ACCESS0x1
> > +#undef PKEY_DISABLE_WRITE
> > +#define PKEY_DISABLE_WRITE 0x2
> > +#undef PKEY_DISABLE_EXECUTE
> > +#define PKEY_DISABLE_EXECUTE 0x4
> > +#undef PKEY_ACCESS_MASK
> > +#define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\
> > + PKEY_DISABLE_WRITE |\
> > + PKEY_DISABLE_EXECUTE)
> > +
>
> Is it ok to #undef macros from another header? Especially since said
> header is in uapi (include/uapi/asm-generic/mman-common.h).
>
> Also, it's unnecessary to undef the _ACCESS and _WRITE macros since they
> are identical to the original definition. And since these macros are
> originally defined in an uapi header, the powerpc-specific ones should
> be in an uapi header as well, if I understand it correctly.
The architectural neutral code allows the implementation to define the
macros to its taste. powerpc headers due to legacy reason includes the
include/uapi/asm-generic/mman-common.h header. That header includes the
generic definitions of only PKEY_DISABLE_ACCESS and PKEY_DISABLE_WRITE.
Unfortunately we end up importing them. I dont want to depend on them.
Any changes there could effect us. Example if the generic uapi header
changed PKEY_DISABLE_ACCESS to 0x4, we will have a conflict with
PKEY_DISABLE_EXECUTE. Hence I undef them and define the it my way.
>
> An alternative solution is to define only PKEY_DISABLE_EXECUTE in
> arch/powerpc/include/uapi/asm/mman.h and then test for its existence to
> properly define PKEY_ACCESS_MASK in
> include/uapi/asm-generic/mman-common.h. What do you think of the code
> below?
>
> diff --git a/arch/powerpc/include/asm/pkeys.h
> b/arch/powerpc/include/asm/pkeys.h
> index e31f5ee8e81f..67e6a3a343ae 100644
> --- a/arch/powerpc/include/asm/pkeys.h
> +++ b/arch/powerpc/include/asm/pkeys.h
> @@ -4,17 +4,6 @@
> #include
>
> extern bool pkey_inited;
> -/* override any generic PKEY Permission defines */
> -#undef PKEY_DISABLE_ACCESS
> -#define PKEY_DISABLE_ACCESS0x1
> -#undef PKEY_DISABLE_WRITE
> -#define PKEY_DISABLE_WRITE 0x2
> -#undef PKEY_DISABLE_EXECUTE
> -#define PKEY_DISABLE_EXECUTE 0x4
> -#undef PKEY_ACCESS_MASK
> -#define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\
> - PKEY_DISABLE_WRITE |\
> - PKEY_DISABLE_EXECUTE)
>
> #define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \
> VM_PKEY_BIT3 | VM_PKEY_BIT4)
> diff --git a/arch/powerpc/include/uapi/asm/mman.h
> b/arch/powerpc/include/uapi/asm/mman.h
> index ab45cc2f3101..dee43feb7c53 100644
> --- a/arch/powerpc/include/uapi/asm/mman.h
> +++ b/arch/powerpc/include/uapi/asm/mman.h
> @@ -45,4 +45,6 @@
> #define MAP_HUGE_1GB (30 << MAP_HUGE_SHIFT) /* 1GB HugeTLB Page */
> #define MAP_HUGE_16GB(34 << MAP_HUGE_SHIFT) /* 16GB HugeTLB Page */
>
> +#define PKEY_DISABLE_EXECUTE 0x4
> +
> #endif /* _UAPI_ASM_POWERPC_MMAN_H */
> diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
> index 72eb9a1bde79..777f8f8dff47 100644
> --- a/arch/powerpc/mm/pkeys.c
> +++ b/arch/powerpc/mm/pkeys.c
> @@ -12,7 +12,7 @@
> * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> * more details.
> */
> -#include
> +#include
> #include /* PKEY_* */
>
> bool pkey_inited;
> diff --git a/include/uapi/asm-generic/mman-common.h
> b/include/uapi/asm-generic/mman-common.h
> index 8c27db0c5c08..93e3841d9ada 100644
> --- a/include/uapi/asm-generic/mman-common.h
> +++ b/include/uapi/asm-generic/mman-common.h
> @@ -74,7 +74,15 @@
>
> #define PKEY_DISABLE_ACCESS 0x1
> #define PKEY_DISABLE_WRITE 0x2
> +
> +/* The arch-specific code may define PKEY_DISABLE_EXECUTE */
> +#ifdef PKEY_DISABLE_EXECUTE
> +#define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\
> + PKEY_DISABLE_WRITE | \
> + PKEY_DISABLE_EXECUTE)
> +#else
> #define PKEY_ACCESS_MASK (PKEY_DISABLE_ACCESS |\
>PKEY_DISABLE_WRITE)
> +#endif
>
> #endif /* __ASM_GENERIC_MMAN_COMMON_H */
I suppose we can do it this way aswell. but dont like the way it is
spreading the defines accross multiple files.
>
>
> > diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
> > index 98d0391..b9ad98d 100644
> > --- a/arch/powerpc/mm/pkeys.c
> > +++ b/arch/powerpc/mm/pkeys.c
> > @@ -73,6 +73,7 @@ int __arch_set_user_pkey_access(struct task_struct *tsk,
> > int pkey,
> > unsigned long init_val)
> > {
> > u64 new_amr
Re: Yes you have standing to sue GRSecurity
> It's not even clear that there is infringement. The GPL merely > requires that people who have been distributed copies of GPL'ed code > must not be restricted from further redistribution of the code. It > does not require that that someone who is distributing it must > available on a public FTP/HTTP server. > > Brad Spengler has asserted that he has not forbidden any of his > customers from further redistribution of the code. Other than his > claim of being in compliance with the GPL, I do not personally have > any information either suggesting that he is or is not violating the > terms of the GNU Public License. > > Personally, I think I don't think it makes any difference one way or > another. GRSecurity has made themselves irrelevant from the > perspective of upstream development. If someone wants to find some > embedded device which is using GRSecurity, and wishes to purchase said > device, and then demand access to source code under the terms of the > GPL, and then post those sources on some web site, that is all within > their right to do. For the most part, though, it's rarely useful to > get dead code posted on a web site. This is the same reason that > people who do drive-by open sourcing of code largely don't make much > difference. You can make a code drop of (for example) Digital's old > Tru64 advfs and make it available under an open source license. But > even though it was a very good file system for its time, unless it > comes with a community of developers, the code drop will very likely > just sit there. > > So personally, I don't think it's a particularly good use of *my* time > to investigate whether or not folks who are responsible for grsecurity > are violating the terms of the GPL, and to get involved in a lawsuit. > It may be that there is no "there" there, in which case it will be a > waste of my time. And even if we can find proof that GRsecurity has > forbidden its customers from redistribution code derived from the > Linux kernel, in violation of the GPL, it will be messy, it will > enrich a bunch of attorneys --- and at the end of the day we will get > a dump of code that probably won't make any real difference to the > upstream development of the Linux kernel, since it will probably be > based on some ancient 3.18 kernel or some such. > If there is something to this (that GRSecurity is somehow in violation of the GPL), then it would probably be a very good idea for someone (the community, Red Hat, etc.) to protect the kernel. From my understanding, at least in America, protections under any license or contract (especially dealing with copyright and trademark infringement) are only enforceable as long as the party with the rights enforce the license/contract/agreement. There is also something in law called "setting a precedent" and if the violating of the Linux license agreement is left unchecked, then quite possibly a precedent could be set to allow an entire upstream kernel to be co-opted. I've know a LOT of engineers over the past 30+ years that ignore the legal ramifications of what they do (because most engineers want to engineer, not deal with legal garbage), and end up losing in the end (or causing lawsuits for their company). In other words, if things like this are left unchecked, then eventually Linux possibly becomes co-opted by a company that violates the license and everyone else is left having to pay them. I have had code stolen in the past (an entire game in fact). That was at a time when I was not financially able to do anything about it, and even if I was, I was too young tot know any better and would not have pursued any action. I now know better and have seen - since then - people lose and be diminished because some entity took the fruits of their long, hard work. In summary, I think dismissing such a thing out-of-hand is a mistake. Looking into it and making sure of the issue helps everyone, and continues to keep the kernel free (who here remembers SCO?). Thanks, PGA -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com
Re: [PATCH v4 15/17] ASoC: cs47l35: Add codec driver for Cirrus Logic CS47L35
Hi Richard,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.13-rc2 next-20170728]
[cannot apply to ljones-mfd/for-mfd-next asoc/for-next]
[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/Richard-Fitzgerald/Add-support-for-Cirrus-Logic-CS47L35-L85-L90-L91-codecs/20170730-062737
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the
linux-review/Richard-Fitzgerald/Add-support-for-Cirrus-Logic-CS47L35-L85-L90-L91-codecs/20170730-062737
HEAD 15487144eec6910ecfd97bb5a2c7efdb259f builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
>> sound/soc//codecs/madera.c:146:2: error: 'MADERA_IRQ_DSP1_BUS_ERROR'
>> undeclared here (not in a function)
MADERA_IRQ_DSP1_BUS_ERROR,
^
>> sound/soc//codecs/madera.c:147:2: error: 'MADERA_IRQ_DSP2_BUS_ERROR'
>> undeclared here (not in a function)
MADERA_IRQ_DSP2_BUS_ERROR,
^
>> sound/soc//codecs/madera.c:148:2: error: 'MADERA_IRQ_DSP3_BUS_ERROR'
>> undeclared here (not in a function)
MADERA_IRQ_DSP3_BUS_ERROR,
^
>> sound/soc//codecs/madera.c:149:2: error: 'MADERA_IRQ_DSP4_BUS_ERROR'
>> undeclared here (not in a function)
MADERA_IRQ_DSP4_BUS_ERROR,
^
>> sound/soc//codecs/madera.c:150:2: error: 'MADERA_IRQ_DSP5_BUS_ERROR'
>> undeclared here (not in a function)
MADERA_IRQ_DSP5_BUS_ERROR,
^
>> sound/soc//codecs/madera.c:151:2: error: 'MADERA_IRQ_DSP6_BUS_ERROR'
>> undeclared here (not in a function)
MADERA_IRQ_DSP6_BUS_ERROR,
^
>> sound/soc//codecs/madera.c:152:2: error: 'MADERA_IRQ_DSP7_BUS_ERROR'
>> undeclared here (not in a function)
MADERA_IRQ_DSP7_BUS_ERROR,
^
vim +/MADERA_IRQ_DSP1_BUS_ERROR +146 sound/soc//codecs/madera.c
da1efc4cc Richard Fitzgerald 2017-07-28 130
da1efc4cc Richard Fitzgerald 2017-07-28 131 #define madera_fll_err(_fll, fmt,
...) \
da1efc4cc Richard Fitzgerald 2017-07-28 132dev_err(_fll->madera->dev,
"FLL%d: " fmt, _fll->id, ##__VA_ARGS__)
da1efc4cc Richard Fitzgerald 2017-07-28 133 #define madera_fll_warn(_fll,
fmt, ...) \
da1efc4cc Richard Fitzgerald 2017-07-28 134dev_warn(_fll->madera->dev,
"FLL%d: " fmt, _fll->id, ##__VA_ARGS__)
da1efc4cc Richard Fitzgerald 2017-07-28 135 #define madera_fll_dbg(_fll, fmt,
...) \
da1efc4cc Richard Fitzgerald 2017-07-28 136dev_dbg(_fll->madera->dev,
"FLL%d: " fmt, _fll->id, ##__VA_ARGS__)
da1efc4cc Richard Fitzgerald 2017-07-28 137
da1efc4cc Richard Fitzgerald 2017-07-28 138 #define madera_aif_err(_dai, fmt,
...) \
da1efc4cc Richard Fitzgerald 2017-07-28 139dev_err(_dai->dev, "AIF%d: "
fmt, _dai->id, ##__VA_ARGS__)
da1efc4cc Richard Fitzgerald 2017-07-28 140 #define madera_aif_warn(_dai,
fmt, ...) \
da1efc4cc Richard Fitzgerald 2017-07-28 141dev_warn(_dai->dev, "AIF%d: "
fmt, _dai->id, ##__VA_ARGS__)
da1efc4cc Richard Fitzgerald 2017-07-28 142 #define madera_aif_dbg(_dai, fmt,
...) \
da1efc4cc Richard Fitzgerald 2017-07-28 143dev_dbg(_dai->dev, "AIF%d: "
fmt, _dai->id, ##__VA_ARGS__)
da1efc4cc Richard Fitzgerald 2017-07-28 144
da1efc4cc Richard Fitzgerald 2017-07-28 145 static const int
madera_dsp_bus_error_irqs[MADERA_MAX_ADSP] = {
da1efc4cc Richard Fitzgerald 2017-07-28 @146MADERA_IRQ_DSP1_BUS_ERROR,
da1efc4cc Richard Fitzgerald 2017-07-28 @147MADERA_IRQ_DSP2_BUS_ERROR,
da1efc4cc Richard Fitzgerald 2017-07-28 @148MADERA_IRQ_DSP3_BUS_ERROR,
da1efc4cc Richard Fitzgerald 2017-07-28 @149MADERA_IRQ_DSP4_BUS_ERROR,
da1efc4cc Richard Fitzgerald 2017-07-28 @150MADERA_IRQ_DSP5_BUS_ERROR,
da1efc4cc Richard Fitzgerald 2017-07-28 @151MADERA_IRQ_DSP6_BUS_ERROR,
da1efc4cc Richard Fitzgerald 2017-07-28 @152MADERA_IRQ_DSP7_BUS_ERROR,
da1efc4cc Richard Fitzgerald 2017-07-28 153 };
da1efc4cc Richard Fitzgerald 2017-07-28 154
:: The code at line 146 was first introduced by commit
:: da1efc4cc715281f9599274bb5ff408b19cd3335 ASoC: madera: Add common
support for Cirrus Logic Madera codecs
:: TO: Richard Fitzgerald
:: CC: 0day robot
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC v6 17/62] powerpc: implementation for arch_set_user_pkey_access()
On Thu, Jul 27, 2017 at 11:15:36AM -0300, Thiago Jung Bauermann wrote:
>
> Ram Pai writes:
> > @@ -113,10 +117,14 @@ static inline int arch_override_mprotect_pkey(struct
> > vm_area_struct *vma,
> > return 0;
> > }
> >
> > +extern int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
> > + unsigned long init_val);
> > static inline int arch_set_user_pkey_access(struct task_struct *tsk, int
> > pkey,
> > unsigned long init_val)
> > {
> > - return 0;
> > + if (!pkey_inited)
> > + return -1;
> > + return __arch_set_user_pkey_access(tsk, pkey, init_val);
> > }
>
> If non-zero, the return value of this function will be passed to
> userspace by the pkey_alloc syscall. Shouldn't it be returning an errno
> macro such as -EPERM?
Yes. it should be -EINVAL. fixed it.
>
> Also, why are there both arch_set_user_pkey_access and
> __arch_set_user_pkey_access? Is it a speed optimization so that the
> early return is inlined into the caller? Ditto for execute_only_pkey
> and __arch_override_mprotect_pkey.
arch_set_user_pkey_access() is the interface expected by the
architecture independent code. The __arch_set_user_pkey_access() is an
powerpc internal function that implements the bulk of the work. It can
be called by any of the pkeys internal code only. This gives me the
flexibility to change implementation without having to worry about
changing the interface.
RP
Re: [RFC v6 13/62] powerpc: track allocation status of all pkeys
On Thu, Jul 27, 2017 at 11:01:44AM -0300, Thiago Jung Bauermann wrote: > > Hello Ram, > > I'm still going through the patches and haven't formed a full picture of > the feature in my mind yet, so my comments today won't be particularly > insightful... > > But hopefully the comments that I currently have will be helpful anyway. sure. thanx for taking the time to look through the patches. > > Ram Pai writes: > > diff --git a/arch/powerpc/include/asm/pkeys.h > > b/arch/powerpc/include/asm/pkeys.h > > index 203d7de..09b268e 100644 > > --- a/arch/powerpc/include/asm/pkeys.h > > +++ b/arch/powerpc/include/asm/pkeys.h > > @@ -2,21 +2,87 @@ > > #define _ASM_PPC64_PKEYS_H > > > > extern bool pkey_inited; > > -#define ARCH_VM_PKEY_FLAGS 0 > > +#define arch_max_pkey() 32 > > +#define ARCH_VM_PKEY_FLAGS (VM_PKEY_BIT0 | VM_PKEY_BIT1 | VM_PKEY_BIT2 | \ > > + VM_PKEY_BIT3 | VM_PKEY_BIT4) > > +/* > > + * Bits are in BE format. > > + * NOTE: key 31, 1, 0 are not used. > > + * key 0 is used by default. It give read/write/execute permission. > > + * key 31 is reserved by the hypervisor. > > + * key 1 is recommended to be not used. > > + * PowerISA(3.0) page 1015, programming note. > > + */ > > +#define PKEY_INITIAL_ALLOCAION 0xc001 > > There's a typo in the macro name, should be "ALLOCATION". Thanks fixed it. The new version of the code, calculates the allocation_mask at runtime, depending on the number of keys specified by the device tree as well as other factors. So the above macro is replaced by a variable 'initial_allocation_mask'. RP > > -- > Thiago Jung Bauermann > IBM Linux Technology Center -- Ram Pai
Re: wake_wide mechanism clarification
On Sat, Jul 29, 2017 at 3:28 PM, Joel Fernandes wrote: Again I didn't follow why the second condition couldn't just be: waker->nr_wakee_switch > factor, or, (waker->nr_wakee_switch + wakee->nr_wakee_switch) > factor, based on the above explanation from Micheal Wang that I quoted. and why he's instead doing the whole multiplication thing there that I was talking about earlier: "factor * wakee->nr_wakee_switch". Rephrasing my question in another way, why are we talking the ratio of master/slave instead of the sum when comparing if its > factor? I am surely missing something here. >>> >>> Because the heuristic tries to not demolish 1:1 buddies. Big partner >>> flip delta means the pair are unlikely to be a communicating pair, >>> perhaps at high frequency where misses hurt like hell. >> >> But it does seem to me to demolish the N:N communicating pairs from a >> latency/load balancing standpoint. For he case of N readers and N >> writers, the ratio (master/slave) comes down to 1:1 and we wake >> affine. Hopefully I didn't miss something too obvious about that. > > I think wake_affine() should correctly handle the case (of > overloading) I bring up here where wake_wide() is too conservative and > does affine a lot, (I don't have any data for this though, this just > from code reading), so I take this comment back for this reason. aargh, nope :( it still runs select_idle_sibling although on the previous CPU even if want_affine is 0 (and doesn't do the wider wakeup..), so the comment still applies.. its easy to get lost into the code with so many if statements :-\ sorry about the noise :) thanks, -Joel
Re: [PATCH] rtc: rtc-stmp3xxx: detect power failure on backup power domain
On 07/06/2017 at 15:05:03 +0200, Michael Thalmeier wrote:
> On Thu, May 18, 2017 at 05:56:31PM +0200, Alexandre Belloni wrote:
> > Hi,
> >
> > On 18/05/2017 at 16:45:21 +0200, Michael Thalmeier wrote:
> > > To detect when the backup power domain has lost power a software defined
> > > bit
> > > is set in one of the general purpose persistent registers when writing a
> > > new
> > > time into the rtc.
> > > When reading the time this bit is checked to determine if a power fail has
> > > happened since the last time the rtc time was set.
> > >
> >
> > I'm kind of concerned that other people may want to use those register
> > for something else but I don't currently have anything better to
> > suggest.
> >
> > The other concern is that when updating the kernel, this will make amm
> > the rtc report that the time is invalid until the next update. So this
> > should be disabled by default.
>
> How would you think this is best to disable by default? With a config
> option or with a module parameter?
> Either way would also allow to make the bit mask in the PERSISTENT2
> register configurable, so one can use whichever bit is still unused by
> some other applications.
>
What you could do is export the persistent registers with nvmem. Then
you can define a cell in DT using a bit in persistent2 and use it from
the rtc driver itself.
If the cell is defined, then the driver know it has been configured to
detect power failure.
> >
> > > When we detect a power fail we return -ENODATA.
> > >
> >
> > All the other drivers return -EINVAL in that case.
> >
> > > Signed-off-by: Michael Thalmeier
> > > ---
> > > drivers/rtc/rtc-stmp3xxx.c | 9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/drivers/rtc/rtc-stmp3xxx.c b/drivers/rtc/rtc-stmp3xxx.c
> > > index d578e40..51330ec 100644
> > > --- a/drivers/rtc/rtc-stmp3xxx.c
> > > +++ b/drivers/rtc/rtc-stmp3xxx.c
> > > @@ -62,6 +62,9 @@
> > > /* missing bitmask in headers */
> > > #define STMP3XXX_RTC_PERSISTENT1_FORCE_UPDATER 0x8000
> > >
> > > +#define STMP3XXX_RTC_PERSISTENT2 0x80
> > > +#define STMP3XXX_RTC_PERSISTENT2_VALID_TIME 0x01
> > > +
> > > struct stmp3xxx_rtc_data {
> > > struct rtc_device *rtc;
> > > void __iomem *io;
> > > @@ -160,6 +163,10 @@ static int stmp3xxx_rtc_gettime(struct device *dev,
> > > struct rtc_time *rtc_tm)
> > > if (ret)
> > > return ret;
> > >
> > > + if (!(readl(rtc_data->io + STMP3XXX_RTC_PERSISTENT2) &
> > > + STMP3XXX_RTC_PERSISTENT2_VALID_TIME))
> > > + return -ENODATA;
> > > +
> > > rtc_time_to_tm(readl(rtc_data->io + STMP3XXX_RTC_SECONDS), rtc_tm);
> > > return 0;
> > > }
> > > @@ -169,6 +176,8 @@ static int stmp3xxx_rtc_set_mmss(struct device *dev,
> > > unsigned long t)
> > > struct stmp3xxx_rtc_data *rtc_data = dev_get_drvdata(dev);
> > >
> > > writel(t, rtc_data->io + STMP3XXX_RTC_SECONDS);
> > > + writel(STMP3XXX_RTC_PERSISTENT2_VALID_TIME,
> > > + rtc_data->io + STMP3XXX_RTC_PERSISTENT2 + STMP_OFFSET_REG_SET);
> > > return stmp3xxx_wait_time(rtc_data);
> > > }
> > >
> > > --
> > > 2.9.2
> > >
> >
> > --
> > Alexandre Belloni, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> --
>
> Michael Thalmeier
> (Entwicklung)
> HALE electronic GmbH
> Eugen-Müller-Straße 18, 5020 Salzburg, Austria
> Tel: +43 (662) 439011 0
> Fax: +43 (662) 439011 9
> michael.thalme...@hale.at
> Firmenbuchnummer: FN 66801m HG Salzburg
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
bc6febb2166b65e7032c424620ec5e47.jpeg★★★ 10月,广交会 —— 2017广州国际进出口汽车配件展览会 ★★★ [地右P4/L100-Z]
【通过本邮件参展优惠500元一展位，需回信专用邮箱“12809...@qq.com”报名】 尊敬的 bc6febb2166b65e7032c424620ec5e47.jpeg 企业领导/公司负责人： 诚邀参加中国最大汽配外贸展 —— APF 2017 汽配行业品牌盛会，外贸企业最佳选择，全球采购首选平台！ ★ 与“广交会”同期同地举行， ★ 以“广交会”庞大的客流量为依托，买家互动，借势兴展， ★ 共享来自全球数十万采购商资源••• 【 基 本 信 息 】 中文名称： 2017广州国际进出口汽车配件展览会 英文名称： The Guangzhou International Import and Export Auto Parts Fair 2017 （APF 2017） 展会日期： 2017年10月13—15日 展会场馆： 广州琶洲国际采购中心 批准单位： 中华人民共和国商务部 主办单位： 中国对外贸易经济合作企业协会、映德国际会展有限公司 官方网站： http://www.CAPE-china.com 在线客服： 邮箱/QQ：q...@12809395.com； 微信：ZhanShangZhiJia； 微博：http://weibo.com/yingdehuizhan 咨询电话： 4000-580-850（转5206或8144）； 131-2662-5206； 010―8699-7155、 8084-2128； 【 展 会 介 绍 】 中国目前的汽车保有量已达1.95亿多辆，预计到2020年，中国汽车保有量将超过2.5亿辆。预计2016年中国汽车年产销量将超过3000万辆，到2020年中国汽车产销量将分别超过4500万辆，从而成为名副其实的全球第一大汽车市场。汽车配件是汽车工业发展的基础，汽车配件配套及售后服务市场是汽车市场的重要组成部分，中国汽车工业的迅猛发展，为汽车配件行业提供了坚实的产业基础和有力的市场支撑，并将形成1.5-2万亿元超大规模的市场产值。 作为汽车市场的焦点，广州拥有国内最大的汽车生产基地和汽车产业集群，连续三年汽车消费增速全国前列。2017年是“十三五”规划实施的重要一年，是供给侧结构性改革的深化之年，中国汽车工业已步入由大到强的发展之路，行业资源分配日益优化、产业布局日趋合理的态势已初现端倪，产业发展正逐步由产销量的提升演变为质量的飞跃。尤其在夯实产业根基、促使健康发展原则指导下，汽车配件产业，已被提升为汽车产业链条中首要的发展对象，资源倾斜、政策扶持、整顿规范，可以预计，继我国整车生产及消费在过去十年取得蓬勃发展成就之后，未来五到十年，将是我国汽车配件行业产生根本性变革的黄金时期。 得益于中国汽车产业高速发展和全球汽车零部件产业链积极向中国转移，映德会展、中汽展览联合行业权威机构定于2017年10月13-15日在广州琶洲国际采购中心举办“2017广州国际进出口汽车配件展览会”（APF 2017）。依托汽车产业和全球最大的潜在市场资源，根据汽车配件产业发展现状和中外市场需求，在继承和延伸往届展会成功经验的基础上，在各级政府部门、行业协会的关心与支持下、经过主承办单位的精心组织策划，“APF 2017”将以全新的面貌再现广州，展会将全面展示汽车领域的最新产品与成果及未来发展方向，将有超过百家合作媒体的超大阵容作全方位的立体宣传。APF 全国统一参展报名热线：4000-580-850（转5206、8144）。 我们将继续以“突出品牌、开拓创新、注重实效、强化服务”的办展宗旨，凭借独特的创意，科学的组织管理和卓越的服务，以全新的理念为广大中外参展商提供一个“专业化、国际化、品牌化”的展示交流平台，为全球汽车配件及后市场行业提供更多的合作机会，有力推动中国汽车配件产品全面进入全球采购体系，与世界各国汽车产业协调合作、互利共赢、共同发展进步。 【 展 会 优 势 】 ●绝佳商机 —— APF 2017举办时间正值“广交会”期间，享有“中国第一展”美誉的“广交会”，每年参加的采购商大约20多万，来自一百多个国家和地区。我们将通过一系列途径充分借助“广交会”全球买家的巨大资源，并通过组委会客户关系邀请系统向国内外三十多万采购商发出邀请，与“广交会”完全互动，借势兴展，同时弥补“广交会”内销的不足，形成“一内一外、相辅相成”的作用。以“广交会”庞大的客流量为依托，中外采购商云集，市场潜力不可估量，巨大商机全面彰显，是开拓国际市场的重要平台！ ● 黄金地段 —— 广州琶洲国际采购中心与广交会展馆一路之隔，连为一体，形成完美对接，连接广交会同类产品展区，距离地铁八号线琶洲站A出口仅200米之遥，交通非常便利，方便海外客商前来参观、采购。 ● 参展回报 —— 与每个国内外采购决策者面对面交流，和意向客户达成交易，在专业客户中扩大品牌影响力；建立海外分销网络，拓展国际市场；新产品、新技术推广；开拓新市场；了解竞争对手及行业发展趋势；洞悉国际最新技术与资讯；约见老客户并发展新业务。 【 目 标 观 众 】 中国（广州）国际汽车零部件及用品展览会组委会（映德会展―YOND EXPO）将专业观众组织和媒体宣传作为工作重点，邀请中外汽车制造商、改装厂、改装行、改装店，汽车工业设备制造商、汽车零配件用品制造商、贸易商、代理商、经销商、终端用户，汽车配件用品市场、超市、连锁加盟店、4S店，汽车保养及美容中心、汽车维修中心、汽车修理厂，汽车综合性能检测站、汽车后市场经销商，汽车后市场连锁经营领域专家、学者、投资公司及国内外有志于汽车后市场投资创业人士、汽车服务行业、汽车爱好者、车友会、俱乐部、商务机构、汽车维修检测行业相关部门、汽车交通运输部门、政府主管部门、汽车行业协会、专业媒体等主要单位及负责人参会。采取卓有实效的措施为参展企业搭建交流与合作的平台，促进科技成果转化，提高企业市场竞争力；同时通过系列紧密有序的宣传活动，确保展会在国内外引起最大关注。 16万国内外专业买家云集羊城 —— 一、 国内专业买家 1、300家整车厂和汽车销售公司 - 本田（广州，东风），丰田（一汽，广汽），大众（一汽，上海），北京现代，上海通用，东风日产，长安福特，比亚迪，奇瑞等35家主流整车企业和60家汽车销售公司，汽车用品公司的采购负责人现场参观采购。 2、8000家4S店集团及全国4S店 - 新疆广汇，冀东庞大，上海永达，浙江物产元通，广物汽贸，东创建国，大连中升，湖南申湘，深圳深业，中汽西南，安徽亚夏，郑州豫华等300家4S店集团和中国各品牌4000家4S店采购负责人参展采购。 3、1500家全国一级批发物流商 - 欧特隆（辽宁，杭州，南京，山西），沈阳新天成，郑州二仟家，山西茂德隆，长沙湘泸，福建永联，成都穗丰，广州永丰，新疆半分利，北京派安，石家庄中惠等1200家一级批发物流参展采购。 4、7000家全国各地市代理经销商 5、2500家全国优质影音改装专业店 - 以新城子昂，上海车之宝，北京双周，音乐前线，先歌兄弟， 非常城市等为代表的全国各区域优质影音改装店参展采购。 6、300家大型零售终端连锁 - 以新奇特，黄帽子，上海美车饰等为代表的全国各区域优质零售终端及大型连锁参展采购。。 7、9家国内终端零售店（含南方/泛珠三角地区终端店3家） - 以金手指，车元素等为代表的福建，江西，湖南，广东，广西，海南，四川，贵州，云南，香港，澳门等泛珠三角地区零售终端现场采购。以及2万家全国优秀零售终端。 二、 国外专业买家 1、4000亚洲买家： - 包括日本、韩国、印度尼西亚、马来西亚、印度、泰国、菲律宾、越南、新加坡等国行业商会组团采购参观。 2、1500中东买家： - 包括阿联酋、沙特阿拉伯、伊朗、叙利亚、以色列、科威特、卡塔尔、也门等国采购商组团参观采购。 3、2500欧美买家： - 包括德国、英国、法国、美国、墨西哥、加拿大等国采购商采购参观。 【 展 品 范 围 】 汽车零部件、零配件，发动机系统、底盘系统、制动系统、行驶系统、转向系统、车身系统、传动系统、排气系统、散热冷却系统、燃油系统，汽车附件、通用件、紧固件、密封件、摩擦材料，汽车电机、轴承、蓄电池、滤清器、散热器、消声器、传感器、仪器仪表、雨刷器、变速器、离合器、离合片、刹车片、汽车弹簧、减震器、保险杠、安全气囊、座椅、玻璃、车镜、车灯、汽车空调、轮胎、轮毂、链条、防滑链，汽车线束、插接器、硬管、软管、软轴、拉索，车用纺织品，汽车油漆、润滑油、机油、添加剂，汽车用品，汽车电子电器，汽车音影、音响、导航、车载通讯、安全和防盗系统，汽车改装部件及用品，汽保设备及工具，汽车模具，汽车零部件制造技术、设备、工具及材料，汽车零部件清洗设备及包装，汽车新产品，汽车节能环保与新能源技术及产品，相关软件、媒体、认证、金融和保险机构等。 【 参 展 细 则 】 ◆ 展位规格： 1、特装展位：36平方米起租，仅提供相应面积室内外空地。展台搭建、展览器具、用电用水等自理。 2、标准展位：9平方米（3m×3m）每个，2.5m高壁板、一条楣板（展商名称）、一张洽谈桌、两把椅子、两盏射灯、220V/5A电源插座一处。 ◆ 展位费用： 特装展位：境内企业RMB2000/平方米； 境外企业USD500/平方米； 标准展位：境内企业RMB2/个； 境外企业USD5000/个； （双面开口标准展位另加收10%费用） ◆ 会刊广告： （大会《会刊》将帮助您在展会后找到客户！除在展会期间广为发送外，还通过各种有关渠道发送给未能前来参观展会的各地专业人士手中，他们可利用会刊迅速查找服务内容与联络方法。 会刊尺寸：130mm*210mm，进口铜板纸彩色精印，发行量10万册。） 封面 CNY 3； 封二封三 CNY 22000； 扉页 CNY 18000； 黑白页 CNY 5000； 封底 CNY 2； 彩页跨版 CNY 18000； 彩页 CNY 12000； 300字简介 CNY 2000； ◆ 会议论坛： 如技术交流会/产品推广发布会，CNY9000/小时/场，用于会场及相关设备租金（包括场地、扩音设施、灯具、投影机、投影仪，桌椅、空调、茶水并协助主讲企业组织听众）。 【 参 展 程 序 】 1、大会即日起开始接受厂商报名，组委会（映德会展―YOND EXPO）严格按“款到先后顺序优先安排展位”，先期报名参展企业除“在统一参展费用的基础上获得较靠前展台位置”的同时，并可享受更多“展前宣传”和“买家推介”等增值服务。 2、参展单位请详细填写《参展申请表》（备索）并加盖公章，传真或复印后寄送至大会组织办公室（映德会展―YOND EXPO），并于三个工作日内向大会指定账户汇出参展费用。 3、参展单位请于报名时将300字内企业简介同时提供至大会组织办公室，以便进行及时展前宣传和刊登《会刊》等。 4、展品运输、仓储、吊装，展商报道、接待、食宿等后勤服务，详见会前《参展商手册》，约在大会开幕前一个半月发送。 5、需用动力电、气或用水、特装展台装修等事宜，请于大会开幕前一月将有关资料提供给大会组委会，以便会务组协助参展企业做好相应安排。 6、组委会拒绝与参展范围不符的厂商参展。报名截止日期：2017年08月31日。 【 筹 展 联 络 】 广州国际进出口汽车配件展组委会 官方网站： http://www.CAPE-china.com 全国统一
Re: pull-request: wireless-drivers-next 2017-07-28
From: Kalle Valo Date: Fri, 28 Jul 2017 14:05:59 + > Kalle Valo writes: > >> Hi Dave, >> >> here's a pull request for net, more info the signed tag below. Please >> let me know if there are any problems. >> >> Kalle >> >> The following changes since commit d755cbc26e8295ae8e5d30425364e093b4247a85: >> >> Merge tag 'iwlwifi-for-kalle-2017-07-21' of >> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes >> (2017-07-21 14:33:27 +0300) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git >> tags/wireless-drivers-for-davem-2017-07-28 > > Argh, the subject is of course wrong and it should be: > > pull-request: wireless-drivers 2017-07-28 Yeah that makes more sense. :) > So this pull request is for net tree to get these two brcmfmac fixes to > 4.13. Otherwise the pull request is correct so I don't submit a new one > (but let me know if you prefer that). Pulled, thanks Kalle.
Re: wake_wide mechanism clarification
Hi Mike, On Sat, Jul 29, 2017 at 1:19 PM, Joel Fernandes wrote: > >>> To explain the second condition above, Michael Wang said the following in >>> [1] >>> >>> "Furthermore, if waker also has a high 'nr_wakee_switch', imply that >>> multiple >>> tasks rely on it, then waker's higher latency will damage all of them, pull >>> wakee seems to be a bad deal." >> >> Yes, "Furthermore". To detect 1:N, Michael chose llc_size as his N. Is >> the one flipping partners at least N/s, and the other about N times as >> often? If so, the two may be part of a too big to wisely pull 1:N. >> >> If you have a better idea, by all means, pull it out. Nobody is > > Sure yeah, first I'm trying to understand the heuristic itself which > I'm glad to be making progress with thanks to yours and others' help! > >> attached to wake_wide(), in fact, I suspect Peter hates it. I'm not >> fond of it either, it having obvious holes. The only thing it has >> going for it is simplicity. Bend it up, replace it, fire away. >> > > Ok, it makes much more sense to me now. Also for the N:N case, > wouldn't the excessive wake-affine increase the latency and a > spreading might be better? Say if slave and master flips are much > greater than factor (llc_size), then slave > factor && master < slave > * factor, would probably return true a lot (and we would return 0 > causing an affine wakeup). That's probably a bad thing right as it > could overload the waker's CPU quickly? I guess the heuristic tries to > maximize cache-hits more than reduce latency? > >>> Again I didn't follow why the second condition couldn't just be: >>> waker->nr_wakee_switch > factor, or, (waker->nr_wakee_switch + >>> wakee->nr_wakee_switch) > factor, based on the above explanation from >>> Micheal Wang that I quoted. >>> and why he's instead doing the whole multiplication thing there that I >>> was talking about earlier: "factor * wakee->nr_wakee_switch". >>> >>> Rephrasing my question in another way, why are we talking the ratio of >>> master/slave instead of the sum when comparing if its > factor? I am >>> surely missing something here. >> >> Because the heuristic tries to not demolish 1:1 buddies. Big partner >> flip delta means the pair are unlikely to be a communicating pair, >> perhaps at high frequency where misses hurt like hell. > > But it does seem to me to demolish the N:N communicating pairs from a > latency/load balancing standpoint. For he case of N readers and N > writers, the ratio (master/slave) comes down to 1:1 and we wake > affine. Hopefully I didn't miss something too obvious about that. I think wake_affine() should correctly handle the case (of overloading) I bring up here where wake_wide() is too conservative and does affine a lot, (I don't have any data for this though, this just from code reading), so I take this comment back for this reason. thanks, -Joel
Re: [PATCH 2/2] mfd: ds1374: Add Dallas/Maxim DS1374 Multi Function Device
On 13/07/2017 at 12:54:25 -0700, Moritz Fischer wrote: > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > index 52a70ee..1703611 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -120,6 +120,16 @@ config DA9062_WATCHDOG > > This driver can be built as a module. The module name is da9062_wdt. > > +config DS1374_WATCHDOG > + tristate "Maxim/Dallas 1374 Watchdog" If you want to keep the backward compatibility, this probably needs to be defaulting to RTC_DRV_DS1374 when RTC_DRV_DS1374_WDT is selected. Also, maybe we need to make RTC_DRV_DS1374_WDT not user selectable. If you don't think backward compatibility can be achieved, then we can drop everything. Else, the RTC part seems fine to me but the driver may be cleaned up a bit further afterwards. > + depends on MFD_DS1374 > + depends on REGMAP_I2C > + select WATCHDOG_CORE > + help > + Support for the watchdog in the Maxim/Dallas DS1374 MFD. > + > + This driver can be built as a module. The module name is ds1374-wdt. > + > config GPIO_WATCHDOG > tristate "Watchdog device controlled through GPIO-line" > depends on OF_GPIO -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Re: [PATCH] net: tc35815: fix spelling mistake: "Intterrupt" -> "Interrupt"
From: Colin King Date: Thu, 27 Jul 2017 23:15:09 +0100 > From: Colin Ian King > > Trivial fix to spelling mistake in printk message > > Signed-off-by: Colin Ian King Applied.
Re: [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
On Sat, Jul 29, 2017 at 10:51:15AM +0200, Marcus Wolf wrote: > Hi Greg, > > already had a discussion concerning that patch with Dan yesterday. > I really don't know what's going on there. I detached the patch once more from > my outbox and had a very close look in an editor and looked at it with a > difftool. In my outbox the patch is fine. I really don't knwo why it reaches > you > crapped. > > Since there are contsant problems with my patches, I will stop sending patches > for a while. As soon as I can find time to deeply confess with the tooling, I > will start over with trying. Just use 'git send-email' for patches if you are having problems with your email client. And get a better email client the kernel Documentation has a whole file just about that topic and how to do it correctly. > Concerning this patch: You can use Arnds Patch from yesterday instead: > [PATCH] staging: pi433: use div_u64 for 64-bit division > It's a bit different to my patch, but according to yesterdays discussion, it > should also fix the problem. I already took it into my tree. thanks, greg k-h
Re: module: Remove const attribute from alias for MODULE_DEVICE_TABLE
+++ Matthias Kaehlcke [24/07/17 18:27 -0700]: MODULE_DEVICE_TABLE(type, name) creates an alias of type 'extern const typeof(name)'. If 'name' is already constant the 'const' attribute is specified twice, which is not allowed in C89 (see discussion at https://lkml.org/lkml/2017/5/23/1440). Since the kernel is built with -std=gnu89 clang generates warnings like this: drivers/thermal/x86_pkg_temp_thermal.c:509:1: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier] MODULE_DEVICE_TABLE(x86cpu, pkg_temp_thermal_ids); ^ ./include/linux/module.h:212:8: note: expanded from macro 'MODULE_DEVICE_TABLE' extern const typeof(name) __mod_##type##__##name##_device_table Remove the const attribute from the alias to avoid the duplicate specifier. After all it is only an alias and the attribute shouldn't have any effect. Signed-off-by: Matthias Kaehlcke Applied, thanks! Jessica include/linux/module.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/module.h b/include/linux/module.h index e7bdd549e527..fe5aa3736707 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -209,7 +209,7 @@ extern void cleanup_module(void); #ifdef MODULE /* Creates an alias so file2alias.c can find device table. */ #define MODULE_DEVICE_TABLE(type, name) \ -extern const typeof(name) __mod_##type##__##name##_device_table \ +extern typeof(name) __mod_##type##__##name##_device_table \ __attribute__ ((unused, alias(__stringify(name #else /* !MODULE */ #define MODULE_DEVICE_TABLE(type, name) -- 2.14.0.rc0.284.gd933b75aa4-goog
Re: [PATCH RFC 3/4] arch/sparc: Optimized memcpy, memset, copy_to_user, copy_from_user for M7
From: Babu Moger Date: Thu, 27 Jul 2017 15:57:29 -0600 > @@ -600,7 +600,7 @@ niagara_tlb_fixup: > be,pt %xcc, niagara4_patch >nop > cmp %g1, SUN4V_CHIP_SPARC_M7 > - be,pt %xcc, niagara4_patch > + be,pt %xcc, sparc_m7_patch >nop > cmp %g1, SUN4V_CHIP_SPARC_SN > be,pt %xcc, niagara4_patch This part will need to be respun now that the M8 patches are in as there will be a slight conflict in this hunk. > +.register %g2,#scratch > + > + .section".text" > + .global FUNC_NAME > + .type FUNC_NAME, #function > + .align 16 > +FUNC_NAME: > + srlx%o2, 31, %g2 > + cmp %g2, 0 > + tne %xcc, 5 > + PREAMBLE > + mov %o0, %g1! save %o0 > + brz,pn %o2, .Lsmallx > + > + cmp%o2, 3 > +ble,pn %icc, .Ltiny_cp > + cmp%o2, 19 > +ble,pn %icc, .Lsmall_cp > + or %o0, %o1, %g2 > +cmp %o2, SMALL_MAX > +bl,pn %icc, .Lmedium_cp > + nop What in world is going on with this indentation? I can't comprehend how, if anyone actually put their eyes on this code and the patch itself, wouldn't notice this. DO NOT mix all-spaced and TAB+space indentation. Always, consistently, use as many TABs as you can and then when needed add trailing spaces. > +.Lsrc_dst_aligned_on_8: > + ! check if we are copying MED_MAX or more bytes > +set MED_MAX, %o3 > +cmp %o2, %o3 ! limit to store buffer size > + bgu,pn %ncc, .Llarge_align8_copy > + nop Again, same problem here. > +/* > + * Handle all cases where src and dest are aligned on word > + * boundaries. Use unrolled loops for better performance. > + * This option wins over standard large data move when > + * source and destination is in cache for.Lmedium > + * to short data moves. > + */ > +set MED_WMAX, %o3 > +cmp %o2, %o3 ! limit to store buffer size > + bge,pt %ncc, .Lunalignrejoin ! otherwise rejoin main loop > + nop More weird indentation. > +.dbalign: > +andcc %o5, 7, %o3 ! is sp1 aligned on a 8 byte bound? > +bz,pt %ncc, .blkalign ! already long word aligned > + sub %o3, 8, %o3 ! -(bytes till long word aligned) > + > +add %o2, %o3, %o2 ! update o2 with new count > +! Set -(%o3) bytes till sp1 long word aligned > +1: stb %o1, [%o5] ! there is at least 1 byte to set > + inccc %o3 ! byte clearing loop > +bl,pt %ncc, 1b > + inc %o5 More weird indentation. > +! Now sp1 is block aligned > +.blkwr: > +andn%o2, 63, %o4! calculate size of blocks in bytes > +brz,pn %o1, .wrzero! special case if c == 0 > + and %o2, 63, %o3! %o3 = bytes left after blk stores. > + > +set MIN_LOOP, %g1 > +cmp %o4, %g1! check there are enough bytes to set > + blu,pn %ncc, .short_set! to justify cost of membar > +! must be > pre-cleared lines > + nop Likewise. > + > +! initial cache-clearing stores > +! get store pipeline moving > + rd %asi, %g3 ! save %asi to be restored later > +wr %g0, ASI_STBIMRU_P, %asi Likewise. > +.wrzero_small: > +stxa%o1, [%o5]ASI_STBI_P > +subcc %o4, 64, %o4 > +bgu,pt %ncc, .wrzero_small > + add %o5, 64, %o5 > + ba,a.bsi_done Likewise. > +.asi_done: > + wr %g3, 0x0, %asi ! restored saved %asi > +.bsi_done: > +membar #StoreStore ! required by use of Block Store Init Likewise. > + .size M7memset,.-M7memset It's usually a lot better to use ENTRY() and ENDPROC() instead of expanding these kinds of directives out. > + .globl m7_patch_copyops > + .type m7_patch_copyops,#function > +m7_patch_copyops: ENTRY() > + .size m7_patch_copyops,.-m7_patch_copyops ENDPROC() > + .globl m7_patch_bzero > + .type m7_patch_bzero,#function > +m7_patch_bzero: Likewise. > + .size m7_patch_bzero,.-m7_patch_bzero Likewise. > + .globl m7_patch_pageops > + .type m7_patch_pageops,#function > +m7_patch_pageops: Likewise. > + .size m7_patch_pageops,.-m7_patch_pageops Likewise.
Re: [PATCH BUGFIX] block, bfq: consider also in_service_entity to state whether an entity is active
On 07/29/2017 04:42 AM, Paolo Valente wrote: > Groups of BFQ queues are represented by generic entities in BFQ. When > a queue belonging to a parent entity is deactivated, the parent entity > may need to be deactivated too, in case the deactivated queue was the > only active queue for the parent entity. This deactivation may need to > be propagated upwards if the entity belongs, in its turn, to a further > higher-level entity, and so on. In particular, the upward propagation > of deactivation stops at the first parent entity that remains active > even if one of its child entities has been deactivated. > > To decide whether the last non-deactivation condition holds for a > parent entity, BFQ checks whether the field next_in_service is still > not NULL for the parent entity, after the deactivation of one of its > child entity. If it is not NULL, then there are certainly other active > entities in the parent entity, and deactivations can stop. > > Unfortunately, this check misses a corner case: if in_service_entity > is not NULL, then next_in_service may happen to be NULL, although the > parent entity is evidently active. This happens if: 1) the entity > pointed by in_service_entity is the only active entity in the parent > entity, and 2) according to the definition of next_in_service, the > in_service_entity cannot be considered as next_in_service. See the > comments on the definition of next_in_service for details on this > second point. > > Hitting the above corner case causes crashes. > > To address this issue, this commit: > 1) Extends the above check on only next_in_service to controlling both > next_in_service and in_service_entity (if any of them is not NULL, > then no further deactivation is performed) > 2) Improves the (important) comments on how next_in_service is defined > and updated; in particular it fixes a few rather obscure paragraphs Applied, thanks. -- Jens Axboe
Re: [PATCH BUGFIX] block, bfq: reset in_service_entity if it becomes idle
On 07/28/2017 01:41 PM, Paolo Valente wrote: > BFQ implements hierarchical scheduling by representing each group of > queues with a generic parent entity. For each parent entity, BFQ > maintains an in_service_entity pointer: if one of the child entities > happens to be in service, in_service_entity points to it. The > resetting of these pointers happens only on queue expirations: when > the in-service queue is expired, i.e., stops to be the queue in > service, BFQ resets all in_service_entity pointers along the > parent-entity path from this queue to the root entity. > > Functions handling the scheduling of entities assume, naturally, that > in-service entities are active, i.e., have pending I/O requests (or, > as a special case, even if they have no pending requests, they are > expected to receive a new request very soon, with the scheduler idling > the storage device while waiting for such an event). Unfortunately, > the above resetting scheme of the in_service_entity pointers may cause > this assumption to be violated. For example, the in-service queue may > happen to remain without requests because of a request merge. In this > case the queue does become idle, and all related data structures are > updated accordingly. But in_service_entity still points to the queue > in the parent entity. This inconsistency may even propagate to > higher-level parent entities, if they happen to become idle as well, > as a consequence of the leaf queue becoming idle. For this queue and > parent entities, scheduling functions have an undefined behaviour, > and, as reported, may easily lead to kernel crashes or hangs. > > This commit addresses this issue by simply resetting the > in_service_entity field also when it is detected to point to an entity > becoming idle (regardless of why the entity becomes idle). Applied, thanks. -- Jens Axboe
Re: [resend PATCH v2 11/33] dm: add dax_device and dax_operations support
On Sat, 2017-07-29 at 12:57 -0700, Dan Williams wrote: > On Fri, Jul 28, 2017 at 9:17 AM, Bart Van Assche > wrote: > > On Mon, 2017-04-17 at 12:09 -0700, Dan Williams wrote: > > > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig > > > index b7767da50c26..1de8372d9459 100644 > > > --- a/drivers/md/Kconfig > > > +++ b/drivers/md/Kconfig > > > @@ -200,6 +200,7 @@ config BLK_DEV_DM_BUILTIN > > > config BLK_DEV_DM > > > tristate "Device mapper support" > > > select BLK_DEV_DM_BUILTIN > > > + select DAX > > > ---help--- > > > Device-mapper is a low level volume manager. It works by allowing > > > people to specify mappings for ranges of logical sectors. Various > > > > (replying to an e-mail of three months ago) > > > > Hello Dan, > > > > While building a v4.12 kernel I noticed that enabling device mapper support > > now unconditionally enables DAX. I think there are plenty of systems that > > use > > dm but do not need DAX. Have you considered to rework this such that instead > > of dm selecting DAX that DAX support is only enabled in dm if CONFIG_DAX is > > enabled? > > I'd rather flip this around and add a CONFIG_DM_DAX that gates whether > DM enables / links to the DAX core. I'll take a look at a patch. Thanks! Please also consider to move all DAX-related dm code into a separate source file such that the number of #ifdef CONFIG_DM_DAX statements can be kept to an absolute minimum. Bart.
Re: [PATCH 1/1] netfilter: constify nf_conntrack_l3/4proto parameters
Julia Lawall wrote: > > I think we can indeed constify these completely after making > > 'nla_size' set at compile time. > > > > I'll send a simple attempt to make it so for l3proto soon. > > There is another issue with respect to nf_ct_l3proto_unregister. This > calls nf_ct_iterate_destroy with l3proto as the second argument. This > function has signature: > > void > nf_ct_iterate_destroy(int (*iter)(struct nf_conn *i, void *data), void *data) > > The void * is not const. Maybe it could be. Haven't looked if we can constify it in general, but, as the argument is not going to be written to in this particular case it will not be a showstopper.
Re: [PATCH] net: thunderx: Fix BGX transmit stall due to underflow
From: sunil.kovv...@gmail.com Date: Thu, 27 Jul 2017 12:53:04 +0530 > From: Sunil Goutham > > For SGMII/RGMII/QSGMII interfaces when physical link goes down > while traffic is high is resulting in underflow condition being set > on that specific BGX's LMAC. Which assets a backpresure and VNIC stops > transmitting packets. > > This is due to BGX being disabled in link status change callback while > packet is in transit. This patch fixes this issue by not disabling BGX > but instead just disables packet Rx and Tx. > > Signed-off-by: Sunil Goutham Applied.
[PATCH] staging: sm750fb: avoid conflicting vesafb
From: Teddy Wang
commit 740c433ec35187b45abe08bb6c45a321a791be8e upstream
If vesafb is enabled in the config then /dev/fb0 is created by vesa
and this sm750 driver gets fb1, fb2. But we need to be fb0 and fb1 to
effectively work with xorg.
So if it has been alloted fb1, then try to remove the other fb0.
In the previous send, why #ifdef is used was asked.
https://lkml.org/lkml/2017/6/25/57
Answered at: https://lkml.org/lkml/2017/6/25/69
Also pasting here for reference.
'Did a quick research into "why".
The patch d8801e4df91e ("x86/PCI: Set IORESOURCE_ROM_SHADOW only for the
default VGA device") has started setting IORESOURCE_ROM_SHADOW in flags
for a default VGA device and that is being done only for x86.
And so, we will need that #ifdef to check IORESOURCE_ROM_SHADOW as that
needs to be checked only for a x86 and not for other arch.'
Cc: # v4.4
Signed-off-by: Teddy Wang
Signed-off-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/sm750fb/sm750.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 860e1c2..2a89dc2 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -1002,6 +1002,26 @@ NO_PARAM:
}
}
+static int lynxfb_kick_out_firmware_fb(struct pci_dev *pdev)
+{
+ struct apertures_struct *ap;
+ bool primary = false;
+
+ ap = alloc_apertures(1);
+ if (!ap)
+ return -ENOMEM;
+
+ ap->ranges[0].base = pci_resource_start(pdev, 0);
+ ap->ranges[0].size = pci_resource_len(pdev, 0);
+#ifdef CONFIG_X86
+ primary = pdev->resource[PCI_ROM_RESOURCE].flags &
+ IORESOURCE_ROM_SHADOW;
+#endif
+ remove_conflicting_framebuffers(ap, "sm750_fb1", primary);
+ kfree(ap);
+ return 0;
+}
+
static int lynxfb_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -1009,6 +1029,10 @@ static int lynxfb_pci_probe(struct pci_dev *pdev,
struct sm750_dev *sm750_dev = NULL;
int fbidx;
+ err = lynxfb_kick_out_firmware_fb(pdev);
+ if (err)
+ return err;
+
/* enable device */
if (pci_enable_device(pdev)) {
pr_err("can not enable device.\n");
--
1.9.1
Re: blk-mq breaks suspend even with runtime PM patch
Recompiled kernel with lockdep enabled gives me this:
===
[ 368.655051] Showing all locks held in the system:
[ 368.656387] 1 lock held by khungtaskd/37:
[ 368.657171] #0: (tasklist_lock){.+.+..}, at: []
debug_show_all_locks+0x3d/0x1a0
[ 368.658725] 1 lock held by md0_raid10/458:
[ 368.659455] #0: (&mddev->reconfig_mutex){+.+.+.}, at:
[] md_check_recovery+0xaf/0x4d0 [md_mod]
[ 368.661403] 3 locks held by btrfs-transacti/550:
[ 368.662754] #0: (&fs_info->transaction_kthread_mutex){+.+...}, at:
[] transaction_kthread+0x69/0x1c0 [btrfs]
[ 368.664797] #1: (&fs_info->reloc_mutex){+.+...}, at: []
btrfs_commit_transaction+0x2e1/0x9b0 [btrfs]
[ 368.69] #2: (&fs_info->tree_log_mutex){+.+...}, at:
[] btrfs_commit_transaction+0x351/0x9b0 [btrfs]
[ 368.668644] 4 locks held by kworker/0:2/888:
[ 368.669384] #0: ("events"){.+.+.+}, at: []
process_one_work+0x1fb/0x6e0
[ 368.670916] #1: ((shepherd).work){+.+...}, at: []
process_one_work+0x1fb/0x6e0
[ 368.672592] #2: (cpu_hotplug.dep_map){++}, at: []
get_online_cpus.part.14+0x5/0x50
[ 368.674742] #3: (cpu_hotplug.lock){+.+.+.}, at: []
get_online_cpus.part.14+0x3a/0x50
[ 368.677494] 10 locks held by systemd-sleep/889:
[ 368.678650] #0: (sb_writers#5){.+.+.+}, at: []
vfs_write+0x17b/0x1a0
[ 368.680483] #1: (&of->mutex){+.+.+.}, at: []
kernfs_fop_write+0x123/0x1e0
[ 368.682412] #2: (s_active#257){.+.+.+}, at: []
kernfs_fop_write+0x12c/0x1e0
[ 368.684440] #3: (autosleep_lock){+.+.+.}, at: []
pm_autosleep_lock+0x17/0x20
[ 368.686707] #4: (pm_mutex){+.+.+.}, at: [] pm_suspend
+0x88/0x490
[ 368.688086] #5: (acpi_scan_lock){+.+.+.}, at: []
acpi_scan_lock_acquire+0x17/0x20
[ 368.690213] #6: (cpu_add_remove_lock){+.+.+.}, at: []
freeze_secondary_cpus+0x30/0x3c0
[ 368.692016] #7: (cpu_hotplug.dep_map){++}, at: []
cpu_hotplug_begin+0x5/0xe0
[ 368.694347] #8: (cpu_hotplug.lock){+.+.+.}, at: []
cpu_hotplug_begin+0x83/0xe0
[ 368.696010] #9: (all_q_mutex){+.+...}, at: []
blk_mq_queue_reinit_work+0x1a/0x110
[ 368.698624]
[ 368.698990] =
[ 368.698990]
===
Deadlock with CPU hotplug?
On sobota 29. července 2017 17:27:41 CEST Oleksandr Natalenko wrote:
> Hello Jens, Christoph.
>
> Unfortunately, even with "block: disable runtime-pm for blk-mq" patch
> applied blk-mq breaks suspend to RAM for me. It is reproducible on my
> laptop as well as in a VM.
>
> I use complex disk layout involving MD, LUKS and LVM, and managed to get
> these warnings from VM via serial console when suspend fails:
>
> ===
> [ 245.516573] INFO: task kworker/0:1:49 blocked for more than 120 seconds.
> [ 245.520025] Not tainted 4.12.0-pf4 #1
> [ 245.521836] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 245.525612] kworker/0:1 D049 2 0x
> [ 245.527515] Workqueue: events vmstat_shepherd
> [ 245.528685] Call Trace:
> [ 245.529296] __schedule+0x459/0xe40
> [ 245.530115] ? kvm_clock_read+0x25/0x40
> [ 245.531003] ? ktime_get+0x40/0xa0
> [ 245.531819] schedule+0x3d/0xb0
> [ 245.532542] ? schedule+0x3d/0xb0
> [ 245.533299] schedule_preempt_disabled+0x15/0x20
> [ 245.534367] __mutex_lock.isra.5+0x295/0x530
> [ 245.535351] __mutex_lock_slowpath+0x13/0x20
> [ 245.536362] ? __mutex_lock_slowpath+0x13/0x20
> [ 245.537334] mutex_lock+0x25/0x30
> [ 245.538118] get_online_cpus.part.14+0x15/0x30
> [ 245.539588] get_online_cpus+0x20/0x30
> [ 245.540560] vmstat_shepherd+0x21/0xc0
> [ 245.541538] process_one_work+0x1de/0x430
> [ 245.542364] worker_thread+0x47/0x3f0
> [ 245.543042] kthread+0x125/0x140
> [ 245.543649] ? process_one_work+0x430/0x430
> [ 245.544417] ? kthread_create_on_node+0x70/0x70
> [ 245.545737] ret_from_fork+0x25/0x30
> [ 245.546490] INFO: task md0_raid10:459 blocked for more than 120 seconds.
> [ 245.547668] Not tainted 4.12.0-pf4 #1
> [ 245.548769] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
> this message.
> [ 245.550133] md0_raid10 D0 459 2 0x
> [ 245.551092] Call Trace:
> [ 245.551539] __schedule+0x459/0xe40
> [ 245.552163] schedule+0x3d/0xb0
> [ 245.552728] ? schedule+0x3d/0xb0
> [ 245.553344] md_super_wait+0x6e/0xa0 [md_mod]
> [ 245.554118] ? wake_bit_function+0x60/0x60
> [ 245.554854] md_update_sb.part.60+0x3df/0x840 [md_mod]
> [ 245.555771] md_check_recovery+0x215/0x4b0 [md_mod]
> [ 245.556732] raid10d+0x62/0x13c0 [raid10]
> [ 245.557456] ? schedule+0x3d/0xb0
> [ 245.558169] ? schedule+0x3d/0xb0
> [ 245.558803] ? schedule_timeout+0x21f/0x330
> [ 245.559593] md_thread+0x120/0x160 [md_mod]
> [ 245.560380] ? md_thread+0x120/0x160 [md_mod]
> [ 245.561202] ? wake_bit_function+0x60/0x60
> [ 245.561975] kthread+0x125/0x140
> [ 245.562601] ? find_pers+0x70/0x70 [md_mod]
> [ 245.563394] ? kthread_create_on_node+0x70/0x70
> [ 245.564516] ret_from_fork+0x25/0x30
> [ 245.565669] INFO: task
Re: [PATCH V2 net] Revert "vhost: cache used event for better performance"
From: Jason Wang Date: Thu, 27 Jul 2017 11:22:05 +0800 > This reverts commit 809ecb9bca6a9424ccd392d67e368160f8b76c92. Since it > was reported to break vhost_net. We want to cache used event and use > it to check for notification. The assumption was that guest won't move > the event idx back, but this could happen in fact when 16 bit index > wraps around after 64K entries. > > Signed-off-by: Jason Wang Applied, thanks.
Re: [PATCH v1 2/2] arm64: dts: rockchip: add rk3328 spdif node
Am Donnerstag, 27. Juli 2017, 16:16:04 CEST schrieb Sugar Zhang:
> This patch add the spdif dt node for rk3328.
>
> Signed-off-by: Sugar Zhang
>
> ---
>
> arch/arm64/boot/dts/rockchip/rk3328.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index f1a284b..d278670 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -189,6 +189,19 @@
> status = "disabled";
> };
>
I've adapted the patch so that it can exist without the previous one
and applied it for 4.14.
Thanks
Heiko
> + spdif: spdif@ff03 {
> + compatible = "rockchip,rk3328-spdif";
> + reg = <0x0 0xff03 0x0 0x1000>;
> + interrupts = ;
> + clocks = <&cru SCLK_SPDIF>, <&cru HCLK_SPDIF_8CH>;
> + clock-names = "mclk", "hclk";
> + dmas = <&dmac 10>;
> + dma-names = "tx";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spdifm2_tx>;
> + status = "disabled";
> + };
> +
> grf: syscon@ff10 {
> compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
> reg = <0x0 0xff10 0x0 0x1000>;
>
Re: [PATCH] ti-msgmgr: fix of_irq_get_byname() error check
On 07/30/2017 12:04 AM, Sergei Shtylyov wrote:
of_irq_get_byname() may return 0 as well as negative error number on
failure, while the driver only checks for the negative values. The driver
would then call request_irq(0, ...) in ti_msgmgr_queue_startup() and never
get a valid channel interrupt.
Check for 'qinst->irq <= 0' instead and return -ENXIO from
ti_msgmgr_queue_setup() and this fail the driver's probe iff
s/this/thus/, sorry for the typo.
of_irq_get_byname() returned 0.
Fixes: aace66b170ce ("mailbox: Introduce TI message manager driver")
Signed-off-by: Sergei Shtylyov
[...]
MBR, Sergei
Re: [PATCH v1 1/2] arm64: dts: rockchip: add rk3328 i2s nodes
Am Donnerstag, 27. Juli 2017, 16:16:03 CEST schrieb Sugar Zhang:
> This patch add the i2s dt nodes for rk3328.
>
> Signed-off-by: Sugar Zhang
> ---
>
> arch/arm64/boot/dts/rockchip/rk3328.dtsi | 33
>
> 1 file changed, 33 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index 0be96ce..f1a284b 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -156,6 +156,39 @@
> clock-output-names = "xin24m";
> };
>
> + i2s0: i2s@ff00 {
> + compatible = "rockchip,rk3328-i2s", "rockchip,rk3066-i2s";
It looks like the rockchip,rk3328-i2s compatible is missing in the binding
documentation (Documentation/devicetree/bindings/sound/rockchip-i2s.txt)
Send a patch adding it first please.
Heiko
Re: [PATCH] ti-msgmgr: fix of_irq_get_byname() error check
Forgot to mention that the patch is against the Linus' repo.
Re: [PATCH] arm64: dts: rockchip: add rk3368 spdif node
Am Donnerstag, 27. Juli 2017, 15:46:38 CEST schrieb Sugar Zhang: > This patch add the spdif dt node for rk3368 soc. > > Signed-off-by: Sugar Zhang applied for 4.14 after replacing the pin number (23) with its constand equivalent RK_PC7. Heiko
[PATCH] ti-msgmgr: fix of_irq_get_byname() error check
of_irq_get_byname() may return 0 as well as negative error number on
failure, while the driver only checks for the negative values. The driver
would then call request_irq(0, ...) in ti_msgmgr_queue_startup() and never
get a valid channel interrupt.
Check for 'qinst->irq <= 0' instead and return -ENXIO from
ti_msgmgr_queue_setup() and this fail the driver's probe iff
of_irq_get_byname() returned 0.
Fixes: aace66b170ce ("mailbox: Introduce TI message manager driver")
Signed-off-by: Sergei Shtylyov
---
drivers/mailbox/ti-msgmgr.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux/drivers/mailbox/ti-msgmgr.c
===
--- linux.orig/drivers/mailbox/ti-msgmgr.c
+++ linux/drivers/mailbox/ti-msgmgr.c
@@ -444,12 +444,12 @@ static int ti_msgmgr_queue_setup(int idx
"rx_%03d", qinst->queue_id);
qinst->irq = of_irq_get_byname(np, of_rx_irq_name);
- if (qinst->irq < 0) {
+ if (qinst->irq <= 0) {
dev_crit(dev,
"[%d]QID %d PID %d:No IRQ[%s]: %d\n",
idx, qinst->queue_id, qinst->proxy_id,
of_rx_irq_name, qinst->irq);
- return qinst->irq;
+ return qinst->irq ?: -ENXIO;
}
/* Allocate usage buffer for rx */
qinst->rx_buff = devm_kzalloc(dev,
Re: [PATCH 0/6] net: moxa: Fix style issues
From: SZ Lin Date: Sat, 29 Jul 2017 18:42:33 +0800 > This patch set fixs the WARNINGs found by the checkpatch.pl tool Series applied, thanks.
Re: [PATCH] dmaengine: rcar-dmac: avoid array overflow
Hi Arnd,
Thank you for the patch.
On Friday 28 Jul 2017 15:15:49 Arnd Bergmann wrote:
> Building with CONFIG_UBSAN_SANITIZE_ALL shows this warning:
>
> drivers/dma/sh/rcar-dmac.c: In function 'rcar_dmac_chan_prep_sg':
> drivers/dma/sh/rcar-dmac.c:839:29: error: array subscript is above array
> bounds [-Werror=array-bounds] desc->chcr = chcr |
> chcr_ts[desc->xfer_shift];
>
> As the compiler doesn't know what the xfer_size is, it is impossible
> to rule out the array overflow here. As we know that xfer_size
> can only be within enum dma_slave_buswidth, this will not overflow
> for correct users, and adding a range check will handle the
> obscure case and shut up the warning.
>
> Fixes: 87244fe5abdf ("dmaengine: rcar-dmac: Add Renesas R-Car Gen2 DMA
> Controller (DMAC) driver") Signed-off-by: Arnd Bergmann
> ---
> drivers/dma/sh/rcar-dmac.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index ffcadca53243..f5b28eb4009e 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -836,7 +836,8 @@ static void rcar_dmac_chan_configure_desc(struct
> rcar_dmac_chan *chan, }
>
> desc->xfer_shift = ilog2(xfer_size);
> - desc->chcr = chcr | chcr_ts[desc->xfer_shift];
> + if (desc->xfer_shift < ARRAY_SIZE(chcr_ts))
> + desc->chcr = chcr | chcr_ts[desc->xfer_shift];
I think this counts as an invalid warning. As you stated in the commit
message, we know that xfer_shift is within a valid range of values. True, if
the DMA engine API changed to support larger transfer sizes without updating
the driver, we would have a problem. But your patch will silently leave desc-
>chcr unset in that case, which is not good either. We should instead track
back xfer_size to where it gets set (in rcar_dmac_device_config() if I'm not
mistaken, but I haven't checked in details whether other locations need to be
handled too), and return an error there, possibly with a debug or warning
message.
Assuming we want to guard against that problem (which could be argued), that's
in my opinion the right fix. And it won't get rid of the compiler warning I'm
afraid.
> }
>
> /*
--
Regards,
Laurent Pinchart
Re: [PATCH 1/1] netfilter: constify nf_conntrack_l3/4proto parameters
On Sat, 29 Jul 2017, Florian Westphal wrote: > Julia Lawall wrote: > > When a nf_conntrack_l3/4proto parameter is not on the left hand side > > of an assignment, its address is not taken, and it is not passed to a > > function that may modify its fields, then it can be declared as const. > > > > This change is useful from a documentation point of view, and can > > possibly facilitate making some nf_conntrack_l3/4proto structures const > > subsequently. > > > > Done with the help of Coccinelle. > > > > Some spacing adjusted to fit within 80 characters. > > Acked-by: Florian Westphal > > Thanks Julia. > > I think we can indeed constify these completely after making > 'nla_size' set at compile time. > > I'll send a simple attempt to make it so for l3proto soon. There is another issue with respect to nf_ct_l3proto_unregister. This calls nf_ct_iterate_destroy with l3proto as the second argument. This function has signature: void nf_ct_iterate_destroy(int (*iter)(struct nf_conn *i, void *data), void *data) The void * is not const. Maybe it could be. julia > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Re: wake_wide mechanism clarification
Hi Mike, On Sat, Jul 29, 2017 at 8:07 AM, Mike Galbraith wrote: > On Sat, 2017-07-29 at 01:01 -0700, Joel Fernandes wrote: >> Hi Mike, >> >> I have take spent some time understanding the email thread and >> previous discussions. Unfortunately the second condition we are >> checking for in the wake_wide still didn't make sense to me (mentioned >> below) :-( >> >> On Fri, Jun 30, 2017 at 10:02 AM, Mike Galbraith >> wrote: >> > On Fri, 2017-06-30 at 10:28 -0400, Josef Bacik wrote: >> >> On Thu, Jun 29, 2017 at 08:04:59PM -0700, Joel Fernandes wrote: >> >> >> >> > That makes sense that we multiply slave's flips by a factor because >> >> > its low, but I still didn't get why the factor is chosen to be >> >> > llc_size instead of something else for the multiplication with slave >> >> > (slave * factor). >> > >> >> Yeah I don't know why llc_size was chosen... >> > >> > The goal of wake wide was to approximate when pulling would be a futile >> > consolidation effort and counterproductive to scaling. 'course with >> > ever increasing socket size, any 1:N waker is ever more likely to run >> > out of CPU for its one and only self (slamming into scaling wall) >> > before it needing to turn its minions loose to conquer the world. >> >> Actually the original question was why do we have the second condition >> as "master < slave * factor", instead of "master < factor". that's >> what didn't make sense to me. Why don't we return 0 from wake_wide if >> master < factor ? >> >> Infact, as the factor is set to the llc_size, I think the condition >> that makes sense to me is: >> >> if ((master + slave) < llc_size) >> return 0; > > That says to me turn affine wakeups off for nearly everything. Ok, I see that now. thanks >> To explain the second condition above, Michael Wang said the following in [1] >> >> "Furthermore, if waker also has a high 'nr_wakee_switch', imply that multiple >> tasks rely on it, then waker's higher latency will damage all of them, pull >> wakee seems to be a bad deal." > > Yes, "Furthermore". To detect 1:N, Michael chose llc_size as his N. Is > the one flipping partners at least N/s, and the other about N times as > often? If so, the two may be part of a too big to wisely pull 1:N. > > If you have a better idea, by all means, pull it out. Nobody is Sure yeah, first I'm trying to understand the heuristic itself which I'm glad to be making progress with thanks to yours and others' help! > attached to wake_wide(), in fact, I suspect Peter hates it. I'm not > fond of it either, it having obvious holes. The only thing it has > going for it is simplicity. Bend it up, replace it, fire away. > Ok, it makes much more sense to me now. Also for the N:N case, wouldn't the excessive wake-affine increase the latency and a spreading might be better? Say if slave and master flips are much greater than factor (llc_size), then slave > factor && master < slave * factor, would probably return true a lot (and we would return 0 causing an affine wakeup). That's probably a bad thing right as it could overload the waker's CPU quickly? I guess the heuristic tries to maximize cache-hits more than reduce latency? >> Again I didn't follow why the second condition couldn't just be: >> waker->nr_wakee_switch > factor, or, (waker->nr_wakee_switch + >> wakee->nr_wakee_switch) > factor, based on the above explanation from >> Micheal Wang that I quoted. >> and why he's instead doing the whole multiplication thing there that I >> was talking about earlier: "factor * wakee->nr_wakee_switch". >> >> Rephrasing my question in another way, why are we talking the ratio of >> master/slave instead of the sum when comparing if its > factor? I am >> surely missing something here. > > Because the heuristic tries to not demolish 1:1 buddies. Big partner > flip delta means the pair are unlikely to be a communicating pair, > perhaps at high frequency where misses hurt like hell. But it does seem to me to demolish the N:N communicating pairs from a latency/load balancing standpoint. For he case of N readers and N writers, the ratio (master/slave) comes down to 1:1 and we wake affine. Hopefully I didn't miss something too obvious about that. thanks, -Joel
[PATCH] Staging: rtl8723bs: Do not initialise static to 0.
Do not initialise static to 0.
Static variables by default initialise to 0.
This patch fixes the errors found by checkpatch.
Signed-off-by: Shreeya Patel
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 +-
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 2 +-
drivers/staging/rtl8723bs/core/rtw_pwrctrl.c | 4 ++--
drivers/staging/rtl8723bs/core/rtw_recv.c | 2 +-
drivers/staging/rtl8723bs/core/rtw_security.c | 14 +++---
drivers/staging/rtl8723bs/core/rtw_xmit.c | 4 ++--
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index d5ab123..260e23f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -1384,7 +1384,7 @@ static void rtw_joinbss_update_network(struct adapter
*padapter, struct wlan_net
/* define REJOIN */
void rtw_joinbss_event_prehandle(struct adapter *adapter, u8 *pbuf)
{
- static u8 retry = 0;
+ static u8 retry;
u8 timer_cancelled;
struct sta_info *ptarget_sta = NULL, *pcur_sta = NULL;
struct sta_priv *pstapriv = &adapter->stapriv;
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 17d881d..99e3b68 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -2392,7 +2392,7 @@ s32 dump_mgntframe_and_wait(struct adapter *padapter,
struct xmit_frame *pmgntfr
s32 dump_mgntframe_and_wait_ack(struct adapter *padapter, struct xmit_frame
*pmgntframe)
{
- static u8 seq_no = 0;
+ static u8 seq_no;
s32 ret = _FAIL;
u32 timeout_ms = 500;/* 500ms */
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
diff --git a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
index f708dbf..f060e54 100644
--- a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
+++ b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
@@ -210,8 +210,8 @@ void pwr_state_check_handler(RTW_TIMER_HDL_ARGS)
void traffic_check_for_leave_lps(struct adapter *padapter, u8 tx, u32
tx_packets)
{
- static unsigned long start_time = 0;
- static u32 xmit_cnt = 0;
+ static unsigned long start_time;
+ static u32 xmit_cnt;
u8 bLeaveLPS = false;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c
b/drivers/staging/rtl8723bs/core/rtw_recv.c
index 695a5c9..c6018f0 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -1005,7 +1005,7 @@ sint ap2sta_data_frame(
if (*psta == NULL) {
/* for AP multicast issue , modify by yiwei */
- static unsigned long send_issue_deauth_time = 0;
+ static unsigned long send_issue_deauth_time;
/* DBG_871X("After send deauth , %u ms has
elapsed.\n", jiffies_to_msecs(jiffies - send_issue_deauth_time)); */
diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c
b/drivers/staging/rtl8723bs/core/rtw_security.c
index e832f16..06a7e40 100644
--- a/drivers/staging/rtl8723bs/core/rtw_security.c
+++ b/drivers/staging/rtl8723bs/core/rtw_security.c
@@ -162,7 +162,7 @@ static void arcfour_encrypt(
dest[i] = src[i] ^ (unsigned char)arcfour_byte(parc4ctx);
}
-static sint bcrc32initialized = 0;
+static sint bcrc32initialized;
static u32 crc32_table[256];
@@ -791,9 +791,9 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8
*precvframe)
stainfo = rtw_get_stainfo(&padapter->stapriv,
&prxattrib->ta[0]);
if (stainfo != NULL) {
if (IS_MCAST(prxattrib->ra)) {
- static unsigned long start = 0;
- static u32 no_gkey_bc_cnt = 0;
- static u32 no_gkey_mc_cnt = 0;
+ static unsigned long start;
+ static u32 no_gkey_bc_cnt;
+ static u32 no_gkey_mc_cnt;
if (psecuritypriv->binstallGrpkey == false) {
res = _FAIL;
@@ -1882,9 +1882,9 @@ u32 rtw_aes_decrypt(struct adapter *padapter, u8
*precvframe)
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
("rtw_aes_decrypt: stainfo!= NULL!!!\n"));
if (IS_MCAST(prxattrib->ra)) {
- static unsigned long start = 0;
- static u32 no_gkey_bc_cnt = 0;
- static u32 no_gkey_mc_cnt = 0;
+ static unsigned long start;
+ static u32 no_gkey_bc_cnt;
+ static u32 no_gk
Re: Yes you have standing to sue GRSecurity
On Sat, Jul 29, 2017 at 09:32:36AM -0600, Paul G. Allen wrote: > I have not contributed to the kernel for some time (I have been > working on some stuff, but nothing that's been contributed), so I > don't know if any of my code would be infringed (or if it's even in > the latest kernels). > > My work was on AGP and VIA drivers, so I am wondering if GRSecurity's > patches affect that code? It's not even clear that there is infringement. The GPL merely requires that people who have been distributed copies of GPL'ed code must not be restricted from further redistribution of the code. It does not require that that someone who is distributing it must available on a public FTP/HTTP server. Brad Spengler has asserted that he has not forbidden any of his customers from further redistribution of the code. Other than his claim of being in compliance with the GPL, I do not personally have any information either suggesting that he is or is not violating the terms of the GNU Public License. Personally, I think I don't think it makes any difference one way or another. GRSecurity has made themselves irrelevant from the perspective of upstream development. If someone wants to find some embedded device which is using GRSecurity, and wishes to purchase said device, and then demand access to source code under the terms of the GPL, and then post those sources on some web site, that is all within their right to do. For the most part, though, it's rarely useful to get dead code posted on a web site. This is the same reason that people who do drive-by open sourcing of code largely don't make much difference. You can make a code drop of (for example) Digital's old Tru64 advfs and make it available under an open source license. But even though it was a very good file system for its time, unless it comes with a community of developers, the code drop will very likely just sit there. So personally, I don't think it's a particularly good use of *my* time to investigate whether or not folks who are responsible for grsecurity are violating the terms of the GPL, and to get involved in a lawsuit. It may be that there is no "there" there, in which case it will be a waste of my time. And even if we can find proof that GRsecurity has forbidden its customers from redistribution code derived from the Linux kernel, in violation of the GPL, it will be messy, it will enrich a bunch of attorneys --- and at the end of the day we will get a dump of code that probably won't make any real difference to the upstream development of the Linux kernel, since it will probably be based on some ancient 3.18 kernel or some such. Cheers, - Ted
Re: [PATCH 1/1] netfilter: constify nf_conntrack_l3/4proto parameters
Julia Lawall wrote: > When a nf_conntrack_l3/4proto parameter is not on the left hand side > of an assignment, its address is not taken, and it is not passed to a > function that may modify its fields, then it can be declared as const. > > This change is useful from a documentation point of view, and can > possibly facilitate making some nf_conntrack_l3/4proto structures const > subsequently. > > Done with the help of Coccinelle. > > Some spacing adjusted to fit within 80 characters. Acked-by: Florian Westphal Thanks Julia. I think we can indeed constify these completely after making 'nla_size' set at compile time. I'll send a simple attempt to make it so for l3proto soon.
Re: [resend PATCH v2 11/33] dm: add dax_device and dax_operations support
On Fri, Jul 28, 2017 at 9:17 AM, Bart Van Assche wrote: > On Mon, 2017-04-17 at 12:09 -0700, Dan Williams wrote: >> diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig >> index b7767da50c26..1de8372d9459 100644 >> --- a/drivers/md/Kconfig >> +++ b/drivers/md/Kconfig >> @@ -200,6 +200,7 @@ config BLK_DEV_DM_BUILTIN >> config BLK_DEV_DM >> tristate "Device mapper support" >> select BLK_DEV_DM_BUILTIN >> + select DAX >> ---help--- >> Device-mapper is a low level volume manager. It works by allowing >> people to specify mappings for ranges of logical sectors. Various > > (replying to an e-mail of three months ago) > > Hello Dan, > > While building a v4.12 kernel I noticed that enabling device mapper support > now unconditionally enables DAX. I think there are plenty of systems that use > dm but do not need DAX. Have you considered to rework this such that instead > of dm selecting DAX that DAX support is only enabled in dm if CONFIG_DAX is > enabled? > I'd rather flip this around and add a CONFIG_DM_DAX that gates whether DM enables / links to the DAX core. I'll take a look at a patch.
[PATCH 3/3] xfs: persist S_IOMAP_IMMUTABLE in di_flags2
Record the immutable state in the on-disk inode so that on the next boot
the protections against reflink and hole punch etc are automatically
restored.
This deliberately does not add a FS_XFLAG_IOMAP_IMMUTABLE since
fallocate(2) is the path to toggle this flag.
Cc: Jan Kara
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc: Ross Zwisler
Cc: Alexander Viro
Suggested-by: Dave Chinner
Suggested-by: "Darrick J. Wong"
Signed-off-by: Dan Williams
---
fs/xfs/libxfs/xfs_format.h |5 -
fs/xfs/xfs_bmap_util.c | 14 +++---
fs/xfs/xfs_bmap_util.h |2 +-
fs/xfs/xfs_file.c |4 ++--
fs/xfs/xfs_ioctl.c |4 ++--
fs/xfs/xfs_iops.c |8 +---
6 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_format.h b/fs/xfs/libxfs/xfs_format.h
index d4d9bef20c3a..9e720e55776b 100644
--- a/fs/xfs/libxfs/xfs_format.h
+++ b/fs/xfs/libxfs/xfs_format.h
@@ -1063,12 +1063,15 @@ static inline void xfs_dinode_put_rdev(struct
xfs_dinode *dip, xfs_dev_t rdev)
#define XFS_DIFLAG2_DAX_BIT0 /* use DAX for this inode */
#define XFS_DIFLAG2_REFLINK_BIT1 /* file's blocks may be shared
*/
#define XFS_DIFLAG2_COWEXTSIZE_BIT 2 /* copy on write extent size hint */
+#define XFS_DIFLAG2_IOMAP_IMMUTABLE_BIT 3 /* set S_IOMAP_IMMUTABLE for this
inode */
#define XFS_DIFLAG2_DAX(1 << XFS_DIFLAG2_DAX_BIT)
#define XFS_DIFLAG2_REFLINK (1 << XFS_DIFLAG2_REFLINK_BIT)
#define XFS_DIFLAG2_COWEXTSIZE (1 << XFS_DIFLAG2_COWEXTSIZE_BIT)
+#define XFS_DIFLAG2_IOMAP_IMMUTABLE (1 << XFS_DIFLAG2_IOMAP_IMMUTABLE_BIT)
#define XFS_DIFLAG2_ANY \
- (XFS_DIFLAG2_DAX | XFS_DIFLAG2_REFLINK | XFS_DIFLAG2_COWEXTSIZE)
+ (XFS_DIFLAG2_DAX | XFS_DIFLAG2_REFLINK | XFS_DIFLAG2_COWEXTSIZE | \
+XFS_DIFLAG2_IOMAP_IMMUTABLE)
/*
* Inode number format:
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index c4fc79a0704f..1dcb521da456 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -1021,7 +1021,8 @@ xfs_alloc_file_space(
struct xfs_inode*ip,
xfs_off_t offset,
xfs_off_t len,
- int alloc_type)
+ int alloc_type,
+ uint64_tdi_flags2)
{
xfs_mount_t *mp = ip->i_mount;
xfs_off_t count;
@@ -1119,6 +1120,12 @@ xfs_alloc_file_space(
break;
}
xfs_ilock(ip, XFS_ILOCK_EXCL);
+ if (di_flags2) {
+ /* fold inode attributes for this allocation */
+ ip->i_d.di_flags2 |= di_flags2;
+ di_flags2 = 0;
+ }
+
error = xfs_trans_reserve_quota_nblks(tp, ip, qblocks,
0, quota_flag);
if (error)
@@ -1381,7 +1388,7 @@ xfs_zero_file_space(
error = xfs_alloc_file_space(ip, round_down(offset, blksize),
round_up(offset + len, blksize) -
round_down(offset, blksize),
-XFS_BMAPI_PREALLOC);
+XFS_BMAPI_PREALLOC, 0);
out:
return error;
@@ -1461,7 +1468,8 @@ xfs_seal_file_space(
goto err;
error = xfs_alloc_file_space(ip, offset, len,
- XFS_BMAPI_CONVERT | XFS_BMAPI_ZERO);
+ XFS_BMAPI_CONVERT | XFS_BMAPI_ZERO,
+ XFS_DIFLAG2_IOMAP_IMMUTABLE);
if (error)
goto err;
diff --git a/fs/xfs/xfs_bmap_util.h b/fs/xfs/xfs_bmap_util.h
index 5115a32a2483..1698e0c58b78 100644
--- a/fs/xfs/xfs_bmap_util.h
+++ b/fs/xfs/xfs_bmap_util.h
@@ -51,7 +51,7 @@ int xfs_bmap_last_extent(struct xfs_trans *tp, struct
xfs_inode *ip,
/* preallocation and hole punch interface */
intxfs_alloc_file_space(struct xfs_inode *ip, xfs_off_t offset,
-xfs_off_t len, int alloc_type);
+xfs_off_t len, int alloc_type, uint64_t di_flags2);
intxfs_free_file_space(struct xfs_inode *ip, xfs_off_t offset,
xfs_off_t len);
intxfs_zero_file_space(struct xfs_inode *ip, xfs_off_t offset,
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index e21121530a90..2d9ffa1773bd 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -837,12 +837,12 @@ xfs_file_fallocate(
goto out_unlock;
error = xfs_alloc_file_space(ip, offset, len,
- XFS_BMAPI_PREALLOC);
+ XFS_BMAPI_PREALLOC, 0);
} else if (mode & FALLOC_FL_SEAL_BLOCK_MAP) {
error = xfs_seal_file_space(ip, offset, len);
[PATCH 2/3] fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP
>From falloc.h:
FALLOC_FL_SEAL_BLOCK_MAP is used to seal (make immutable) all of the
file logical-to-physical extent offset mappings in the file. The
purpose is to allow an application to assume that there are no holes
or shared extents in the file and that the metadata needed to find
all the physical extents of the file is stable and can never be
dirtied.
For now this patch only permits setting / clearing the in-memory state
of S_IOMAP_IMMMUTABLE, persisting the state is saved for a later patch.
The implementation is careful to not allow the immutable state to change
while any process might have any established mappings. It reuses the
existing xfs_reflink_unshare() and xfs_alloc_file_space() to unshare
extents and fill all holes in the file, or otherwise extend the file
size in the same operation that sets S_IOMAP_IMMUTABLE.
Cc: Jan Kara
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc: Ross Zwisler
Cc: Alexander Viro
Suggested-by: Dave Chinner
Suggested-by: "Darrick J. Wong"
Signed-off-by: Dan Williams
---
fs/open.c | 26 -
fs/xfs/xfs_bmap_util.c | 86 +++
fs/xfs/xfs_bmap_util.h |2 +
fs/xfs/xfs_file.c | 14 +--
include/linux/falloc.h |3 +-
include/uapi/linux/falloc.h | 19 ++
6 files changed, 142 insertions(+), 8 deletions(-)
diff --git a/fs/open.c b/fs/open.c
index 7395860d7164..df075484fad5 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -241,7 +241,11 @@ int vfs_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
struct inode *inode = file_inode(file);
long ret;
- if (offset < 0 || len <= 0)
+ if (offset < 0 || len < 0)
+ return -EINVAL;
+
+ /* Allow zero len only for the unseal operation */
+ if (!(mode & FALLOC_FL_SEAL_BLOCK_MAP) && len == 0)
return -EINVAL;
/* Return error if mode is not supported */
@@ -273,6 +277,17 @@ int vfs_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
(mode & ~(FALLOC_FL_UNSHARE_RANGE | FALLOC_FL_KEEP_SIZE)))
return -EINVAL;
+ /*
+* Seal block map should only be used exclusively, and with
+* the IMMUTABLE capability.
+*/
+ if (mode & FALLOC_FL_SEAL_BLOCK_MAP) {
+ if (mode & ~FALLOC_FL_SEAL_BLOCK_MAP)
+ return -EINVAL;
+ if (!capable(CAP_LINUX_IMMUTABLE))
+ return -EPERM;
+ }
+
if (!(file->f_mode & FMODE_WRITE))
return -EBADF;
@@ -292,9 +307,14 @@ int vfs_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
return -ETXTBSY;
/*
-* We cannot allow any allocation changes on an iomap immutable file
+* We cannot allow any allocation changes on an iomap immutable
+* file, however if the operation is FALLOC_FL_SEAL_BLOCK_MAP,
+* call down to ->fallocate() to determine if the operations is
+* allowed. ->fallocate() may either clear the flag when @len is
+* zero, or validate that the requested operation is already the
+* current state of the file.
*/
- if (IS_IOMAP_IMMUTABLE(inode))
+ if (IS_IOMAP_IMMUTABLE(inode) && (!(mode & FALLOC_FL_SEAL_BLOCK_MAP)))
return -ETXTBSY;
/*
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 93e955262d07..c4fc79a0704f 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -1387,6 +1387,92 @@ xfs_zero_file_space(
}
+int
+xfs_seal_file_space(
+ struct xfs_inode*ip,
+ xfs_off_t offset,
+ xfs_off_t len)
+{
+ struct inode*inode = VFS_I(ip);
+ struct address_space*mapping = inode->i_mapping;
+ int error = 0;
+
+ if (offset)
+ return -EINVAL;
+
+ i_mmap_lock_read(mapping);
+ xfs_ilock(ip, XFS_ILOCK_EXCL);
+ if (len == 0) {
+ /*
+* Clear the immutable flag provided there are no active
+* mappings. The active mapping check prevents an
+* application that is assuming a static block map, for
+* DAX or peer-to-peer DMA, from having this state
+* silently change behind its back.
+*/
+ if (RB_EMPTY_ROOT(&mapping->i_mmap))
+ inode->i_flags &= ~S_IOMAP_IMMUTABLE;
+ else
+ error = -EBUSY;
+ } else if (IS_IOMAP_IMMUTABLE(inode)) {
+ if (len == i_size_read(inode)) {
+ /*
+* The file is already in the correct state,
+* bail out without error below.
+*/
+ len = 0;
+ } else {
+ /* to
[PATCH 1/3] fs, xfs: introduce S_IOMAP_IMMUTABLE
An inode with this flag set indicates that the file's block map cannot
be changed, no size change, deletion, hole-punch, range collapse, or
reflink.
The implementation of toggling the flag and sealing the state of the
extent map is saved for a later patch. The functionality provided by
S_IOMAP_IMMUTABLE, once toggle support is added, will be a superset of
that provided by S_SWAPFILE, and it is targeted to replace it.
For now, only xfs and the core vfs are updated to consider the new flag.
The additional check that is added for this flag, beyond what we are
already doing for swapfiles, is to truncate or abort writes that try to
extend the file size.
Cc: Jan Kara
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc: Ross Zwisler
Cc: Alexander Viro
Suggested-by: Dave Chinner
Suggested-by: "Darrick J. Wong"
Signed-off-by: Dan Williams
---
fs/attr.c | 10 ++
fs/namei.c |3 ++-
fs/open.c |6 ++
fs/read_write.c|3 +++
fs/xfs/xfs_ioctl.c |6 ++
include/linux/fs.h |2 ++
mm/filemap.c |9 +
7 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/fs/attr.c b/fs/attr.c
index 135304146120..8573e364bd06 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -112,6 +112,16 @@ EXPORT_SYMBOL(setattr_prepare);
*/
int inode_newsize_ok(const struct inode *inode, loff_t offset)
{
+ if (IS_IOMAP_IMMUTABLE(inode)) {
+ /*
+* Any size change is disallowed. Size increases may
+* dirty metadata that an application is not prepared to
+* sync, and a size decrease may expose free blocks to
+* in-flight DMA.
+*/
+ return -ETXTBSY;
+ }
+
if (inode->i_size < offset) {
unsigned long limit;
diff --git a/fs/namei.c b/fs/namei.c
index ddb6a7c2b3d4..588f1135c42c 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -2793,7 +2793,8 @@ static int may_delete(struct inode *dir, struct dentry
*victim, bool isdir)
return -EPERM;
if (check_sticky(dir, inode) || IS_APPEND(inode) ||
- IS_IMMUTABLE(inode) || IS_SWAPFILE(inode) || HAS_UNMAPPED_ID(inode))
+ IS_IMMUTABLE(inode) || IS_SWAPFILE(inode) || HAS_UNMAPPED_ID(inode)
+ || IS_IOMAP_IMMUTABLE(inode))
return -EPERM;
if (isdir) {
if (!d_is_dir(victim))
diff --git a/fs/open.c b/fs/open.c
index 35bb784763a4..7395860d7164 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -292,6 +292,12 @@ int vfs_fallocate(struct file *file, int mode, loff_t
offset, loff_t len)
return -ETXTBSY;
/*
+* We cannot allow any allocation changes on an iomap immutable file
+*/
+ if (IS_IOMAP_IMMUTABLE(inode))
+ return -ETXTBSY;
+
+ /*
* Revalidate the write permissions, in case security policy has
* changed since the files were opened.
*/
diff --git a/fs/read_write.c b/fs/read_write.c
index 0cc7033aa413..dc673be7c7cb 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -1706,6 +1706,9 @@ int vfs_clone_file_prep_inodes(struct inode *inode_in,
loff_t pos_in,
if (IS_SWAPFILE(inode_in) || IS_SWAPFILE(inode_out))
return -ETXTBSY;
+ if (IS_IOMAP_IMMUTABLE(inode_in) || IS_IOMAP_IMMUTABLE(inode_out))
+ return -ETXTBSY;
+
/* Don't reflink dirs, pipes, sockets... */
if (S_ISDIR(inode_in->i_mode) || S_ISDIR(inode_out->i_mode))
return -EISDIR;
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index e75c40a47b7d..2e64488bc4de 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -1755,6 +1755,12 @@ xfs_ioc_swapext(
goto out_put_tmp_file;
}
+ if (IS_IOMAP_IMMUTABLE(file_inode(f.file)) ||
+ IS_IOMAP_IMMUTABLE(file_inode(tmp.file))) {
+ error = -EINVAL;
+ goto out_put_tmp_file;
+ }
+
/*
* We need to ensure that the fds passed in point to XFS inodes
* before we cast and access them as XFS structures as we have no
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 6e1fd5d21248..0a254b768855 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1829,6 +1829,7 @@ struct super_operations {
#else
#define S_DAX 0 /* Make all the DAX code disappear */
#endif
+#define S_IOMAP_IMMUTABLE 16384 /* logical-to-physical extent map is fixed */
/*
* Note that nosuid etc flags are inode-specific: setting some file-system
@@ -1867,6 +1868,7 @@ struct super_operations {
#define IS_AUTOMOUNT(inode)((inode)->i_flags & S_AUTOMOUNT)
#define IS_NOSEC(inode)((inode)->i_flags & S_NOSEC)
#define IS_DAX(inode) ((inode)->i_flags & S_DAX)
+#define IS_IOMAP_IMMUTABLE(inode) ((inode)->i_flags & S_IOMAP_IMMUTABLE)
#define IS_WHITEOUT(inode) (S_ISCHR(inode->i_mode) && \
(inode)->i_rdev =
[PATCH 0/3] fs, xfs: block map immutable files for dax, dma-to-storage, and swap
tl;dr: The proposed S_IOMAP_IMMUTABLE mechanism The daxfile proposal a few weeks back [1] sought to piggy back on the swapfile implementation to approximate a block map immutable file. This is an idea Dave originated last year to solve the dax "flush from userspace" problem [2]. The discussion yielded several results. First, Christoph pointed out that swapfiles are subtly broken [3]. Second, Darrick [4] and Dave [5] proposed how to properly implement a block map immutable file. Finally, Dave identified some improvements to swapfiles that can be built on the block-map-immutable mecahanism. These patches seek to implement the first part of the proposal and save the swapfile work to build on top once the base mechanism is complete. While the initial motivation for this feature is support for byte-addressable updates of persistent memory and managing cache maintenance from userspace, the applications of the feature are broader. In addition to being the start of a better swapfile mechanism it can also support a DMA-to-storage use case. This use case enables data-acquisition hardware to DMA directly to a storage device address while being safe in the knowledge that storage mappings will not change. These patches are relative to Darrick's 'devel' tree. Patch 3 is likely wrong in the way it sets the new XFS_DIFLAG2_IOMAP_IMMUTABLE flag, but seems to work with a basic test. The test just turns the flag on and off, checks that the file is fully allocated and immutable, and validates that the state persists over a umount / mount cycle. A proper xfstest is in the works, but comments on this first draft are welcome. [1]: https://lkml.org/lkml/2017/6/16/790 [2]: https://lkml.org/lkml/2016/9/11/159 [3]: https://lkml.org/lkml/2017/6/18/31 [4]: https://lkml.org/lkml/2017/6/20/49 [5]: https://www.spinics.net/lists/linux-xfs/msg07871.html --- Dan Williams (3): fs, xfs: introduce S_IOMAP_IMMUTABLE fs, xfs: introduce FALLOC_FL_SEAL_BLOCK_MAP xfs: persist S_IOMAP_IMMUTABLE in di_flags2 fs/attr.c | 10 fs/namei.c |3 + fs/open.c | 28 fs/read_write.c |3 + fs/xfs/libxfs/xfs_format.h |5 ++ fs/xfs/xfs_bmap_util.c | 98 ++- fs/xfs/xfs_bmap_util.h |4 +- fs/xfs/xfs_file.c | 14 -- fs/xfs/xfs_ioctl.c | 10 fs/xfs/xfs_iops.c |8 ++-- include/linux/falloc.h |3 + include/linux/fs.h |2 + include/uapi/linux/falloc.h | 19 mm/filemap.c|9 14 files changed, 200 insertions(+), 16 deletions(-)
[PATCH 1/1] netfilter: constify nf_conntrack_l3/4proto parameters
When a nf_conntrack_l3/4proto parameter is not on the left hand side
of an assignment, its address is not taken, and it is not passed to a
function that may modify its fields, then it can be declared as const.
This change is useful from a documentation point of view, and can
possibly facilitate making some nf_conntrack_l3/4proto structures const
subsequently.
Done with the help of Coccinelle.
Some spacing adjusted to fit within 80 characters.
Signed-off-by: Julia Lawall
---
include/net/netfilter/nf_conntrack_l3proto.h |6 +++---
include/net/netfilter/nf_conntrack_l4proto.h |8
include/net/netfilter/nf_conntrack_timeout.h |2 +-
net/netfilter/nf_conntrack_core.c|8
net/netfilter/nf_conntrack_netlink.c |6 +++---
net/netfilter/nf_conntrack_proto.c | 20 ++--
net/netfilter/nfnetlink_cttimeout.c |2 +-
7 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_l3proto.h
b/include/net/netfilter/nf_conntrack_l3proto.h
index 6d14b36..4782b15 100644
--- a/include/net/netfilter/nf_conntrack_l3proto.h
+++ b/include/net/netfilter/nf_conntrack_l3proto.h
@@ -76,17 +76,17 @@ struct nf_conntrack_l3proto {
#ifdef CONFIG_SYSCTL
/* Protocol pernet registration. */
int nf_ct_l3proto_pernet_register(struct net *net,
- struct nf_conntrack_l3proto *proto);
+ const struct nf_conntrack_l3proto *proto);
#else
static inline int nf_ct_l3proto_pernet_register(struct net *n,
- struct nf_conntrack_l3proto *p)
+ const struct nf_conntrack_l3proto *p)
{
return 0;
}
#endif
void nf_ct_l3proto_pernet_unregister(struct net *net,
-struct nf_conntrack_l3proto *proto);
+const struct nf_conntrack_l3proto *proto);
/* Protocol global registration. */
int nf_ct_l3proto_register(struct nf_conntrack_l3proto *proto);
diff --git a/include/net/netfilter/nf_conntrack_l4proto.h
b/include/net/netfilter/nf_conntrack_l4proto.h
index 7032e04..72589b7 100644
--- a/include/net/netfilter/nf_conntrack_l4proto.h
+++ b/include/net/netfilter/nf_conntrack_l4proto.h
@@ -125,13 +125,13 @@ struct nf_conntrack_l4proto
*__nf_ct_l4proto_find(u_int16_t l3proto,
struct nf_conntrack_l4proto *nf_ct_l4proto_find_get(u_int16_t l3proto,
u_int8_t l4proto);
-void nf_ct_l4proto_put(struct nf_conntrack_l4proto *p);
+void nf_ct_l4proto_put(const struct nf_conntrack_l4proto *p);
/* Protocol pernet registration. */
int nf_ct_l4proto_pernet_register_one(struct net *net,
- struct nf_conntrack_l4proto *proto);
+ const struct nf_conntrack_l4proto *proto);
void nf_ct_l4proto_pernet_unregister_one(struct net *net,
-struct nf_conntrack_l4proto *proto);
+ const struct nf_conntrack_l4proto *proto);
int nf_ct_l4proto_pernet_register(struct net *net,
struct nf_conntrack_l4proto *proto[],
unsigned int num_proto);
@@ -141,7 +141,7 @@ void nf_ct_l4proto_pernet_unregister(struct net *net,
/* Protocol global registration. */
int nf_ct_l4proto_register_one(struct nf_conntrack_l4proto *proto);
-void nf_ct_l4proto_unregister_one(struct nf_conntrack_l4proto *proto);
+void nf_ct_l4proto_unregister_one(const struct nf_conntrack_l4proto *proto);
int nf_ct_l4proto_register(struct nf_conntrack_l4proto *proto[],
unsigned int num_proto);
void nf_ct_l4proto_unregister(struct nf_conntrack_l4proto *proto[],
diff --git a/include/net/netfilter/nf_conntrack_timeout.h
b/include/net/netfilter/nf_conntrack_timeout.h
index d40b893..b222957 100644
--- a/include/net/netfilter/nf_conntrack_timeout.h
+++ b/include/net/netfilter/nf_conntrack_timeout.h
@@ -68,7 +68,7 @@ struct nf_conn_timeout *nf_ct_timeout_ext_add(struct nf_conn
*ct,
static inline unsigned int *
nf_ct_timeout_lookup(struct net *net, struct nf_conn *ct,
-struct nf_conntrack_l4proto *l4proto)
+const struct nf_conntrack_l4proto *l4proto)
{
#ifdef CONFIG_NF_CONNTRACK_TIMEOUT
struct nf_conn_timeout *timeout_ext;
diff --git a/net/netfilter/nf_conntrack_core.c
b/net/netfilter/nf_conntrack_core.c
index 51390fe..ed4e04e 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1183,8 +1183,8 @@ void nf_conntrack_free(struct nf_conn *ct)
static noinline struct nf_conntrack_tuple_hash *
init_conntrack(struct net *net, struct nf_conn *tmpl,
const struct nf_conntrack_tuple *tuple,
- struct nf_conntrack_l3proto *l3proto,
- struct nf_conntrack_l4proto *l4proto,
+
[PATCH 0/1] constify nf_conntrack_l3/4proto parameters
When a nf_conntrack_l3/4proto parameter is not on the left hand side
of an assignment, its address is not taken, and it is not passed to a
function that may modify its fields, then it can be declared as const.
This change is useful from a documentation point of view, and can
possibly facilitate making some nf_conntrack_l4proto structures const
subsequently.
Done with the help of Coccinelle. The following semantic patch shows
the nf_conntrack_l4proto case.
//
virtual update_results
virtual after_start
@initialize:ocaml@
@@
let unsafe = Hashtbl.create 101
let is_unsafe f = Hashtbl.mem unsafe f
let changed = ref false
(* The next three rules relate to the fact that we do not know the type of
void * variables. Fortunately this is only needed on the first iteration,
but it still means that the whole kernel will end up being considered. *)
@has depends on !after_start@
identifier f,l4proto;
position p;
@@
f(...,struct nf_conntrack_l4proto *l4proto,...) { ... }
@others depends on !after_start@
position p != has.p;
identifier f,x;
@@
f(...,void *x,...) { ... }
@script:ocaml@
f << others.f;
@@
changed := true;
Hashtbl.add unsafe f ()
@fpb depends on !update_results disable optional_qualifier exists@
identifier f : script:ocaml() { not(is_unsafe(f)) };
identifier l4proto,fld;
identifier bad : script:ocaml() { is_unsafe(bad) };
assignment operator aop;
expression e;
local idexpression fp;
@@
f(...,struct nf_conntrack_l4proto *l4proto,...)
{
<+...
(
(<+...l4proto...+>) aop e
|
&(<+...l4proto...+>)
|
bad(...,l4proto,...)
|
fp(...,l4proto,...)
|
(<+...e->fld...+>)(...,l4proto,...)
)
...+> }
@script:ocaml@
f << fpb.f;
@@
changed := true;
Hashtbl.add unsafe f ()
@finalize:ocaml depends on !update_results@
tbls << merge.unsafe;
c << merge.changed;
@@
List.iter
(fun t ->
Hashtbl.iter
(fun k v ->
if not (Hashtbl.mem unsafe k) then Hashtbl.add unsafe k ()) t)
tbls;
let changed = List.exists (fun x -> !x) c in
let it = new iteration() in
it#add_virtual_rule After_start;
(if not changed
then it#add_virtual_rule Update_results);
it#register()
@depends on update_results disable optional_qualifier@
identifier f : script:ocaml() { not(is_unsafe(f)) };
identifier l4proto;
@@
f(...,
+ const
struct nf_conntrack_l4proto *l4proto,...) { ... }
@depends on update_results disable optional_qualifier@
identifier f : script:ocaml() { not(is_unsafe(f)) };
identifier l4proto;
type T;
@@
T f(...,
+ const
struct nf_conntrack_l4proto *l4proto,...);
//
---
include/net/netfilter/nf_conntrack_l3proto.h |6 +++---
include/net/netfilter/nf_conntrack_l4proto.h |8
include/net/netfilter/nf_conntrack_timeout.h |2 +-
net/netfilter/nf_conntrack_core.c|8
net/netfilter/nf_conntrack_netlink.c |6 +++---
net/netfilter/nf_conntrack_proto.c | 20 ++--
net/netfilter/nfnetlink_cttimeout.c |2 +-
7 files changed, 26 insertions(+), 26 deletions(-)
Re: [PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display
On 07/29/2017 02:17 PM, David Lechner wrote: The goal of this series is to get the built-in LCD of the LEGO MINDSTORMS EV3 working. But, most of the content here is building up the infrastructure to do that. Some general comments/questions: I have noticed that DRM doesn't really have support for monochrome displays. I'm guessing that is because no one really uses them anymore? The LEGO EV3 display is just an LCD (not the backlit kind). It has two modes of operation. It can to 2bbp grayscale or it can do 1bpp monochrome. The grayscale isn't the best (looks splotchy in places), so it would be nice to be able to choose between these two modes. How would I implement something like that? Also, how can I indicate to userspace that this display really is monochrome/grayscale since the reported color depth 16bpp?
Re: [PATCH 3/6] drm/tinydrm: rename mi028qt module to mipi-panel
On 07/29/2017 02:17 PM, David Lechner wrote:
This renames the mi028qt module to mipi-panel so that it can be used for
other types of panels as well. There is no reason to copy a bunch of
boiler-plate code for each panel or controller.
Signed-off-by: David Lechner
---
.../devicetree/bindings/display/mipi-panel.txt | 27 ++
.../bindings/display/multi-inno,mi0283qt.txt | 27 --
MAINTAINERS| 6 +-
drivers/gpu/drm/tinydrm/Kconfig| 12 +-
drivers/gpu/drm/tinydrm/Makefile | 2 +-
drivers/gpu/drm/tinydrm/mi0283qt.c | 283
drivers/gpu/drm/tinydrm/mipi-panel.c | 284 +
7 files changed, 323 insertions(+), 318 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/mipi-panel.txt
delete mode 100644
Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
delete mode 100644 drivers/gpu/drm/tinydrm/mi0283qt.c
create mode 100644 drivers/gpu/drm/tinydrm/mipi-panel.c
Apparently, I missed an option on git format-patch. This diff should be
easier to look at...
---
diff --git
a/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
b/Documentation/devicetree/bindings/display/mipi-panel.txt
similarity index 94%
rename from
Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
rename to Documentation/devicetree/bindings/display/mipi-panel.txt
index eed48c3..01d6ea9 100644
--- a/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
+++ b/Documentation/devicetree/bindings/display/mipi-panel.txt
@@ -1,4 +1,4 @@
-Multi-Inno MI0283QT display panel
+MIPI DBI compatible display panel
Required properties:
- compatible: "multi-inno,mi0283qt".
@@ -17,7 +17,7 @@ Optional properties:
- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
Example:
- mi0283qt@0{
+ display@0{
compatible = "multi-inno,mi0283qt";
reg = <0>;
spi-max-frequency = <3200>;
diff --git a/MAINTAINERS b/MAINTAINERS
index f66488d..812ffd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4315,11 +4315,11 @@ M: Dave Airlie
S: Odd Fixes
F: drivers/gpu/drm/mgag200/
-DRM DRIVER FOR MI0283QT
+DRM DRIVER FOR MIPI DBI compatible panels
M: Noralf Trønnes
S: Maintained
-F: drivers/gpu/drm/tinydrm/mi0283qt.c
-F: Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
+F: drivers/gpu/drm/tinydrm/mipi-panel.c
+F: Documentation/devicetree/bindings/display/mipi-panel.txt
DRM DRIVER FOR MSM ADRENO GPU
M: Rob Clark
diff --git a/drivers/gpu/drm/tinydrm/Kconfig
b/drivers/gpu/drm/tinydrm/Kconfig
index 3504c53..0a0db7a 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -12,10 +12,14 @@ menuconfig DRM_TINYDRM
config TINYDRM_MIPI_DBI
tristate
-config TINYDRM_MI0283QT
- tristate "DRM support for MI0283QT"
+config TINYDRM_MIPI_PANEL
+ tristate "DRM support for MIPI DBI compatible display panels"
depends on DRM_TINYDRM && SPI
select TINYDRM_MIPI_DBI
help
- DRM driver for the Multi-Inno MI0283QT display panel
- If M is selected the module will be called mi0283qt.
+ DRM driver for the MIPI DBI compatible display panels.
+
+ Supported panels include:
+ * Multi-Inno MI0283QT
+
+ If M is selected the module will be called mipi-panel.
diff --git a/drivers/gpu/drm/tinydrm/Makefile
b/drivers/gpu/drm/tinydrm/Makefile
index 7a3604c..7eae65e 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -4,4 +4,4 @@ obj-$(CONFIG_DRM_TINYDRM) += core/
obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
# Displays
-obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
+obj-$(CONFIG_TINYDRM_MIPI_PANEL) += mipi-panel.o
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mipi-panel.c
similarity index 76%
rename from drivers/gpu/drm/tinydrm/mi0283qt.c
rename to drivers/gpu/drm/tinydrm/mipi-panel.c
index 2680dab..64344f0 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mipi-panel.c
@@ -1,7 +1,8 @@
/*
- * DRM driver for Multi-Inno MI0283QT panels
+ * DRM driver for MIPI DBI compatible panels
*
* Copyright 2016 Noralf Trønnes
+ * Copyright 2017 David Lechner
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -20,7 +21,7 @@
#include
#include
-static int mi0283qt_init(struct mipi_dbi *mipi)
+static int mipi_panel_init(struct mipi_dbi *mipi)
{
struct tinydrm_device *tdev = &mipi->tinydrm;
struct device *dev = tdev->drm->dev;
@@ -113,7 +114,7 @@ static int mi0283qt_init(struct mipi_dbi *mipi)
return 0;
}
-static void mi0283qt_fini(void *data)
+stati
Re: [PATCH] thermal: intel_pch_thermal: Read large temp values correctly
On Wed, 2017-07-19 at 17:47 -0700, Ed Swierk wrote:
> On all supported platforms, the TS Reading (TSR) field in the
> Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78
> degrees C) are plausible, so don't mask out the topmost bit. And the
> register itself is 16 bits wide, so use readw() rather than readl().
>
> Signed-off-by: Ed Swierk
Reviewed-by: Srinivas Pandruvada
> ---
> drivers/thermal/intel_pch_thermal.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/intel_pch_thermal.c
> b/drivers/thermal/intel_pch_thermal.c
> index 9889c90..318fc1b 100644
> --- a/drivers/thermal/intel_pch_thermal.c
> +++ b/drivers/thermal/intel_pch_thermal.c
> @@ -49,7 +49,7 @@
> #define WPT_TSGPEN 0x84/* General Purpose Event
> Enables */
>
> /* Wildcat Point-LP PCH Thermal Register bit definitions */
> -#define WPT_TEMP_TSR 0x00ff /* Temp TS Reading */
> +#define WPT_TEMP_TSR 0x01ff /* Temp TS Reading */
> #define WPT_TSC_CPDE 0x01/* Catastrophic Power-Down
> Enable */
> #define WPT_TSS_TSDSS0x10/* Thermal Sensor Dynamic
> Shutdown Status */
> #define WPT_TSS_GPES 0x08/* GPE status */
> @@ -174,9 +174,9 @@ static int pch_wpt_init(struct pch_thermal_device
> *ptd, int *nr_trips)
>
> static int pch_wpt_get_temp(struct pch_thermal_device *ptd, int
> *temp)
> {
> - u8 wpt_temp;
> + u16 wpt_temp;
>
> - wpt_temp = WPT_TEMP_TSR & readl(ptd->hw_base + WPT_TEMP);
> + wpt_temp = WPT_TEMP_TSR & readw(ptd->hw_base + WPT_TEMP);
>
> /* Resolution of 1/2 degree C and an offset of -50C */
> *temp = (wpt_temp * 1000 / 2 - 5);
Re: [PATCH] thermal: fix INTEL_SOC_DTS_IOSF_CORE dependencies
On Fri, 2017-07-21 at 18:16 +0200, Arnd Bergmann wrote:
> We get a Kconfig warning when selecting this without also enabling
> CONFIG_PCI:
>
> warning: (X86_INTEL_LPSS && INTEL_SOC_DTS_IOSF_CORE &&
> SND_SST_IPC_ACPI && MMC_SDHCI_ACPI && PUNIT_ATOM_DEBUG) selects
> IOSF_MBI which has unmet direct dependencies (PCI)
>
> This adds a new depedency.
>
> Fixes: 3a2419f865a6 ("Thermal: Intel SoC: DTS thermal use common
> APIs")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Srinivas Pandruvada
> ---
> drivers/thermal/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index b5b5facb8747..ac2a53823576 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -342,7 +342,7 @@ config X86_PKG_TEMP_THERMAL
>
> config INTEL_SOC_DTS_IOSF_CORE
> tristate
> - depends on X86
> + depends on X86 && PCI
> select IOSF_MBI
> help
> This is becoming a common feature for Intel SoCs to expose
> the additional
> @@ -352,7 +352,7 @@ config INTEL_SOC_DTS_IOSF_CORE
>
> config INTEL_SOC_DTS_THERMAL
> tristate "Intel SoCs DTS thermal driver"
> - depends on X86
> + depends on X86 && PCI
> select INTEL_SOC_DTS_IOSF_CORE
> select THERMAL_WRITABLE_TRIPS
> help
[PATCH 5/6] drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD
LEGO MINDSTORMS EV3 has an LCD with a ST7586 controller. This adds a new
module for the ST7586 controller with parameters for the EV3 LCD dispay.
Signed-off-by: David Lechner
---
.../devicetree/bindings/display/mipi-panel.txt | 2 +-
drivers/gpu/drm/tinydrm/Kconfig| 1 +
drivers/gpu/drm/tinydrm/mipi-panel.c | 87 ++
include/drm/tinydrm/st7586.h | 34 +
4 files changed, 123 insertions(+), 1 deletion(-)
create mode 100644 include/drm/tinydrm/st7586.h
diff --git a/Documentation/devicetree/bindings/display/mipi-panel.txt
b/Documentation/devicetree/bindings/display/mipi-panel.txt
index 01d6ea9..ba8c8ab 100644
--- a/Documentation/devicetree/bindings/display/mipi-panel.txt
+++ b/Documentation/devicetree/bindings/display/mipi-panel.txt
@@ -1,7 +1,7 @@
MIPI DBI compatible display panel
Required properties:
-- compatible: "multi-inno,mi0283qt".
+- compatible: one of "lego,ev3-lcd", "multi-inno,mi0283qt".
The node for this driver must be a child node of a SPI controller, hence
all mandatory properties described in ../spi/spi-bus.txt must be specified.
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 394519b..6e90bb5 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -20,6 +20,7 @@ config TINYDRM_MIPI_PANEL
DRM driver for the MIPI DBI compatible display panels.
Supported panels include:
+ * LEGO MINDSTORMS EV3
* Multi-Inno MI0283QT
If M is selected the module will be called mipi-panel.
diff --git a/drivers/gpu/drm/tinydrm/mipi-panel.c
b/drivers/gpu/drm/tinydrm/mipi-panel.c
index 8aa1d8e..e3d5678 100644
--- a/drivers/gpu/drm/tinydrm/mipi-panel.c
+++ b/drivers/gpu/drm/tinydrm/mipi-panel.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,7 @@
enum mipi_panel_type {
MIPI_PANEL_TYPE_UNKNOWN,
+ MIPI_PANEL_TYPE_LEGO_EV3_LCD,
MIPI_PANEL_TYPE_MULTI_INNO_MI0283QT,
};
@@ -125,6 +127,84 @@ static int mipi_panel_init_ili9341(struct mipi_dbi *mipi)
return 0;
}
+static int mipi_panel_init_st7586(struct mipi_dbi *mipi)
+{
+ struct tinydrm_device *tdev = &mipi->tinydrm;
+ struct device *dev = tdev->drm->dev;
+ u8 addr_mode;
+ int ret;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = regulator_enable(mipi->regulator);
+ if (ret) {
+ dev_err(dev, "Failed to enable regulator %d\n", ret);
+ return ret;
+ }
+
+ /* Avoid flicker by skipping setup if the bootloader has done it */
+ if (mipi_dbi_display_is_on(mipi))
+ return 0;
+
+ mipi_dbi_hw_reset(mipi);
+ ret = mipi_dbi_command(mipi, ST7586_AUTO_READ_CTRL, 0x9f);
+ if (ret) {
+ dev_err(dev, "Error sending command %d\n", ret);
+ regulator_disable(mipi->regulator);
+ return ret;
+ }
+
+ mipi_dbi_command(mipi, ST7586_OTP_RW_CTRL, 0x00);
+
+ msleep(10);
+
+ mipi_dbi_command(mipi, ST7586_OTP_READ);
+
+ msleep(20);
+
+ mipi_dbi_command(mipi, ST7586_OTP_CTRL_OUT);
+ mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+ mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
+
+ msleep(50);
+
+ mipi_dbi_command(mipi, ST7586_SET_VOP_OFFSET, 0x00);
+ mipi_dbi_command(mipi, ST7586_SET_VOP, 0xe3, 0x00);
+ mipi_dbi_command(mipi, ST7586_SET_BIAS_SYSTEM, 0x02);
+ mipi_dbi_command(mipi, ST7586_SET_BOOST_LEVEL, 0x04);
+ mipi_dbi_command(mipi, ST7586_ENABLE_ANALOG, 0x1d);
+ mipi_dbi_command(mipi, ST7586_SET_NLINE_INV, 0x00);
+ mipi_dbi_command(mipi, ST7586_DISP_MODE_GRAY);
+ mipi_dbi_command(mipi, ST7586_ENABLE_DDRAM, 0x02);
+
+ switch (mipi->rotation) {
+ default:
+ addr_mode = 0x00;
+ break;
+ case 90:
+ addr_mode = ST7586_DISP_CTRL_MY;
+ break;
+ case 180:
+ addr_mode = ST7586_DISP_CTRL_MX | ST7586_DISP_CTRL_MY;
+ break;
+ case 270:
+ addr_mode = ST7586_DISP_CTRL_MX;
+ break;
+ }
+ mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+
+ mipi_dbi_command(mipi, ST7586_SET_DISP_DUTY, 0x7f);
+ mipi_dbi_command(mipi, ST7586_SET_PART_DISP, 0xa0);
+ mipi_dbi_command(mipi, MIPI_DCS_SET_PARTIAL_AREA, 0x00, 0x00, 0x00,
0x77);
+ mipi_dbi_command(mipi, MIPI_DCS_EXIT_INVERT_MODE);
+
+ msleep(100);
+
+ mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+
+ return 0;
+}
+
static void mipi_panel_fini(void *data)
{
struct mipi_dbi *mipi = data;
@@ -141,6 +221,11 @@ static const struct drm_simple_display_pipe_funcs
mipi_panel_pipe_funcs = {
};
static const struct mipi_panel_info mipi_panel_infos[] = {
+ [MIPI_PANEL_TYPE_LEGO_EV3_LCD] = {
+
[PATCH 1/6] drm/tinydrm: Add parameter for MIPI DCS pixel format
This adds a parameter for MIPI DCS pixel format to mipi_dbi_init().
This is in preparation for supporting displays that don't use a 16bpp
memory layout.
Signed-off-by: David Lechner
---
drivers/gpu/drm/tinydrm/mi0283qt.c | 3 ++-
drivers/gpu/drm/tinydrm/mipi-dbi.c | 21 ++---
include/drm/tinydrm/mipi-dbi.h | 7 ++-
include/video/mipi_display.h | 14 --
4 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 482ff1c3..2680dab 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -196,7 +196,8 @@ static int mi0283qt_probe(struct spi_device *spi)
device_property_read_u32(dev, "rotation", &rotation);
ret = mipi_dbi_spi_init(spi, mipi, dc, &mi0283qt_pipe_funcs,
- &mi0283qt_driver, &mi0283qt_mode, rotation);
+ &mi0283qt_driver, &mi0283qt_mode,
+ MIPI_DCS_PIXEL_FMT_16BIT, rotation);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index c83eeb7..7d49366 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -336,6 +336,7 @@ static const uint32_t mipi_dbi_formats[] = {
* @pipe_funcs: Display pipe functions
* @driver: DRM driver
* @mode: Display mode
+ * @pixel_fmt: The display memory's pixel format
* @rotation: Initial rotation in degrees Counter Clock Wise
*
* This function initializes a &mipi_dbi structure and it's underlying
@@ -352,15 +353,26 @@ static const uint32_t mipi_dbi_formats[] = {
int mipi_dbi_init(struct device *dev, struct mipi_dbi *mipi,
const struct drm_simple_display_pipe_funcs *pipe_funcs,
struct drm_driver *driver,
- const struct drm_display_mode *mode, unsigned int rotation)
+ const struct drm_display_mode *mode,
+ enum mipi_dcs_pixel_format pixel_fmt, unsigned int rotation)
{
- size_t bufsize = mode->vdisplay * mode->hdisplay * sizeof(u16);
struct tinydrm_device *tdev = &mipi->tinydrm;
+ size_t bufsize;
int ret;
if (!mipi->command)
return -EINVAL;
+ switch (pixel_fmt) {
+ case MIPI_DCS_PIXEL_FMT_16BIT:
+ bufsize = mode->vdisplay * mode->hdisplay * sizeof(u16);
+ break;
+ default:
+ DRM_ERROR("Pixel format is not supported\n");
+ return -EINVAL;
+ }
+ mipi->pixel_fmt = pixel_fmt;
+
mutex_init(&mipi->cmdlock);
mipi->tx_buf = devm_kmalloc(dev, bufsize, GFP_KERNEL);
@@ -781,6 +793,7 @@ static int mipi_dbi_typec3_command(struct mipi_dbi *mipi,
u8 cmd,
* @pipe_funcs: Display pipe functions
* @driver: DRM driver
* @mode: Display mode
+ * @pixel_fmt: The display memory's pixel format
* @rotation: Initial rotation in degrees Counter Clock Wise
*
* This function sets &mipi_dbi->command, enables &mipi->read_commands for the
@@ -803,6 +816,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct
mipi_dbi *mipi,
const struct drm_simple_display_pipe_funcs *pipe_funcs,
struct drm_driver *driver,
const struct drm_display_mode *mode,
+ enum mipi_dcs_pixel_format pixel_fmt,
unsigned int rotation)
{
size_t tx_size = tinydrm_spi_max_transfer_size(spi, 0);
@@ -849,7 +863,8 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct
mipi_dbi *mipi,
return -ENOMEM;
}
- return mipi_dbi_init(dev, mipi, pipe_funcs, driver, mode, rotation);
+ return mipi_dbi_init(dev, mipi, pipe_funcs, driver, mode, pixel_fmt,
+rotation);
}
EXPORT_SYMBOL(mipi_dbi_spi_init);
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index d137b16..dda100c 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -13,6 +13,7 @@
#define __LINUX_MIPI_DBI_H
#include
+#include
struct spi_device;
struct gpio_desc;
@@ -33,6 +34,7 @@ struct regulator;
* @tx_buf9_len: Size of tx_buf9.
* @swap_bytes: Swap bytes in buffer before transfer
* @reset: Optional reset gpio
+ * @pixel_fmt: The display memory's pixel format
* @rotation: initial rotation in degrees Counter Clock Wise
* @backlight: backlight device (optional)
* @regulator: power regulator (optional)
@@ -50,6 +52,7 @@ struct mipi_dbi {
size_t tx_buf9_len;
bool swap_bytes;
struct gpio_desc *reset;
+ enum mipi_dcs_pixel_format pixel_fmt;
unsigned int rotation;
struct backlight_device *backlight;
struct regulator *regulator;
@@ -66,11 +69,13 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct
mipi_dbi *mipi,
[PATCH 6/6] ARM: dts: da850-lego-ev3: Add node for LCD display
This adds a new node for the LEGO MINDSTORMS EV3 LCD display.
Signed-off-by: David Lechner
---
arch/arm/boot/dts/da850-lego-ev3.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts
b/arch/arm/boot/dts/da850-lego-ev3.dts
index 45983c0..249b317 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -249,6 +249,15 @@
0x4c 0x0080 0x00f0
>;
};
+
+ ev3_lcd_pins: pinmux_lcd {
+ pinctrl-single,bits = <
+ /* SIMO, GP2[11], GP2[12], CLK */
+ 0x14 0x00188100 0x0000
+ /* GP5[0] */
+ 0x30 0x8000 0xf000
+ >;
+ };
};
&pinconf {
@@ -357,6 +366,21 @@
};
};
+&spi1 {
+ status = "okay";
+ pinctrl-0 = <&ev3_lcd_pins>;
+ pinctrl-names = "default";
+ cs-gpios = <&gpio 44 GPIO_ACTIVE_LOW>;
+
+ display@0{
+ compatible = "lego,ev3-lcd";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ dc-gpios = <&gpio 43 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 80 GPIO_ACTIVE_HIGH>;
+ };
+};
+
&ehrpwm0 {
status = "okay";
};
--
2.7.4
[PATCH 4/6] drm/tinydrm: mipi-panel: refactor to use driver id
This refactors the mipi-panel module to use the driver id for panel-specific
data. This is in preparation for adding additional panels.
Signed-off-by: David Lechner
---
drivers/gpu/drm/tinydrm/mipi-panel.c | 40
include/drm/tinydrm/mipi-dbi.h | 2 ++
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/mipi-panel.c
b/drivers/gpu/drm/tinydrm/mipi-panel.c
index 64344f0..8aa1d8e 100644
--- a/drivers/gpu/drm/tinydrm/mipi-panel.c
+++ b/drivers/gpu/drm/tinydrm/mipi-panel.c
@@ -21,7 +21,18 @@
#include
#include
-static int mipi_panel_init(struct mipi_dbi *mipi)
+enum mipi_panel_type {
+ MIPI_PANEL_TYPE_UNKNOWN,
+ MIPI_PANEL_TYPE_MULTI_INNO_MI0283QT,
+};
+
+struct mipi_panel_info {
+ int (*init)(struct mipi_dbi *mipi);
+ const struct drm_display_mode mode;
+ enum mipi_dcs_pixel_format pixel_fmt;
+};
+
+static int mipi_panel_init_ili9341(struct mipi_dbi *mipi)
{
struct tinydrm_device *tdev = &mipi->tinydrm;
struct device *dev = tdev->drm->dev;
@@ -129,8 +140,12 @@ static const struct drm_simple_display_pipe_funcs
mipi_panel_pipe_funcs = {
.prepare_fb = tinydrm_display_pipe_prepare_fb,
};
-static const struct drm_display_mode mipi_panel_mode = {
- TINYDRM_MODE(320, 240, 58, 43),
+static const struct mipi_panel_info mipi_panel_infos[] = {
+ [MIPI_PANEL_TYPE_MULTI_INNO_MI0283QT] = {
+ .init = mipi_panel_init_ili9341,
+ .mode = { TINYDRM_MODE(320, 240, 58, 43) },
+ .pixel_fmt = MIPI_DCS_PIXEL_FMT_16BIT,
+ },
};
DEFINE_DRM_GEM_CMA_FOPS(mipi_panel_fops);
@@ -156,13 +171,15 @@ static const struct of_device_id mipi_panel_of_match[] = {
MODULE_DEVICE_TABLE(of, mipi_panel_of_match);
static const struct spi_device_id mipi_panel_id[] = {
- { "mi0283qt", 0 },
+ { "mi0283qt", MIPI_PANEL_TYPE_MULTI_INNO_MI0283QT },
{ },
};
MODULE_DEVICE_TABLE(spi, mipi_panel_id);
static int mipi_panel_probe(struct spi_device *spi)
{
+ const struct spi_device_id *id = spi_get_device_id(spi);
+ enum mipi_panel_type type = id->driver_data;
struct device *dev = &spi->dev;
struct tinydrm_device *tdev;
struct mipi_dbi *mipi;
@@ -170,10 +187,17 @@ static int mipi_panel_probe(struct spi_device *spi)
u32 rotation = 0;
int ret;
+ if (type == MIPI_PANEL_TYPE_UNKNOWN) {
+ dev_err(dev, "Unknown panel type\n");
+ return -EINVAL;
+ }
+
mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
if (!mipi)
return -ENOMEM;
+ mipi->init = mipi_panel_infos[type].init;
+
mipi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(mipi->reset)) {
dev_err(dev, "Failed to get gpio 'reset'\n");
@@ -197,12 +221,12 @@ static int mipi_panel_probe(struct spi_device *spi)
device_property_read_u32(dev, "rotation", &rotation);
ret = mipi_dbi_spi_init(spi, mipi, dc, &mipi_panel_pipe_funcs,
- &mipi_panel_driver, &mipi_panel_mode,
- MIPI_DCS_PIXEL_FMT_16BIT, rotation);
+ &mipi_panel_driver,
&mipi_panel_infos[type].mode,
+ mipi_panel_infos[type].pixel_fmt, rotation);
if (ret)
return ret;
- ret = mipi_panel_init(mipi);
+ ret = mipi->init(mipi);
if (ret)
return ret;
@@ -255,7 +279,7 @@ static int __maybe_unused mipi_panel_pm_resume(struct
device *dev)
struct mipi_dbi *mipi = dev_get_drvdata(dev);
int ret;
- ret = mipi_panel_init(mipi);
+ ret = mipi->init(mipi);
if (ret)
return ret;
diff --git a/include/drm/tinydrm/mipi-dbi.h b/include/drm/tinydrm/mipi-dbi.h
index dda100c..f7ae5ae 100644
--- a/include/drm/tinydrm/mipi-dbi.h
+++ b/include/drm/tinydrm/mipi-dbi.h
@@ -25,6 +25,7 @@ struct regulator;
* @spi: SPI device
* @enabled: Pipeline is enabled
* @cmdlock: Command lock
+ * @init: Panel specific callback executing initialization command sequence.
* @command: Bus specific callback executing commands.
* @read_commands: Array of read commands terminated by a zero entry.
* Reading is disabled if this is NULL.
@@ -44,6 +45,7 @@ struct mipi_dbi {
struct spi_device *spi;
bool enabled;
struct mutex cmdlock;
+ int (*init)(struct mipi_dbi *mipi);
int (*command)(struct mipi_dbi *mipi, u8 cmd, u8 *param, size_t num);
const u8 *read_commands;
struct gpio_desc *dc;
--
2.7.4
[PATCH 3/6] drm/tinydrm: rename mi028qt module to mipi-panel
This renames the mi028qt module to mipi-panel so that it can be used for
other types of panels as well. There is no reason to copy a bunch of
boiler-plate code for each panel or controller.
Signed-off-by: David Lechner
---
.../devicetree/bindings/display/mipi-panel.txt | 27 ++
.../bindings/display/multi-inno,mi0283qt.txt | 27 --
MAINTAINERS| 6 +-
drivers/gpu/drm/tinydrm/Kconfig| 12 +-
drivers/gpu/drm/tinydrm/Makefile | 2 +-
drivers/gpu/drm/tinydrm/mi0283qt.c | 283
drivers/gpu/drm/tinydrm/mipi-panel.c | 284 +
7 files changed, 323 insertions(+), 318 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/mipi-panel.txt
delete mode 100644
Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
delete mode 100644 drivers/gpu/drm/tinydrm/mi0283qt.c
create mode 100644 drivers/gpu/drm/tinydrm/mipi-panel.c
diff --git a/Documentation/devicetree/bindings/display/mipi-panel.txt
b/Documentation/devicetree/bindings/display/mipi-panel.txt
new file mode 100644
index 000..01d6ea9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mipi-panel.txt
@@ -0,0 +1,27 @@
+MIPI DBI compatible display panel
+
+Required properties:
+- compatible: "multi-inno,mi0283qt".
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- dc-gpios:D/C pin. The presence/absence of this GPIO determines
+ the panel interface mode (IM[3:0] pins):
+ - present: IM=x110 4-wire 8-bit data serial interface
+ - absent: IM=x101 3-wire 9-bit data serial interface
+- reset-gpios: Reset pin
+- power-supply:A regulator node for the supply voltage.
+- backlight: phandle of the backlight device attached to the panel
+- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
+
+Example:
+ display@0{
+ compatible = "multi-inno,mi0283qt";
+ reg = <0>;
+ spi-max-frequency = <3200>;
+ rotation = <90>;
+ dc-gpios = <&gpio 25 0>;
+ backlight = <&backlight>;
+ };
diff --git a/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
b/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
deleted file mode 100644
index eed48c3..000
--- a/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Multi-Inno MI0283QT display panel
-
-Required properties:
-- compatible: "multi-inno,mi0283qt".
-
-The node for this driver must be a child node of a SPI controller, hence
-all mandatory properties described in ../spi/spi-bus.txt must be specified.
-
-Optional properties:
-- dc-gpios:D/C pin. The presence/absence of this GPIO determines
- the panel interface mode (IM[3:0] pins):
- - present: IM=x110 4-wire 8-bit data serial interface
- - absent: IM=x101 3-wire 9-bit data serial interface
-- reset-gpios: Reset pin
-- power-supply:A regulator node for the supply voltage.
-- backlight: phandle of the backlight device attached to the panel
-- rotation:panel rotation in degrees counter clockwise (0,90,180,270)
-
-Example:
- mi0283qt@0{
- compatible = "multi-inno,mi0283qt";
- reg = <0>;
- spi-max-frequency = <3200>;
- rotation = <90>;
- dc-gpios = <&gpio 25 0>;
- backlight = <&backlight>;
- };
diff --git a/MAINTAINERS b/MAINTAINERS
index f66488d..812ffd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4315,11 +4315,11 @@ M: Dave Airlie
S: Odd Fixes
F: drivers/gpu/drm/mgag200/
-DRM DRIVER FOR MI0283QT
+DRM DRIVER FOR MIPI DBI compatible panels
M: Noralf Trønnes
S: Maintained
-F: drivers/gpu/drm/tinydrm/mi0283qt.c
-F: Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
+F: drivers/gpu/drm/tinydrm/mipi-panel.c
+F: Documentation/devicetree/bindings/display/mipi-panel.txt
DRM DRIVER FOR MSM ADRENO GPU
M: Rob Clark
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 3504c53..394519b 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -12,10 +12,14 @@ menuconfig DRM_TINYDRM
config TINYDRM_MIPI_DBI
tristate
-config TINYDRM_MI0283QT
- tristate "DRM support for MI0283QT"
+config TINYDRM_MIPI_PANEL
+ tristate "DRM support for MIPI DBI compatible display panels"
depends on DRM_TINYDRM && SPI
select TINYDRM_MIPI_DBI
help
- DRM driver for the Multi-Inno MI0283QT display panel
- If M is selected the module will be called mi0283qt.
+ DRM driver for the MIPI DBI compati
[PATCH 2/6] drm/tinydrm: add helpers for ST7586 controllers
This adds helper functions and support for ST7586 controllers. These
controllers have an unusual memory layout where 3 pixels are packed into
1 byte.
+---+-+
| bit | 7 6 5 4 3 2 1 0 |
+---+-+
| pixel | 0 0 0 1 1 1 2 2 |
+---+-+
So, there are a nuber of places in the tinydrm pipline where this format
needs to be taken into consideration.
Signed-off-by: David Lechner
---
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 148 +
drivers/gpu/drm/tinydrm/mipi-dbi.c | 96
include/drm/tinydrm/tinydrm-helpers.h | 6 +
include/video/mipi_display.h | 2 +
4 files changed, 232 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d4cda33..4a36441 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -181,6 +181,154 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
/**
+ * tinydrm_rgb565_to_st7586 - Convert RGB565 to ST7586 clip buffer
+ * @dst: ST7586 destination buffer
+ * @vaddr: RGB565 source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ * @swap: Swap bytes
+ *
+ * The ST7586 controller has a non-standard pixel layout. It is 2-bit grayscale
+ * (or 1-bit monochrome) packed into 3 pixels per byte.
+ *
+ * Note: the @clip x values are modified! They are aligned to the 3 pixel
+ * boundtry and divied by 3 to get the starting and ending byte (+ 1) in the
+ * @dst buffer.
+ */
+void tinydrm_rgb565_to_st7586(u8 *dst, void *vaddr,
+ struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip)
+{
+ size_t len;
+ unsigned int x, y;
+ u16 *src, *buf;
+ u8 val;
+
+ /* 3 pixels per byte, so align to dst byte */
+ clip->x1 -= clip->x1 % 3;
+ clip->x2 = (clip->x2 + 2) / 3 * 3;
+ len = (clip->x2 - clip->x1) * sizeof(u16);
+
+ buf = kmalloc(len, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ for (y = clip->y1; y < clip->y2; y++) {
+ src = vaddr + (y * fb->pitches[0]);
+ src += clip->x1;
+ memcpy(buf, src, len);
+ src = buf;
+ for (x = clip->x1; x < clip->x2; x += 3) {
+ /*
+* TODO: There is probably a better algorithm to get
+* a better downsampling.
+* If red or green is > 50%, set the high bit, which is
+* bright gray. If blue is greater than 50%, set the
+* low bit, which is dark gray.
+*/
+ val = ((*src & 0x8000) >> 8) |
+ ((*src & 0x0400) >> 3) |
+ ((*src & 0x0010) << 2);
+ if (val & 0xC0)
+ val |= 0x20;
+ src++;
+ val |= ((*src & 0x8000) >> 11) |
+ ((*src & 0x0400) >> 6) |
+ ((*src & 0x0010) >> 1);
+ if (val & 0x18)
+ val |= 0x04;
+ src++;
+ val |= ((*src & 0x8000) >> 14) |
+ ((*src & 0x0400) >> 9) |
+ ((*src & 0x0010) >> 4);
+ src++;
+ *dst++ = ~val;
+ }
+ }
+
+ /* now adjust the clip so it applies to dst */
+ clip->x1 /= 3;
+ clip->x2 /= 3;
+
+ kfree(buf);
+}
+EXPORT_SYMBOL(tinydrm_rgb565_to_st7586);
+
+/**
+ * tinydrm_xrgb_to_st7586 - Convert XRGB to ST7586 clip buffer
+ * @dst: ST7586 destination buffer
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ * @swap: Swap bytes
+ *
+ * The ST7586 controller has a non-standard pixel layout. It is 2-bit grayscale
+ * (or 1-bit monochrome) packed into 3 pixels per byte.
+ *
+ * Note: the @clip x values are modified! They are aligned to the 3 pixel
+ * boundtry and divied by 3 to get the starting and ending byte (+ 1) in the
+ * @dst buffer.
+ */
+void tinydrm_xrgb_to_st7586(u8 *dst, void *vaddr,
+ struct drm_framebuffer *fb,
+ struct drm_clip_rect *clip)
+{
+ size_t len;
+ unsigned int x, y;
+ u32 *src, *buf;
+ u8 val;
+
+ /* 3 pixels per byte, so align to dst byte */
+ clip->x1 -= clip->x1 % 3;
+ clip->x2 = (clip->x2 + 2) / 3 * 3;
+ len = (clip->x2 - clip->x1) * sizeof(u32);
+
+ buf = kmalloc(len, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ for (y = clip->y1; y
[PATCH 0/6] Support for LEGO MINDSTORMS EV3 LCD display
The goal of this series is to get the built-in LCD of the LEGO MINDSTORMS EV3 working. But, most of the content here is building up the infrastructure to do that. The controller used in the EV3 uses MIPI commands, but it uses a different memory layout. The current tinydrm stuff is hard-coded for RGB565, so most of the patches are adding support for other memory layouts. I've also made the one existing tinydrm driver generic so that it can work for any MIPI display rather than copying a bunch of boiler-plate code for each panel and/or controller. Once all of this is done, it is really easy to add a new panel. :-) David Lechner (6): drm/tinydrm: Add parameter for MIPI DCS pixel format drm/tinydrm: add helpers for ST7586 controllers drm/tinydrm: rename mi028qt module to mipi-panel drm/tinydrm: mipi-panel: refactor to use driver id drm/tinydrm: add support for LEGO MINDSTORMS EV3 LCD ARM: dts: da850-lego-ev3: Add node for LCD display .../devicetree/bindings/display/mipi-panel.txt | 27 ++ .../bindings/display/multi-inno,mi0283qt.txt | 27 -- MAINTAINERS| 6 +- arch/arm/boot/dts/da850-lego-ev3.dts | 24 ++ drivers/gpu/drm/tinydrm/Kconfig| 13 +- drivers/gpu/drm/tinydrm/Makefile | 2 +- drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 148 drivers/gpu/drm/tinydrm/mi0283qt.c | 282 --- drivers/gpu/drm/tinydrm/mipi-dbi.c | 117 -- drivers/gpu/drm/tinydrm/mipi-panel.c | 395 + include/drm/tinydrm/mipi-dbi.h | 9 +- include/drm/tinydrm/st7586.h | 34 ++ include/drm/tinydrm/tinydrm-helpers.h | 6 + include/video/mipi_display.h | 16 +- 14 files changed, 759 insertions(+), 347 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mipi-panel.txt delete mode 100644 Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt delete mode 100644 drivers/gpu/drm/tinydrm/mi0283qt.c create mode 100644 drivers/gpu/drm/tinydrm/mipi-panel.c create mode 100644 include/drm/tinydrm/st7586.h -- 2.7.4
Re: [PATCH 4/5] mtd: spi-nor: Add driver for Adaptrum Anarion QSPI controller
Hi Alexandru,
[auto build test WARNING on arc/for-next]
[also build test WARNING on v4.13-rc2 next-20170728]
[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/Alexandru-Gagniuc/Initial-support-for-Adaptrum-Anarion-SOC/20170730-013701
base: https://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git for-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/mtd/spi-nor/anarion-quadspi.c: In function 'anarion_spi_nor_read':
>> drivers/mtd/spi-nor/anarion-quadspi.c:335:19: warning: cast to pointer from
>> integer of different size [-Wint-to-pointer-cast]
void *from_xip = (void *)(aspi->xipbase + from);
^
vim +335 drivers/mtd/spi-nor/anarion-quadspi.c
325
326 /* While we could send read commands manually to the flash chip, we'd
have to
327 * get data back through the DATA2 register. That is on the AHB bus,
whereas
328 * XIP reads go over AXI. Hence, we use the memory-mapped flash space
for read.
329 * TODO: Look at using DMA instead of memcpy().
330 */
331 static ssize_t anarion_spi_nor_read(struct spi_nor *nor, loff_t from,
332size_t len, uint8_t *read_buf)
333 {
334 struct anarion_qspi *aspi = nor->priv;
> 335 void *from_xip = (void *)(aspi->xipbase + from);
336
337 aspi_setup_xip_read_chain(aspi, nor);
338 memcpy(read_buf, from_xip, len);
339
340 return len;
341 }
342
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[PATCH v5 1/3] sparc64: Support huge PUD case in get_user_pages
get_user_pages() is used to do direct IO. It already
handles the case where the address range is backed
by PMD huge pages. This patch now adds the case where
the range could be backed by PUD huge pages.
Signed-off-by: Nitin Gupta
---
arch/sparc/include/asm/pgtable_64.h | 15 +++--
arch/sparc/mm/gup.c | 45 -
2 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/arch/sparc/include/asm/pgtable_64.h
b/arch/sparc/include/asm/pgtable_64.h
index 6fbd931..2579f5a 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -687,6 +687,8 @@ static inline unsigned long pmd_write(pmd_t pmd)
return pte_write(pte);
}
+#define pud_write(pud) pte_write(__pte(pud_val(pud)))
+
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
static inline unsigned long pmd_dirty(pmd_t pmd)
{
@@ -823,9 +825,18 @@ static inline unsigned long __pmd_page(pmd_t pmd)
return ((unsigned long) __va(pfn << PAGE_SHIFT));
}
+
+static inline unsigned long pud_page_vaddr(pud_t pud)
+{
+ pte_t pte = __pte(pud_val(pud));
+ unsigned long pfn;
+
+ pfn = pte_pfn(pte);
+
+ return ((unsigned long) __va(pfn << PAGE_SHIFT));
+}
+
#define pmd_page(pmd) virt_to_page((void *)__pmd_page(pmd))
-#define pud_page_vaddr(pud)\
- ((unsigned long) __va(pud_val(pud)))
#define pud_page(pud) virt_to_page((void
*)pud_page_vaddr(pud))
#define pmd_clear(pmdp)(pmd_val(*(pmdp)) = 0UL)
#define pud_present(pud) (pud_val(pud) != 0U)
diff --git a/arch/sparc/mm/gup.c b/arch/sparc/mm/gup.c
index f80cfc6..d809099 100644
--- a/arch/sparc/mm/gup.c
+++ b/arch/sparc/mm/gup.c
@@ -103,6 +103,45 @@ static int gup_huge_pmd(pmd_t *pmdp, pmd_t pmd, unsigned
long addr,
return 1;
}
+static int gup_huge_pud(pud_t *pudp, pud_t pud, unsigned long addr,
+ unsigned long end, int write, struct page **pages,
+ int *nr)
+{
+ struct page *head, *page;
+ int refs;
+
+ if (!(pud_val(pud) & _PAGE_VALID))
+ return 0;
+
+ if (write && !pud_write(pud))
+ return 0;
+
+ refs = 0;
+ page = pud_page(pud) + ((addr & ~PUD_MASK) >> PAGE_SHIFT);
+ head = compound_head(page);
+ do {
+ VM_BUG_ON(compound_head(page) != head);
+ pages[*nr] = page;
+ (*nr)++;
+ page++;
+ refs++;
+ } while (addr += PAGE_SIZE, addr != end);
+
+ if (!page_cache_add_speculative(head, refs)) {
+ *nr -= refs;
+ return 0;
+ }
+
+ if (unlikely(pud_val(pud) != pud_val(*pudp))) {
+ *nr -= refs;
+ while (refs--)
+ put_page(head);
+ return 0;
+ }
+
+ return 1;
+}
+
static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
int write, struct page **pages, int *nr)
{
@@ -141,7 +180,11 @@ static int gup_pud_range(pgd_t pgd, unsigned long addr,
unsigned long end,
next = pud_addr_end(addr, end);
if (pud_none(pud))
return 0;
- if (!gup_pmd_range(pud, addr, next, write, pages, nr))
+ if (unlikely(pud_large(pud))) {
+ if (!gup_huge_pud(pudp, pud, addr, next,
+ write, pages, nr))
+ return 0;
+ } else if (!gup_pmd_range(pud, addr, next, write, pages, nr))
return 0;
} while (pudp++, addr = next, addr != end);
--
2.9.2
[PATCH v5 2/3] sparc64: Add 16GB hugepage support
Adds support for 16GB hugepage size. To use this page size
use kernel parameters as:
default_hugepagesz=16G hugepagesz=16G hugepages=10
Testing:
Tested with the stream benchmark which allocates 48G of
arrays backed by 16G hugepages and does RW operation on
them in parallel.
Orabug: 25362942
Signed-off-by: Nitin Gupta
---
arch/sparc/include/asm/hugetlb.h| 7
arch/sparc/include/asm/page_64.h| 3 +-
arch/sparc/include/asm/pgtable_64.h | 5 +++
arch/sparc/include/asm/tsb.h| 36 ++
arch/sparc/kernel/tsb.S | 2 +-
arch/sparc/kernel/vmlinux.lds.S | 5 +++
arch/sparc/mm/hugetlbpage.c | 74 ++---
arch/sparc/mm/init_64.c | 54 +++
8 files changed, 156 insertions(+), 30 deletions(-)
diff --git a/arch/sparc/include/asm/hugetlb.h b/arch/sparc/include/asm/hugetlb.h
index d1f837d..0ca7caa 100644
--- a/arch/sparc/include/asm/hugetlb.h
+++ b/arch/sparc/include/asm/hugetlb.h
@@ -4,6 +4,13 @@
#include
#include
+#ifdef CONFIG_HUGETLB_PAGE
+struct pud_huge_patch_entry {
+ unsigned int addr;
+ unsigned int insn;
+};
+extern struct pud_huge_patch_entry __pud_huge_patch, __pud_huge_patch_end;
+#endif
void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, pte_t pte);
diff --git a/arch/sparc/include/asm/page_64.h b/arch/sparc/include/asm/page_64.h
index 5961b2d..8ee1f97 100644
--- a/arch/sparc/include/asm/page_64.h
+++ b/arch/sparc/include/asm/page_64.h
@@ -17,6 +17,7 @@
#define HPAGE_SHIFT23
#define REAL_HPAGE_SHIFT 22
+#define HPAGE_16GB_SHIFT 34
#define HPAGE_2GB_SHIFT31
#define HPAGE_256MB_SHIFT 28
#define HPAGE_64K_SHIFT16
@@ -28,7 +29,7 @@
#define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT)
#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
#define REAL_HPAGE_PER_HPAGE (_AC(1,UL) << (HPAGE_SHIFT - REAL_HPAGE_SHIFT))
-#define HUGE_MAX_HSTATE4
+#define HUGE_MAX_HSTATE5
#endif
#ifndef __ASSEMBLY__
diff --git a/arch/sparc/include/asm/pgtable_64.h
b/arch/sparc/include/asm/pgtable_64.h
index 2579f5a..4fefe37 100644
--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -414,6 +414,11 @@ static inline bool is_hugetlb_pmd(pmd_t pmd)
return !!(pmd_val(pmd) & _PAGE_PMD_HUGE);
}
+static inline bool is_hugetlb_pud(pud_t pud)
+{
+ return !!(pud_val(pud) & _PAGE_PUD_HUGE);
+}
+
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
static inline pmd_t pmd_mkhuge(pmd_t pmd)
{
diff --git a/arch/sparc/include/asm/tsb.h b/arch/sparc/include/asm/tsb.h
index 32258e0..acf5506 100644
--- a/arch/sparc/include/asm/tsb.h
+++ b/arch/sparc/include/asm/tsb.h
@@ -195,6 +195,41 @@ extern struct tsb_phys_patch_entry __tsb_phys_patch,
__tsb_phys_patch_end;
nop; \
699:
+ /* PUD has been loaded into REG1, interpret the value, seeing
+* if it is a HUGE PUD or a normal one. If it is not valid
+* then jump to FAIL_LABEL. If it is a HUGE PUD, and it
+* translates to a valid PTE, branch to PTE_LABEL.
+*
+* We have to propagate bits [32:22] from the virtual address
+* to resolve at 4M granularity.
+*/
+#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
+#define USER_PGTABLE_CHECK_PUD_HUGE(VADDR, REG1, REG2, FAIL_LABEL, PTE_LABEL) \
+700: ba 700f;\
+nop; \
+ .section.pud_huge_patch, "ax"; \
+ .word 700b; \
+ nop;\
+ .previous; \
+ brz,pn REG1, FAIL_LABEL; \
+sethi %uhi(_PAGE_PUD_HUGE), REG2; \
+ sllxREG2, 32, REG2; \
+ andcc REG1, REG2, %g0;\
+ be,pt %xcc, 700f; \
+sethi %hi(0x1ffc), REG2; \
+ sllxREG2, 1, REG2; \
+ brgez,pnREG1, FAIL_LABEL; \
+andn REG1, REG2, REG1; \
+ and VADDR, REG2, REG2; \
+ brlz,pt REG1, PTE_LABEL;\
+or REG1, REG2, REG1; \
+700:
+#else
+#define USER_PGTABLE_CHECK_PUD_HUGE(VADDR, REG1, REG2, FAIL_LABEL, PTE_LABEL) \
+ brz,pn REG1, FAIL_LABEL; \
+nop;
+#endif
+
/* PMD has been loaded into REG1, interpret the value, seeing
* if it is a HUGE PMD or a normal one. If it is not valid
* then jump to FAIL_LABEL. If it is a HUGE PMD, and it
@@ -242,6 +277,7 @@ extern struct tsb_phys_patch_entry __tsb_phys_patch,
__tsb_phys_patch_end;
srlxR
[PATCH v5 3/3] sparc64: Cleanup hugepage table walk functions
Flatten out nested code structure in huge_pte_offset()
and huge_pte_alloc().
Signed-off-by: Nitin Gupta
---
arch/sparc/mm/hugetlbpage.c | 54 +
1 file changed, 20 insertions(+), 34 deletions(-)
diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
index 7acb84d..bcd8cdb 100644
--- a/arch/sparc/mm/hugetlbpage.c
+++ b/arch/sparc/mm/hugetlbpage.c
@@ -266,27 +266,19 @@ pte_t *huge_pte_alloc(struct mm_struct *mm,
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
- pte_t *pte = NULL;
pgd = pgd_offset(mm, addr);
pud = pud_alloc(mm, pgd, addr);
if (!pud)
return NULL;
-
if (sz >= PUD_SIZE)
- pte = (pte_t *)pud;
- else {
- pmd = pmd_alloc(mm, pud, addr);
- if (!pmd)
- return NULL;
-
- if (sz >= PMD_SIZE)
- pte = (pte_t *)pmd;
- else
- pte = pte_alloc_map(mm, pmd, addr);
- }
-
- return pte;
+ return (pte_t *)pud;
+ pmd = pmd_alloc(mm, pud, addr);
+ if (!pmd)
+ return NULL;
+ if (sz >= PMD_SIZE)
+ return (pte_t *)pmd;
+ return pte_alloc_map(mm, pmd, addr);
}
pte_t *huge_pte_offset(struct mm_struct *mm,
@@ -295,27 +287,21 @@ pte_t *huge_pte_offset(struct mm_struct *mm,
pgd_t *pgd;
pud_t *pud;
pmd_t *pmd;
- pte_t *pte = NULL;
pgd = pgd_offset(mm, addr);
- if (!pgd_none(*pgd)) {
- pud = pud_offset(pgd, addr);
- if (!pud_none(*pud)) {
- if (is_hugetlb_pud(*pud))
- pte = (pte_t *)pud;
- else {
- pmd = pmd_offset(pud, addr);
- if (!pmd_none(*pmd)) {
- if (is_hugetlb_pmd(*pmd))
- pte = (pte_t *)pmd;
- else
- pte = pte_offset_map(pmd, addr);
- }
- }
- }
- }
-
- return pte;
+ if (pgd_none(*pgd))
+ return NULL;
+ pud = pud_offset(pgd, addr);
+ if (pud_none(*pud))
+ return NULL;
+ if (is_hugetlb_pud(*pud))
+ return (pte_t *)pud;
+ pmd = pmd_offset(pud, addr);
+ if (pmd_none(*pmd))
+ return NULL;
+ if (is_hugetlb_pmd(*pmd))
+ return (pte_t *)pmd;
+ return pte_offset_map(pmd, addr);
}
void set_huge_pte_at(struct mm_struct *mm, unsigned long addr,
--
2.9.2
Re: [PATCH Y.A. RESEND] MAINTAINERS: fix alpha. ordering
On Fri, 2017-07-28 at 15:30 -0700, Linus Torvalds wrote: > On Thu, Jul 27, 2017 at 8:12 PM, Joe Perches wrote: > > > > I think it's better to centralize the MAINTAINERS > > location in /MAINTAINERS/ than spread > > them all over the tree given how many subsystems and > > maintainerships are also spread around the tree. > > > > But the get_maintainers patch I sent allows both > > styles. > > Possibly. I just did realize that we have one de-centralized > maintainers file out there already, and have had for 3+ years: > drivers/staging/unisys/MAINTAINERS. That file should be deleted as it's duplicated in the standard MAINTAINERS file > One thing I like about the decentralized model is that it looks like > we could automate the initial split fairly well based on F: patterns. > Something like: > > - if we have a single F-pattern line, without directory wildcards, > put the entry in the MAINTAINERS directory for that F-pattern That would create more than 750 files.
Re: [PATCH] soc: ti: knav: Add a NULL pointer check for kdev in knav_pool_create
Hi Keerthy,
[auto build test WARNING on keystone/next]
[also build test WARNING on v4.13-rc2 next-20170728]
[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/Keerthy/soc-ti-knav-Add-a-NULL-pointer-check-for-kdev-in-knav_pool_create/20170729-143239
base:
https://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All warnings (new ones prefixed by >>):
drivers/soc/ti/knav_qmss_queue.c: In function 'knav_pool_create':
>> drivers/soc/ti/knav_qmss_queue.c:749:10: warning: return makes pointer from
>> integer without a cast [-Wint-conversion]
return -EPROBE_DEFER;
^
vim +749 drivers/soc/ti/knav_qmss_queue.c
727
728 /**
729 * knav_pool_create() - Create a pool of descriptors
730 * @name- name to give the pool handle
731 * @num_desc- numbers of descriptors in the pool
732 * @region_id - QMSS region id from which the descriptors are
to be
733 *allocated.
734 *
735 * Returns a pool handle on success.
736 * Use IS_ERR_OR_NULL() to identify error values on return.
737 */
738 void *knav_pool_create(const char *name,
739 int num_desc, int region_id)
740 {
741 struct knav_region *reg_itr, *region = NULL;
742 struct knav_pool *pool, *pi;
743 struct list_head *node;
744 unsigned last_offset;
745 bool slot_found;
746 int ret;
747
748 if (!kdev)
> 749 return -EPROBE_DEFER;
750
751 if (!kdev->dev)
752 return ERR_PTR(-ENODEV);
753
754 pool = devm_kzalloc(kdev->dev, sizeof(*pool), GFP_KERNEL);
755 if (!pool) {
756 dev_err(kdev->dev, "out of memory allocating pool\n");
757 return ERR_PTR(-ENOMEM);
758 }
759
760 for_each_region(kdev, reg_itr) {
761 if (reg_itr->id != region_id)
762 continue;
763 region = reg_itr;
764 break;
765 }
766
767 if (!region) {
768 dev_err(kdev->dev, "region-id(%d) not found\n",
region_id);
769 ret = -EINVAL;
770 goto err;
771 }
772
773 pool->queue = knav_queue_open(name, KNAV_QUEUE_GP, 0);
774 if (IS_ERR_OR_NULL(pool->queue)) {
775 dev_err(kdev->dev,
776 "failed to open queue for pool(%s), error
%ld\n",
777 name, PTR_ERR(pool->queue));
778 ret = PTR_ERR(pool->queue);
779 goto err;
780 }
781
782 pool->name = kstrndup(name, KNAV_NAME_SIZE, GFP_KERNEL);
783 pool->kdev = kdev;
784 pool->dev = kdev->dev;
785
786 mutex_lock(&knav_dev_lock);
787
788 if (num_desc > (region->num_desc - region->used_desc)) {
789 dev_err(kdev->dev, "out of descs in region(%d) for
pool(%s)\n",
790 region_id, name);
791 ret = -ENOMEM;
792 goto err_unlock;
793 }
794
795 /* Region maintains a sorted (by region offset) list of pools
796 * use the first free slot which is large enough to accomodate
797 * the request
798 */
799 last_offset = 0;
800 slot_found = false;
801 node = ®ion->pools;
802 list_for_each_entry(pi, ®ion->pools, region_inst) {
803 if ((pi->region_offset - last_offset) >= num_desc) {
804 slot_found = true;
805 break;
806 }
807 last_offset = pi->region_offset + pi->num_desc;
808 }
809 node = &pi->region_inst;
810
811 if (slot_found) {
812 pool->region = region;
813 pool->num_desc = num_desc;
814 pool->region_offset = last_offset;
815 region->used_desc += num_desc;
816 list_add_tail(&am
[PATCH] xen/events: Fix interrupt lost during irq_disable and irq_enable
Here is a device has xen-pirq-MSI interrupt. Dom0 might lost interrupt
during driver irq_disable/irq_enable. Here is the scenario,
1. irq_disable -> disable_dynirq -> mask_evtchn(irq channel)
2. dev interrupt raised by HW and Xen mark its evtchn as pending
3. irq_enable -> startup_pirq -> eoi_pirq ->
clear_evtchn(channel of irq) -> clear pending status
4. consume_one_event process the irq event without pending bit assert
which result in interrupt lost once
5. No HW interrupt raising anymore.
Now use enable_dynirq for enable_pirq of xen_pirq_chip to remove
eoi_pirq when irq_enable.
Signed-off-by: Liu Shuo
---
drivers/xen/events/events_base.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index bae1f5d3..2d43118 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -574,7 +574,7 @@ static void shutdown_pirq(struct irq_data *data)
static void enable_pirq(struct irq_data *data)
{
- startup_pirq(data);
+ enable_dynirq(data);
}
static void disable_pirq(struct irq_data *data)
--
1.9.4
[PATCH] md: replace seq_release_private with seq_release
Since commit f15146380d28 ("fs: seq_file - add event counter to simplify
poll() support"), md.c code has been no longer used the private field of
the struct seq_file, but seq_release_private() has been continued to be
used to release the allocated seq_file. This seems to have been
forgotten. So convert it to use seq_release() instead of
seq_release_private().
Signed-off-by: Cihangir Akturk
---
drivers/md/md.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 8cdca029..6174360 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -7836,7 +7836,7 @@ static const struct file_operations md_seq_fops = {
.open = md_seq_open,
.read = seq_read,
.llseek = seq_lseek,
- .release= seq_release_private,
+ .release= seq_release,
.poll = mdstat_poll,
};
--
2.7.4
Re: [PATCH v2 02/10] drivers/hwmon/occ: Add command transport method for P8 and P9
Hi Edward, [auto build test ERROR on hwmon/hwmon-next] [also build test ERROR on v4.13-rc2 next-20170728] [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/Eddie-James/drivers-hwmon-Add-On-Chip-Controller-OCC-hwmon-driver/20170729-233004 base: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> drivers/hwmon/occ/p8_i2c.c:14:23: fatal error: linux/occ.h: No such file or >> directory #include ^ compilation terminated. vim +14 drivers/hwmon/occ/p8_i2c.c > 14 #include 15 #include 16 #include 17 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
MikeeUSA warning (Re: Yes you have standing to sue GRSecurity.)
Note that this is quite clearly yet another of MikeeUSA's sockpuppets. And you guys really don't want to be caught in another of his troll threads. Yeah, GRsecurity is a problem, but don't let our dear Mikee milk it. -- ⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition: ⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal ⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads affair) ⠈⠳⣄ • use glitches to walk on water
[PATCH] net-next: stmmac: dwmac-sun8i: fix of_table.cocci warnings
Make sure (of/i2c/platform)_device_id tables are NULL terminated
Generated by: scripts/coccinelle/misc/of_table.cocci
Fixes: d5dbe1976d52 ("net-next: stmmac: dwmac-sun8i: choose internal PHY via
compatible")
CC: Corentin Labbe
Signed-off-by: Fengguang Wu
---
url:
https://github.com/0day-ci/linux/commits/Corentin-Labbe/dt-bindings-net-add-compatible-for-internal-sun8i-h3-sun8i-v3s-PHYs/20170729-174950
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
dwmac-sun8i.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -892,6 +892,7 @@ static int sun8i_dwmac_probe(struct plat
static const struct of_device_id internal_phys[] = {
{ .compatible = "allwinner,sun8i-h3-ephy" },
{ .compatible = "allwinner,sun8i-v3s-ephy" },
+ {},
};
ret = stmmac_get_platform_resources(pdev, &stmmac_res);
blk-mq breaks suspend even with runtime PM patch
Hello Jens, Christoph. Unfortunately, even with "block: disable runtime-pm for blk-mq" patch applied blk-mq breaks suspend to RAM for me. It is reproducible on my laptop as well as in a VM. I use complex disk layout involving MD, LUKS and LVM, and managed to get these warnings from VM via serial console when suspend fails: === [ 245.516573] INFO: task kworker/0:1:49 blocked for more than 120 seconds. [ 245.520025] Not tainted 4.12.0-pf4 #1 [ 245.521836] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 245.525612] kworker/0:1 D049 2 0x [ 245.527515] Workqueue: events vmstat_shepherd [ 245.528685] Call Trace: [ 245.529296] __schedule+0x459/0xe40 [ 245.530115] ? kvm_clock_read+0x25/0x40 [ 245.531003] ? ktime_get+0x40/0xa0 [ 245.531819] schedule+0x3d/0xb0 [ 245.532542] ? schedule+0x3d/0xb0 [ 245.533299] schedule_preempt_disabled+0x15/0x20 [ 245.534367] __mutex_lock.isra.5+0x295/0x530 [ 245.535351] __mutex_lock_slowpath+0x13/0x20 [ 245.536362] ? __mutex_lock_slowpath+0x13/0x20 [ 245.537334] mutex_lock+0x25/0x30 [ 245.538118] get_online_cpus.part.14+0x15/0x30 [ 245.539588] get_online_cpus+0x20/0x30 [ 245.540560] vmstat_shepherd+0x21/0xc0 [ 245.541538] process_one_work+0x1de/0x430 [ 245.542364] worker_thread+0x47/0x3f0 [ 245.543042] kthread+0x125/0x140 [ 245.543649] ? process_one_work+0x430/0x430 [ 245.544417] ? kthread_create_on_node+0x70/0x70 [ 245.545737] ret_from_fork+0x25/0x30 [ 245.546490] INFO: task md0_raid10:459 blocked for more than 120 seconds. [ 245.547668] Not tainted 4.12.0-pf4 #1 [ 245.548769] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 245.550133] md0_raid10 D0 459 2 0x [ 245.551092] Call Trace: [ 245.551539] __schedule+0x459/0xe40 [ 245.552163] schedule+0x3d/0xb0 [ 245.552728] ? schedule+0x3d/0xb0 [ 245.553344] md_super_wait+0x6e/0xa0 [md_mod] [ 245.554118] ? wake_bit_function+0x60/0x60 [ 245.554854] md_update_sb.part.60+0x3df/0x840 [md_mod] [ 245.555771] md_check_recovery+0x215/0x4b0 [md_mod] [ 245.556732] raid10d+0x62/0x13c0 [raid10] [ 245.557456] ? schedule+0x3d/0xb0 [ 245.558169] ? schedule+0x3d/0xb0 [ 245.558803] ? schedule_timeout+0x21f/0x330 [ 245.559593] md_thread+0x120/0x160 [md_mod] [ 245.560380] ? md_thread+0x120/0x160 [md_mod] [ 245.561202] ? wake_bit_function+0x60/0x60 [ 245.561975] kthread+0x125/0x140 [ 245.562601] ? find_pers+0x70/0x70 [md_mod] [ 245.563394] ? kthread_create_on_node+0x70/0x70 [ 245.564516] ret_from_fork+0x25/0x30 [ 245.565669] INFO: task dmcrypt_write:487 blocked for more than 120 seconds. [ 245.567151] Not tainted 4.12.0-pf4 #1 [ 245.567946] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 245.569390] dmcrypt_write D0 487 2 0x [ 245.570352] Call Trace: [ 245.570801] __schedule+0x459/0xe40 [ 245.571601] ? preempt_schedule_common+0x1f/0x30 [ 245.572421] ? ___preempt_schedule+0x16/0x18 [ 245.573168] schedule+0x3d/0xb0 [ 245.573733] ? schedule+0x3d/0xb0 [ 245.574378] md_write_start+0xe3/0x270 [md_mod] [ 245.575180] ? wake_bit_function+0x60/0x60 [ 245.575915] raid10_make_request+0x3f/0x140 [raid10] [ 245.576827] md_make_request+0xa9/0x2a0 [md_mod] [ 245.577659] generic_make_request+0x11e/0x2f0 [ 245.578464] dmcrypt_write+0x22d/0x250 [dm_crypt] [ 245.579288] ? dmcrypt_write+0x22d/0x250 [dm_crypt] [ 245.580183] ? wake_up_process+0x20/0x20 [ 245.580875] kthread+0x125/0x140 [ 245.581455] ? kthread+0x125/0x140 [ 245.582064] ? crypt_iv_essiv_dtr+0x70/0x70 [dm_crypt] [ 245.582971] ? kthread_create_on_node+0x70/0x70 [ 245.583772] ret_from_fork+0x25/0x30 [ 245.584424] INFO: task btrfs-transacti:553 blocked for more than 120 seconds. [ 245.585830] Not tainted 4.12.0-pf4 #1 [ 245.586596] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 245.587947] btrfs-transacti D0 553 2 0x [ 245.588922] Call Trace: [ 245.589377] __schedule+0x459/0xe40 [ 245.590062] ? btrfs_submit_bio_hook+0x8c/0x180 [btrfs] [ 245.590976] schedule+0x3d/0xb0 [ 245.591538] ? schedule+0x3d/0xb0 [ 245.592175] io_schedule+0x16/0x40 [ 245.592794] wait_on_page_bit_common+0xe3/0x180 [ 245.593589] ? page_cache_tree_insert+0xc0/0xc0 [ 245.594387] __filemap_fdatawait_range+0x12a/0x1a0 [ 245.595229] filemap_fdatawait_range+0x14/0x30 [ 245.596033] btrfs_wait_ordered_range+0x6b/0x110 [btrfs] [ 245.596998] ? _raw_spin_unlock+0x10/0x30 [ 245.597735] __btrfs_wait_cache_io+0x45/0x1c0 [btrfs] [ 245.599091] btrfs_wait_cache_io+0x2c/0x30 [btrfs] [ 245.600789] btrfs_write_dirty_block_groups+0x206/0x390 [btrfs] [ 245.602068] commit_cowonly_roots+0x221/0x2c0 [btrfs] [ 245.602981] btrfs_commit_transaction+0x3c4/0x900 [btrfs] [ 245.603940] transaction_kthread+0x190/0x1c0 [btrfs] [ 245.604806] kthread+0x125/0x140 [ 245.605398] ? btrfs_clean
Re: Yes you have standing to sue GRSecurity
I have not contributed to the kernel for some time (I have been working on some stuff, but nothing that's been contributed), so I don't know if any of my code would be infringed (or if it's even in the latest kernels). My work was on AGP and VIA drivers, so I am wondering if GRSecurity's patches affect that code? Thanks, PGA On Sat, Jul 29, 2017 at 7:06 AM, wrote: > It has come to my attention that some entities are claiming that you, dear > Linux Hackers, (1)need to go through some foundation or get some permission > from upon high in-order to sue the progenitors of GRSecurity for their > violation of section 6 of the terms underwhich the linux kernel is > distributed (version 2 of the GPL). And, furthermore, that (2)this > foundation has no intention of bringing such a suit. > > (1) is false. > (2) may very well be true. > > You do have standing to sue GRSecurity for their blatant continuing > copyright violation if GRSecurity has made a derivative work of your code > contribution to the Linux Kernel as-long as (a)you have not assigned your > copyrights, and (b)you are not a work-for-hire. > > How do you know if you are a work for hire or if you have signed away your > copyrights? > If you are working for a company and as your job duties you are programming > the linux kernel, there is a good chance that you are a work for hire and > thus the company owns said copyrights. > > How do you know if you signed away your copyrights? Well if you singed a > document transferring ownership of your copyrights for the code you produced > at some point. > > If you are not working for a company while hacking linux and you haven't > assigned your copyrights away then YOU OWN YOUR CONTRIBUTIONS. > > This means most of you hobby hackers, if GRSecurity has modified your code, > YES YOU HAVE STANDING TO SUE. > > Yes your "betters" are lying to you. > You have individual separate standing to sue. > > Yes you SHOULD consult a lawyer of your own. > Yes you SHOULD consider a joint filing with other individual rights-holders > willing to bring suit against GRSecurity for their blatant violation of your > terms, and yes you should consider starting CLASS ACTION since the number of > Linux Kernel Contributors seemingly numbers in the multitudes upon > multitudes upon multitudes. > > And yes, I am an attorney. > But no, I'm not looking for clients. Just correcting some false information > that has been spreading. > > And yes, GRSecurity will try to claim that the linux-kernel is a work of > Joint ownership (so as to shield themselves via procedural law) and yes they > will try to claim fair use (probably de minimus), and yes your Lawyer will > have to respond to these claims. The Joint ownership claim will go down > quickly but it will have to be responded to. De minimus Fair Use depends on > how much code is modified and how signifigant the modifications are. Don't > let anyone but your own legal council dissuade you from bringing suit: > Remember the statute of limitations is only a few years, so the clock is > ticking on the CURRENT violation. > > Also make sure you register your copyright of the version of the > linux-kernel that GRSecurity is using in its violation prior to bringing > suit. The registration must be for the specific version. Yes you can > register after the violation has occurred, however if you have registered > before the violation then you can also pursue recovery of legal fees, pursue > statutory damages, etc. > > > ( NOTE: If you would like to read on how your copyright is being violated by > GRSecurity, Bruce Perens posted a good write-up on his web-page ) > ( > perens.com/blog/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/ > ) > ( There was also a discussion on the linux section of slashdot, and on the > debian user mailing list, and on the dng devuan mailing list and on the > openwall mailing list and the fedora legal mailing list ) > -- Paul G. Allen, BSIT/SE Owner, Sr. Engineer Random Logic Consulting www.randomlogic.com
Re: [RESEND PATCH 2/6] ipc: mqueue: Replace timespec with timespec64
On 2017-07-28 11:52, Deepa Dinamani wrote:
> struct timespec is not y2038 safe. Replace
> all uses of timespec by y2038 safe struct timespec64.
>
> Even though timespec is used here to represent timeouts,
> replace these with timespec64 so that it facilitates
> in verification by creating a y2038 safe kernel image
> that is free of timespec.
>
> The syscall interfaces themselves are not changed as part
> of the patch. They will be part of a different series.
>
> Signed-off-by: Deepa Dinamani
> Cc: Paul Moore
> Cc: Richard Guy Briggs
Looks reasonable to me.
Reviewed-by: Richard Guy Briggs
> ---
> include/linux/audit.h | 6 +++---
> ipc/mqueue.c | 28 ++--
> kernel/audit.h| 2 +-
> kernel/auditsc.c | 12 ++--
> 4 files changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 2150bdccfbab..74d4d4e8e3db 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -351,7 +351,7 @@ extern int __audit_socketcall(int nargs, unsigned long
> *args);
> extern int __audit_sockaddr(int len, void *addr);
> extern void __audit_fd_pair(int fd1, int fd2);
> extern void __audit_mq_open(int oflag, umode_t mode, struct mq_attr *attr);
> -extern void __audit_mq_sendrecv(mqd_t mqdes, size_t msg_len, unsigned int
> msg_prio, const struct timespec *abs_timeout);
> +extern void __audit_mq_sendrecv(mqd_t mqdes, size_t msg_len, unsigned int
> msg_prio, const struct timespec64 *abs_timeout);
> extern void __audit_mq_notify(mqd_t mqdes, const struct sigevent
> *notification);
> extern void __audit_mq_getsetattr(mqd_t mqdes, struct mq_attr *mqstat);
> extern int __audit_log_bprm_fcaps(struct linux_binprm *bprm,
> @@ -412,7 +412,7 @@ static inline void audit_mq_open(int oflag, umode_t mode,
> struct mq_attr *attr)
> if (unlikely(!audit_dummy_context()))
> __audit_mq_open(oflag, mode, attr);
> }
> -static inline void audit_mq_sendrecv(mqd_t mqdes, size_t msg_len, unsigned
> int msg_prio, const struct timespec *abs_timeout)
> +static inline void audit_mq_sendrecv(mqd_t mqdes, size_t msg_len, unsigned
> int msg_prio, const struct timespec64 *abs_timeout)
> {
> if (unlikely(!audit_dummy_context()))
> __audit_mq_sendrecv(mqdes, msg_len, msg_prio, abs_timeout);
> @@ -549,7 +549,7 @@ static inline void audit_mq_open(int oflag, umode_t mode,
> struct mq_attr *attr)
> { }
> static inline void audit_mq_sendrecv(mqd_t mqdes, size_t msg_len,
>unsigned int msg_prio,
> - const struct timespec *abs_timeout)
> + const struct timespec64 *abs_timeout)
> { }
> static inline void audit_mq_notify(mqd_t mqdes,
> const struct sigevent *notification)
> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> index c9ff943f19ab..5be1346a9167 100644
> --- a/ipc/mqueue.c
> +++ b/ipc/mqueue.c
> @@ -668,11 +668,11 @@ static void __do_notify(struct mqueue_inode_info *info)
> }
>
> static int prepare_timeout(const struct timespec __user *u_abs_timeout,
> -struct timespec *ts)
> +struct timespec64 *ts)
> {
> - if (copy_from_user(ts, u_abs_timeout, sizeof(struct timespec)))
> + if (get_timespec64(ts, u_abs_timeout))
> return -EFAULT;
> - if (!timespec_valid(ts))
> + if (!timespec64_valid(ts))
> return -EINVAL;
> return 0;
> }
> @@ -962,7 +962,7 @@ static inline void pipelined_receive(struct wake_q_head
> *wake_q,
>
> static int do_mq_timedsend(mqd_t mqdes, const char __user *u_msg_ptr,
> size_t msg_len, unsigned int msg_prio,
> - struct timespec *ts)
> + struct timespec64 *ts)
> {
> struct fd f;
> struct inode *inode;
> @@ -979,7 +979,7 @@ static int do_mq_timedsend(mqd_t mqdes, const char __user
> *u_msg_ptr,
> return -EINVAL;
>
> if (ts) {
> - expires = timespec_to_ktime(*ts);
> + expires = timespec64_to_ktime(*ts);
> timeout = &expires;
> }
>
> @@ -1080,7 +1080,7 @@ static int do_mq_timedsend(mqd_t mqdes, const char
> __user *u_msg_ptr,
>
> static int do_mq_timedreceive(mqd_t mqdes, char __user *u_msg_ptr,
> size_t msg_len, unsigned int __user *u_msg_prio,
> - struct timespec *ts)
> + struct timespec64 *ts)
> {
> ssize_t ret;
> struct msg_msg *msg_ptr;
> @@ -1092,7 +1092,7 @@ static int do_mq_timedreceive(mqd_t mqdes, char __user
> *u_msg_ptr,
> struct posix_msg_tree_node *new_leaf = NULL;
>
> if (ts) {
> - expires = timespec_to_ktime(*ts);
> + expires = timespec64_to_ktime(*ts);
> timeout = &expires;
> }
>
> @@ -1184,7 +1184,7 @@ SYSCALL_DEFINE5(mq_timedsend, mqd_t, mqdes, const char
> __user *, u_msg_ptr,
>
Re: wake_wide mechanism clarification
On Sat, 2017-07-29 at 01:01 -0700, Joel Fernandes wrote:
> Hi Mike,
>
> I have take spent some time understanding the email thread and
> previous discussions. Unfortunately the second condition we are
> checking for in the wake_wide still didn't make sense to me (mentioned
> below) :-(
>
> On Fri, Jun 30, 2017 at 10:02 AM, Mike Galbraith
> wrote:
> > On Fri, 2017-06-30 at 10:28 -0400, Josef Bacik wrote:
> >> On Thu, Jun 29, 2017 at 08:04:59PM -0700, Joel Fernandes wrote:
> >>
> >> > That makes sense that we multiply slave's flips by a factor because
> >> > its low, but I still didn't get why the factor is chosen to be
> >> > llc_size instead of something else for the multiplication with slave
> >> > (slave * factor).
> >
> >> Yeah I don't know why llc_size was chosen...
> >
> > static void update_top_cache_domain(int cpu)
> > {
> > struct sched_domain_shared *sds = NULL;
> > struct sched_domain *sd;
> > int id = cpu;
> > int size = 1;
> >
> > sd = highest_flag_domain(cpu, SD_SHARE_PKG_RESOURCES);
> > if (sd) {
> > id = cpumask_first(sched_domain_span(sd));
> > size = cpumask_weight(sched_domain_span(sd));
> > sds = sd->shared;
> > }
> >
> > rcu_assign_pointer(per_cpu(sd_llc, cpu), sd);
> > per_cpu(sd_llc_size, cpu) = size;
> >
> > The goal of wake wide was to approximate when pulling would be a futile
> > consolidation effort and counterproductive to scaling. 'course with
> > ever increasing socket size, any 1:N waker is ever more likely to run
> > out of CPU for its one and only self (slamming into scaling wall)
> > before it needing to turn its minions loose to conquer the world.
>
> Actually the original question was why do we have the second condition
> as "master < slave * factor", instead of "master < factor". that's
> what didn't make sense to me. Why don't we return 0 from wake_wide if
> master < factor ?
>
> Infact, as the factor is set to the llc_size, I think the condition
> that makes sense to me is:
>
> if ((master + slave) < llc_size)
> return 0;
That says to me turn affine wakeups off for nearly everything.
> In other words, if the master flips and the slave flips are totally
> higher than the llc_size, then we are most likely waking up too many
> tasks as affine and should then switch to wide to prevent overloading.
The heuristic is mostly about the ratio of flip counts.
> Digging further into the original patch from Michael Wang (I also CC'd
> him), this was the code (before you had changed it to master/slave):
>
> wakee->nr_wakee_switch > factor &&
> waker->nr_wakee_switch > (factor * wakee->nr_wakee_switch)
Yeah, it was originally unidirectional.
> To explain the second condition above, Michael Wang said the following in [1]
>
> "Furthermore, if waker also has a high 'nr_wakee_switch', imply that multiple
> tasks rely on it, then waker's higher latency will damage all of them, pull
> wakee seems to be a bad deal."
Yes, "Furthermore". To detect 1:N, Michael chose llc_size as his N. Is
the one flipping partners at least N/s, and the other about N times as
often? If so, the two may be part of a too big to wisely pull 1:N.
If you have a better idea, by all means, pull it out. Nobody is
attached to wake_wide(), in fact, I suspect Peter hates it. I'm not
fond of it either, it having obvious holes. The only thing it has
going for it is simplicity. Bend it up, replace it, fire away.
> Again I didn't follow why the second condition couldn't just be:
> waker->nr_wakee_switch > factor, or, (waker->nr_wakee_switch +
> wakee->nr_wakee_switch) > factor, based on the above explanation from
> Micheal Wang that I quoted.
> and why he's instead doing the whole multiplication thing there that I
> was talking about earlier: "factor * wakee->nr_wakee_switch".
>
> Rephrasing my question in another way, why are we talking the ratio of
> master/slave instead of the sum when comparing if its > factor? I am
> surely missing something here.
Because the heuristic tries to not demolish 1:1 buddies. Big partner
flip delta means the pair are unlikely to be a communicating pair,
perhaps at high frequency where misses hurt like hell.
> Just taking an example:
>
> Say we have llc_size = 3, we have 3 masters M1, M2 and M3. M1 has 8
> slaves, M2 has 4 slaves and M3 has 4 slaves. Only 1 slave is common
> between all 3 masters. Also to make it a bit more interesting, let s8
> wake up some random task T0. A diagram to show the master/slave
> relation ships could look like:
I don't need the artwork, as soon as you describe a squid orgie in a
bucket with no adult supervision, I can visualize what happens: the
load balancer tries to make pedantically perfect load numbers, caring
not one whit about any of the relationships in either text or graphic
description, stirs bucket vigorously, making squid soup.
IMHO, placement optimization of that is a job for a human, the
scheduler a
