arch/powerpc/platforms/powernv/eeh-powernv.c:230:18: warning: variable 'phb' set but not used
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 9ebcfadb0610322ac537dd7aa5d9cbc2b2894c68
commit: 0e4a459f56c32d3e52ae69a4b447db2f48a65f44 tracing: Remove unnecessary
DEBUG_FS dependency
date: 7 months ago
config: powerpc-randconfig-m031-20200629 (attached as .config)
compiler: powerpc64le-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
arch/powerpc/platforms/powernv/eeh-powernv.c:41:6: warning: no previous
prototype for 'pnv_pcibios_bus_add_device' [-Wmissing-prototypes]
41 | void pnv_pcibios_bus_add_device(struct pci_dev *pdev)
| ^~
arch/powerpc/platforms/powernv/eeh-powernv.c:200:6: warning: no previous
prototype for 'pnv_eeh_enable_phbs' [-Wmissing-prototypes]
200 | void pnv_eeh_enable_phbs(void)
| ^~~
arch/powerpc/platforms/powernv/eeh-powernv.c: In function
'pnv_eeh_post_init':
>> arch/powerpc/platforms/powernv/eeh-powernv.c:230:18: warning: variable 'phb'
>> set but not used [-Wunused-but-set-variable]
230 | struct pnv_phb *phb;
| ^~~
vim +/phb +230 arch/powerpc/platforms/powernv/eeh-powernv.c
4cf17445589932 Gavin Shan 2015-02-16 40
988fc3ba565327 Bryant G. Ly 2017-11-09 @41 void
pnv_pcibios_bus_add_device(struct pci_dev *pdev)
988fc3ba565327 Bryant G. Ly 2017-11-09 42 {
988fc3ba565327 Bryant G. Ly 2017-11-09 43 struct pci_dn *pdn =
pci_get_pdn(pdev);
988fc3ba565327 Bryant G. Ly 2017-11-09 44
b905f8cdca7725 Sam Bobroff2019-08-16 45 if
(eeh_has_flag(EEH_FORCE_DISABLED))
988fc3ba565327 Bryant G. Ly 2017-11-09 46 return;
988fc3ba565327 Bryant G. Ly 2017-11-09 47
1ff8f36fc770dd Sam Bobroff2019-08-16 48 dev_dbg(>dev,
"EEH: Setting up device\n");
988fc3ba565327 Bryant G. Ly 2017-11-09 49
eeh_add_device_early(pdn);
988fc3ba565327 Bryant G. Ly 2017-11-09 50
eeh_add_device_late(pdev);
988fc3ba565327 Bryant G. Ly 2017-11-09 51
eeh_sysfs_add_device(pdev);
988fc3ba565327 Bryant G. Ly 2017-11-09 52 }
988fc3ba565327 Bryant G. Ly 2017-11-09 53
01f3bfb7804ae2 Gavin Shan 2015-02-16 54 static int
pnv_eeh_init(void)
29310e5e860697 Gavin Shan 2013-06-20 55 {
dc561fb9e7e13a Gavin Shan 2014-07-17 56 struct pci_controller
*hose;
dc561fb9e7e13a Gavin Shan 2014-07-17 57 struct pnv_phb *phb;
5cb1f8fdddb747 Russell Currey 2017-06-14 58 int max_diag_size =
PNV_PCI_DIAG_BUF_SIZE;
dc561fb9e7e13a Gavin Shan 2014-07-17 59
e4d54f71d29997 Stewart Smith 2015-12-09 60 if
(!firmware_has_feature(FW_FEATURE_OPAL)) {
e4d54f71d29997 Stewart Smith 2015-12-09 61 pr_warn("%s:
OPAL is required !\n",
0dae27439acc75 Gavin Shan 2014-07-17 62
__func__);
29310e5e860697 Gavin Shan 2013-06-20 63 return -EINVAL;
29310e5e860697 Gavin Shan 2013-06-20 64 }
29310e5e860697 Gavin Shan 2013-06-20 65
05b1721d9f4993 Gavin Shan 2014-07-17 66 /* Set probe mode */
05b1721d9f4993 Gavin Shan 2014-07-17 67
eeh_add_flag(EEH_PROBE_MODE_DEV);
29310e5e860697 Gavin Shan 2013-06-20 68
dc561fb9e7e13a Gavin Shan 2014-07-17 69 /*
dc561fb9e7e13a Gavin Shan 2014-07-17 70* P7IOC blocks PCI
config access to frozen PE, but PHB3
dc561fb9e7e13a Gavin Shan 2014-07-17 71* doesn't do that. So
we have to selectively enable I/O
dc561fb9e7e13a Gavin Shan 2014-07-17 72* prior to collecting
error log.
dc561fb9e7e13a Gavin Shan 2014-07-17 73*/
dc561fb9e7e13a Gavin Shan 2014-07-17 74
list_for_each_entry(hose, _list, list_node) {
dc561fb9e7e13a Gavin Shan 2014-07-17 75 phb =
hose->private_data;
dc561fb9e7e13a Gavin Shan 2014-07-17 76
dc561fb9e7e13a Gavin Shan 2014-07-17 77 if (phb->model
== PNV_PHB_MODEL_P7IOC)
dc561fb9e7e13a Gavin Shan 2014-07-17 78
eeh_add_flag(EEH_ENABLE_IO_FOR_LOG);
2aa5cf9e48f2f3 Gavin Shan 2014-11-25 79
5cb1f8fdddb747 Russell Currey 2017-06-14 80 if
(phb->diag_data_size > max_diag_size)
5cb1f8fdddb747 Russell Currey 2017-06-14 81
max_diag_size = phb->diag_data_size;
5cb1f8fdddb747 Russell Currey 2017-06-14 82
2aa5cf9e48f2f3 Gavin Shan 2014-11-25 83 /*
2aa5cf9e48f2f3 Gavin Shan 2014-11-25 84* PE#0 should
be regarded as valid by EEH core
2aa5cf9e48f2f3 Gavin Shan 2014-11-25 85
Re: [PATCH net] lib: packing: add documentation for pbuflen argument
From: Vladimir Oltean
Date: Sun, 28 Jun 2020 17:49:35 +0300
> Fixes sparse warning:
>
> Function parameter or member 'pbuflen' not described in 'packing'
>
> Fixes: 554aae35007e ("lib: Add support for generic packing operations")
> Signed-off-by: Vladimir Oltean
> ---
> Hi David, since the original "packing" submission went in through your
> tree, could you please take this patch as well?
Sure, applied, thank you.
Re: [PATCH net] bridge: mrp: Fix endian conversion and some other warnings
From: Horatiu Vultur
Date: Sun, 28 Jun 2020 15:45:16 +0200
> The following sparse warnings are fixed:
> net/bridge/br_mrp.c:106:18: warning: incorrect type in assignment (different
> base types)
> net/bridge/br_mrp.c:106:18:expected unsigned short [usertype]
> net/bridge/br_mrp.c:106:18:got restricted __be16 [usertype]
> net/bridge/br_mrp.c:281:23: warning: incorrect type in argument 1 (different
> modifiers)
> net/bridge/br_mrp.c:281:23:expected struct list_head *entry
> net/bridge/br_mrp.c:281:23:got struct list_head [noderef] *
> net/bridge/br_mrp.c:332:28: warning: incorrect type in argument 1 (different
> modifiers)
> net/bridge/br_mrp.c:332:28:expected struct list_head *new
> net/bridge/br_mrp.c:332:28:got struct list_head [noderef] *
> net/bridge/br_mrp.c:332:40: warning: incorrect type in argument 2 (different
> modifiers)
> net/bridge/br_mrp.c:332:40:expected struct list_head *head
> net/bridge/br_mrp.c:332:40:got struct list_head [noderef] *
> net/bridge/br_mrp.c:682:29: warning: incorrect type in argument 1 (different
> modifiers)
> net/bridge/br_mrp.c:682:29:expected struct list_head const *head
> net/bridge/br_mrp.c:682:29:got struct list_head [noderef] *
>
> Reported-by: kernel test robot
> Fixes: 2f1a11ae11d222 ("bridge: mrp: Add MRP interface.")
> Fixes: 4b8d7d4c599182 ("bridge: mrp: Extend bridge interface")
> Fixes: 9a9f26e8f7ea30 ("bridge: mrp: Connect MRP API with the switchdev API")
> Signed-off-by: Horatiu Vultur
Applied, thank you.
Re: [PATCH RFC 0/5] Introduced new Cadence USBSSP DRD Driver.
On 20-06-26 07:19:56, Pawel Laszczak wrote: > Hi Felipe, > > > > >Hi, > > > >Pawel Laszczak writes: > >> This patch introduce new Cadence USBSS DRD driver to linux kernel. > >> > >> The Cadence USBSS DRD Controller is a highly configurable IP Core which > >> can be instantiated as Dual-Role Device (DRD), Peripheral Only and > >> Host Only (XHCI)configurations. > >> > >> The current driver has been validated with FPGA burned. We have support > >> for PCIe bus, which is used on FPGA prototyping. > >> > >> The host side of USBSS-DRD controller is compliance with XHCI > >> specification, so it works with standard XHCI Linux driver. > >> > >> The host side of USBSS DRD controller is compliant with XHCI. > >> The architecture for device side is almost the same as for host side, > >> and most of the XHCI specification can be used to understand how > >> this controller operates. > >> > >> This controller and driver support Full Speed, Hight Speed, Supper Speed > >> and Supper Speed Plus USB protocol. > >> > >> The prefix cdnsp used in driver has chosen by analogy to cdn3 driver. > >> The last letter of this acronym means PLUS. The formal name of controller > >> is USBSSP but it's to generic so I've decided to use CDNSP. > >> > >> The patch 1: adds DT binding. > >> The patch 2: adds PCI to platform wrapper used on Cadnece testing > >> platform. It is FPGA based on platform. > >> The patches 3-5: add the main part of driver and has been intentionally > >> split into 3 part. In my opinion such division should not > >> affect understanding and reviewing the driver, and cause that > >> main patch (4/5) is little smaller. Patch 3 introduces main > >> header file for driver, 4 is the main part that implements all > >> functionality of driver and 5 introduces tracepoints. > > > >I'm more interested in how is this different from CDNS3. Aren't they SW > >compatible? > > In general, the controller can be split into 2 part- DRD part and the rest > UDC. > > The second part UDC which consist gadget.c, ring.c and mem.c file is > completely different. > > The DRD part contains drd.c and core.c. > cdnsp drd.c is similar to cdns3 drd.c but it's little different. CDNSP has > similar, but has different register space. > Some register was moved, some was removed and some was added. > > core.c is very similar and eventually could be common for both drivers. I > thought about this but > I wanted to avoid interfering with cdns3 driver at this point CDNSP is still > under testing and > CDNS3 is used by some products on the market. Pawel, I suggest adding CDNSP at driver/staging first since it is still under testing. When you are thinking the driver (as well as hardware) are mature, you could try to add gadget part (eg, gadget-v2) and make necessary changes for core.c. -- Thanks, Peter Chen
Re: [PATCH net-next v4 0/5] hinic: add some ethtool ops support
From: Luo bin Date: Sun, 28 Jun 2020 20:36:19 +0800 > patch #1: support to set and get pause params with > "ethtool -A/a" cmd > patch #2: support to set and get irq coalesce params with > "ethtool -C/c" cmd > patch #3: support to do self test with "ethtool -t" cmd > patch #4: support to identify physical device with "ethtool -p" cmd > patch #5: support to get eeprom information with "ethtool -m" cmd Series applied, thank you.
[PATCH v2] ext4: fix direct I/O read error
Fixes: 9fe55eea7e4b ("Fix race when checking i_size on direct i/o read").
This commit caused ext4 direct I/O read error when the read size is not
alignment with block size.
Then, I will use a test to explain the error.
(1) Make the file that is not alignment with block size:
$dd if=/dev/zero of=./test.jar bs=1000 count=3
(2) I wrote a test script named "direct_io_read_file.c" as following:
#include
#include
#include
#include
#include
#include
#include
#define BUF_SIZE 1024
int main()
{
int fd;
int ret;
unsigned char *buf;
ret = posix_memalign((void **), 512, BUF_SIZE);
if (ret) {
perror("posix_memalign failed");
exit(1);
}
fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755);
if (fd < 0){
perror("open ./test.jar failed");
exit(1);
}
do {
ret = read(fd, buf, BUF_SIZE);
printf("ret=%d\n",ret);
if (ret < 0) {
perror("write test.jar failed");
}
} while (ret > 0);
free(buf);
close(fd);
}
(3) Compiling the script:
$gcc direct_io_read_file.c -D_GNU_SOURCE
(4) Exec the script:
$./a.out
The result is as following:
ret=1024
ret=1024
ret=952
ret=-1
write test.jar failed: Invalid argument.
I have tested this script on XFS filesystem, XFS does not have
this problem, because XFS use iomap_dio_rw() to do direct I/O
read. And the comparing between read offset and file size is done
in iomap_dio_rw(), the code is as following:
if (pos < size) {
retval = filemap_write_and_wait_range(mapping, pos,
pos + iov_length(iov, nr_segs) - 1);
if (!retval) {
retval = mapping->a_ops->direct_IO(READ, iocb,
iov, pos, nr_segs);
}
...
}
Only when "pos < size", direct I/O can be done, or 0 will be return.
I have tested my fix patch, it is up to the mustard of EINVAL in
man2(read) as following:
#include
ssize_t read(int fd, void *buf, size_t count);
EINVAL
fd is attached to an object which is unsuitable for reading;
or the file was opened with the O_DIRECT flag, and either the
address specified in buf, the value specified in count, or the
current file offset is not suitably aligned.
So I think this patch can be applied to fix ext4 direct I/O error.
However Ext4 introduces direct I/O read using iomap infrastructure
on kernel 5.5, the patch is commit
("ext4: introduce direct I/O read using iomap infrastructure"),
then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct
I/O read. So this problem does not exist on kernel 5.5 for Ext4.
>From above description, we can see this problem exists on all the kernel
versions between kernel 3.14 and kernel 5.4. Please apply this patch
on these kernel versions, or please use the method on kernel 5.5 to fix
this problem. Thanks.
Co-developed-by: Wang Long
Signed-off-by: Wang Long
Signed-off-by: Jiang Ying
---
fs/ext4/inode.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 516faa2..d514ff5 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3821,6 +3821,12 @@ static ssize_t ext4_direct_IO_read(struct kiocb *iocb,
struct iov_iter *iter)
struct inode *inode = mapping->host;
size_t count = iov_iter_count(iter);
ssize_t ret;
+ loff_t offset = iocb->ki_pos;
+ loff_t size;
+
+ size = i_size_read(inode);
+ if (offset >= size)
+ return 0;
/*
* Shared inode_lock is enough for us - it protects against concurrent
--
1.8.3.1
Re: [PATCH] rtlwifi/*/dm.c: Use const in swing_table declarations
On Mon, 2020-06-29 at 11:12 +0800, Pkshih wrote:
> On Sun, 2020-06-28 at 19:51 -0700, j...@perches.com wrote:
> > On 2020-06-28 19:09, Pkshih wrote:
> > > On Sun, 2020-06-28 at 03:17 -0700, Joe Perches wrote:
> > >
> > > Use 'rtlwifi:' as subject title prefix is enough, likes
> > > rtlwifi: Use const in swing_table declarations
> >
> > We disagree.
> >
> > I like knowing what content is changed via patch subject lines
> > as there are 3 rtlwifi drivers being changed by this one patch.
>
> If 3 drivers are needed to be listed, I'd use below subject
>
> "rtlwifi: Use const in rtl8188ee/rtl8723be/rtl8821ae swing_table declarations"
>
> >
> > But your choice, you can change it if you choose.
> >
> > >> Reduce data usage about 1KB by using const.
> > []
> > > Please remove below type casting:
> > >
> > > @@ -1872,10 +1872,10 @@ static void
> > > rtl8821ae_get_delta_swing_table(struct
> > > ieee80211_hw *hw,
> > > *up_b = rtl8821ae_delta_swing_table_idx_5gb_p[2];
> > > *down_b = rtl8821ae_delta_swing_table_idx_5gb_n[2];
> > > } else {
> > > - *up_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
> > > - *down_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
> > > - *up_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
> > > - *down_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
> > > + *up_a = rtl8818e_delta_swing_table_idx_24gb_p;
> > > + *down_a = rtl8818e_delta_swing_table_idx_24gb_n;
> > > + *up_b = rtl8818e_delta_swing_table_idx_24gb_p;
> > > + *down_b = rtl8818e_delta_swing_table_idx_24gb_n;
> >
> > The compiler is quiet about this so I believe this to be
> > an unrelated change and whitespace correction.
>
> I know compiler doesn't warn this, but it looks wired to cast 'const u8 *'
> to 'u8 *' to 'const u8 *'.
>
>
> >
> > Of course you could modify it if you choose.
> >
> > btw: There's an unnecessary return at the 2nd instance
> > of this cast removal too.
>
> It seems like to copy from rtl8812ae_get_delta_swing_table(), so
> I can remove it by another patch.
>
Two patches are sent:
rtlwifi: 8821ae: remove unused path B parameters from swing table
rtlwifi: Use const in 8188ee/8723be/8821ae swing_table declarations
---
Thanks
PK
[PATCH v1 1/2] ipw2100: use generic power management
With legacy PM, drivers themselves were responsible for managing the
device's power states and takes care of register states.
After upgrading to the generic structure, PCI core will take care of
required tasks and drivers should do only device-specific operations.
The driver was invoking PCI helper functions like pci_save/restore_state(),
pci_enable/disable_device() and pci_set_power_state(), which is not
recommended.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 31 +---
1 file changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index 624fe721e2b5..57ce55728808 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -6397,10 +6397,9 @@ static void ipw2100_pci_remove_one(struct pci_dev
*pci_dev)
IPW_DEBUG_INFO("exit\n");
}
-#ifdef CONFIG_PM
-static int ipw2100_suspend(struct pci_dev *pci_dev, pm_message_t state)
+static int __maybe_unused ipw2100_suspend(struct device *dev_d)
{
- struct ipw2100_priv *priv = pci_get_drvdata(pci_dev);
+ struct ipw2100_priv *priv = dev_get_drvdata(dev_d);
struct net_device *dev = priv->net_dev;
IPW_DEBUG_INFO("%s: Going into suspend...\n", dev->name);
@@ -6414,10 +6413,6 @@ static int ipw2100_suspend(struct pci_dev *pci_dev,
pm_message_t state)
/* Remove the PRESENT state of the device */
netif_device_detach(dev);
- pci_save_state(pci_dev);
- pci_disable_device(pci_dev);
- pci_set_power_state(pci_dev, PCI_D3hot);
-
priv->suspend_at = ktime_get_boottime_seconds();
mutex_unlock(>action_mutex);
@@ -6425,11 +6420,11 @@ static int ipw2100_suspend(struct pci_dev *pci_dev,
pm_message_t state)
return 0;
}
-static int ipw2100_resume(struct pci_dev *pci_dev)
+static int __maybe_unused ipw2100_resume(struct device *dev_d)
{
+ struct pci_dev *pci_dev = to_pci_dev(dev_d);
struct ipw2100_priv *priv = pci_get_drvdata(pci_dev);
struct net_device *dev = priv->net_dev;
- int err;
u32 val;
if (IPW2100_PM_DISABLED)
@@ -6439,16 +6434,6 @@ static int ipw2100_resume(struct pci_dev *pci_dev)
IPW_DEBUG_INFO("%s: Coming out of suspend...\n", dev->name);
- pci_set_power_state(pci_dev, PCI_D0);
- err = pci_enable_device(pci_dev);
- if (err) {
- printk(KERN_ERR "%s: pci_enable_device failed on resume\n",
- dev->name);
- mutex_unlock(>action_mutex);
- return err;
- }
- pci_restore_state(pci_dev);
-
/*
* Suspend/Resume resets the PCI configuration space, so we have to
* re-disable the RETRY_TIMEOUT register (0x41) to keep PCI Tx retries
@@ -6473,7 +6458,6 @@ static int ipw2100_resume(struct pci_dev *pci_dev)
return 0;
}
-#endif
static void ipw2100_shutdown(struct pci_dev *pci_dev)
{
@@ -6539,15 +6523,14 @@ static const struct pci_device_id
ipw2100_pci_id_table[] = {
MODULE_DEVICE_TABLE(pci, ipw2100_pci_id_table);
+static SIMPLE_DEV_PM_OPS(ipw2100_pm_ops, ipw2100_suspend, ipw2100_resume);
+
static struct pci_driver ipw2100_pci_driver = {
.name = DRV_NAME,
.id_table = ipw2100_pci_id_table,
.probe = ipw2100_pci_init_one,
.remove = ipw2100_pci_remove_one,
-#ifdef CONFIG_PM
- .suspend = ipw2100_suspend,
- .resume = ipw2100_resume,
-#endif
+ .driver.pm = _pm_ops,
.shutdown = ipw2100_shutdown,
};
--
2.27.0
[PATCH v1 2/2] ipw2200: use generic power management
With legacy PM, drivers themselves were responsible for managing the
device's power states and takes care of register states.
After upgrading to the generic structure, PCI core will take care of
required tasks and drivers should do only device-specific operations.
The driver was invoking PCI helper functions like pci_save/restore_state(),
pci_enable/disable_device() and pci_set_power_state(), which is not
recommended.
Compile-tested only.
Signed-off-by: Vaibhav Gupta
---
drivers/net/wireless/intel/ipw2x00/ipw2200.c | 30 +---
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 661e63bfc892..39ff3a426092 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -11838,10 +11838,9 @@ static void ipw_pci_remove(struct pci_dev *pdev)
free_firmware();
}
-#ifdef CONFIG_PM
-static int ipw_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+static int __maybe_unused ipw_pci_suspend(struct device *dev_d)
{
- struct ipw_priv *priv = pci_get_drvdata(pdev);
+ struct ipw_priv *priv = dev_get_drvdata(dev_d);
struct net_device *dev = priv->net_dev;
printk(KERN_INFO "%s: Going into suspend...\n", dev->name);
@@ -11852,33 +11851,20 @@ static int ipw_pci_suspend(struct pci_dev *pdev,
pm_message_t state)
/* Remove the PRESENT state of the device */
netif_device_detach(dev);
- pci_save_state(pdev);
- pci_disable_device(pdev);
- pci_set_power_state(pdev, pci_choose_state(pdev, state));
-
priv->suspend_at = ktime_get_boottime_seconds();
return 0;
}
-static int ipw_pci_resume(struct pci_dev *pdev)
+static int __maybe_unused ipw_pci_resume(struct device *dev_d)
{
+ struct pci_dev *pdev = to_pci_dev(dev_d);
struct ipw_priv *priv = pci_get_drvdata(pdev);
struct net_device *dev = priv->net_dev;
- int err;
u32 val;
printk(KERN_INFO "%s: Coming out of suspend...\n", dev->name);
- pci_set_power_state(pdev, PCI_D0);
- err = pci_enable_device(pdev);
- if (err) {
- printk(KERN_ERR "%s: pci_enable_device failed on resume\n",
- dev->name);
- return err;
- }
- pci_restore_state(pdev);
-
/*
* Suspend/Resume resets the PCI configuration space, so we have to
* re-disable the RETRY_TIMEOUT register (0x41) to keep PCI Tx retries
@@ -11900,7 +11886,6 @@ static int ipw_pci_resume(struct pci_dev *pdev)
return 0;
}
-#endif
static void ipw_pci_shutdown(struct pci_dev *pdev)
{
@@ -11912,16 +11897,15 @@ static void ipw_pci_shutdown(struct pci_dev *pdev)
pci_disable_device(pdev);
}
+static SIMPLE_DEV_PM_OPS(ipw_pci_pm_ops, ipw_pci_suspend, ipw_pci_resume);
+
/* driver initialization stuff */
static struct pci_driver ipw_driver = {
.name = DRV_NAME,
.id_table = card_ids,
.probe = ipw_pci_probe,
.remove = ipw_pci_remove,
-#ifdef CONFIG_PM
- .suspend = ipw_pci_suspend,
- .resume = ipw_pci_resume,
-#endif
+ .driver.pm = _pci_pm_ops,
.shutdown = ipw_pci_shutdown,
};
--
2.27.0
[PATCH v1 0/2] ipw2x00: use generic power management
Linux Kernel Mentee: Remove Legacy Power Management. The purpose of this patch series is to remove legacy power management callbacks from amd ethernet drivers. The callbacks performing suspend() and resume() operations are still calling pci_save_state(), pci_set_power_state(), etc. and handling the power management themselves, which is not recommended. The conversion requires the removal of the those function calls and change the callback definition accordingly and make use of dev_pm_ops structure. All patches are compile-tested only. Vaibhav Gupta (2): ipw2100: use generic power management ipw2200: use generic power management drivers/net/wireless/intel/ipw2x00/ipw2100.c | 31 +--- drivers/net/wireless/intel/ipw2x00/ipw2200.c | 30 +-- 2 files changed, 14 insertions(+), 47 deletions(-) -- 2.27.0
Re: wait_on_page_bit_common(TASK_KILLABLE, EXCLUSIVE) can miss wakeup?
Excerpts from Linus Torvalds's message of June 28, 2020 3:39 pm:
> On Fri, Jun 26, 2020 at 8:43 AM Peter Zijlstra wrote:
>>
>> I ended up with something like the below.. but it is too warm to think
>> properly.
>>
>> I don't particularly like WQ_FLAG_PAGEWAITERS, but I liked open-coding
>> all that even less.
>
> Ugh.
>
> I think I have a much simpler approach, actually.
>
> So the *problem* is purely around that
>
> if (behavior == EXCLUSIVE) {
> if (!test_and_set_bit_lock(bit_nr, >flags))
> break;
> } else ..
>
> and in particular it is purely *after* that test_and_set_bit_lock()
> case. We have two cases:
>
> (a) *If* we get the lock there, we're good, and all done, and we have
> the lock. We don't care about any other wakeups, because they'll be
> stale anyway (the thing that released the lock that we just took) and
> because we got the lock, no other exclusive waiters should be woken up
> anyway (and we will in turn wake up any waiters when we release it)
>
> (b) we did *not* get the lock, because somebody else got it and is
> about to immediately unlock again. And that _future_ wakeup that they
> send might get lost because it might end up targeting us (but we might
> just exit and not care).
>
> Agreed?
>
> So the only case that really matters is that we didn't get the lock,
> but we must *not* be woken up afterwards.
>
> So how about the attached trivial two-liner? We solve the problem by
> simply marking ourselves TASK_RUNNING, which means that we won't be
> counted as an exclusive wakeup.
>
> Ok, so the "one" line to do that is that is actually two lines:
>
> __set_current_state(TASK_RUNNING);
> smp_mb__before_atomic();
>
> and there's four lines of comments to go with it, but it really is
> very simple: if we do that before we do the test_and_set_bit_lock(),
> no wakeups will be lost, because we won't be sleeping for that wakeup.
>
> I'm not entirely happy about that "smp_mb__before_atomic()". I think
> it's right in practice that test_and_set_bit_lock() (when it actually
> does a write) has at LEAST atomic seqmantics, so I think it's good.
> But it's not pretty.
>
> But I don't want to use a heavy
>
> set_current_state(TASK_RUNNING);
> if (!test_and_set_bit_lock(bit_nr, >flags)) ..
>
> sequence, because at least on x86, that test_and_set_bit_lock()
> already has a memory barrier in it, so the extra memory barrier from
> set_current_state() is all kinds of pointless.
>
> Hmm?
Wow good catch. Does bit_is_set even have to be true? If it's woken due
to a signal, it may still be on the waitqueue right? I think your patch
works, but it looks like a pretty standard variant of "don't lose
wakeups" bug.
prepare_to_wait_event() has a pretty good pattern (and comment), I would
favour using that (test the signal when inserting on the waitqueue).
@@ -1133,6 +1133,15 @@ static inline int
wait_on_page_bit_common(wait_queue_head_t *q,
for (;;) {
spin_lock_irq(>lock);
+ if (signal_pending_state(state, current)) {
+ /* Must not lose an exclusive wake up, see
+* prepare_to_wait_event comment */
+ list_del_init(>entry);
+ spin_unlock_irq(>lock);
+ ret = -EINTR;
+ break;
+ }
+
if (likely(list_empty(>entry))) {
__add_wait_queue_entry_tail(q, wait);
SetPageWaiters(page);
@@ -1157,11 +1166,6 @@ static inline int
wait_on_page_bit_common(wait_queue_head_t *q,
break;
}
- if (signal_pending_state(state, current)) {
- ret = -EINTR;
- break;
- }
-
if (behavior == DROP) {
/*
* We can no longer safely access page->flags:
- mutex_lock_common does the signal check under its wait queue lock.
- rwsem looks like it does it backward and checks if it was woken if it
got a signal and tries to handle it that way (hopefully okay, I prefer
the standard pattern).
- futex unqueues and tests for wakeup before testing signal.
Etc. And it's not even exclusive to signals of course, those are just
the typical asynchronous thing that would wake us without removing from
the wait queue. Bit of a shame there is no standard pattern to follow
though.
I wonder how you could improve that. finish_wait could WARN_ON an
exclusive waiter being found on the queue?
@@ -377,6 +377,7 @@ void finish_wait(struct wait_queue_head *wq_head, struct
wait_queue_entry *wq_en
*the list).
*/
if (!list_empty_careful(_entry->entry)) {
+ WARN_ON(wq_entry->flags & WQ_FLAG_EXCLUSIVE);
spin_lock_irqsave(_head->lock, flags);
[PATCH -next] ASoC: Documentation: fix reference to renamed source file
From: Randy Dunlap sound/soc/soc-io.c was merged into sound/soc/soc-component.c, so fixup the Documentation to use the updated file name. Error: Cannot open file ../sound/soc/soc-io.c WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno ../sound/soc/soc-io.c' failed with return code 1 Signed-off-by: Randy Dunlap Cc: Kuninori Morimoto Cc: Mark Brown --- Documentation/sound/kernel-api/alsa-driver-api.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200626.orig/Documentation/sound/kernel-api/alsa-driver-api.rst +++ linux-next-20200626/Documentation/sound/kernel-api/alsa-driver-api.rst @@ -99,7 +99,7 @@ ASoC Core API .. kernel-doc:: include/sound/soc.h .. kernel-doc:: sound/soc/soc-core.c .. kernel-doc:: sound/soc/soc-devres.c -.. kernel-doc:: sound/soc/soc-io.c +.. kernel-doc:: sound/soc/soc-component.c .. kernel-doc:: sound/soc/soc-pcm.c .. kernel-doc:: sound/soc/soc-ops.c .. kernel-doc:: sound/soc/soc-compress.c
[RFC PATCH 2/6] riscv: dts: sifive: Add DT support for PMU
Add performance monitor unit DT node in SiFive Fu540 soc-specific DT
file. This pmu node passes the dtbs_check verification.
Signed-off-by: Zong Li
---
arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
index 7db861053483..824351fe2a57 100644
--- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
+++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
@@ -283,4 +283,17 @@ gpio: gpio@1006 {
status = "disabled";
};
};
+ pmu {
+ compatible = "riscv,pmu";
+ riscv,width-base-cntr = <64>;
+ riscv,width-event-cntr = <40>;
+ riscv,n-event-cntr = <2>;
+ riscv,hw-event-map = <0x0 0x0
+ 0x1 0x1
+ 0x3 0x0202
+ 0x4 0x4000
+ 0x5 0x2001>;
+ riscv,hw-cache-event-map = <0x010201 0x0102
+ 0x010204 0x0802>;
+ };
};
--
2.27.0
[RFC PATCH 0/6] Support raw event and DT for perf on RISC-V
This patch set adds raw event support on RISC-V. In addition, we introduce the DT mechanism to make our perf more generic and common. Currently, we set the hardware events by writing the mhpmeventN CSRs, it would raise an illegal instruction exception and trap into m-mode to emulate event selector CSRs access. It doesn't make sense because we shouldn't write the m-mode CSRs in s-mode. Ideally, we should set event selector through standard SBI call or the shadow CSRs of s-mode. We have prepared a proposal of a new SBI extension, called "PMU SBI extension", but we also discussing the feasibility of accessing these PMU CSRs on s-mode at the same time, such as delegation mechanism, so I was wondering if we could use SBI calls first and make the PMU SBI extension as legacy when s-mode access mechanism is accepted by Foundation? or keep the current situation to see what would happen in the future. This patch set also introduces the DT mechanism, we don't want to add too much platform-dependency code in perf like other architectures, so we put the mapping of generic hardware events to DT, then we can easy to transfer generic hardware events to vendor's own hardware events without any platfrom-dependency stuff in our perf. Zong Li (6): dt-bindings: riscv: Add YAML documentation for PMU riscv: dts: sifive: Add DT support for PMU riscv: add definition of hpmcounter CSRs riscv: perf: Add raw event support riscv: perf: introduce DT mechanism riscv: remove PMU menu of Kconfig .../devicetree/bindings/riscv/pmu.yaml| 59 +++ arch/riscv/Kconfig| 13 - arch/riscv/boot/dts/sifive/fu540-c000.dtsi| 13 + arch/riscv/include/asm/csr.h | 58 +++ arch/riscv/include/asm/perf_event.h | 100 ++-- arch/riscv/kernel/Makefile| 2 +- arch/riscv/kernel/perf_event.c| 471 +++--- 7 files changed, 471 insertions(+), 245 deletions(-) create mode 100644 Documentation/devicetree/bindings/riscv/pmu.yaml -- 2.27.0
[RFC PATCH 1/6] dt-bindings: riscv: Add YAML documentation for PMU
Add device tree bindings for performance monitor unit. And it passes the
dt_binding_check verification.
Signed-off-by: Zong Li
---
.../devicetree/bindings/riscv/pmu.yaml| 59 +++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/pmu.yaml
diff --git a/Documentation/devicetree/bindings/riscv/pmu.yaml
b/Documentation/devicetree/bindings/riscv/pmu.yaml
new file mode 100644
index ..f55ccbc6c685
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/pmu.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/pmu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: RISC-V Performance Monitor Units
+
+maintainers:
+ - Zong Li
+ - Paul Walmsley
+ - Palmer Dabbelt
+
+properties:
+ compatible:
+items:
+ - const: riscv,pmu
+
+ riscv,width-base-cntr:
+description: The width of cycle and instret CSRs.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+ riscv,width-event-cntr:
+description: The width of hpmcounter CSRs.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+ riscv,n-event-cntr:
+description: The number of hpmcounter CSRs.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+ riscv,hw-event-map:
+description: The mapping of generic hardware events. Default is no mapping.
+$ref: /schemas/types.yaml#/definitions/uint32-array
+
+ riscv,hw-cache-event-map:
+description: The mapping of generic hardware cache events.
+ Default is no mapping.
+$ref: /schemas/types.yaml#/definitions/uint32-array
+
+required:
+ - compatible
+ - riscv,width-base-cntr
+ - riscv,width-event-cntr
+ - riscv,n-event-cntr
+
+additionalProperties: false
+
+examples:
+ - |
+pmu {
+ compatible = "riscv,pmu";
+ riscv,width-base-cntr = <64>;
+ riscv,width-event-cntr = <40>;
+ riscv,n-event-cntr = <2>;
+ riscv,hw-event-map = <0x0 0x0 0x1 0x1 0x3 0x0202 0x4 0x4000>;
+ riscv,hw-cache-event-map = <0x010201 0x0102 0x010204 0x0802>;
+};
+
+...
--
2.27.0
[RFC PATCH 3/6] riscv: add definition of hpmcounter CSRs
The hpmcounter CSRs are used for perf to read the value of monitoring hardware events. Signed-off-by: Zong Li --- arch/riscv/include/asm/csr.h | 58 1 file changed, 58 insertions(+) diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h index cec462e198ce..3a18a0bbdc6d 100644 --- a/arch/riscv/include/asm/csr.h +++ b/arch/riscv/include/asm/csr.h @@ -83,9 +83,67 @@ #define CSR_CYCLE 0xc00 #define CSR_TIME 0xc01 #define CSR_INSTRET0xc02 +#define CSR_HPMCOUNTER30xc03 +#define CSR_HPMCOUNTER40xc04 +#define CSR_HPMCOUNTER50xc05 +#define CSR_HPMCOUNTER60xc06 +#define CSR_HPMCOUNTER70xc07 +#define CSR_HPMCOUNTER80xc08 +#define CSR_HPMCOUNTER90xc09 +#define CSR_HPMCOUNTER10 0xc0a +#define CSR_HPMCOUNTER11 0xc0b +#define CSR_HPMCOUNTER12 0xc0c +#define CSR_HPMCOUNTER13 0xc0d +#define CSR_HPMCOUNTER14 0xc0e +#define CSR_HPMCOUNTER15 0xc0f +#define CSR_HPMCOUNTER16 0xc10 +#define CSR_HPMCOUNTER17 0xc11 +#define CSR_HPMCOUNTER18 0xc12 +#define CSR_HPMCOUNTER19 0xc13 +#define CSR_HPMCOUNTER20 0xc14 +#define CSR_HPMCOUNTER21 0xc15 +#define CSR_HPMCOUNTER22 0xc16 +#define CSR_HPMCOUNTER23 0xc17 +#define CSR_HPMCOUNTER24 0xc18 +#define CSR_HPMCOUNTER25 0xc19 +#define CSR_HPMCOUNTER26 0xc1a +#define CSR_HPMCOUNTER27 0xc1b +#define CSR_HPMCOUNTER28 0xc1c +#define CSR_HPMCOUNTER29 0xc1d +#define CSR_HPMCOUNTER30 0xc1e +#define CSR_HPMCOUNTER31 0xc1f #define CSR_CYCLEH 0xc80 #define CSR_TIMEH 0xc81 #define CSR_INSTRETH 0xc82 +#define CSR_HPMCOUNTER3H 0xc83 +#define CSR_HPMCOUNTER4H 0xc84 +#define CSR_HPMCOUNTER5H 0xc85 +#define CSR_HPMCOUNTER6H 0xc86 +#define CSR_HPMCOUNTER7H 0xc87 +#define CSR_HPMCOUNTER8H 0xc88 +#define CSR_HPMCOUNTER9H 0xc89 +#define CSR_HPMCOUNTER10H 0xc8a +#define CSR_HPMCOUNTER11H 0xc8b +#define CSR_HPMCOUNTER12H 0xc8c +#define CSR_HPMCOUNTER13H 0xc8d +#define CSR_HPMCOUNTER14H 0xc8e +#define CSR_HPMCOUNTER15H 0xc8f +#define CSR_HPMCOUNTER16H 0xc90 +#define CSR_HPMCOUNTER17H 0xc91 +#define CSR_HPMCOUNTER18H 0xc92 +#define CSR_HPMCOUNTER19H 0xc93 +#define CSR_HPMCOUNTER20H 0xc94 +#define CSR_HPMCOUNTER21H 0xc95 +#define CSR_HPMCOUNTER22H 0xc96 +#define CSR_HPMCOUNTER23H 0xc97 +#define CSR_HPMCOUNTER24H 0xc98 +#define CSR_HPMCOUNTER25H 0xc99 +#define CSR_HPMCOUNTER26H 0xc9a +#define CSR_HPMCOUNTER27H 0xc9b +#define CSR_HPMCOUNTER28H 0xc9c +#define CSR_HPMCOUNTER29H 0xc9d +#define CSR_HPMCOUNTER30H 0xc9e +#define CSR_HPMCOUNTER31H 0xc9f #define CSR_SSTATUS0x100 #define CSR_SIE0x104 -- 2.27.0
[RFC PATCH 4/6] riscv: perf: Add raw event support
Add support for raw events and hardware cache events. Currently, we set
the events by writing the mhpmeventN CSRs, it would raise an illegal
instruction exception and trap into m-mode to emulate event selector
CSRs access. It doesn't make sense because we shouldn't write the
m-mode CSRs in s-mode, it would be better that set events through SBI
call or the shadow CSRs of s-mode. We would change it later.
Signed-off-by: Zong Li
---
arch/riscv/include/asm/perf_event.h | 65 ++---
arch/riscv/kernel/perf_event.c | 204 +++-
2 files changed, 215 insertions(+), 54 deletions(-)
diff --git a/arch/riscv/include/asm/perf_event.h
b/arch/riscv/include/asm/perf_event.h
index 062efd3a1d5d..41d515a1f331 100644
--- a/arch/riscv/include/asm/perf_event.h
+++ b/arch/riscv/include/asm/perf_event.h
@@ -14,39 +14,64 @@
#ifdef CONFIG_RISCV_BASE_PMU
#define RISCV_BASE_COUNTERS2
+#define RISCV_EVENT_COUNTERS 29
+#define RISCV_TOTAL_COUNTERS (RISCV_BASE_COUNTERS + RISCV_EVENT_COUNTERS)
/*
- * The RISCV_MAX_COUNTERS parameter should be specified.
- */
-
-#define RISCV_MAX_COUNTERS 2
-
-/*
- * These are the indexes of bits in counteren register *minus* 1,
- * except for cycle. It would be coherent if it can directly mapped
- * to counteren bit definition, but there is a *time* register at
- * counteren[1]. Per-cpu structure is scarce resource here.
- *
* According to the spec, an implementation can support counter up to
* mhpmcounter31, but many high-end processors has at most 6 general
* PMCs, we give the definition to MHPMCOUNTER8 here.
*/
-#define RISCV_PMU_CYCLE0
-#define RISCV_PMU_INSTRET 1
-#define RISCV_PMU_MHPMCOUNTER3 2
-#define RISCV_PMU_MHPMCOUNTER4 3
-#define RISCV_PMU_MHPMCOUNTER5 4
-#define RISCV_PMU_MHPMCOUNTER6 5
-#define RISCV_PMU_MHPMCOUNTER7 6
-#define RISCV_PMU_MHPMCOUNTER8 7
+#define RISCV_PMU_CYCLE0
+#define RISCV_PMU_INSTRET 2
+#define RISCV_PMU_HPMCOUNTER3 3
+#define RISCV_PMU_HPMCOUNTER4 4
+#define RISCV_PMU_HPMCOUNTER5 5
+#define RISCV_PMU_HPMCOUNTER6 6
+#define RISCV_PMU_HPMCOUNTER7 7
+#define RISCV_PMU_HPMCOUNTER8 8
+
+#define RISCV_PMU_HPMCOUNTER_FIRST 3
+#define RISCV_PMU_HPMCOUNTER_LAST \
+ (RISCV_PMU_HPMCOUNTER_FIRST + riscv_pmu->num_counters - 1)
#define RISCV_OP_UNSUPP(-EOPNOTSUPP)
+/* Hardware cache event encoding */
+#define PERF_HW_CACHE_TYPE 0
+#define PERF_HW_CACHE_OP 8
+#define PERF_HW_CACHE_RESULT 16
+#define PERF_HW_CACHE_MASK 0xff
+
+/* config_base encoding */
+#define RISCV_PMU_TYPE_MASK0x3
+#define RISCV_PMU_TYPE_BASE0x1
+#define RISCV_PMU_TYPE_EVENT 0x2
+#define RISCV_PMU_EXCLUDE_MASK 0xc
+#define RISCV_PMU_EXCLUDE_USER 0x3
+#define RISCV_PMU_EXCLUDE_KERNEL 0x4
+
+/*
+ * Currently, machine-mode supports emulation of mhpmeventN. Setting mhpmeventN
+ * to raise an illegal instruction exception to set event types in
machine-mode.
+ * Eventually, we should set event types through standard SBI call or the
shadow
+ * CSRs of supervisor-mode, because it is weird for writing CSR of machine-mode
+ * explicitly in supervisor-mode. These macro should be removed in the future.
+ */
+#define CSR_MHPMEVENT3 0x323
+#define CSR_MHPMEVENT4 0x324
+#define CSR_MHPMEVENT5 0x325
+#define CSR_MHPMEVENT6 0x326
+#define CSR_MHPMEVENT7 0x327
+#define CSR_MHPMEVENT8 0x328
+
struct cpu_hw_events {
/* # currently enabled events*/
int n_events;
/* currently enabled events */
- struct perf_event *events[RISCV_MAX_COUNTERS];
+ struct perf_event *events[RISCV_EVENT_COUNTERS];
+ /* bitmap of used event counters */
+ unsigned long used_cntr_mask;
/* vendor-defined PMU data */
void*platform;
};
diff --git a/arch/riscv/kernel/perf_event.c b/arch/riscv/kernel/perf_event.c
index c835f0362d94..0cfcd6f1e57b 100644
--- a/arch/riscv/kernel/perf_event.c
+++ b/arch/riscv/kernel/perf_event.c
@@ -139,6 +139,53 @@ static const int
riscv_cache_event_map[PERF_COUNT_HW_CACHE_MAX]
},
};
+/*
+ * Methods for checking and getting PMU information
+ */
+
+static inline int is_base_counter(int idx)
+{
+ return (idx == RISCV_PMU_CYCLE || idx == RISCV_PMU_INSTRET);
+}
+
+static inline int is_event_counter(int idx)
+{
+ return (idx >= RISCV_PMU_HPMCOUNTER_FIRST &&
+ idx <= RISCV_PMU_HPMCOUNTER_LAST);
+}
+
+static inline int get_available_counter(struct perf_event *event)
+{
+ struct cpu_hw_events *cpuc = this_cpu_ptr(_hw_events);
+ struct hw_perf_event *hwc = >hw;
+ unsigned long config_base = hwc->config_base & RISCV_PMU_TYPE_MASK;
+ unsigned long mask;
+ int ret;
+
+ switch (config_base) {
+
[RFC PATCH 6/6] riscv: remove PMU menu of Kconfig
We only one instance of riscv_pmu now, and use DT file to describe the platform-specific information, so drop the dependency and menu of RISCV_BASE_PMU. Signed-off-by: Zong Li --- arch/riscv/Kconfig | 13 - arch/riscv/include/asm/perf_event.h | 2 -- arch/riscv/kernel/Makefile | 2 +- 3 files changed, 1 insertion(+), 16 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 128192e14ff2..deec11e924ce 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -292,19 +292,6 @@ config RISCV_ISA_C If you don't know what to do here, say Y. -menu "supported PMU type" - depends on PERF_EVENTS - -config RISCV_BASE_PMU - bool "Base Performance Monitoring Unit" - def_bool y - help - A base PMU that serves as a reference implementation and has limited - feature of perf. It can run on any RISC-V machines so serves as the - fallback, but this option can also be disable to reduce kernel size. - -endmenu - config FPU bool "FPU support" default y diff --git a/arch/riscv/include/asm/perf_event.h b/arch/riscv/include/asm/perf_event.h index e95d3bbaae3e..9ee654381d8c 100644 --- a/arch/riscv/include/asm/perf_event.h +++ b/arch/riscv/include/asm/perf_event.h @@ -12,7 +12,6 @@ #include #include -#ifdef CONFIG_RISCV_BASE_PMU #define RISCV_BASE_COUNTERS2 #define RISCV_EVENT_COUNTERS 29 #define RISCV_TOTAL_COUNTERS (RISCV_BASE_COUNTERS + RISCV_EVENT_COUNTERS) @@ -79,7 +78,6 @@ #define CSR_MHPMEVENT7 0x327 #define CSR_MHPMEVENT8 0x328 -#endif #ifdef CONFIG_PERF_EVENTS #define perf_arch_bpf_user_pt_regs(regs) (struct user_regs_struct *)regs #endif diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile index b355cf485671..1f5736e996fd 100644 --- a/arch/riscv/kernel/Makefile +++ b/arch/riscv/kernel/Makefile @@ -43,7 +43,7 @@ obj-$(CONFIG_MODULE_SECTIONS) += module-sections.o obj-$(CONFIG_FUNCTION_TRACER) += mcount.o ftrace.o obj-$(CONFIG_DYNAMIC_FTRACE) += mcount-dyn.o -obj-$(CONFIG_RISCV_BASE_PMU) += perf_event.o +obj-$(CONFIG_PERF_EVENTS) += perf_event.o obj-$(CONFIG_PERF_EVENTS) += perf_callchain.o obj-$(CONFIG_HAVE_PERF_REGS) += perf_regs.o obj-$(CONFIG_RISCV_SBI)+= sbi.o -- 2.27.0
[RFC PATCH 5/6] riscv: perf: introduce DT mechanism
Each architecture is responsible for mapping generic hardware and cache
events to their own specific encoding of hardware events. For each
architecture, it also have to distinguish the defination of hardware
events of different platforms of each vendor. We use DT file to describe
platform-specific information to make our perf implementation more
generic and common.
Signed-off-by: Zong Li
---
arch/riscv/include/asm/perf_event.h | 55 ++
arch/riscv/kernel/perf_event.c | 273 +---
2 files changed, 139 insertions(+), 189 deletions(-)
diff --git a/arch/riscv/include/asm/perf_event.h
b/arch/riscv/include/asm/perf_event.h
index 41d515a1f331..e95d3bbaae3e 100644
--- a/arch/riscv/include/asm/perf_event.h
+++ b/arch/riscv/include/asm/perf_event.h
@@ -17,6 +17,8 @@
#define RISCV_EVENT_COUNTERS 29
#define RISCV_TOTAL_COUNTERS (RISCV_BASE_COUNTERS + RISCV_EVENT_COUNTERS)
+#define RISCV_DEFAULT_WIDTH_COUNTER64
+
/*
* According to the spec, an implementation can support counter up to
* mhpmcounter31, but many high-end processors has at most 6 general
@@ -33,9 +35,21 @@
#define RISCV_PMU_HPMCOUNTER_FIRST 3
#define RISCV_PMU_HPMCOUNTER_LAST \
- (RISCV_PMU_HPMCOUNTER_FIRST + riscv_pmu->num_counters - 1)
+ (RISCV_PMU_HPMCOUNTER_FIRST + riscv_pmu.num_event_cntr - 1)
+
+#define RISCV_OP_UNSUPP(-EOPNOTSUPP)
+
+#define RISCV_MAP_ALL_UNSUPPORTED \
+ [0 ... PERF_COUNT_HW_MAX - 1] = RISCV_OP_UNSUPP
-#define RISCV_OP_UNSUPP(-EOPNOTSUPP)
+#define C(x) PERF_COUNT_HW_CACHE_##x
+
+#define RISCV_CACHE_MAP_ALL_UNSUPPORTED
\
+[0 ... C(MAX) - 1] = { \
+ [0 ... C(OP_MAX) - 1] = { \
+ [0 ... C(RESULT_MAX) - 1] = RISCV_OP_UNSUPP,\
+ }, \
+}
/* Hardware cache event encoding */
#define PERF_HW_CACHE_TYPE 0
@@ -65,43 +79,6 @@
#define CSR_MHPMEVENT7 0x327
#define CSR_MHPMEVENT8 0x328
-struct cpu_hw_events {
- /* # currently enabled events*/
- int n_events;
- /* currently enabled events */
- struct perf_event *events[RISCV_EVENT_COUNTERS];
- /* bitmap of used event counters */
- unsigned long used_cntr_mask;
- /* vendor-defined PMU data */
- void*platform;
-};
-
-struct riscv_pmu {
- struct pmu *pmu;
-
- /* generic hw/cache events table */
- const int *hw_events;
- const int (*cache_events)[PERF_COUNT_HW_CACHE_MAX]
- [PERF_COUNT_HW_CACHE_OP_MAX]
- [PERF_COUNT_HW_CACHE_RESULT_MAX];
- /* method used to map hw/cache events */
- int (*map_hw_event)(u64 config);
- int (*map_cache_event)(u64 config);
-
- /* max generic hw events in map */
- int max_events;
- /* number total counters, 2(base) + x(general) */
- int num_counters;
- /* the width of the counter */
- int counter_width;
-
- /* vendor-defined PMU features */
- void*platform;
-
- irqreturn_t (*handle_irq)(int irq_num, void *dev);
- int irq;
-};
-
#endif
#ifdef CONFIG_PERF_EVENTS
#define perf_arch_bpf_user_pt_regs(regs) (struct user_regs_struct *)regs
diff --git a/arch/riscv/kernel/perf_event.c b/arch/riscv/kernel/perf_event.c
index 0cfcd6f1e57b..3bdfbe4efd5c 100644
--- a/arch/riscv/kernel/perf_event.c
+++ b/arch/riscv/kernel/perf_event.c
@@ -9,6 +9,7 @@
* Copyright (C) 2009 Google, Inc., Stephane Eranian
* Copyright 2014 Tilera Corporation. All Rights Reserved.
* Copyright (C) 2018 Andes Technology Corporation
+ * Copyright (C) 2020 SiFive
*
* Perf_events support for RISC-V platforms.
*
@@ -30,113 +31,55 @@
#include
#include
#include
+#include
#include
-static const struct riscv_pmu *riscv_pmu __read_mostly;
+static struct riscv_pmu {
+ struct pmu *pmu;
+
+ /* number of event counters */
+ int num_event_cntr;
+
+ /* the width of base counters */
+ int width_base_cntr;
+
+ /* the width of event counters */
+ int width_event_cntr;
+
+ irqreturn_t (*handle_irq)(int irq_num, void *dev);
+
+ int irq;
+} riscv_pmu;
+
+struct cpu_hw_events {
+ /* # currently enabled events*/
+ int n_events;
+
+ /* currently enabled events */
+ struct perf_event *events[RISCV_EVENT_COUNTERS];
+
+ /* bitmap of used event counters */
+ unsigned long used_cntr_mask;
+};
+
static DEFINE_PER_CPU(struct
Re: [PATCH] rtlwifi/*/dm.c: Use const in swing_table declarations
On Sun, 2020-06-28 at 19:51 -0700, j...@perches.com wrote:
> On 2020-06-28 19:09, Pkshih wrote:
> > On Sun, 2020-06-28 at 03:17 -0700, Joe Perches wrote:
> >
> > Use 'rtlwifi:' as subject title prefix is enough, likes
> > rtlwifi: Use const in swing_table declarations
>
> We disagree.
>
> I like knowing what content is changed via patch subject lines
> as there are 3 rtlwifi drivers being changed by this one patch.
If 3 drivers are needed to be listed, I'd use below subject
"rtlwifi: Use const in rtl8188ee/rtl8723be/rtl8821ae swing_table declarations"
>
> But your choice, you can change it if you choose.
>
> >> Reduce data usage about 1KB by using const.
> []
> > Please remove below type casting:
> >
> > @@ -1872,10 +1872,10 @@ static void
> > rtl8821ae_get_delta_swing_table(struct
> > ieee80211_hw *hw,
> > *up_b = rtl8821ae_delta_swing_table_idx_5gb_p[2];
> > *down_b = rtl8821ae_delta_swing_table_idx_5gb_n[2];
> > } else {
> > - *up_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
> > - *down_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
> > - *up_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
> > - *down_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
> > + *up_a = rtl8818e_delta_swing_table_idx_24gb_p;
> > + *down_a = rtl8818e_delta_swing_table_idx_24gb_n;
> > + *up_b = rtl8818e_delta_swing_table_idx_24gb_p;
> > + *down_b = rtl8818e_delta_swing_table_idx_24gb_n;
>
> The compiler is quiet about this so I believe this to be
> an unrelated change and whitespace correction.
I know compiler doesn't warn this, but it looks wired to cast 'const u8 *'
to 'u8 *' to 'const u8 *'.
>
> Of course you could modify it if you choose.
>
> btw: There's an unnecessary return at the 2nd instance
> of this cast removal too.
It seems like to copy from rtl8812ae_get_delta_swing_table(), so
I can remove it by another patch.
>
> cheers, Joe
>
> --Please consider the environment before printing this e-mail.
RE: [PATCH] fpga: dfl: improve configuration of dfl pci devices
> -Original Message- > From: linux-fpga-ow...@vger.kernel.org > On Behalf Of Xu Yilun > Sent: Monday, June 29, 2020 10:19 AM > To: t...@redhat.com > Cc: m...@kernel.org; linux-f...@vger.kernel.org; linux- > ker...@vger.kernel.org; Wu, Hao ; > matthew.gerl...@linux.intel.com > Subject: Re: [PATCH] fpga: dfl: improve configuration of dfl pci devices > > I think maybe we don't have to select them all. It is now possible for > FPGA DFL boards to work without FME or AFU, providing limited > functionality. It is possible designers trim the bitstream for their > purpose, and also need a smaller driver set. > Yes, we hope that this dfl-pci could be a common module shared by different cards. Some device doesn't have FME, e.g. some VF device with AFU only, some device has FME, but no PR support, and in the future, it's possible to add new modules, or something replacing AFU or FME, so we don't have to select all here. > I think we may add "default FPGA_DFL" for FPGA_DFL_FME, > FPGA_DFL_FME_MGR and others to make life easier. It's hard to say it's easier for everybody, e.g. I am a user of N3000, but I have to unselect the PR modules, as they are default Yes as proposed? Maybe it's better to let user select what they want, unless we find something really common needed under DFL framework. Hao
[PATCH] usb: gadget: fix langid kernel-doc warning in usbstring.c
From: Randy Dunlap
Fix spelling of the 'langid' function argument in the kernel-doc
notation to quieten a kernel-doc warning.
../drivers/usb/gadget/usbstring.c:77: warning: Function parameter or member
'langid' not described in 'usb_validate_langid'
../drivers/usb/gadget/usbstring.c:77: warning: Excess function parameter 'lang'
description in 'usb_validate_langid'
Fixes: 17309a6a4356 ("usb: gadget: add "usb_validate_langid" function")
Signed-off-by: Randy Dunlap
Cc: Tao Ren
Cc: Felipe Balbi
---
drivers/usb/gadget/usbstring.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200626.orig/drivers/usb/gadget/usbstring.c
+++ linux-next-20200626/drivers/usb/gadget/usbstring.c
@@ -68,7 +68,7 @@ EXPORT_SYMBOL_GPL(usb_gadget_get_string)
/**
* usb_validate_langid - validate usb language identifiers
- * @lang: usb language identifier
+ * @langid: usb language identifier
*
* Returns true for valid language identifier, otherwise false.
*/
RE: [PATCH] xen: introduce xen_vring_use_dma
> Subject: Re: [PATCH] xen: introduce xen_vring_use_dma > > On Thu, Jun 25, 2020 at 10:31:27AM -0700, Stefano Stabellini wrote: > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote: > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma > > > > > > > > APIs to map the > > > > > > > > ring: when xen_swiotlb is enabled the dma API is required. > > > > > > > > When it is disabled, it is not required. > > > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for > this? > > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to > > > > > > translate foreign mappings (memory coming from other VMs) to > physical addresses. > > > > > > On x86, it also uses dma_ops to translate Linux's idea of a > > > > > > physical address into a real physical address (this is > > > > > > unneeded on ARM.) > > > > > > > > > > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be > > > > > > used on Xen/x86 always and on Xen/ARM if Linux is Dom0 > > > > > > (because it has foreign > > > > > > mappings.) That is why we have the if (xen_domain) return > > > > > > true; in vring_use_dma_api. > > > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* forces > > > > > DMA ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > > > > > Unfortunately as a result Xen never got around to properly > > > > > setting VIRTIO_F_IOMMU_PLATFORM. > > > > > > > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this > > > > because the usage of swiotlb_xen is not a property of virtio, > > > > > > > > > Basically any device without VIRTIO_F_ACCESS_PLATFORM (that is it's > > > name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is what linux > > > calls it) is declared as "special, don't follow normal rules for > > > access". > > > > > > So yes swiotlb_xen is not a property of virtio, but what *is* a > > > property of virtio is that it's not special, just a regular device from > > > DMA > POV. > > > > I am trying to understand what you meant but I think I am missing > > something. > > > > Are you saying that modern virtio should always have > > VIRTIO_F_ACCESS_PLATFORM, hence use normal dma_ops as any other > devices? > > I am saying it's a safe default. Clear VIRTIO_F_ACCESS_PLATFORM if you have > some special needs e.g. you are very sure it's ok to bypass DMA ops, or you > need to support a legacy guest (produced in the window between virtio 1 > support in 2014 and support for VIRTIO_F_ACCESS_PLATFORM in 2016). > > > > If that is the case, how is it possible that virtio breaks on ARM > > using the default dma_ops? The breakage is not Xen related (except > > that Xen turns dma_ops on). The original message from Peng was: > > > > vring_map_one_sg -> vring_use_dma_api > >-> dma_map_page > >-> __swiotlb_map_page > > ->swiotlb_map_page > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > dev_addr)), size, dir); > > However we are using per device dma area for rpmsg, phys_to_virt > > could not return a correct virtual address for virtual address in > > vmalloc area. Then kernel panic. > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > I think it's an RPMesg bug, yes rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, and use vmalloc_to_page. Anyway here using dma api will also trigger issue. > > > > > > > > > You might have noticed that I missed one possible case above: > > > > > > Xen/ARM DomU :-) > > > > > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even > > > > > > initialized. So if > > > > > > (xen_domain) return true; would give the wrong answer in that case. > > > > > > Linux would end up calling the "normal" dma_ops, not > > > > > > swiotlb-xen, and the "normal" dma_ops fail. > > > > > > > > > > > > > > > > > > The solution I suggested was to make the check in > > > > > > vring_use_dma_api more flexible by returning true if the > > > > > > swiotlb_xen is supposed to be used, not in general for all Xen > > > > > > domains, because that is what the check was really meant to do. > > > > > > > > >
RE: [PATCH] xen: introduce xen_vring_use_dma
> Subject: Re: [PATCH] xen: introduce xen_vring_use_dma > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote: > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote: > > > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote: > > > > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote: > > > > > > > Export xen_swiotlb for all platforms using xen swiotlb > > > > > > > > > > > > > > Use xen_swiotlb to determine when vring should use dma APIs > > > > > > > to map the > > > > > > > ring: when xen_swiotlb is enabled the dma API is required. > > > > > > > When it is disabled, it is not required. > > > > > > > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > Isn't there some way to use VIRTIO_F_IOMMU_PLATFORM for this? > > > > > > Xen was there first, but everyone else is using that now. > > > > > > > > > > Unfortunately it is complicated and it is not related to > > > > > VIRTIO_F_IOMMU_PLATFORM :-( > > > > > > > > > > > > > > > The Xen subsystem in Linux uses dma_ops via swiotlb_xen to > > > > > translate foreign mappings (memory coming from other VMs) to > physical addresses. > > > > > On x86, it also uses dma_ops to translate Linux's idea of a > > > > > physical address into a real physical address (this is unneeded > > > > > on ARM.) > > > > > > > > > > > > > > > So regardless of VIRTIO_F_IOMMU_PLATFORM, dma_ops should be > used > > > > > on Xen/x86 always and on Xen/ARM if Linux is Dom0 (because it > > > > > has foreign > > > > > mappings.) That is why we have the if (xen_domain) return true; > > > > > in vring_use_dma_api. > > > > > > > > VIRTIO_F_IOMMU_PLATFORM makes guest always use DMA ops. > > > > > > > > Xen hack predates VIRTIO_F_IOMMU_PLATFORM so it *also* forces > DMA > > > > ops even if VIRTIO_F_IOMMU_PLATFORM is clear. > > > > > > > > Unfortunately as a result Xen never got around to properly setting > > > > VIRTIO_F_IOMMU_PLATFORM. > > > > > > I don't think VIRTIO_F_IOMMU_PLATFORM would be correct for this > > > because the usage of swiotlb_xen is not a property of virtio, > > > > > > Basically any device without VIRTIO_F_ACCESS_PLATFORM (that is it's > > name in latest virtio spec, VIRTIO_F_IOMMU_PLATFORM is what linux > > calls it) is declared as "special, don't follow normal rules for > > access". > > > > So yes swiotlb_xen is not a property of virtio, but what *is* a > > property of virtio is that it's not special, just a regular device from DMA > > POV. > > I am trying to understand what you meant but I think I am missing something. > > Are you saying that modern virtio should always have > VIRTIO_F_ACCESS_PLATFORM, hence use normal dma_ops as any other > devices? > > If that is the case, how is it possible that virtio breaks on ARM using the > default dma_ops? The breakage is not Xen related (except that Xen turns > dma_ops on). The original message from Peng was: > > vring_map_one_sg -> vring_use_dma_api >-> dma_map_page > -> __swiotlb_map_page > ->swiotlb_map_page > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > dev_addr)), size, dir); > However we are using per device dma area for rpmsg, phys_to_virt > could not return a correct virtual address for virtual address in > vmalloc area. Then kernel panic. > > I must be missing something. Maybe it is because it has to do with RPMesg? I am not going to fix the rpmsg issue with this patch. It is when ARM DomU Android os communicate with secure world trusty os using virtio, the vring_use_dma_api will return true for xen domu, but I no need it return true and fall into swiotlb. Thanks, Peng. > > > > > > > You might have noticed that I missed one possible case above: > > > > > Xen/ARM DomU :-) > > > > > > > > > > Xen/ARM domUs don't need swiotlb_xen, it is not even > > > > > initialized. So if > > > > > (xen_domain) return true; would give the wrong answer in that case. > > > > > Linux would end up calling the "normal" dma_ops, not > > > > > swiotlb-xen, and the "normal" dma_ops fail. > > > > > > > > > > > > > > > The solution I suggested was to make the check in > > > > > vring_use_dma_api more flexible by returning true if the > > > > > swiotlb_xen is supposed to be used, not in general for all Xen > > > > > domains, because that is what the check was really meant to do. > > > > > > > > Why not fix DMA ops so they DTRT (nop) on Xen/ARM DomU? What is > wrong with that? > > > > > > swiotlb-xen is not used on Xen/ARM DomU, the default dma_ops are the > > > ones that are used. So you are saying, why don't we fix the default > > > dma_ops to work with virtio? > > > > > > It is bad that the default dma_ops crash with virtio, so yes I think > > > it would be good to fix that. However, even if we fixed that, the if > > > (xen_domain()) check in vring_use_dma_api is still
[PATCH v10 4/6] dt-bindings: ARM: tegra: Add Acer Iconia Tab A500
Add a binding for the Tegra20-based Acer Iconia Tab A500 tablet device. Acked-by: Rob Herring Signed-off-by: Dmitry Osipenko --- Documentation/devicetree/bindings/arm/tegra.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 60b38eb5c61a..7fd0b66c69b2 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -34,6 +34,9 @@ properties: - toradex,colibri_t20-iris - const: toradex,colibri_t20 - const: nvidia,tegra20 + - items: + - const: acer,picasso + - const: nvidia,tegra20 - items: - enum: - nvidia,beaver -- 2.26.0
[PATCH v10 2/6] ARM: tegra: Add device-tree for ASUS Google Nexus 7
There are few hardware variants of NVIDIA Tegra30-based Nexus 7 device:
1. WiFi-only (named Grouper)
2. GSM (named Tilapia)
3. Using Maxim PMIC (E1565 board ID)
4. Using Ti PMIC (PM269 board ID)
This patch adds device-trees for known and tested variants.
Link: https://wiki.postmarketos.org/wiki/Google_Nexus_7_2012_(asus-grouper)
Tested-by: Pedro Ângelo
Tested-by: Matt Merhar
Tested-by: Zack Pearsall
Signed-off-by: David Heidelberg
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/Makefile|3 +
.../dts/tegra30-asus-nexus7-grouper-E1565.dts |9 +
.../dts/tegra30-asus-nexus7-grouper-PM269.dts |9 +
.../tegra30-asus-nexus7-grouper-common.dtsi | 1232 +
...egra30-asus-nexus7-grouper-maxim-pmic.dtsi | 185 ++
...30-asus-nexus7-grouper-memory-timings.dtsi | 1565 +
.../tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 149 ++
.../boot/dts/tegra30-asus-nexus7-grouper.dtsi | 149 ++
.../dts/tegra30-asus-nexus7-tilapia-E1565.dts |9 +
...30-asus-nexus7-tilapia-memory-timings.dtsi | 325
.../boot/dts/tegra30-asus-nexus7-tilapia.dtsi | 235 +++
11 files changed, 3870 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dts
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-PM269.dts
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
create mode 100644
arch/arm/boot/dts/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
create mode 100644
arch/arm/boot/dts/tegra30-asus-nexus7-grouper-memory-timings.dtsi
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-grouper.dtsi
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-tilapia-E1565.dts
create mode 100644
arch/arm/boot/dts/tegra30-asus-nexus7-tilapia-memory-timings.dtsi
create mode 100644 arch/arm/boot/dts/tegra30-asus-nexus7-tilapia.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5168edd17611..a1a7846e3781 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1213,6 +1213,9 @@ dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
dtb-$(CONFIG_ARCH_TEGRA_3x_SOC) += \
tegra30-apalis-eval.dtb \
tegra30-apalis-v1.1-eval.dtb \
+ tegra30-asus-nexus7-grouper-PM269.dtb \
+ tegra30-asus-nexus7-grouper-E1565.dtb \
+ tegra30-asus-nexus7-tilapia-E1565.dtb \
tegra30-beaver.dtb \
tegra30-cardhu-a02.dtb \
tegra30-cardhu-a04.dtb \
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dts
b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dts
new file mode 100644
index ..a25b8560b0cd
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-E1565.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "tegra30-asus-nexus7-grouper-maxim-pmic.dtsi"
+#include "tegra30-asus-nexus7-grouper.dtsi"
+
+/ {
+ model = "ASUS Google Nexus 7 (Project Nakasi / ME370T) E1565";
+};
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-PM269.dts
b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-PM269.dts
new file mode 100644
index ..06ef13ea5df8
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-PM269.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "tegra30-asus-nexus7-grouper-ti-pmic.dtsi"
+#include "tegra30-asus-nexus7-grouper.dtsi"
+
+/ {
+ model = "ASUS Google Nexus 7 (Project Nakasi / ME370T) PM269";
+};
diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
new file mode 100644
index ..3922517145e7
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
@@ -0,0 +1,1232 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include
+#include
+#include
+
+#include "tegra30.dtsi"
+#include "tegra30-cpu-opp.dtsi"
+#include "tegra30-cpu-opp-microvolt.dtsi"
+
+/ {
+ aliases {
+ rtc0 =
+ rtc1 = "/rtc@7000e000";
+
+ serial1 = /* Bluetooth */
+ serial2 = /* GPS */
+ };
+
+ /*
+* The decompressor and also some bootloaders rely on a
+* pre-existing /chosen node to be available to insert the
+* command line and merge other ATAGS info.
+*/
+ chosen {};
+
+ memory@8000 {
+ reg = <0x8000 0x4000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ linux,cma@8000 {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0x8000 0x3000>;
+ size = <0x1000>; /* 256MiB */
+ linux,cma-default;
+ reusable;
+ };
+
+ ramoops@bfdf {
+
[PATCH v10 0/6] Support NVIDIA Tegra-based Acer A500 and Nexus 7 devices
Hello,
This series introduces upstream kernel support for Acer Iconia Tab A500
and ASUS Google Nexus 7 tablet devices. Please review and apply, thanks
in advance.
Changelog:
v10:- Rebased on a recent linux-next which got some device-tree changes:
- Renamed sdhci@ DT nodes to mmc@
- Removed simple-busses from DTs
- Checked DTBs using upcoming YAML bindings from Thierry Reding
v9: - Nexus 7 memory timings are moved out to a separate dtsi file to ease
reviewing of the device-trees since the sparse definition of the timings
within multiple DT files created some unnecessary confusion.
Thanks to Michał Mirosław for the suggestion.
v8: - The eMMC voltage regulator is now marked as always-ON in all
device-trees because turned out that some bootloader versions have
assumption about the enabled regulator at a boot time. This fixes
machine hanging on a warm reboot, it's also matching the downstream
kernel regulator configuration.
- The core regulator of the Ti PMIC Nexus 7 variant is now limited
to a 1.35V, which is a more realistic limit than 1.5V that was borrowed
from the Cardhu device-tree. Now both Maxim and Ti variants have the
common limits.
- Added acks from Rob Herring.
v7: - This version brings support for a Nexus 7 variant that uses Ti PMIC
instead of the Maxim PMIC. Previously we assumed that variant with
the Ti PMIC doesn't exist in a wild, but turned out that it was a
wrong assumption. In a result the device-trees are separated into
more DTSI pieces, which combined together form the final device-tree.
Thanks to Zack Pearsall for testing the Ti version!
- The camera voltage regulator is now preset to a correct 1.8v in the
Nexus 7 device-tree.
v6: - Corrected PMIC's RTC alias in the DTs. Sometime ago I renamed the
PMIC's node to match the modern upstream styling, but forgot to change
the RTC alias. Now PMIC RTC alias uses node's handle instead of string.
- Removed "panel: " handle from device trees, which became unused after
v5 and I just missed to remove it.
v5: - After spending some more time on adding LVDS encoder bridge support
to the Tegra DRM driver, I'm now having a second thought and agree
with Thierry Reding that in a longer run it should be better not to
mix old nvidia,panel with new output graph in device-tree. So the
nvidia,panel phandle is removed now in both A500 and Nexus 7 DTs.
v4: - Corrected CPU's thermal zone on both A500 and Nexus 7, which
should use the remote thermal sensor (Tegra chip) instead of the
local ("skin" temperature).
- Added default PMIC pinmux state on Nexus 7, for completeness.
- Added PMIC cpu_pwr_req GPIO hog on Nexus 7, for completeness.
- Renamed thermal sensor node label to NCT72 on Nexus 7 to match the
actual hardware (NCT72 is compatible with NCT1008). For completeness.
- Added always-on USB AVDD regulator on Nexus 7, which is controlled by
the PMIC GPIO. For completeness.
- Added PMIC GPIO enable-control to the 3v3_sys regulator on Nexus 7,
for completeness.
- Added CONFIG_NAMESPACES, CONFIG_USER_NS, CONFIG_SECCOMP and
CONFIG_PINCTRL_MAX77620 to the tegra_defconfig. The first three
options are must-have for the modern userspace, the last is somewhat
actual now since the default PMIC pinmux state is added to the N7 DT.
v3: - Improved device-tree node-names in accordance to review comments that
were made by Thierry Reding to v2.
- Corrected LVDS encoder powerdown-GPIO polarity on both A500 and Nexus 7
because I implemented the DRM bridges support in the Tegra DRM driver
and found that there was a mistake in the device-trees. The updated
polarity also matches the boards schematics. Now DRM bridges support
becomes mandatory since LVDS is getting disabled during of the encoder
driver probing. I'll send the DRM patch separately from this series.
- Replaced recently deprecated CONFIG_DRM_LVDS_ENCODER with the new
CONFIG_DRM_LVDS_CODEC in tegra_defconfig.
- Added more config options to tegra_defconfig, like pstore and thermal.
- Added atmel,cfg_name to the A500 DT, which is a new upcoming property
in 5.8+ that allows to specify the per-board hardware config file name.
v2: - Corrected "volume down" key-label in the grouper's device-tree and
improved some other names in device-trees.
- Added optional (upcoming in 5.8+) VDD/AVDD regulators to the touchscreen
node in A500 device-tree.
Dmitry Osipenko (6):
ARM: tegra: Add device-tree for Acer Iconia Tab A500
ARM: tegra: Add device-tree for ASUS Google Nexus 7
dt-bindings: Add vendor prefix for Acer Inc.
dt-bindings: ARM: tegra: Add Acer Iconia Tab A500
dt-bindings: ARM: tegra: Add ASUS Google Nexus 7
ARM: tegra_defconfig: Enable options useful for Nexus 7 and
[PATCH v10 1/6] ARM: tegra: Add device-tree for Acer Iconia Tab A500
Add device-tree for Acer Iconia Tab A500, which is NVIDIA Tegra20-based
tablet device.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/Makefile|1 +
.../boot/dts/tegra20-acer-a500-picasso.dts| 1438 +
2 files changed, 1439 insertions(+)
create mode 100644 arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 74dd94e72848..5168edd17611 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1199,6 +1199,7 @@ dtb-$(CONFIG_MACH_SUNIV) += \
dtb-$(CONFIG_ARCH_TANGO) += \
tango4-vantage-1172.dtb
dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
+ tegra20-acer-a500-picasso.dtb \
tegra20-harmony.dtb \
tegra20-colibri-eval-v3.dtb \
tegra20-colibri-iris.dtb \
diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
new file mode 100644
index ..2d683c9a1a5d
--- /dev/null
+++ b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
@@ -0,0 +1,1438 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include
+#include
+#include
+
+#include "tegra20.dtsi"
+#include "tegra20-cpu-opp.dtsi"
+#include "tegra20-cpu-opp-microvolt.dtsi"
+
+/ {
+ model = "Acer Iconia Tab A500";
+ compatible = "acer,picasso", "nvidia,tegra20";
+
+ aliases {
+ rtc0 =
+ rtc1 = "/rtc@7000e000";
+
+ serial0 = /* Docking station */
+ serial1 = /* Bluetooth */
+ serial2 = /* GPS */
+ };
+
+ /*
+* The decompressor and also some bootloaders rely on a
+* pre-existing /chosen node to be available to insert the
+* command line and merge other ATAGS info.
+*/
+ chosen {};
+
+ memory@0 {
+ reg = <0x 0x4000>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ ramoops@2ffe {
+ compatible = "ramoops";
+ reg = <0x2ffe 0x1>; /* 64kB */
+ console-size = <0x8000>;/* 32kB */
+ record-size = <0x400>; /* 1kB */
+ ecc-size = <16>;
+ };
+
+ linux,cma@3000 {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0x3000 0x1000>;
+ size = <0x1000>; /* 256MiB */
+ linux,cma-default;
+ reusable;
+ };
+ };
+
+ host1x@5000 {
+ dc@5420 {
+ rgb {
+ status = "okay";
+
+ port@0 {
+ lcd_output: endpoint {
+ remote-endpoint =
<_encoder_input>;
+ bus-width = <18>;
+ };
+ };
+ };
+ };
+
+ hdmi@5428 {
+ status = "okay";
+
+ vdd-supply = <_vdd_reg>;
+ pll-supply = <_pll_reg>;
+ hdmi-supply = <_5v0_sys>;
+
+ nvidia,ddc-i2c-bus = <_ddc>;
+ nvidia,hpd-gpio = < TEGRA_GPIO(N, 7)
+ GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ pinmux@7014 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_default>;
+
+ state_default: pinmux {
+ ata {
+ nvidia,pins = "ata";
+ nvidia,function = "ide";
+ };
+ atb {
+ nvidia,pins = "atb", "gma", "gme";
+ nvidia,function = "sdio4";
+ };
+ atc {
+ nvidia,pins = "atc";
+ nvidia,function = "nand";
+ };
+ atd {
+ nvidia,pins = "atd", "ate", "gmb", "spia",
+ "spib", "spic";
+ nvidia,function = "gmi";
+ };
+ cdev1 {
+ nvidia,pins = "cdev1";
+ nvidia,function = "plla_out";
+ };
+ cdev2 {
+ nvidia,pins = "cdev2";
+ nvidia,function = "pllp_out4";
+ };
+ crtp {
+ nvidia,pins = "crtp", "lm1";
[PATCH v10 5/6] dt-bindings: ARM: tegra: Add ASUS Google Nexus 7
Add a binding for the Tegra30-based ASUS Google Nexus 7 tablet device. Acked-by: Rob Herring Signed-off-by: Dmitry Osipenko --- Documentation/devicetree/bindings/arm/tegra.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 7fd0b66c69b2..fb3bbf7a5fb4 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -62,6 +62,13 @@ properties: - toradex,colibri_t30-eval-v3 - const: toradex,colibri_t30 - const: nvidia,tegra30 + - items: + - const: asus,grouper + - const: nvidia,tegra30 + - items: + - const: asus,tilapia + - const: asus,grouper + - const: nvidia,tegra30 - items: - enum: - nvidia,dalmore -- 2.26.0
[PATCH v10 6/6] ARM: tegra_defconfig: Enable options useful for Nexus 7 and Acer A500
Enable several very useful options and drivers for hardware that is found on Nexus 7 and Acer A500 tablet devices. Please note that some drivers may require firmware files extracted from original Android image. Link: https://github.com/grate-driver/linux-firmware Link: https://github.com/grate-driver/alsa-ucm-conf Signed-off-by: Dmitry Osipenko --- arch/arm/configs/tegra_defconfig | 42 1 file changed, 42 insertions(+) diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index aa94369bdd0f..9b01f8cc8262 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -10,6 +10,8 @@ CONFIG_RT_GROUP_SCHED=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_CPUACCT=y CONFIG_CGROUP_DEBUG=y +CONFIG_NAMESPACES=y +CONFIG_USER_NS=y CONFIG_BLK_DEV_INITRD=y # CONFIG_ELF_CORE is not set CONFIG_EMBEDDED=y @@ -18,6 +20,7 @@ CONFIG_SLAB=y CONFIG_ARCH_TEGRA=y CONFIG_SMP=y CONFIG_HIGHMEM=y +CONFIG_SECCOMP=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_KEXEC=y @@ -63,11 +66,17 @@ CONFIG_BT_RFCOMM=y CONFIG_BT_BNEP=y CONFIG_BT_HIDP=y CONFIG_BT_HCIBTUSB=m +CONFIG_BT_HCIUART=y +CONFIG_BT_HCIUART_BCM=y CONFIG_CFG80211=y CONFIG_MAC80211=y CONFIG_RFKILL=y CONFIG_RFKILL_INPUT=y CONFIG_RFKILL_GPIO=y +CONFIG_NFC=y +CONFIG_NFC_HCI=y +CONFIG_NFC_SHDLC=y +CONFIG_NFC_PN544_I2C=y CONFIG_PCI=y CONFIG_PCIEPORTBUS=y CONFIG_PCI_MSI=y @@ -106,20 +115,24 @@ CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_TEGRA=y +CONFIG_KEYBOARD_CAP11XX=y CONFIG_KEYBOARD_CROS_EC=y CONFIG_MOUSE_PS2_ELANTECH=y CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ATMEL_MXT=y +CONFIG_TOUCHSCREEN_ELAN=y CONFIG_TOUCHSCREEN_WM97XX=y # CONFIG_TOUCHSCREEN_WM9705 is not set # CONFIG_TOUCHSCREEN_WM9713 is not set CONFIG_TOUCHSCREEN_STMPE=y CONFIG_INPUT_MISC=y +CONFIG_INPUT_GPIO_VIBRA=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_TEGRA=y +CONFIG_SERIAL_DEV_BUS=y # CONFIG_HW_RANDOM is not set # CONFIG_I2C_COMPAT is not set CONFIG_I2C_CHARDEV=y @@ -131,10 +144,12 @@ CONFIG_SPI_TEGRA114=y CONFIG_SPI_TEGRA20_SFLASH=y CONFIG_SPI_TEGRA20_SLINK=y CONFIG_PINCTRL_AS3722=y +CONFIG_PINCTRL_MAX77620=y CONFIG_PINCTRL_PALMAS=y CONFIG_GPIO_SYSFS=y CONFIG_GPIO_PCA953X=y CONFIG_GPIO_PCA953X_IRQ=y +CONFIG_GPIO_MAX77620=y CONFIG_GPIO_PALMAS=y CONFIG_GPIO_TPS6586X=y CONFIG_GPIO_TPS65910=y @@ -142,13 +157,21 @@ CONFIG_POWER_RESET=y CONFIG_POWER_RESET_AS3722=y CONFIG_POWER_RESET_GPIO=y CONFIG_BATTERY_SBS=y +CONFIG_BATTERY_BQ27XXX=y +CONFIG_CHARGER_GPIO=y +CONFIG_CHARGER_SMB347=y CONFIG_CHARGER_TPS65090=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM95245=y +CONFIG_THERMAL=y +CONFIG_THERMAL_STATISTICS=y +CONFIG_CPU_THERMAL=y CONFIG_WATCHDOG=y +CONFIG_MAX77620_WATCHDOG=y CONFIG_TEGRA_WATCHDOG=y CONFIG_MFD_AS3722=y CONFIG_MFD_CROS_EC=y +CONFIG_MFD_MAX77620=y CONFIG_MFD_MAX8907=y CONFIG_MFD_STMPE=y CONFIG_MFD_PALMAS=y @@ -159,6 +182,7 @@ CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y CONFIG_REGULATOR_AS3722=y CONFIG_REGULATOR_GPIO=y +CONFIG_REGULATOR_MAX77620=y CONFIG_REGULATOR_MAX8907=y CONFIG_REGULATOR_PALMAS=y CONFIG_REGULATOR_TPS51632=y @@ -174,7 +198,10 @@ CONFIG_USB_GSPCA=y CONFIG_DRM=y CONFIG_DRM_NOUVEAU=m CONFIG_DRM_TEGRA=y +CONFIG_DRM_TEGRA_STAGING=y +CONFIG_DRM_PANEL_LVDS=y CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_DRM_LVDS_CODEC=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_GENERIC is not set @@ -238,6 +265,7 @@ CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_AS3722=y CONFIG_RTC_DRV_DS1307=y CONFIG_RTC_DRV_MAX8907=y +CONFIG_RTC_DRV_MAX77686=y CONFIG_RTC_DRV_PALMAS=y CONFIG_RTC_DRV_TPS6586X=y CONFIG_RTC_DRV_TPS65910=y @@ -259,11 +287,18 @@ CONFIG_ARCH_TEGRA_2x_SOC=y CONFIG_ARCH_TEGRA_3x_SOC=y CONFIG_ARCH_TEGRA_114_SOC=y CONFIG_ARCH_TEGRA_124_SOC=y +CONFIG_PM_DEVFREQ=y +CONFIG_ARM_TEGRA_DEVFREQ=y +CONFIG_ARM_TEGRA20_DEVFREQ=y CONFIG_MEMORY=y CONFIG_IIO=y +CONFIG_KXCJK1013=y CONFIG_MPU3050_I2C=y +CONFIG_INV_MPU6050_I2C=y +CONFIG_AL3010=y CONFIG_SENSORS_ISL29018=y CONFIG_SENSORS_ISL29028=y +CONFIG_AK8974=y CONFIG_AK8975=y CONFIG_PWM=y CONFIG_PWM_TEGRA=y @@ -282,6 +317,13 @@ CONFIG_TMPFS_POSIX_ACL=y CONFIG_SQUASHFS=y CONFIG_SQUASHFS_LZO=y CONFIG_SQUASHFS_XZ=y +CONFIG_PSTORE=y +CONFIG_PSTORE_LZO_COMPRESS=y +CONFIG_PSTORE_LZ4_COMPRESS=y +CONFIG_PSTORE_LZ4HC_COMPRESS=y +CONFIG_PSTORE_842_COMPRESS=y +CONFIG_PSTORE_CONSOLE=y +CONFIG_PSTORE_RAM=y CONFIG_NFS_FS=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y -- 2.26.0
[PATCH v10 3/6] dt-bindings: Add vendor prefix for Acer Inc.
Acer is a hardware and electronics corporation, specializing in advanced electronics technology. Acer's products include desktop PCs, laptop PCs, tablets, servers, displays, storage devices, virtual reality devices, smartphones and peripherals. Their web site is http://www.acer.com/. Acked-by: Rob Herring Signed-off-by: Dmitry Osipenko --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 9aeab66be85f..9f7af78d6864 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -27,6 +27,8 @@ patternProperties: description: Abilis Systems "^abracon,.*": description: Abracon Corporation + "^acer,.*": +description: Acer Inc. "^acme,.*": description: Acme Systems srl "^actions,.*": -- 2.26.0
[PATCH] usb: fix kernel-doc warnings and formatting in
From: Randy Dunlap
Fix kernel-doc warnings in :
../include/linux/usb.h:713: warning: Function parameter or member
'use_generic_driver' not described in 'usb_device'
../include/linux/usb.h:1253: warning: Function parameter or member 'match' not
described in 'usb_device_driver'
../include/linux/usb.h:1253: warning: Function parameter or member 'id_table'
not described in 'usb_device_driver'
Also drop an extra blank line and fix indentation.
Fixes: 77419aa403ca ("USB: Fallback to generic driver when specific driver
fails")
Fixes: 88b7381a939d ("USB: Select better matching USB drivers when available")
Signed-off-by: Randy Dunlap
Cc: Bastien Nocera
---
include/linux/usb.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- linux-next-20200626.orig/include/linux/usb.h
+++ linux-next-20200626/include/linux/usb.h
@@ -620,9 +620,9 @@ struct usb3_lpm_parameters {
* Management to be disabled for this usb_device. This count should only
* be manipulated by those functions, with the bandwidth_mutex is held.
* @hub_delay: cached value consisting of:
- * parent->hub_delay + wHubDelay + tTPTransmissionDelay (40ns)
- *
+ * parent->hub_delay + wHubDelay + tTPTransmissionDelay (40ns)
* Will be used as wValue for SetIsochDelay requests.
+ * @use_generic_driver: ask driver core to reprobe using the generic driver.
*
* Notes:
* Usbcore drivers should not set usbdev->state directly. Instead use
@@ -1215,6 +1215,7 @@ struct usb_driver {
* struct usb_device_driver - identifies USB device driver to usbcore
* @name: The driver name should be unique among USB drivers,
* and should normally be the same as the module name.
+ * @match: If set, used for better device/driver matching.
* @probe: Called to see if the driver is willing to manage a particular
* device. If it is, probe returns zero and uses dev_set_drvdata()
* to associate driver-specific data with the device. If unwilling
@@ -1227,13 +1228,16 @@ struct usb_driver {
* @dev_groups: Attributes attached to the device that will be created once it
* is bound to the driver.
* @drvwrap: Driver-model core structure wrapper.
+ * @id_table: used with @match() to select better matching driver at
+ * probe() time.
* @supports_autosuspend: if set to 0, the USB core will not allow autosuspend
* for devices bound to this driver.
* @generic_subclass: if set to 1, the generic USB driver's probe, disconnect,
* resume and suspend functions will be called in addition to the driver's
* own, so this part of the setup does not need to be replicated.
*
- * USB drivers must provide all the fields listed above except drvwrap.
+ * USB drivers must provide all the fields listed above except drvwrap,
+ * match, and id_table.
*/
struct usb_device_driver {
const char *name;
[Patch V2] arm64: dts: ls1028a: Add DSPI flash nodes for LS1028a-qds
From: Xiaowei Bao
Add the DSPI flash nodes into fsl-ls1028a-qds.dts
Signed-off-by: Xiaowei Bao
Signed-off-by: Zhao Qiang
---
Changes for v2
- correct commit msg
arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 85 +++
1 file changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index dd69c5b..e4f00c2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -107,6 +107,91 @@
};
};
+ {
+ bus-num = <0>;
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ };
+
+ flash@1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ reg = <1>;
+ spi-max-frequency = <1000>;
+ };
+
+ flash@2 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ reg = <2>;
+ spi-max-frequency = <1000>;
+ };
+};
+
+ {
+ bus-num = <1>;
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ };
+
+ flash@1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ reg = <1>;
+ spi-max-frequency = <1000>;
+ };
+
+ flash@2 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ reg = <2>;
+ spi-max-frequency = <1000>;
+ };
+};
+
+ {
+ bus-num = <2>;
+ status = "okay";
+
+ flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ reg = <0>;
+ spi-max-frequency = <1000>;
+ };
+};
+
{
status = "okay";
};
--
2.7.4
[PATCH 3/3 V2] ring-buffer: Add rb_time_t 64 bit operations for speeding up 32 bit
From: "Steven Rostedt (VMware)"
After a discussion with the new time algorithm to have nested events still
have proper time keeping but required using local64_t atomic operations.
Mathieu was concerned about the performance this would have on 32 bit
machines, as in most cases, atomic 64 bit operations on them can be
expensive.
As the ring buffer's timing needs do not require full features of local64_t,
a wrapper is made to implement a new rb_time_t operation that uses two longs
on 32 bit machines but still uses the local64_t operations on 64 bit
machines. There's a switch that can be made in the file to force 64 bit to
use the 32 bit version just for testing purposes.
All reads do not need to succeed if a read happened while the stamp being
read is in the process of being updated. The requirement is that all reads
must succed that were done by an interrupting event (where this event was
interrupted by another event that did the write). Or if the event itself did
the write first. That is: rb_time_set(t, x) followed by rb_time_read(t) will
always succeed (even if it gets interrupted by another event that writes to
t. The result of the read will be either the previous set, or a set
performed by an interrupting event.
If the read is done by an event that interrupted another event that was in
the process of setting the time stamp, and no other event came along to
write to that time stamp, it will fail and the rb_time_read() will return
that it failed (the value to read will be undefined).
A set will always write to the time stamp and return with a valid time
stamp, such that any read after it will be valid.
A cmpxchg may fail if it interrupted an event that was in the process of
updating the time stamp just like the reads do. Other than that, it will act
like a normal cmpxchg.
The way this works is that the rb_time_t is made of of three fields. A cnt,
that gets updated atomically everyting a modification is made. A top that
represents the most significant 30 bits of the time, and a bottom to
represent the least significant 30 bits of the time. Notice, that the time
values is only 60 bits long (where the ring buffer only uses 59 bits, which
gives us 18 years of nanoseconds!).
The top two bits of both the top and bottom is a 2 bit counter that gets set
by the value of the least two significant bits of the cnt. A read of the top
and the bottom where both the top and bottom have the same most significant
top 2 bits, are considered a match and a valid 60 bit number can be created
from it. If they do not match, then the number is considered invalid, and
this must only happen if an event interrupted another event in the midst of
updating the time stamp.
This is only used for 32 bits machines as 64 bit machines can get better
performance out of the local64_t. This has been tested heavily by forcing 64
bit to use this logic.
Link: https://lore.kernel.org/r/20200625225345.18cf5...@oasis.local.home
Inspired-by: Mathieu Desnoyers
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/ring_buffer.c | 262 +
1 file changed, 238 insertions(+), 24 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 7ee6619951ea..350350254a8b 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -27,7 +27,6 @@
#include
#include
-#include
static void update_pages_handler(struct work_struct *work);
@@ -449,6 +448,28 @@ enum {
RB_CTX_MAX
};
+#if BITS_PER_LONG == 32
+#define RB_TIME_32
+#endif
+
+/* To test on 64 bit machines */
+//#define RB_TIME_32
+
+#ifdef RB_TIME_32
+
+struct rb_time_struct {
+ local_t cnt;
+ local_t top;
+ local_t bottom;
+};
+#else
+#include
+struct rb_time_struct {
+ local64_t time;
+};
+#endif
+typedef struct rb_time_struct rb_time_t;
+
/*
* head_page == tail_page && head == tail then buffer is empty.
*/
@@ -484,8 +505,8 @@ struct ring_buffer_per_cpu {
size_t shortest_full;
unsigned long read;
unsigned long read_bytes;
- local64_t write_stamp;
- local64_t before_stamp;
+ rb_time_t write_stamp;
+ rb_time_t before_stamp;
u64 read_stamp;
/* ring buffer pages to update, > 0 to add, < 0 to remove */
longnr_pages_to_update;
@@ -528,6 +549,189 @@ struct ring_buffer_iter {
int missed_events;
};
+#ifdef RB_TIME_32
+
+/*
+ * On 32 bit machines, local64_t is very expensive. As the ring
+ * buffer doesn't need all the features of a true 64 bit atomic,
+ * on 32 bit, it uses these functions (64 still uses local64_t).
+ *
+ * For the ring buffer, 64 bit required operations for the time is
+ * the following:
+ *
+ * - Only need 59 bits
[PATCH 2/3 V2] ring-buffer: Incorporate absolute timestamp into add_timestamp logic
From: "Steven Rostedt (VMware)"
Instead of calling out the absolute test for each time to check if the
ring buffer wants absolute time stamps for all its recording, incorporate it
with the add_timestamp field and turn it into flags for faster processing
between wanting a absolute tag and needing to force one.
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/ring_buffer.c | 40 +-
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 026238c55b0c..7ee6619951ea 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -422,13 +422,15 @@ struct rb_event_info {
/*
* Used for the add_timestamp
* NONE
- * NORMAL - may be for either time extend or absolute
+ * EXTEND - wants a time extend
+ * ABSOLUTE - the buffer requests all events to have absolute time stamps
* FORCE - force a full time stamp.
*/
enum {
- RB_ADD_STAMP_NONE,
- RB_ADD_STAMP_NORMAL,
- RB_ADD_STAMP_FORCE
+ RB_ADD_STAMP_NONE = 0,
+ RB_ADD_STAMP_EXTEND = BIT(1),
+ RB_ADD_STAMP_ABSOLUTE = BIT(2),
+ RB_ADD_STAMP_FORCE = BIT(3)
};
/*
* Used for which event context the event is in.
@@ -2434,8 +2436,8 @@ rb_update_event(struct ring_buffer_per_cpu *cpu_buffer,
* add it to the start of the reserved space.
*/
if (unlikely(info->add_timestamp)) {
- bool abs = info->add_timestamp == RB_ADD_STAMP_FORCE ||
- ring_buffer_time_stamp_abs(cpu_buffer->buffer);
+ bool abs = info->add_timestamp &
+ (RB_ADD_STAMP_FORCE | RB_ADD_STAMP_ABSOLUTE);
event = rb_add_time_stamp(event, abs ? info->delta : delta,
abs);
length -= RB_LEN_TIME_EXTEND;
@@ -2884,8 +2886,8 @@ int ring_buffer_unlock_commit(struct trace_buffer *buffer,
EXPORT_SYMBOL_GPL(ring_buffer_unlock_commit);
static noinline void
-rb_handle_timestamp(struct ring_buffer_per_cpu *cpu_buffer,
- struct rb_event_info *info)
+rb_check_timestamp(struct ring_buffer_per_cpu *cpu_buffer,
+ struct rb_event_info *info)
{
WARN_ONCE(info->delta > (1ULL << 59),
KERN_WARNING "Delta way too big! %llu ts=%llu write stamp =
%llu\n%s",
@@ -2897,7 +2899,6 @@ rb_handle_timestamp(struct ring_buffer_per_cpu
*cpu_buffer,
"please switch to the trace global clock:\n"
" echo global > /sys/kernel/debug/tracing/trace_clock\n"
"or add trace_clock=global to the kernel command line\n");
- info->add_timestamp = RB_ADD_STAMP_NORMAL;
}
static struct ring_buffer_event *
@@ -2908,7 +2909,6 @@ __rb_reserve_next(struct ring_buffer_per_cpu *cpu_buffer,
struct buffer_page *tail_page;
unsigned long tail, write, w;
u64 before, after;
- bool abs = false;
/* Don't let the compiler play games with cpu_buffer->tail_page */
tail_page = info->tail_page = READ_ONCE(cpu_buffer->tail_page);
@@ -2922,20 +2922,23 @@ __rb_reserve_next(struct ring_buffer_per_cpu
*cpu_buffer,
if (ring_buffer_time_stamp_abs(cpu_buffer->buffer)) {
info->delta = info->ts;
- abs = true;
+ info->add_timestamp = RB_ADD_STAMP_ABSOLUTE;
} else {
info->delta = info->ts - after;
}
- if (unlikely(test_time_stamp(info->delta)))
- rb_handle_timestamp(cpu_buffer, info);
+ if (unlikely(test_time_stamp(info->delta))) {
+ rb_check_timestamp(cpu_buffer, info);
+ info->add_timestamp |= RB_ADD_STAMP_EXTEND;
+ }
/*
* If interrupting an event time update, we may need an absolute
timestamp.
* Don't bother if this is the start of a new page (w == 0).
*/
if (unlikely(before != after && w))
- info->add_timestamp = RB_ADD_STAMP_FORCE;
+ info->add_timestamp |= RB_ADD_STAMP_FORCE | RB_ADD_STAMP_EXTEND;
+
/*
* If the time delta since the last event is too big to
* hold in the time field of the event, then we append a
@@ -2972,7 +2975,8 @@ __rb_reserve_next(struct ring_buffer_per_cpu *cpu_buffer,
/*D*/ local64_set(_buffer->write_stamp, info->ts);
barrier();
/*E*/ save_before = local64_read(_buffer->before_stamp);
- if (likely(info->add_timestamp != RB_ADD_STAMP_FORCE))
+ if (likely(!(info->add_timestamp &
+(RB_ADD_STAMP_FORCE | RB_ADD_STAMP_ABSOLUTE
/* This did not interrupt any time update */
info->delta = info->ts - after;
else
@@ -3015,15 +3019,15 @@ __rb_reserve_next(struct ring_buffer_per_cpu
*cpu_buffer,
*/
[PATCH 1/3 V2] ring-buffer: Have nested events still record running time stamp
From: "Steven Rostedt (VMware)"
Up until now, if an event is interrupted while it is recorded by an
interrupt, and that interrupt records events, the time of those events will
all be the same. This is because events only record the delta of the time
since the previous event (or beginning of a page), and to handle updating
the time keeping for that of nested events is extremely racy. After years of
thinking about this and several failed attempts, I finally have a solution
to solve this puzzle.
The problem is that you need to atomically calculate the delta and then
update the time stamp you made the delta from, as well as then record it
into the buffer, all this while at any time an interrupt can come in and
do the same thing. This is easy to solve with heavy weight atomics, but that
would be detrimental to the performance of the ring buffer. The current
state of affairs sacrificed the time deltas for nested events for
performance.
The reason for previous failed attempts at solving this puzzle was because I
was trying to completely avoid slow atomic operations like cmpxchg. I final
came to the conclusion to always avoid cmpxchg is not possible, which is why
those previous attempts always failed. But it is possible to pick one path
(the most common case) and avoid cmpxchg in that path, which is the "fast
path". The most common case is that an event will not be interrupted and
have other events added into it. An event can detect if it has
interrupted another event, and for these cases we can make it the slow
path and use the heavy operations like cmpxchg.
One more player was added to the game that made this possible, and that is
the "absolute timestamp" (by Tom Zanussi) that allows us to inject a full 59
bit time stamp. (Of course this breaks if a machine is running for more than
18 years without a reboot!).
There's barrier() placements around for being paranoid, even when they
are not needed because of other atomic functions near by. But those
should not hurt, as if they are not needed, they basically become a nop.
Note, this also makes the race window much smaller, which means there
are less slow paths to slow down the performance.
Here's the design of this solution:
All this is per cpu, and only needs to worry about nested events (not
parallel events).
The players:
write_tail: The index in the buffer where new events can be written to.
It is incremented via local_add() to reserve space for a new event.
before_stamp: A time stamp set by all events before reserving space.
write_stamp: A time stamp updated by events after it has successfully
reserved space.
/* Save the current position of write */
[A]w = local_read(write_tail);
barrier();
/* Read both before and write stamps before touching anything */
before = local_read(before_stamp);
after = local_read(write_stamp);
barrier();
/*
* If before and after are the same, then this event is not
* interrupting a time update. If it is, then reserve space for adding
* a full time stamp (this can turn into a time extend which is
* just an extended time delta but fill up the extra space).
*/
if (after != before)
abs = true;
ts = clock();
/* Now update the before_stamp (everyone does this!) */
[B]local_set(before_stamp, ts);
/* Now reserve space on the buffer */
[C]write = local_add_return(len, write_tail);
/* Set tail to be were this event's data is */
tail = write - len;
if (w == tail) {
/* Nothing interrupted this between A and C */
[D]local_set(write_stamp, ts);
barrier();
[E]save_before = local_read(before_stamp);
if (!abs) {
/* This did not interrupt a time update */
delta = ts - after;
} else {
delta = ts; /* The full time stamp will be in use */
}
if (ts != save_before) {
/* slow path - Was interrupted between C and E */
/* The update to write_stamp could have overwritten the
update to
* it by the interrupting event, but before and after
should be
* the same for all completed top events */
after = local_read(write_stamp);
if (save_before > after)
local_cmpxchg(write_stamp, after, save_before);
}
} else {
/* slow path - Interrupted between A and C */
after = local_read(write_stamp);
temp_ts = clock();
barrier();
[F]if (write == local_read(write_tail) && after < temp_ts) {
/* This was not interrupted since C and F
* The last
[PATCH 0/3 V2] ring-buffer: Restructure ftrace ring buffer time keeping to allow accurate nested timing
V1 of this patch set can be found here: https://lore.kernel.org/r/20200627010041.517736...@goodmis.org Changes since V1 patch set: - Fixed white space issues (kernel test robot) - Fixed change log algorithm to match the code (Masami Hiramatsu) - Removed next_write useless code. (Masami Hiramatsu) Head SHA1: 72c27b3e97be0b2fca6b5518d299bccbc714a245 Steven Rostedt (VMware) (3): ring-buffer: Have nested events still record running time stamp ring-buffer: Incorporate absolute timestamp into add_timestamp logic ring-buffer: Add rb_time_t 64 bit operations for speeding up 32 bit kernel/trace/ring_buffer.c | 498 - 1 file changed, 401 insertions(+), 97 deletions(-)
Re: [PATCH] rtlwifi/*/dm.c: Use const in swing_table declarations
On 2020-06-28 19:09, Pkshih wrote:
On Sun, 2020-06-28 at 03:17 -0700, Joe Perches wrote:
Use 'rtlwifi:' as subject title prefix is enough, likes
rtlwifi: Use const in swing_table declarations
We disagree.
I like knowing what content is changed via patch subject lines
as there are 3 rtlwifi drivers being changed by this one patch.
But your choice, you can change it if you choose.
Reduce data usage about 1KB by using const.
[]
Please remove below type casting:
@@ -1872,10 +1872,10 @@ static void
rtl8821ae_get_delta_swing_table(struct
ieee80211_hw *hw,
*up_b = rtl8821ae_delta_swing_table_idx_5gb_p[2];
*down_b = rtl8821ae_delta_swing_table_idx_5gb_n[2];
} else {
- *up_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
- *down_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
- *up_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
- *down_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
+ *up_a = rtl8818e_delta_swing_table_idx_24gb_p;
+ *down_a = rtl8818e_delta_swing_table_idx_24gb_n;
+ *up_b = rtl8818e_delta_swing_table_idx_24gb_p;
+ *down_b = rtl8818e_delta_swing_table_idx_24gb_n;
The compiler is quiet about this so I believe this to be
an unrelated change and whitespace correction.
Of course you could modify it if you choose.
btw: There's an unnecessary return at the 2nd instance
of this cast removal too.
cheers, Joe
RE: [PATCH V3] firmware: imx: Move i.MX SCU soc driver into imx firmware folder
> From: Anson Huang > Sent: Friday, June 26, 2020 5:14 AM > > The i.MX SCU soc driver depends on SCU firmware driver, so it has to use > platform driver model for proper defer probe operation, since it has no device > binding in DT file, a simple platform device is created together inside the > platform driver. To make it more clean, we can just move the entire SCU soc > driver into imx firmware folder and initialized by i.MX SCU firmware driver. > > Signed-off-by: Anson Huang Reviewed-by: Dong Aisheng Regards Aisheng
RE: [PATCH/RFC v4 3/4] mmc: core: Call mmc_poweroff_nofity() if regulators are disabled
Hi Mark, > From: Mark Brown, Sent: Saturday, June 27, 2020 12:14 AM > > On Fri, Jun 26, 2020 at 06:32:21PM +0900, Yoshihiro Shimoda wrote: > > Note that this is possible to happen when the regulator-fixed driver > > turns the vmmc and vqmmc off by firmware like PSCI while the system > > is suspended. > > This is not a good interface, if there's a need to query the state over > suspend then we should query the state over suspend rather than trying > to somehow shoehorn it via the runtime enable state which is going to > break any other users and relies on the regulator driver doing dodgy > stuff representing the enable state. I understood it. So, as I mentioned other email thread, I'm thinking adding a new property into MMC is better. Best regards, Yoshihiro Shimoda
Re: [PATCH v1] mm:free unused pages in kmalloc_order
On Sat, Jun 27, 2020 at 04:55:07AM +, Long Li wrote:
> Environment using the slub allocator, 1G memory in my ARM32.
> kmalloc(1024, GFP_HIGHUSER) can allocate memory normally,
> kmalloc(64*1024, GFP_HIGHUSER) will cause a memory leak, because
> alloc_pages returns highmem physical pages, but it cannot be directly
> converted into a virtual address and return NULL, the pages has not
> been released. Usually driver developers will not use the
> GFP_HIGHUSER flag to allocate memory in kmalloc, but I think this
> memory leak is not perfect, it is best to be fixed. This is the
> first time I have posted a patch, there may be something wrong.
Slab used to disallow GFP_HIGHMEM allocations earlier than this,
so you'd never get here. See one moron's patch here, 20 years ago ...
https://lore.kernel.org/lkml/20001228145801.c19...@parcelfarce.linux.theplanet.co.uk/
Things changed a bit since then. SLAB_LEVEL_MASK became GFP_SLAB_BUG_MASK,
then GFP_SLAB_BUG_MASK moved to mm/internal.h. Nowadays, GFP_SLAB_BUG_MASK
is checked only in new_slab(), and it is definitely skipped when we go through
the kmalloc_large() patch.
Could you send a replacement patch which checks GFP_SLAB_BUG_MASK before
calling alloc_pages()?
> +++ b/mm/slab_common.c
> @@ -819,8 +819,12 @@ void *kmalloc_order(size_t size, gfp_t flags, unsigned
> int order)
> page = alloc_pages(flags, order);
> if (likely(page)) {
> ret = page_address(page);
> - mod_node_page_state(page_pgdat(page), NR_SLAB_UNRECLAIMABLE_B,
> - PAGE_SIZE << order);
> + if (ret)
> + mod_node_page_state(page_pgdat(page),
> + NR_SLAB_UNRECLAIMABLE_B,
> + PAGE_SIZE << order);
> + else
> + __free_pages(page, order);
> }
> ret = kasan_kmalloc_large(ret, size, flags);
> /* As ret might get tagged, call kmemleak hook after KASAN. */
> --
> 2.17.1
>
>
RE: [PATCH/RFC v4 2/4] regulator: fixed: add regulator_ops members for suspend/resume
Hi Mark,
> From: Mark Brown, Sent: Friday, June 26, 2020 11:39 PM
>
> On Fri, Jun 26, 2020 at 06:32:20PM +0900, Yoshihiro Shimoda wrote:
>
> > +static int reg_is_enabled(struct regulator_dev *rdev)
> > +{
> > + struct fixed_voltage_data *priv = rdev_get_drvdata(rdev);
> > +
> > + return !priv->disabled_in_suspend;
> > +}
>
> This is broken, the state of the regualtor during system runtime need
> have no connection with the state of the regulator during system
> suspend.
>
> > +static int reg_prepare_disable(struct regulator_dev *rdev)
> > +{
> > + struct fixed_voltage_data *priv = rdev_get_drvdata(rdev);
> > +
> > + priv->disabled_in_suspend = true;
> > +
> > + return 0;
> > +}
>
> According to the changelog this is all about reflecting changes in the
> system state done by firmware but there's no interaction with firmware
> here which means this will be at best fragile. If we need to reflect
> changes in firmware configuration I'd expect there to be some
> interaction with firmware about how it is configured, or at least that
> the configuration would come from the same source.
I should have described background of previous patch series though,
according to previous discussion [1] the firmware side (like PSCI) is
also fragile unfortunately... So, I thought using regulator-off-in-suspend
in a regulator was better.
On other hand, Ulf is talking about either adding a property (perhaps like
regulator-off-in-suspend) into a regulator or just adding a new property
into MMC [2]. What do you think about Ulf' comment? I'm thinking
adding a new property "full-pwr-cycle-in-suspend" is the best solution.
This is because using a regulator property and reflecting a state of regulator
without
firmware is fragile, as you said.
[1]
https://lore.kernel.org/linux-renesas-soc/CAMuHMdXjU7N4oG89YsozGijMpjgKGN6ezw2qm6FeGX=jyrh...@mail.gmail.com/
[2]
https://lore.kernel.org/linux-renesas-soc/CAPDyKFpiBU1D+a7zb+Ggm0_HZ+YR4=LXJZ5MPytXtT=ubed...@mail.gmail.com/
Best regards,
Yoshihiro Shimoda
Re: [PATCH v2] PM / devfreq: rk3399_dmc: Fix kernel oops when rockchip,pmu is absent
Hi Marc,
On 6/23/20 12:28 AM, Marc Zyngier wrote:
> Booting a recent kernel on a rk3399-based system (nanopc-t4),
> equipped with a recent u-boot and ATF results in the following:
>
> [5.607431] Unable to handle kernel NULL pointer dereference at virtual
> address 01e4
> [5.608219] Mem abort info:
> [5.608469] ESR = 0x9604
> [5.608749] EC = 0x25: DABT (current EL), IL = 32 bits
> [5.609223] SET = 0, FnV = 0
> [5.609600] EA = 0, S1PTW = 0
> [5.609891] Data abort info:
> [5.610149] ISV = 0, ISS = 0x0004
> [5.610489] CM = 0, WnR = 0
> [5.610757] user pgtable: 4k pages, 48-bit VAs, pgdp=e62fb000
> [5.611326] [01e4] pgd=, p4d=
> [5.611931] Internal error: Oops: 9604 [#1] SMP
> [5.612363] Modules linked in: rockchip_thermal(E+) rk3399_dmc(E+)
> soundcore(E) dw_wdt(E) rockchip_dfi(E) nvmem_rockchip_efuse(E)
> pwm_rockchip(E) cfg80211(E+) rockchip_saradc(E) industrialio(E) rfkill(E)
> cpufreq_dt(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc32c_generic(E)
> crc16(E) mbcache(E) jbd2(E) realtek(E) nvme(E) nvme_core(E) t10_pi(E)
> xhci_plat_hcd(E) xhci_hcd(E) rtc_rk808(E) rk808_regulator(E) clk_rk808(E)
> dwc3(E) udc_core(E) roles(E) ulpi(E) rk808(E) fan53555(E) rockchipdrm(E)
> analogix_dp(E) dw_hdmi(E) cec(E) dw_mipi_dsi(E) fixed(E) dwc3_of_simple(E)
> phy_rockchip_emmc(E) gpio_keys(E) drm_kms_helper(E) phy_rockchip_inno_usb2(E)
> ehci_platform(E) dwmac_rk(E) stmmac_platform(E) phy_rockchip_pcie(E)
> ohci_platform(E) ohci_hcd(E) rockchip_io_domain(E) stmmac(E)
> phy_rockchip_typec(E) ehci_hcd(E) sdhci_of_arasan(E) mdio_xpcs(E)
> sdhci_pltfm(E) cqhci(E) drm(E) sdhci(E) phylink(E) of_mdio(E) usbcore(E)
> i2c_rk3x(E) dw_mmc_rockchip(E) dw_mmc_pltfm(E) dw_mmc(E) fixed_phy(E)
> libphy(E)
> [5.612454] pl330(E)
> [5.620255] CPU: 1 PID: 270 Comm: systemd-udevd Tainted: GE
> 5.7.0-13692-g83ae758d8b22 #1157
> [5.621110] Hardware name: rockchip evb_rk3399/evb_rk3399, BIOS
> 2020.07-rc4-00023-g10d4cafe0f 06/10/2020
> [5.621947] pstate: 4005 (nZcv daif -PAN -UAO BTYPE=--)
> [5.622446] pc : regmap_read+0x1c/0x80
> [5.622787] lr : rk3399_dmcfreq_probe+0x6a4/0x8c0 [rk3399_dmc]
> [5.623299] sp : 8000126cb8a0
> [5.623594] x29: 8000126cb8a0 x28: 8000126cbdb0
> [5.624063] x27: f22dac40 x26: f6779800
> [5.624533] x25: f6779810 x24: ffea
> [5.625002] x23: ffea x22: f65b74c8
> [5.625471] x21: f783ca08 x20: f65b7480
> [5.625941] x19: x18: 0001
> [5.626410] x17: x16:
> [5.626878] x15: f22db138 x14:
> [5.627347] x13: 0018 x12: 80001106a8c7
> [5.627817] x11: 0003 x10: 0101010101010101
> [5.627861] systemd[1]: Found device SPCC M.2 PCIE SSD 3.
> [5.628286] x9 : 88d7c89c x8 : 7f7f7f7f7f7f7f7f
> [5.629238] x7 : fefefeff646c606d x6 : 1c0e0e0ee3e8e9f0
> [5.629709] x5 : 706968630e0e0e1c x4 : 80808080
> [5.630178] x3 : 937b1b5b1b434b80 x2 : 8000126cb944
> [5.630648] x1 : 0308 x0 :
> [5.631119] Call trace:
> [5.631346] regmap_read+0x1c/0x80
> [5.631654] rk3399_dmcfreq_probe+0x6a4/0x8c0 [rk3399_dmc]
> [5.632142] platform_drv_probe+0x5c/0xb0
> [5.632500] really_probe+0xe4/0x448
> [5.632819] driver_probe_device+0xfc/0x168
> [5.633191] device_driver_attach+0x7c/0x88
> [5.633567] __driver_attach+0xac/0x178
> [5.633914] bus_for_each_dev+0x78/0xc8
> [5.634261] driver_attach+0x2c/0x38
> [5.634582] bus_add_driver+0x14c/0x230
> [5.634925] driver_register+0x6c/0x128
> [5.635269] __platform_driver_register+0x50/0x60
> [5.635692] rk3399_dmcfreq_driver_init+0x2c/0x1000 [rk3399_dmc]
> [5.636226] do_one_initcall+0x50/0x230
> [5.636569] do_init_module+0x60/0x248
> [5.636902] load_module+0x21f8/0x28d8
> [5.637237] __do_sys_finit_module+0xb0/0x118
> [5.637627] __arm64_sys_finit_module+0x28/0x38
> [5.638031] el0_svc_common.constprop.0+0x7c/0x1f8
> [5.638456] do_el0_svc+0x2c/0x98
> [5.638754] el0_svc+0x18/0x48
> [5.639029] el0_sync_handler+0x8c/0x2d4
> [5.639378] el0_sync+0x158/0x180
> [5.639680] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941e400)
> [5.640221] ---[ end trace 63675fe5d0021970 ]---
>
> This turns out to be due to the rk3399-dmc driver looking for
> an *undocumented* property (rockchip,pmu), and happily using
> a NULL pointer when the property isn't there.
>
> Instead, make most of what was brought in with 9173c5ceb035
> ("PM / devfreq: rk3399_dmc: Pass ODT and auto power down parameters
> to TF-A.") conditioned on finding this property in the device-tree,
> preventing the driver from exploding.
>
> Fixes:
[PATCH v7 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 SoC SMMU topology.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 3 +
drivers/iommu/arm-smmu-nvidia.c | 195
drivers/iommu/arm-smmu.h| 1 +
5 files changed, 202 insertions(+), 1 deletion(-)
create mode 100644 drivers/iommu/arm-smmu-nvidia.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7b5ffd646c6b9..64c37dbdd4426 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16808,8 +16808,10 @@ F: drivers/i2c/busses/i2c-tegra.c
TEGRA IOMMU DRIVERS
M: Thierry Reding
+R: Krishna Reddy
L: linux-te...@vger.kernel.org
S: Supported
+F: drivers/iommu/arm-smmu-nvidia.c
F: drivers/iommu/tegra*
TEGRA KBC DRIVER
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 342190196dfb0..2b8203db73ec3 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_AMD_IOMMU) += amd/iommu.o amd/init.o amd/quirks.o
obj-$(CONFIG_AMD_IOMMU_DEBUGFS) += amd/debugfs.o
obj-$(CONFIG_AMD_IOMMU_V2) += amd/iommu_v2.o
obj-$(CONFIG_ARM_SMMU) += arm_smmu.o
-arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-qcom.o
+arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-nvidia.o arm-smmu-qcom.o
obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
obj-$(CONFIG_DMAR_TABLE) += intel/dmar.o
obj-$(CONFIG_INTEL_IOMMU) += intel/iommu.o intel/pasid.o
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
index c75b9d957b702..70f7318017617 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -171,6 +171,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
if (of_property_read_bool(np, "calxeda,smmu-secure-config-access"))
smmu->impl = _impl;
+ if (of_device_is_compatible(smmu->dev->of_node, "nvidia,tegra194-smmu"))
+ return nvidia_smmu_impl_init(smmu);
+
if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
of_device_is_compatible(np, "qcom,sc7180-smmu-500"))
return qcom_smmu_impl_init(smmu);
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
new file mode 100644
index 0..b73c483fa3376
--- /dev/null
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// NVIDIA ARM SMMU v2 implementation quirks
+// Copyright (C) 2019-2020 NVIDIA CORPORATION. All rights reserved.
+
+#include
+#include
+#include
+#include
+#include
+
+#include "arm-smmu.h"
+
+/*
+ * Tegra194 has three ARM MMU-500 Instances.
+ * Two of them are used together for interleaved IOVA accesses and
+ * used by non-isochronous HW devices for SMMU translations.
+ * Third one is used for SMMU translations from isochronous HW devices.
+ * It is possible to use this implementation to program either
+ * all three or two of the instances identically as desired through
+ * DT node.
+ *
+ * Programming all the three instances identically comes with redundant TLB
+ * invalidations as all three never need to be TLB invalidated for a HW device.
+ *
+ * When Linux kernel supports multiple SMMU devices, the SMMU device used for
+ * isochornous HW devices should be added as a separate ARM MMU-500 device
+ * in DT and be programmed independently for efficient TLB invalidates.
+ */
+#define MAX_SMMU_INSTANCES 3
+
+#define TLB_LOOP_TIMEOUT_IN_US 100 /* 1s! */
+#define TLB_SPIN_COUNT 10
+
+struct nvidia_smmu {
+ struct arm_smmu_device smmu;
+ unsigned intnum_inst;
+ void __iomem*bases[MAX_SMMU_INSTANCES];
+};
+
+static inline struct nvidia_smmu *to_nvidia_smmu(struct arm_smmu_device *smmu)
+{
+ return container_of(smmu, struct nvidia_smmu, smmu);
+}
+
+static inline void __iomem *nvidia_smmu_page(struct arm_smmu_device *smmu,
+ unsigned int inst, int page)
+{
+ struct nvidia_smmu *nvidia_smmu = to_nvidia_smmu(smmu);
+
+ if (!nvidia_smmu->bases[0])
+ nvidia_smmu->bases[0] = smmu->base;
+
+ return nvidia_smmu->bases[inst] + (page << smmu->pgshift);
+}
+
+static u32 nvidia_smmu_read_reg(struct arm_smmu_device *smmu,
+ int page, int offset)
+{
+ void __iomem *reg = nvidia_smmu_page(smmu, 0, page) + offset;
+
+ return readl_relaxed(reg);
+}
+
+static void nvidia_smmu_write_reg(struct arm_smmu_device *smmu,
+ int page, int offset, u32 val)
+{
+ unsigned int i;
+ struct nvidia_smmu *nvidia_smmu = to_nvidia_smmu(smmu);
+
+ for (i = 0; i < nvidia_smmu->num_inst; i++) {
+ void __iomem *reg = nvidia_smmu_page(smmu, i, page) + offset;
+
+
[PATCH v7 3/3] iommu/arm-smmu: Add global/context fault implementation hooks
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 101 +++-
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu/arm-smmu.h| 3 +
3 files changed, 118 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
index b73c483fa3376..7276bb203ae79 100644
--- a/drivers/iommu/arm-smmu-nvidia.c
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -147,6 +147,102 @@ static int nvidia_smmu_reset(struct arm_smmu_device *smmu)
return 0;
}
+static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
+{
+ return container_of(dom, struct arm_smmu_domain, domain);
+}
+
+static irqreturn_t nvidia_smmu_global_fault_inst(int irq,
+ struct arm_smmu_device *smmu,
+ int inst)
+{
+ u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
+ void __iomem *gr0_base = nvidia_smmu_page(smmu, inst, 0);
+
+ gfsr = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSR);
+ gfsynr0 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR0);
+ gfsynr1 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR1);
+ gfsynr2 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR2);
+
+ if (!gfsr)
+ return IRQ_NONE;
+
+ dev_err_ratelimited(smmu->dev,
+ "Unexpected global fault, this could be serious\n");
+ dev_err_ratelimited(smmu->dev,
+ "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2
0x%08x\n",
+ gfsr, gfsynr0, gfsynr1, gfsynr2);
+
+ writel_relaxed(gfsr, gr0_base + ARM_SMMU_GR0_sGFSR);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t nvidia_smmu_global_fault(int irq, void *dev)
+{
+ int inst;
+ irqreturn_t irq_ret = IRQ_NONE;
+ struct arm_smmu_device *smmu = dev;
+ struct nvidia_smmu *nvidia_smmu = to_nvidia_smmu(smmu);
+
+ for (inst = 0; inst < nvidia_smmu->num_inst; inst++) {
+ irq_ret = nvidia_smmu_global_fault_inst(irq, smmu, inst);
+ if (irq_ret == IRQ_HANDLED)
+ return irq_ret;
+ }
+
+ return irq_ret;
+}
+
+static irqreturn_t nvidia_smmu_context_fault_bank(int irq,
+ struct arm_smmu_device *smmu,
+ int idx, int inst)
+{
+ u32 fsr, fsynr, cbfrsynra;
+ unsigned long iova;
+ void __iomem *gr1_base = nvidia_smmu_page(smmu, inst, 1);
+ void __iomem *cb_base = nvidia_smmu_page(smmu, inst, smmu->numpage +
idx);
+
+ fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
+ if (!(fsr & ARM_SMMU_FSR_FAULT))
+ return IRQ_NONE;
+
+ fsynr = readl_relaxed(cb_base + ARM_SMMU_CB_FSYNR0);
+ iova = readq_relaxed(cb_base + ARM_SMMU_CB_FAR);
+ cbfrsynra = readl_relaxed(gr1_base + ARM_SMMU_GR1_CBFRSYNRA(idx));
+
+ dev_err_ratelimited(smmu->dev,
+ "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x,
cbfrsynra=0x%x, cb=%d\n",
+ fsr, iova, fsynr, cbfrsynra, idx);
+
+ writel_relaxed(fsr, cb_base + ARM_SMMU_CB_FSR);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t nvidia_smmu_context_fault(int irq, void *dev)
+{
+ int inst, idx;
+ irqreturn_t irq_ret = IRQ_NONE;
+ struct iommu_domain *domain = dev;
+ struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+ struct arm_smmu_device *smmu = smmu_domain->smmu;
+
+ for (inst = 0; inst < to_nvidia_smmu(smmu)->num_inst; inst++) {
+ /*
+* Interrupt line shared between all context faults.
+* Check for faults across all contexts.
+*/
+ for (idx = 0; idx < smmu->num_context_banks; idx++) {
+ irq_ret = nvidia_smmu_context_fault_bank(irq, smmu,
+idx, inst);
+
+ if (irq_ret == IRQ_HANDLED)
+ return irq_ret;
+ }
+ }
+
+ return irq_ret;
+}
+
static const struct arm_smmu_impl nvidia_smmu_impl = {
.read_reg = nvidia_smmu_read_reg,
.write_reg = nvidia_smmu_write_reg,
@@ -154,6 +250,8 @@ static const struct arm_smmu_impl nvidia_smmu_impl = {
.write_reg64 = nvidia_smmu_write_reg64,
.reset = nvidia_smmu_reset,
.tlb_sync = nvidia_smmu_tlb_sync,
+ .global_fault = nvidia_smmu_global_fault,
+ .context_fault = nvidia_smmu_context_fault,
};
struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
@@ -185,7 +283,8 @@ struct arm_smmu_device *nvidia_smmu_impl_init(struct
arm_smmu_device *smmu)
}
nvidia_smmu->smmu.impl = _smmu_impl;
- /* Free the arm_smmu_device struct allocated
[PATCH v7 0/3] Nvidia Arm SMMUv2 Implementation
Changes in v7: Incorporated the review feedback from Nicolin Chen, Robin Murphy and Thierry Reding. Rebased and validated patches on top of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next v6- https://lkml.org/lkml/2020/6/4/1018 v5 - https://lkml.org/lkml/2020/5/21/1114 v4 - https://lkml.org/lkml/2019/10/30/1054 v3 - https://lkml.org/lkml/2019/10/18/1601 v2 - https://lkml.org/lkml/2019/9/2/980 v1 - https://lkml.org/lkml/2019/8/29/1588 Krishna Reddy (3): iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage dt-bindings: arm-smmu: Add binding for Tegra194 SMMU iommu/arm-smmu: Add global/context fault implementation hooks .../devicetree/bindings/iommu/arm,smmu.yaml | 5 + MAINTAINERS | 2 + drivers/iommu/Makefile| 2 +- drivers/iommu/arm-smmu-impl.c | 3 + drivers/iommu/arm-smmu-nvidia.c | 294 ++ drivers/iommu/arm-smmu.c | 17 +- drivers/iommu/arm-smmu.h | 4 + 7 files changed, 324 insertions(+), 3 deletions(-) create mode 100644 drivers/iommu/arm-smmu-nvidia.c base-commit: 48f0bcfb7aad2c6eb4c1e66476b58475aa14393e -- 2.26.2
[PATCH v7 2/3] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based on ARM MMU-500. Signed-off-by: Krishna Reddy --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index d7ceb4c34423b..5b2586ac715ed 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -38,6 +38,11 @@ properties: - qcom,sc7180-smmu-500 - qcom,sdm845-smmu-500 - const: arm,mmu-500 + - description: NVIDIA SoCs that use more than one "arm,mmu-500" +items: + - enum: + - nvdia,tegra194-smmu + - const: arm,mmu-500 - items: - const: arm,mmu-500 - const: arm,smmu-v2 -- 2.26.2
Re: [PATCH] fpga: dfl: improve configuration of dfl pci devices
I think maybe we don't have to select them all. It is now possible for FPGA DFL boards to work without FME or AFU, providing limited functionality. It is possible designers trim the bitstream for their purpose, and also need a smaller driver set. I think we may add "default FPGA_DFL" for FPGA_DFL_FME, FPGA_DFL_FME_MGR and others to make life easier. How do you think? On Sun, Jun 28, 2020 at 08:18:13AM -0700, t...@redhat.com wrote: > From: Tom Rix > > To use a dfl pci device, several dfl configs need to be selected. > This is tedious and error prone. > > So automagically select the needed configs when FPGA_DFL_PCI > is selected. > > Signed-off-by: Tom Rix > --- > drivers/fpga/Kconfig | 36 +--- > 1 file changed, 21 insertions(+), 15 deletions(-) > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > index 7cd5a29fc437..4b9e05af5426 100644 > --- a/drivers/fpga/Kconfig > +++ b/drivers/fpga/Kconfig > @@ -138,6 +138,27 @@ config OF_FPGA_REGION > Support for loading FPGA images by applying a Device Tree > overlay. > > +config FPGA_DFL_PCI > + tristate "FPGA DFL PCIe Device Driver" > + depends on PCI > + select FPGA_DFL > + select FPGA_DFL_FME > + select FPGA_DFL_FME_MGR > + select FPGA_DFL_FME_BRIDGE > + select FPGA_DFL_FME_REGION > + select FPGA_DFL_AFU > + help > + Select this option to enable PCIe driver for PCIe-based > + Field-Programmable Gate Array (FPGA) solutions which implement > + the Device Feature List (DFL). This driver provides interfaces > + for userspace applications to configure, enumerate, open and access > + FPGA accelerators on the FPGA DFL devices, enables system level > + management functions such as FPGA partial reconfiguration, power > + management and virtualization with DFL framework and DFL feature > + device drivers. > + > + To compile this as a module, choose M here. > + > config FPGA_DFL > tristate "FPGA Device Feature List (DFL) support" > select FPGA_BRIDGE > @@ -191,21 +212,6 @@ config FPGA_DFL_AFU > to the FPGA infrastructure via a Port. There may be more than one > Port/AFU per DFL based FPGA device. > > -config FPGA_DFL_PCI > - tristate "FPGA DFL PCIe Device Driver" > - depends on PCI && FPGA_DFL > - help > - Select this option to enable PCIe driver for PCIe-based > - Field-Programmable Gate Array (FPGA) solutions which implement > - the Device Feature List (DFL). This driver provides interfaces > - for userspace applications to configure, enumerate, open and access > - FPGA accelerators on the FPGA DFL devices, enables system level > - management functions such as FPGA partial reconfiguration, power > - management and virtualization with DFL framework and DFL feature > - device drivers. > - > - To compile this as a module, choose M here. > - > config FPGA_MGR_ZYNQMP_FPGA > tristate "Xilinx ZynqMP FPGA" > depends on ZYNQMP_FIRMWARE || (!ZYNQMP_FIRMWARE && COMPILE_TEST) > -- > 2.18.1
[v1,net-next] net:qos: police action offloading parameter 'burst' change to the original value
Since 'tcfp_burst' with TICK factor, driver side always need to recover
it to the original value, this patch moves the generic calculation and
recover to the 'burst' original value before offloading to device driver.
Signed-off-by: Po Liu
Signed-off-by: Vladimir Oltean
---
drivers/net/dsa/ocelot/felix.c| 4 +--
drivers/net/dsa/sja1105/sja1105_flower.c | 16 --
drivers/net/dsa/sja1105/sja1105_main.c| 4 +--
.../net/ethernet/freescale/enetc/enetc_qos.c | 8 +
drivers/net/ethernet/mscc/ocelot_flower.c | 4 +--
drivers/net/ethernet/mscc/ocelot_net.c| 4 +--
.../ethernet/netronome/nfp/flower/qos_conf.c | 6 ++--
include/net/dsa.h | 2 +-
include/net/flow_offload.h| 2 +-
include/net/tc_act/tc_police.h| 32 +--
net/sched/cls_api.c | 2 +-
11 files changed, 48 insertions(+), 36 deletions(-)
diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 25046777c993..75020af7f7a4 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -746,9 +746,7 @@ static int felix_port_policer_add(struct dsa_switch *ds,
int port,
struct ocelot *ocelot = ds->priv;
struct ocelot_policer pol = {
.rate = div_u64(policer->rate_bytes_per_sec, 1000) * 8,
- .burst = div_u64(policer->rate_bytes_per_sec *
-PSCHED_NS2TICKS(policer->burst),
-PSCHED_TICKS_PER_SEC),
+ .burst = policer->burst,
};
return ocelot_port_policer_add(ocelot, port, );
diff --git a/drivers/net/dsa/sja1105/sja1105_flower.c
b/drivers/net/dsa/sja1105/sja1105_flower.c
index 9ee8968610cd..12e76020bea3 100644
--- a/drivers/net/dsa/sja1105/sja1105_flower.c
+++ b/drivers/net/dsa/sja1105/sja1105_flower.c
@@ -31,7 +31,7 @@ static int sja1105_setup_bcast_policer(struct sja1105_private
*priv,
struct netlink_ext_ack *extack,
unsigned long cookie, int port,
u64 rate_bytes_per_sec,
- s64 burst)
+ u32 burst)
{
struct sja1105_rule *rule = sja1105_rule_find(priv, cookie);
struct sja1105_l2_policing_entry *policing;
@@ -79,9 +79,8 @@ static int sja1105_setup_bcast_policer(struct sja1105_private
*priv,
policing[rule->bcast_pol.sharindx].rate = div_u64(rate_bytes_per_sec *
512, 100);
- policing[rule->bcast_pol.sharindx].smax = div_u64(rate_bytes_per_sec *
-
PSCHED_NS2TICKS(burst),
- PSCHED_TICKS_PER_SEC);
+ policing[rule->bcast_pol.sharindx].smax = burst;
+
/* TODO: support per-flow MTU */
policing[rule->bcast_pol.sharindx].maxlen = VLAN_ETH_FRAME_LEN +
ETH_FCS_LEN;
@@ -103,7 +102,7 @@ static int sja1105_setup_tc_policer(struct sja1105_private
*priv,
struct netlink_ext_ack *extack,
unsigned long cookie, int port, int tc,
u64 rate_bytes_per_sec,
- s64 burst)
+ u32 burst)
{
struct sja1105_rule *rule = sja1105_rule_find(priv, cookie);
struct sja1105_l2_policing_entry *policing;
@@ -152,9 +151,8 @@ static int sja1105_setup_tc_policer(struct sja1105_private
*priv,
policing[rule->tc_pol.sharindx].rate = div_u64(rate_bytes_per_sec *
512, 100);
- policing[rule->tc_pol.sharindx].smax = div_u64(rate_bytes_per_sec *
- PSCHED_NS2TICKS(burst),
- PSCHED_TICKS_PER_SEC);
+ policing[rule->tc_pol.sharindx].smax = burst;
+
/* TODO: support per-flow MTU */
policing[rule->tc_pol.sharindx].maxlen = VLAN_ETH_FRAME_LEN +
ETH_FCS_LEN;
@@ -177,7 +175,7 @@ static int sja1105_flower_policer(struct sja1105_private
*priv, int port,
unsigned long cookie,
struct sja1105_key *key,
u64 rate_bytes_per_sec,
- s64 burst)
+ u32 burst)
{
switch (key->type) {
case SJA1105_KEY_BCAST:
diff --git a/drivers/net/dsa/sja1105/sja1105_main.c
b/drivers/net/dsa/sja1105/sja1105_main.c
index 789b288cc78b..5079e4aeef80 100644
--- a/drivers/net/dsa/sja1105/sja1105_main.c
+++
[GIT PULL] Crypto Fixes for 5.8
Hi Linus: This push fixes two race conditions, one in padata and one in af_alg. The following changes since commit 819966c06b759022e9932f328284314d9272b9f3: crypto: drbg - always try to free Jitter RNG instance (2020-06-15 17:38:54 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus for you to fetch changes up to e04ec0de61c1eb9693179093e83ab8ca68a30d08: padata: upgrade smp_mb__after_atomic to smp_mb in padata_do_serial (2020-06-18 17:09:54 +1000) Daniel Jordan (1): padata: upgrade smp_mb__after_atomic to smp_mb in padata_do_serial Herbert Xu (1): crypto: af_alg - fix use-after-free in af_alg_accept() due to bh_lock_sock() crypto/af_alg.c | 26 +++--- crypto/algif_aead.c | 9 +++-- crypto/algif_hash.c | 9 +++-- crypto/algif_skcipher.c | 9 +++-- include/crypto/if_alg.h | 4 ++-- kernel/padata.c | 4 ++-- 6 files changed, 24 insertions(+), 37 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v3 0/3] Build ORC fast lookup table in scripts/sorttable tool
Hi Josh, will you please have a look at this patchset? There might be another way to set SHT_PROGBITS of section .orc_lookup by writing section headers when orc_unwind and orc_unwind_ip tables are writen. It might be as follows: diff --git a/tools/objtool/orc_gen.c b/tools/objtool/orc_gen.c index 3f98dcfbc177..860d4dcec8e6 100644 --- a/tools/objtool/orc_gen.c +++ b/tools/objtool/orc_gen.c @@ -183,6 +183,10 @@ int create_orc_sections(struct objtool_file *file) u_sec = elf_create_section(file->elf, ".orc_unwind", sizeof(struct orc_entry), idx); + /* make flags of section orc_lookup right */ + if (!elf_create_section(file->elf, ".orc_lookup", sizeof(int), 0)) + return -1; + What do you think about this way of setting SHT_PROGBITS? > On Jun 3, 2020, at 10:39 PM, Huaixin Chang > wrote: > > Move building of fast lookup table from boot to sorttable tool. This saves us > 6380us boot time on Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz with cores. It > adds a little more than 7ms to boot time when testing on the same CPU. > > Changelog v3: > 1. Modify annotation of unwind_init(). > > Changelog v2: > 1. Type of section orc_lookup needs to be SHT_PROGBITS. > 2. unwind_init() cannot be removed totally as setting lookup_num_blocks is > needed. > > Huaixin Chang (3): > scripts/sorttable: Change section type of orc_lookup to SHT_PROGBITS > scripts/sorttable: Build orc fast lookup table via sorttable tool > x86/unwind/orc: Simplify unwind_init() for x86 boot > > arch/x86/kernel/unwind_orc.c | 41 +--- > include/asm-generic/vmlinux.lds.h | 2 + > scripts/sorttable.h | 99 --- > 3 files changed, 96 insertions(+), 46 deletions(-) > > -- > 2.14.4.44.g2045bb6
Re: [PATCH V3 1/3] cpufreq: Fix locking issues with governors
On 26-06-20, 09:24, Quentin Perret wrote:
> On Friday 26 Jun 2020 at 09:21:42 (+0530), Viresh Kumar wrote:
> > The locking around governors handling isn't adequate currently. The list
> > of governors should never be traversed without locking in place. Also we
> > must make sure the governor isn't removed while it is still referenced
> > by code.
> >
> > Reported-by: Quentin Perret
> > Signed-off-by: Viresh Kumar
> > ---
> > drivers/cpufreq/cpufreq.c | 59 ---
> > 1 file changed, 36 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > index 0128de3603df..e798a1193bdf 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -621,6 +621,24 @@ static struct cpufreq_governor *find_governor(const
> > char *str_governor)
> > return NULL;
> > }
> >
> > +static struct cpufreq_governor *get_governor(const char *str_governor)
> > +{
> > + struct cpufreq_governor *t;
> > +
> > + mutex_lock(_governor_mutex);
> > + t = find_governor(str_governor);
> > + if (!t)
> > + goto unlock;
> > +
> > + if (!try_module_get(t->owner))
> > + t = NULL;
> > +
> > +unlock:
> > + mutex_unlock(_governor_mutex);
> > +
> > + return t;
> > +}
> > +
> > static unsigned int cpufreq_parse_policy(char *str_governor)
> > {
> > if (!strncasecmp(str_governor, "performance", CPUFREQ_NAME_LEN))
> > @@ -640,28 +658,14 @@ static struct cpufreq_governor
> > *cpufreq_parse_governor(char *str_governor)
> > {
> > struct cpufreq_governor *t;
> >
> > - mutex_lock(_governor_mutex);
> > -
> > - t = find_governor(str_governor);
> > - if (!t) {
> > - int ret;
> > -
> > - mutex_unlock(_governor_mutex);
> > -
> > - ret = request_module("cpufreq_%s", str_governor);
> > - if (ret)
> > - return NULL;
> > -
> > - mutex_lock(_governor_mutex);
> > + t = get_governor(str_governor);
> > + if (t)
> > + return t;
> >
> > - t = find_governor(str_governor);
> > - }
> > - if (t && !try_module_get(t->owner))
> > - t = NULL;
> > -
> > - mutex_unlock(_governor_mutex);
> > + if (request_module("cpufreq_%s", str_governor))
> > + return NULL;
> >
> > - return t;
> > + return get_governor(str_governor);
> > }
> >
> > /**
> > @@ -815,12 +819,14 @@ static ssize_t
> > show_scaling_available_governors(struct cpufreq_policy *policy,
> > goto out;
> > }
> >
> > + mutex_lock(_governor_mutex);
> > for_each_governor(t) {
> > if (i >= (ssize_t) ((PAGE_SIZE / sizeof(char))
> > - (CPUFREQ_NAME_LEN + 2)))
> > - goto out;
> > + break;
> > i += scnprintf([i], CPUFREQ_NAME_PLEN, "%s ", t->name);
> > }
> > + mutex_unlock(_governor_mutex);
> > out:
> > i += sprintf([i], "\n");
> > return i;
> > @@ -1058,11 +1064,14 @@ static int cpufreq_init_policy(struct
> > cpufreq_policy *policy)
> > struct cpufreq_governor *def_gov = cpufreq_default_governor();
> > struct cpufreq_governor *gov = NULL;
> > unsigned int pol = CPUFREQ_POLICY_UNKNOWN;
> > + bool put_governor = false;
> > + int ret;
> >
> > if (has_target()) {
> > /* Update policy governor to the one used before hotplug. */
> > - gov = find_governor(policy->last_governor);
> > + gov = get_governor(policy->last_governor);
> > if (gov) {
> > + put_governor = true;
> > pr_debug("Restoring governor %s for cpu %d\n",
> > policy->governor->name, policy->cpu);
> > } else if (def_gov) {
> > @@ -1089,7 +1098,11 @@ static int cpufreq_init_policy(struct cpufreq_policy
> > *policy)
> > return -ENODATA;
> > }
> >
> > - return cpufreq_set_policy(policy, gov, pol);
> > + ret = cpufreq_set_policy(policy, gov, pol);
> > + if (put_governor)
> > + module_put(gov->owner);
>
> Nit: I think you could safely do
>
> if (gov)
> module_put(gov->owner);
>
> and get rid of 'put_governor', given that try_module_get() and
> module_put() are nops if owner is NULL (which is guaranteed for
> the result of cpufreq_default_governor() as it is builtin).
I described why I chose to keep it that way in the other email, but I
am all for dropping the variable. And so what about this ?
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index e798a1193bdf..d9e9ae7051bb 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1064,18 +1064,17 @@ static int cpufreq_init_policy(struct cpufreq_policy
*policy)
struct cpufreq_governor *def_gov = cpufreq_default_governor();
struct cpufreq_governor *gov = NULL;
unsigned int pol = CPUFREQ_POLICY_UNKNOWN;
- bool put_governor = false;
int ret;
RE: [PATCH/RFC v4 1/4] regulator: core: add prepare and resume_early
Hi Mark, > From: Mark Brown, Sent: Friday, June 26, 2020 11:30 PM > > On Fri, Jun 26, 2020 at 06:32:19PM +0900, Yoshihiro Shimoda wrote: > > > The regulator-fixed driver is possible to be off by firmware > > like PSCI while the system is suspended. If a consumer could get > > such a condition from regulator_is_enabled(), it's useful by > > consumers. > > > The regulator subsystem already has regulator-state-(standby|mem|disk) > > sub-nodes and regulator-off-in-suspend property. However, > > suitable regulator_ops APIs didn't exist. > > > So, add new regulator_ops APIs and prepare()/resume_early() in > > the regulator_pm_ops to set/clear the condition by new APIs before > > suspend() functions of consumers are called. > > I can't follow this explanation at all, I really can't understand what > these functions are supposed to do or how they are supposed to be used. > Nothing in the rest of this series is at all enlightening either. It > seems there is some need for a consumer to query things about the > suspend state but there is no obvious connection from that to adding > these new operations for regulator drivers. I'm very sorry for lack description... Perhaps I should have described one of use cases like below. regulator_prepare() --> call regulator_ops.set_prepare_disable() if DISABLE_IN_SUSPEND --> A regulator can be disabled by the operation. --> We can guarantee an order which is called before a consumer if it uses dev_pm_ops.suspend(). .. A consumer driver's suspend(). --> call regulator_is_enabled() --> If the regulator was called set_prepare_disable(), this can returns false. Best regards, Yoshihiro Shimoda
Re: [PATCH] rtlwifi/*/dm.c: Use const in swing_table declarations
On Sun, 2020-06-28 at 03:17 -0700, Joe Perches wrote:
Use 'rtlwifi:' as subject title prefix is enough, likes
rtlwifi: Use const in swing_table declarations
> Reduce data usage about 1KB by using const.
>
> Signed-off-by: Joe Perches
> ---
> .../net/wireless/realtek/rtlwifi/rtl8188ee/dm.c| 4 +-
> .../net/wireless/realtek/rtlwifi/rtl8723be/dm.c| 4 +-
> .../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c| 98 -
> -
> 3 files changed, 56 insertions(+), 50 deletions(-)
>
>
[...]
>
>
> static void rtl8812ae_get_delta_swing_table(struct ieee80211_hw *hw,
> - u8 **up_a, u8 **down_a,
> - u8 **up_b, u8 **down_b)
> + const u8 **up_a,
> + const u8 **down_a,
> + const u8 **up_b,
> + const u8 **down_b)
> {
> struct rtl_priv *rtlpriv = rtl_priv(hw);
> struct rtl_phy *rtlphy = >phy;
>
Please remove below type casting:
@@ -1872,10 +1872,10 @@ static void rtl8821ae_get_delta_swing_table(struct
ieee80211_hw *hw,
*up_b = rtl8821ae_delta_swing_table_idx_5gb_p[2];
*down_b = rtl8821ae_delta_swing_table_idx_5gb_n[2];
} else {
- *up_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
- *down_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
- *up_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
- *down_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
+ *up_a = rtl8818e_delta_swing_table_idx_24gb_p;
+ *down_a = rtl8818e_delta_swing_table_idx_24gb_n;
+ *up_b = rtl8818e_delta_swing_table_idx_24gb_p;
+ *down_b = rtl8818e_delta_swing_table_idx_24gb_n;
}
return;
}
[...]
Re: [PATCH V3 3/3] cpufreq: Specify default governor on command line
On 26-06-20, 16:57, Quentin Perret wrote:
> On Friday 26 Jun 2020 at 09:21:44 (+0530), Viresh Kumar wrote:
> > index e798a1193bdf..93c6399c1a42 100644
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -50,6 +50,9 @@ static LIST_HEAD(cpufreq_governor_list);
> > #define for_each_governor(__governor) \
> > list_for_each_entry(__governor, _governor_list, governor_list)
> >
> > +static char cpufreq_param_governor[CPUFREQ_NAME_LEN];
> > +static char default_governor[CPUFREQ_NAME_LEN];
> > +
> > /**
> > * The "cpufreq driver" - the arch- or hardware-dependent low
> > * level driver of CPUFreq support, and its spinlock. This lock
> > @@ -1061,7 +1064,6 @@ __weak struct cpufreq_governor
> > *cpufreq_default_governor(void)
> >
> > static int cpufreq_init_policy(struct cpufreq_policy *policy)
> > {
> > - struct cpufreq_governor *def_gov = cpufreq_default_governor();
> > struct cpufreq_governor *gov = NULL;
> > unsigned int pol = CPUFREQ_POLICY_UNKNOWN;
> > bool put_governor = false;
> > @@ -1071,22 +1073,29 @@ static int cpufreq_init_policy(struct
> > cpufreq_policy *policy)
> > /* Update policy governor to the one used before hotplug. */
> > gov = get_governor(policy->last_governor);
> > if (gov) {
> > - put_governor = true;
> > pr_debug("Restoring governor %s for cpu %d\n",
> > -policy->governor->name, policy->cpu);
> > - } else if (def_gov) {
> > - gov = def_gov;
> > +gov->name, policy->cpu);
> > } else {
> > - return -ENODATA;
> > + gov = get_governor(default_governor);
> > + }
> > +
> > + if (gov) {
> > + put_governor = true;
> > + } else {
> > + gov = cpufreq_default_governor();
> > + if (!gov)
> > + return -ENODATA;
> > }
>
> As mentioned on patch 01, doing put_module() below if gov != NULL would
> avoid this dance with put_governor, but this works too, so no strong
> opinion.
I did it this way because the code looks buggy otherwise, even though
it isn't as put_module() handles it just fine. And so I would like to
keep it this way, unless there are two votes against mine :)
> > +
> > } else {
> > +
> > /* Use the default policy if there is no last_policy. */
> > if (policy->last_policy) {
> > pol = policy->last_policy;
> > - } else if (def_gov) {
> > - pol = cpufreq_parse_policy(def_gov->name);
> > + } else {
> > + pol = cpufreq_parse_policy(default_governor);
> > /*
> > -* In case the default governor is neiter "performance"
> > +* In case the default governor is neither "performance"
> > * nor "powersave", fall back to the initial policy
> > * value set by the driver.
> > */
> > @@ -2796,13 +2805,22 @@ EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
> >
> > static int __init cpufreq_core_init(void)
> > {
> > + struct cpufreq_governor *gov = cpufreq_default_governor();
> > + char *name = gov->name;
> > +
> > if (cpufreq_disabled())
> > return -ENODEV;
> >
> > cpufreq_global_kobject = kobject_create_and_add("cpufreq",
> > _subsys.dev_root->kobj);
> > BUG_ON(!cpufreq_global_kobject);
> >
> > + if (strlen(cpufreq_param_governor))
> > + name = cpufreq_param_governor;
> > +
> > + strncpy(default_governor, name, CPUFREQ_NAME_LEN);
>
> Do we need both cpufreq_param_governor and default_governor?
> Could we move everything to only one of them? Something a little bit
> like that maybe?
No because we want to fallback to the default governor when the
governor shown by the cpufreq_param_governor is valid but missing.
> Also, one thing to keep in mind with this version (or the one you
> suggested) is that if the command line parameter is not valid, we will
> not fallback on the builtin default for the ->setpolicy() case. But I
> suppose one might argue this is a reasonable behaviour, so no objection
> from me.
Right, I did that on purpose.
> Otherwise, apart from these nits, I gave this a go on my setup, with
> builtin and modular governors & drivers, and everything worked exactly
> as expected.
Thanks for testing it out Quentin.
--
viresh
[v2,iproute2-next 2/2] action police: make 'mtu' could be set independently in police action
Current police action must set 'rate' and 'burst'. 'mtu' parameter
set the max frame size and could be set alone without 'rate' and 'burst'
in some situation. Offloading to hardware for example, 'mtu' could limit
the flow max frame size.
Signed-off-by: Po Liu
---
v1->v2 changes:
- fix the print message style and add space acked by Stephen Hemminger
tc/m_police.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tc/m_police.c b/tc/m_police.c
index 7eb47f8e..83b25db4 100644
--- a/tc/m_police.c
+++ b/tc/m_police.c
@@ -161,8 +161,8 @@ action_ctrl_ok:
return -1;
/* Must at least do late binding, use TB or ewma policing */
- if (!rate64 && !avrate && !p.index) {
- fprintf(stderr, "'rate' or 'avrate' MUST be specified.\n");
+ if (!rate64 && !avrate && !p.index && !mtu) {
+ fprintf(stderr, "'rate' or 'avrate' or 'mtu' MUST be
specified.\n");
return -1;
}
--
2.17.1
Re: [PATCH] ARM: dts: spear: Align L2 cache-controller nodename with dtschema
On 26-06-20, 10:05, Krzysztof Kozlowski wrote:
> Fix dtschema validator warnings like:
> l2-cache: $nodename:0: 'l2-cache' does not match
> '^(cache-controller|cpu)(@[0-9a-f,]+)*$'
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> arch/arm/boot/dts/spear13xx.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/spear13xx.dtsi
> b/arch/arm/boot/dts/spear13xx.dtsi
> index f187da4485f4..c87b881b2c8b 100644
> --- a/arch/arm/boot/dts/spear13xx.dtsi
> +++ b/arch/arm/boot/dts/spear13xx.dtsi
> @@ -43,7 +43,7 @@
> 0 7 0x04>;
> };
>
> - L2: l2-cache {
> + L2: cache-controller {
> compatible = "arm,pl310-cache";
> reg = <0xed00 0x1000>;
> cache-unified;
Acked-by: Viresh Kumar
--
viresh
[v2,iproute2-next 1/2] action police: change the print message quotes style
Change the double quotes to single quotes in fprintf message to make it
more readable.
Signed-off-by: Po Liu
---
v1->v2 changes:
- Patch new added
tc/m_police.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tc/m_police.c b/tc/m_police.c
index a5bc20c0..7eb47f8e 100644
--- a/tc/m_police.c
+++ b/tc/m_police.c
@@ -162,23 +162,23 @@ action_ctrl_ok:
/* Must at least do late binding, use TB or ewma policing */
if (!rate64 && !avrate && !p.index) {
- fprintf(stderr, "\"rate\" or \"avrate\" MUST be specified.\n");
+ fprintf(stderr, "'rate' or 'avrate' MUST be specified.\n");
return -1;
}
/* When the TB policer is used, burst is required */
if (rate64 && !buffer && !avrate) {
- fprintf(stderr, "\"burst\" requires \"rate\".\n");
+ fprintf(stderr, "'burst' requires 'rate'.\n");
return -1;
}
if (prate64) {
if (!rate64) {
- fprintf(stderr, "\"peakrate\" requires \"rate\".\n");
+ fprintf(stderr, "'peakrate' requires 'rate'.\n");
return -1;
}
if (!mtu) {
- fprintf(stderr, "\"mtu\" is required, if \"peakrate\"
is requested.\n");
+ fprintf(stderr, "'mtu' is required, if 'peakrate' is
requested.\n");
return -1;
}
}
--
2.17.1
Re: [PATCH] i2c: mediatek: Add to support continuous mode
Hi Qiangming:
Do you have the specific timing cost data about the "continuous mode"?
Is it better than the default multi-write mode(one message by one
message) ?I need to know if this patch is very necessary.
On Fri, 2020-06-19 at 16:06 +0800, Qiangming Xia wrote:
> From: "qiangming.xia"
>
> Mediatek i2c controller support for continuous mode,
> it allow to transfer once multiple writing messages of equal length.
> For example, a slave need write a serial of non-continuous
> offset range in chip,e.g. writing offset 0,offset 2 and offset 4.
> Normally, it need three times i2c write operation. However,it can
> use once transfer to finish it by using continuous mode.
>
> Change-Id: If06991e3fd32867bdeaacf15bb24864d5c5904d0
> Signed-off-by: Qiangming Xia
> ---
> drivers/i2c/busses/i2c-mt65xx.c | 67 +
> 1 file changed, 67 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index deef69e56906..76ec65d869f6 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -97,6 +97,7 @@ enum mtk_trans_op {
> I2C_MASTER_WR = 1,
> I2C_MASTER_RD,
> I2C_MASTER_WRRD,
> + I2C_MASTER_CONTINUOUS_WR,
> };
>
> enum I2C_REGS_OFFSET {
> @@ -846,6 +847,9 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
> struct i2c_msg *msgs,
> OFFSET_TRANSFER_LEN);
> }
> mtk_i2c_writew(i2c, I2C_WRRD_TRANAC_VALUE, OFFSET_TRANSAC_LEN);
> + } else if (i2c->op == I2C_MASTER_CONTINUOUS_WR) {
> + mtk_i2c_writew(i2c, msgs->len / num, OFFSET_TRANSFER_LEN);
> + mtk_i2c_writew(i2c, num, OFFSET_TRANSAC_LEN);
> } else {
> mtk_i2c_writew(i2c, msgs->len, OFFSET_TRANSFER_LEN);
> mtk_i2c_writew(i2c, num, OFFSET_TRANSAC_LEN);
> @@ -896,6 +900,23 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
> struct i2c_msg *msgs,
> writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
> }
>
> + writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
> + writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
> + } else if (i2c->op == I2C_MASTER_CONTINUOUS_WR) {
> + writel(I2C_DMA_INT_FLAG_NONE, i2c->pdmabase + OFFSET_INT_FLAG);
> + writel(I2C_DMA_CON_TX, i2c->pdmabase + OFFSET_CON);
> + wpaddr = dma_map_single(i2c->dev, msgs->buf,
> + msgs->len, DMA_TO_DEVICE);
> + if (dma_mapping_error(i2c->dev, wpaddr)) {
> + kfree(msgs->buf);
> + return -ENOMEM;
> + }
> +
> + if (i2c->dev_comp->support_33bits) {
> + reg_4g_mode = mtk_i2c_set_4g_mode(wpaddr);
> + writel(reg_4g_mode, i2c->pdmabase + OFFSET_TX_4G_MODE);
> + }
> +
> writel((u32)wpaddr, i2c->pdmabase + OFFSET_TX_MEM_ADDR);
> writel(msgs->len, i2c->pdmabase + OFFSET_TX_LEN);
> } else {
> @@ -979,6 +1000,11 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c,
> struct i2c_msg *msgs,
>msgs->len, DMA_FROM_DEVICE);
>
> i2c_put_dma_safe_msg_buf(dma_rd_buf, msgs, true);
> + } else if (i2c->op == I2C_MASTER_CONTINUOUS_WR) {
> + dma_unmap_single(i2c->dev, wpaddr,
> + msgs->len, DMA_TO_DEVICE);
> +
> + kfree(msgs->buf);
> } else {
> dma_unmap_single(i2c->dev, wpaddr, msgs->len,
>DMA_TO_DEVICE);
> @@ -1009,6 +1035,9 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
> {
> int ret;
> int left_num = num;
> + int i, j;
> + u8 *dma_multi_wr_buf;
> + struct i2c_msg multi_msg[1];
> struct mtk_i2c *i2c = i2c_get_adapdata(adap);
>
> ret = mtk_i2c_clock_enable(i2c);
> @@ -1025,6 +1054,44 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
> }
> }
>
> + if (num > 1) {
> + for (i = 0; i < num - 1; i++) {
> + if (!(msgs[i].flags & I2C_M_RD) && !(msgs[i+1].flags &
> + I2C_M_RD) && (msgs[i].addr == msgs[i+1].addr)
> + && (msgs[i].len == msgs[i+1].len)) {
> + continue;
> + } else
> + break;
> + }
> + if (i >= num - 1) {
> + i2c->op = I2C_MASTER_CONTINUOUS_WR;
> + j = 0;
> + dma_multi_wr_buf = kzalloc(msgs->len * num, GFP_KERNEL);
> + if (!dma_multi_wr_buf) {
> + ret = -ENOMEM;
> + goto err_exit;
> + }
> + multi_msg->addr = msgs->addr;
> +
Re: [PATCH 4/4] ARM: dts: uniphier: change support card to simple-mfd from simple-bus
On Thu, Jun 25, 2020 at 11:57 PM Lee Jones wrote: > > On Thu, 25 Jun 2020, Masahiro Yamada wrote: > > > On Thu, Jun 25, 2020 at 3:16 AM Lee Jones wrote: > > > > > > On Thu, 25 Jun 2020, Masahiro Yamada wrote: > > > > > > > On Tue, Jun 23, 2020 at 9:24 PM Lee Jones wrote: > > > > > > > > > > On Tue, 23 Jun 2020, Masahiro Yamada wrote: > > > > > > > > > > > 'make ARCH=arm dtbs_check' emits the following warning: > > > > > > > > > > > > support-card@1,1f0: $nodename:0: 'support-card@1,1f0' > > > > > > does not match '^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' > > > > > > > > > > > > Maybe, simple-mfd could be a better fit for this device. > > > > > > > > > > The two should be equivalent. > > > > > > > > Yes, I know. > > > > That's why I can change "simple-bus" to "simple-mfd" > > > > with no risk. > > > > > > > > The difference is schema-check. > > > > > > > > The node name for "simple-bus" is checked by 'make dtbs_check'. > > > > > > > > See this code: > > > > https://github.com/robherring/dt-schema/blob/v2020.05/schemas/simple-bus.yaml#L17 > > > > > > > > Even if I rename the node, it does not accept the > > > > unit name '1,1f0' > > > > > > > > > What do you mean by "maybe"? Does this squash the warning? > > > > > > > > "maybe" means I am not quite sure > > > > which compatible is a better fit > > > > to describe this device. > > > > > > > > As mentioned above, simple-bus and simple-mfd > > > > are interchangeable from a driver point of view. > > > > > > > > This add-on board is integrated with various peripherals > > > > such as 16550a serial, smsc9115 ether etc. > > > > The address-decode is implemented in a CPLD device. > > > > It has chip selects and local addresses, which are mapped to > > > > the parent. > > > > > > > > It can be either simple-bus or simple-mfd, I think. > > > > > > > > > > > > dt-schema checks the node name of simple-bus. > > > > Currently, there is no check for simple-mfd. > > > > > > > > So, I think this patch is an easy solution > > > > to fix the warning. > > > > > > Yes, looking at the documentation it seems as though 'simple-mfd' > > > would be a better fit. Is the device a single IP with various > > > different functions? > > > > Not an IP. > > > > This is a small board that consists of > > a CPLD + ethernet controller + serial controller + LED, etc. > > Then simple MFD does not seem like a good fit. > > Neither does 'simple-bus'. Then, I do not know what to do. This board connection is so simple that no hardware initialization needed to get access to peripherals. So, 'simple-bus' or 'simple-mfd' is preferred. If this is not either simple-bus or simple-mfd, I need a special driver to probe the child devices such as ethernet, serial etc. > What is it you're trying to describe in the device hierarchy? The connection is as follows: |-Main board -| |- add-on board | | | | (this board) | | | | | |(SoC) ---|--|--- CPLD --- ethernet | | | | |- serial| |-| | |- LED | | | |---| uniphier-support-card.dtsi describes the "add-on board" part. Address-decode is implemented in CPLD. So, the criteria to become MFD is whether it is an IP integrated into SoC. - implemented in an SoC --> MFD - implemented in a board + CPLD --> not MFD Right? > > > > > Rob is in Cc. Please add comments if any. > > > > > > > > > Isn't the issue caused by the ','? > > > > > > > > Right. > > > > > > > > The node name of simple-bus > > > > must meet the regular expression: > > > > "^(bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$" > > > > > > > > > > > > Even if I rename the node > > > > "support-card@1,1f0" > > > > to "bus@1,1f0", the warning is still > > > > displayed due to ',' > > > > > > > > "1,1f0" means > > > > the address 0x01f0 of chip select 1. > > > > > > Is this an officially accepted format? > > > > I am not sure if it is official. > > > > Rob said the data fields should be separated by commas. > > https://www.spinics.net/lists/devicetree/msg201565.html > > Are you sure he doesn't mean in the 'reg' property. > > Rather than the node-name@ syntax. > > BTW, I think the error you link to above is related to the > node-name@ not matching the value listed in the 'reg' > property. If I get rid of @ part, DTC warns the following for W=1 builds: arch/arm/boot/dts/uniphier-support-card.dtsi:12.29-32.4: Warning (unit_address_vs_reg): /soc/system-bus@58c0/support-card: node has a reg or ranges property, but no unit name So, 'reg' or 'range' requires a unit name. A unit name should be a base address. If it has a chip select, the format is , But the schema does not allow commas in a unit name of simple-bus. This is the problem I am trying to do something for. > > -- > Lee Jones [李琼斯] > Senior
Re: [PATCH 01/26] mm: Do page fault accounting in handle_mm_fault
On 2020-06-26 15:31, Peter Xu wrote:
This is a preparation patch to move page fault accountings into the general
code in handle_mm_fault(). This includes both the per task flt_maj/flt_min
counters, and the major/minor page fault perf events. To do this, the pt_regs
pointer is passed into handle_mm_fault().
PERF_COUNT_SW_PAGE_FAULTS should still be kept in per-arch page fault handlers.
So far, all the pt_regs pointer that passed into handle_mm_fault() is NULL,
which means this patch should have no intented functional change.
Suggested-by: Linus Torvalds
Signed-off-by: Peter Xu
---
arch/alpha/mm/fault.c | 2 +-
arch/arc/mm/fault.c | 2 +-
arch/arm/mm/fault.c | 2 +-
arch/arm64/mm/fault.c | 2 +-
arch/csky/mm/fault.c | 3 +-
arch/hexagon/mm/vm_fault.c| 2 +-
arch/ia64/mm/fault.c | 2 +-
arch/m68k/mm/fault.c | 2 +-
arch/microblaze/mm/fault.c| 2 +-
arch/mips/mm/fault.c | 2 +-
arch/nds32/mm/fault.c | 2 +-
arch/nios2/mm/fault.c | 2 +-
arch/openrisc/mm/fault.c | 2 +-
arch/parisc/mm/fault.c| 2 +-
arch/powerpc/mm/copro_fault.c | 2 +-
arch/powerpc/mm/fault.c | 2 +-
arch/riscv/mm/fault.c | 2 +-
arch/s390/mm/fault.c | 2 +-
arch/sh/mm/fault.c| 2 +-
arch/sparc/mm/fault_32.c | 4 +--
arch/sparc/mm/fault_64.c | 2 +-
arch/um/kernel/trap.c | 2 +-
arch/unicore32/mm/fault.c | 2 +-
arch/x86/mm/fault.c | 2 +-
arch/xtensa/mm/fault.c| 2 +-
drivers/iommu/amd_iommu_v2.c | 2 +-
The above file is renamed, as of a couple weeks ago, via
commit ad8694bac410 ("iommu/amd: Move AMD IOMMU driver into
subdirectory").
Also there are a number of changes to mm/gup.c (not a concern for this
patch, but it is for the overall series). So I'm hoping you're going to
post a version that is rebased against 5.8-rc*.
thanks,
--
John Hubbard
NVIDIA
Re: usb: mtu3: Checking initialisation of the variable “mep” in two functions
Hi, On Sat, 2020-06-27 at 14:28 +0200, Markus Elfring wrote: > Hello, > > A source code analysis approach by the means of the semantic patch language > (Coccinelle software) pointed an implementation detail out for further > development considerations. > > The functions “mtu3_gadget_ep_set_halt” and “mtu3_gadget_ep_set_wedge” check > at the beginning if the input parameter “ep” is a null pointer. > The error code “-EINVAL” will be returned then. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/mtu3/mtu3_gadget.c?id=1590a2e1c681b0991bd42c992cabfd380e0338f2#n371 > https://elixir.bootlin.com/linux/v5.7.2/source/drivers/usb/mtu3/mtu3_gadget.c#L371 > > Can it be nicer to assign the variable “mep” only after a successful check > instead of an initialisation before? Yes, I'll fix it, thanks a lot > > Regards, > Markus
Re: [PATCH v4 16/23] ASoC: soc-pcm: Get all BEs along DAPM path
Hi Sameer
> dpcm_end_walk_at_be() stops the graph walk when first BE is found for
> the given FE component. In a component model we may want to connect
> multiple DAIs from different components. A new flag is introduced in
> 'snd_soc_card', which when set allows DAI/component chaining. Later
> PCM operations can be called for all these listed components for a
> valid DAPM path.
(snip)
> @@ -1069,6 +1069,7 @@ struct snd_soc_card {
> int num_of_dapm_widgets;
> const struct snd_soc_dapm_route *of_dapm_routes;
> int num_of_dapm_routes;
> + bool component_chaining;
snd_soc_card has many /* bit field */ variables.
Please use it instead of bool.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
Re: brocken devfreq simple_ondemand for Odroid XU3/4?
Hi Sylwester, On 6/25/20 12:11 AM, Sylwester Nawrocki wrote: > Hi All, > > On 24.06.2020 12:32, Lukasz Luba wrote: >> I had issues with devfreq governor which wasn't called by devfreq >> workqueue. The old DELAYED vs DEFERRED work discussions and my patches >> for it [1]. If the CPU which scheduled the next work went idle, the >> devfreq workqueue will not be kicked and devfreq governor won't check >> DMC status and will not decide to decrease the frequency based on low >> busy_time. >> The same applies for going up with the frequency. They both are >> done by the governor but the workqueue must be scheduled periodically. > > As I have been working on resolving the video mixer IOMMU fault issue > described here: https://patchwork.kernel.org/patch/10861757 > I did some investigation of the devfreq operation, mostly on Odroid U3. > > My conclusions are similar to what Lukasz says above. I would like to add > that broken scheduling of the performance counters read and the devfreq > updates seems to have one more serious implication. In each call, which > normally should happen periodically with fixed interval we stop the counters, > read counter values and start the counters again. But if period between > calls becomes long enough to let any of the counters overflow, we will > get wrong performance measurement results. My observations are that > the workqueue job can be suspended for several seconds and conditions for > the counter overflow occur sooner or later, depending among others > on the CPUs load. > Wrong bus load measurement can lead to setting too low interconnect bus > clock frequency and then bad things happen in peripheral devices. > > I agree the workqueue issue needs to be fixed. I have some WIP code to use > the performance counters overflow interrupts instead of SW polling and with It is good way to resolve the overflow issue. > that the interconnect bus clock control seems to work much better. > -- Best Regards, Chanwoo Choi Samsung Electronics
Re: [PATCH v2 01/13] dmaengine: pl330: Remove the burst limit for quirk 'NO-FLUSHP'
On 2020/6/24 15:54, Vinod Koul wrote:
On 09-06-20, 09:14, Sugar Zhang wrote:
There is no reason to limit the performance on the 'NO-FLUSHP' SoCs,
cuz these platforms are just that the 'FLUSHP' instruction is broken.
Lets not use terms like cuz... 'because' is perfect term :)
It can rephrased to:
There is no reason to limit the performance on the 'NO-FLUSHP' SoCs
beacuse 'FLUSHP' instruction is broken on these platforms, so remove the
limit to improve the efficiency
Thanks, I will send a v3 including these.
so, remove the limit to improve the efficiency.
Signed-off-by: Sugar Zhang
---
Changes in v2: None
drivers/dma/pl330.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 6a158ee..ff0a91f 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1183,9 +1183,6 @@ static inline int _ldst_peripheral(struct pl330_dmac
*pl330,
{
int off = 0;
- if (pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP)
- cond = BURST;
-
/*
* do FLUSHP at beginning to clear any stale dma requests before the
* first WFP.
@@ -1231,8 +1228,9 @@ static int _bursts(struct pl330_dmac *pl330, unsigned
dry_run, u8 buf[],
}
/*
- * transfer dregs with single transfers to peripheral, or a reduced size burst
- * for mem-to-mem.
+ * only the unaligned bursts transfers have the dregs.
+ * transfer dregs with a reduced size burst to peripheral,
+ * or a reduced size burst for mem-to-mem.
This is not related to broken flush and should be a different patch
explaining why this changes were done
ok, I will split this patch in v3.
*/
static int _dregs(struct pl330_dmac *pl330, unsigned int dry_run, u8 buf[],
const struct _xfer_spec *pxs, int transfer_length)
@@ -1247,8 +1245,23 @@ static int _dregs(struct pl330_dmac *pl330, unsigned int
dry_run, u8 buf[],
case DMA_MEM_TO_DEV:
/* fall through */
case DMA_DEV_TO_MEM:
- off += _ldst_peripheral(pl330, dry_run, [off], pxs,
- transfer_length, SINGLE);
+ /*
+* dregs_len = (total bytes - BURST_TO_BYTE(bursts, ccr)) /
+* BRST_SIZE(ccr)
+* the dregs len must be smaller than burst len,
+* so, for higher efficiency, we can modify CCR
+* to use a reduced size burst len for the dregs.
+*/
+ dregs_ccr = pxs->ccr;
+ dregs_ccr &= ~((0xf << CC_SRCBRSTLEN_SHFT) |
+ (0xf << CC_DSTBRSTLEN_SHFT));
+ dregs_ccr |= (((transfer_length - 1) & 0xf) <<
+ CC_SRCBRSTLEN_SHFT);
+ dregs_ccr |= (((transfer_length - 1) & 0xf) <<
+ CC_DSTBRSTLEN_SHFT);
+ off += _emit_MOV(dry_run, [off], CCR, dregs_ccr);
+ off += _ldst_peripheral(pl330, dry_run, [off], pxs, 1,
+ BURST);
break;
case DMA_MEM_TO_MEM:
@@ -2221,9 +2234,7 @@ static bool pl330_prep_slave_fifo(struct dma_pl330_chan
*pch,
static int fixup_burst_len(int max_burst_len, int quirks)
{
- if (quirks & PL330_QUIRK_BROKEN_NO_FLUSHP)
- return 1;
- else if (max_burst_len > PL330_MAX_BURST)
+ if (max_burst_len > PL330_MAX_BURST)
return PL330_MAX_BURST;
else if (max_burst_len < 1)
return 1;
@@ -3128,8 +3139,7 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
pd->dst_addr_widths = PL330_DMA_BUSWIDTHS;
pd->directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
pd->residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
- pd->max_burst = ((pl330->quirks & PL330_QUIRK_BROKEN_NO_FLUSHP) ?
-1 : PL330_MAX_BURST);
+ pd->max_burst = PL330_MAX_BURST;
ret = dma_async_device_register(pd);
if (ret) {
--
2.7.4
--
Re: [PATCH v4 15/23] ASoC: soc-core: Identify 'no_pcm' DAI links for DPCM
Hi Sameer
> PCM devices are created for dai links with 'no-pcm' flag as '0'.
> Such DAI links have CPU component which implement pcm_construct()
> and pcm_destruct() callbacks. Based on this, current patch exposes
> a helper function to identify such components and populate 'no_pcm'
> flag for DPCM DAI link.
(snip)
> +bool soc_component_is_pcm(struct snd_soc_dai_link_component *dlc)
> +{
> + struct snd_soc_component *component;
> + struct snd_soc_dai *dai;
> +
> + for_each_component(component) {
> + if (!component->driver)
> + continue;
> +
> + for_each_component_dais(component, dai) {
> + if (!dai->name || !dlc->dai_name)
> + continue;
> +
> + if (strcmp(dai->name, dlc->dai_name))
> + continue;
We can/should NULL poinster check for "dlc->dai_name" on top of
this function instead of inside loop ?
And then, we can remove "dai->name" check because next strcmp()
automatically fail if dai->name was NULL.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
Re: [PATCH 2/2] block: add BLKSETDESCZONE ioctl for Zoned Block Devices
On 2020-06-28 16:01, Matias Bjørling wrote:
> + /* This may take a while, so be nice to others */
> + cond_resched();
> +
> + return submit_bio_wait();
A cond_resched() call before a submit_bio_wait() call? I think it's the
first time that I see this. Is that call really necessary? Isn't the
wait_for_completion() call inside submit_bio_wait() sufficient?
> + /* no flags is currently supported */
^^
are?
> + /* allocate the size of the zone descriptor extension and fill
> + * with the data in the user data buffer. If the data size is less
> + * than the zone descriptor extension size, then the rest of the
> + * zone description extension data buffer is zero-filled.
> + */
> + zsd_data = (void *) get_zeroed_page(GFP_KERNEL);
> + if (!zsd_data)
> + return -ENOMEM;
> +
> + if (copy_from_user(zsd_data, argp + sizeof(struct blk_zone_set_desc),
> +zsd.len)) {
> + ret = -EFAULT;
> + goto free;
> + }
Has it been considered to use kmalloc() instead of get_zeroed_page()?
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index ccb895f911b1..53b7b05b0004 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -316,6 +316,8 @@ enum req_opf {
> REQ_OP_ZONE_FINISH = 12,
> /* write data at the current zone write pointer */
> REQ_OP_ZONE_APPEND = 13,
> + /* associate zone desc extension data to a zone */
> + REQ_OP_ZONE_SET_DESC= 14,
>
> /* SCSI passthrough using struct scsi_request */
> REQ_OP_SCSI_IN = 32,
Does REQ_OP_ZONE_SET_DESC count as a read or as a write operation? See also:
static inline bool op_is_write(unsigned int op)
{
return (op & 1);
}
> +/**
> + * struct blk_zone_set_desc - BLKSETDESCZONE ioctl requests
> + * @sector: Starting sector of the zone to operate on.
> + * @flags: Feature flags.
> + * @len: size, in bytes, of the data to be associated to the zone.
> + * @data: data to be associated.
> + */
> +struct blk_zone_set_desc {
> + __u64 sector;
> + __u32 flags;
> + __u32 len;
> + __u8data[0];
> +};
Isn't the recommended style to use a flexible array ([] instead of [0])?
See also https://lore.kernel.org/lkml/20200608213711.GA22271@embeddedor/.
Thanks,
Bart.
Re: brocken devfreq simple_ondemand for Odroid XU3/4?
Hi, Sorry for late reply because of my perfornal issue. I count not check the email. On 6/26/20 8:22 PM, Bartlomiej Zolnierkiewicz wrote: > > On 6/25/20 2:12 PM, Kamil Konieczny wrote: >> On 25.06.2020 14:02, Lukasz Luba wrote: >>> >>> >>> On 6/25/20 12:30 PM, Kamil Konieczny wrote: Hi Lukasz, On 25.06.2020 12:02, Lukasz Luba wrote: > Hi Sylwester, > > On 6/24/20 4:11 PM, Sylwester Nawrocki wrote: >> Hi All, >> >> On 24.06.2020 12:32, Lukasz Luba wrote: >>> I had issues with devfreq governor which wasn't called by devfreq >>> workqueue. The old DELAYED vs DEFERRED work discussions and my patches >>> for it [1]. If the CPU which scheduled the next work went idle, the >>> devfreq workqueue will not be kicked and devfreq governor won't check >>> DMC status and will not decide to decrease the frequency based on low >>> busy_time. >>> The same applies for going up with the frequency. They both are >>> done by the governor but the workqueue must be scheduled periodically. >> >> As I have been working on resolving the video mixer IOMMU fault issue >> described here: https://patchwork.kernel.org/patch/10861757 >> I did some investigation of the devfreq operation, mostly on Odroid U3. >> >> My conclusions are similar to what Lukasz says above. I would like to add >> that broken scheduling of the performance counters read and the devfreq >> updates seems to have one more serious implication. In each call, which >> normally should happen periodically with fixed interval we stop the >> counters, >> read counter values and start the counters again. But if period between >> calls becomes long enough to let any of the counters overflow, we will >> get wrong performance measurement results. My observations are that >> the workqueue job can be suspended for several seconds and conditions for >> the counter overflow occur sooner or later, depending among others >> on the CPUs load. >> Wrong bus load measurement can lead to setting too low interconnect bus >> clock frequency and then bad things happen in peripheral devices. >> >> I agree the workqueue issue needs to be fixed. I have some WIP code to >> use >> the performance counters overflow interrupts instead of SW polling and >> with >> that the interconnect bus clock control seems to work much better. >> > > Thank you for sharing your use case and investigation results. I think > we are reaching a decent number of developers to maybe address this > issue: 'workqueue issue needs to be fixed'. > I have been facing this devfreq workqueue issue ~5 times in different > platforms. > > Regarding the 'performance counters overflow interrupts' there is one > thing worth to keep in mind: variable utilization and frequency. > For example, in order to make a conclusion in algorithm deciding that > the device should increase or decrease the frequency, we fix the period > of observation, i.e. to 500ms. That can cause the long delay if the > utilization of the device suddenly drops. For example we set an > overflow threshold to value i.e. 1000 and we know that at 1000MHz > and full utilization (100%) the counter will reach that threshold > after 500ms (which we want, because we don't want too many interrupts > per sec). What if suddenly utilization drops to 2% (i.e. from 5GB/s > to 250MB/s (what if it drops to 25MB/s?!)), the counter will reach the > threshold after 50*500ms = 25s. It is impossible just for the counters > to predict next utilization and adjust the threshold. [...] irq triggers for underflow and overflow, so driver can adjust freq >>> >>> Probably possible on some platforms, depends on how many PMU registers >>> are available, what information can be can assign to them and type of >>> interrupt. A lot of hassle and still - platform and device specific. >>> Also, drivers should not adjust the freq, governors (different types >>> of them with different settings that they can handle) should do it. >>> >>> What the framework can do is to take this responsibility and provide >>> generic way to monitor the devices (or stop if they are suspended). >>> That should work nicely with the governors, which try to predict the >>> next best frequency. From my experience the more fluctuating intervals >>> the governors are called, the more odd decisions they make. >>> That's why I think having a predictable interval i.e. 100ms is something >>> desirable. Tuning the governors is easier in this case, statistics >>> are easier to trace and interpret, solution is not to platform specific, >>> etc. >>> >>> Kamil do you have plans to refresh and push your next version of the >>> workqueue solution? >> >> I do not, as Bartek takes over my work, >> +CC Bartek > > Hi Lukasz, > > As you remember in January Chanwoo has
Re: [RFC PATCH] nvme-pci: Move the sg table allocation/free into init/exit_request
On Sun, Jun 28, 2020 at 06:34:46PM +0800, Baolin Wang wrote: > Move the sg table allocation and free into the init_request() and > exit_request(), instead of allocating sg table when queuing requests, > which can benefit the IO performance. If you want to pre-allocate something per-request, you can add the size to the tagset's cmd_size. But this is adding almost 4k per request. Considering how many requests we try to allocate, that's a bit too large to count on being available or sequestor for this driver.
Re: [PATCH v4 12/23] ASoC: simple-card: Support DPCM DAI link with multiple Codecs
Hi Sameer
> The simple-card driver supports multiple CPU and single Codec entries
> for DPCM DAI links. In some cases it is required to have multiple
> CPU/Codecs. Currently parsing logic for DPCM link loops over all
> children of DAI link but assumes that there is a single Codec entry.
> When DAI link has multiple Codecs it considers only the first Codec
> entry and remaining Codecs are wrongly treated as CPU. This happens
> because first Codec is used as reference for parsing all other child
> nodes.
(snip)
> @@ -137,8 +136,13 @@ static int simple_dai_link_of_dpcm(struct
> asoc_simple_priv *priv,
>* Codec |return|Pass
>* np
>*/
> - if (li->cpu == (np == codec))
> - return 0;
> + if (li->cpu) {
> + if (!strcmp(np->name, "codec"))
> + return 0;
> + } else {
> + if (!strcmp(np->name, "cpu"))
> + return 0;
> + }
Checking node name is maybe nice idea,
but please consider "prefix" here.
Maybe base issue for multiple codec support
is that simple_for_each_link() is caring first codec only ?
simple_for_each_link(...)
{
...
do {
=> /* get codec */
=> codec = of_get_child_by_name(...);
...
}
}
Remove above and having simple_node_is_codec(np, xxx) function
or something can help it ?
Thank you for your help !!
Best regards
---
Kuninori Morimoto
[PATCH] [scripts] read_file: fix memory leak
Free buf before returning to avoid memory leak.
Signed-off-by: Gaurav Singh
---
scripts/insert-sys-cert.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/insert-sys-cert.c b/scripts/insert-sys-cert.c
index 8902836c2342..22d99a8faca9 100644
--- a/scripts/insert-sys-cert.c
+++ b/scripts/insert-sys-cert.c
@@ -250,6 +250,7 @@ static char *read_file(char *file_name, int *size)
}
if (read(fd, buf, *size) != *size) {
perror("File read failed");
+ free(buf);
close(fd);
return NULL;
}
--
2.17.1
[PATCH v4] nbd: Fix memory leak in nbd_add_socket
When adding first socket to nbd, if nsock's allocation failed, the data
structure member "config->socks" was reallocated, but the data structure
member "config->num_connections" was not updated. A memory leak will occur
then because the function "nbd_config_put" will free "config->socks" only
when "config->num_connections" is not zero.
Fixes: 03bf73c315ed ("nbd: prevent memory leak")
Reported-by: syzbot+934037347002901b8...@syzkaller.appspotmail.com
Signed-off-by: Zheng Bin
---
v1->v2: improve change description
v2->v3: fix some code style issues, improve change description
v3->v4: add "Reported-by" tag
drivers/block/nbd.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 01794cd2b6ca..3ff4054d6834 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -1036,25 +1036,26 @@ static int nbd_add_socket(struct nbd_device *nbd,
unsigned long arg,
test_bit(NBD_RT_BOUND, >runtime_flags))) {
dev_err(disk_to_dev(nbd->disk),
"Device being setup by another task");
- sockfd_put(sock);
- return -EBUSY;
+ err = -EBUSY;
+ goto put_socket;
+ }
+
+ nsock = kzalloc(sizeof(*nsock), GFP_KERNEL);
+ if (!nsock) {
+ err = -ENOMEM;
+ goto put_socket;
}
socks = krealloc(config->socks, (config->num_connections + 1) *
sizeof(struct nbd_sock *), GFP_KERNEL);
if (!socks) {
- sockfd_put(sock);
- return -ENOMEM;
+ kfree(nsock);
+ err = -ENOMEM;
+ goto put_socket;
}
config->socks = socks;
- nsock = kzalloc(sizeof(struct nbd_sock), GFP_KERNEL);
- if (!nsock) {
- sockfd_put(sock);
- return -ENOMEM;
- }
-
nsock->fallback_index = -1;
nsock->dead = false;
mutex_init(>tx_lock);
@@ -1066,6 +1067,10 @@ static int nbd_add_socket(struct nbd_device *nbd,
unsigned long arg,
atomic_inc(>live_connections);
return 0;
+
+put_socket:
+ sockfd_put(sock);
+ return err;
}
static int nbd_reconnect_socket(struct nbd_device *nbd, unsigned long arg)
--
2.26.0.106.g9fadedd
linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/nouveau/dispnv04/crtc.c
drivers/gpu/drm/nouveau/dispnv04/overlay.c
drivers/gpu/drm/nouveau/dispnv50/base507c.c
drivers/gpu/drm/nouveau/dispnv50/wndw.c
drivers/gpu/drm/nouveau/nouveau_dmem.c
drivers/gpu/drm/nouveau/nouveau_fbcon.c
between commits:
183405879255 ("drm/nouveau/kms: Remove field nvbo from struct
nouveau_framebuffer")
c586f30bf74c ("drm/nouveau/kms: Add format mod prop to base/ovly/nvdisp")
1d7f940c3a16 ("drm/nouveau/nouveau/hmm: fix nouveau_dmem_chunk allocations")
from Linus' tree and commit:
0dc9b286b8d2 ("drm/nouveau: don't use ttm bo->offset v3")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/nouveau/dispnv04/crtc.c
index 640738f3196c,cc6ab3c2eec7..
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@@ -840,12 -839,13 +840,12 @@@ nv04_crtc_do_mode_set_base(struct drm_c
*/
if (atomic) {
drm_fb = passed_fb;
- fb = nouveau_framebuffer(passed_fb);
} else {
drm_fb = crtc->primary->fb;
- fb = nouveau_framebuffer(crtc->primary->fb);
}
- nv_crtc->fb.offset = fb->nvbo->offset;
+ nvbo = nouveau_gem_object(drm_fb->obj[0]);
- nv_crtc->fb.offset = nvbo->bo.offset;
++ nv_crtc->fb.offset = nvbo->offset;
if (nv_crtc->lut.depth != drm_fb->format->depth) {
nv_crtc->lut.depth = drm_fb->format->depth;
diff --cc drivers/gpu/drm/nouveau/dispnv04/overlay.c
index 6248fd1dbc6d,9529bd9053e7..
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@@ -152,7 -150,7 +152,7 @@@ nv10_update_plane(struct drm_plane *pla
nvif_mask(dev, NV_PCRTC_ENGINE_CTRL + soff2, NV_CRTC_FSEL_OVERLAY, 0);
nvif_wr32(dev, NV_PVIDEO_BASE(flip), 0);
- nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nvbo->bo.offset);
- nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nv_fb->nvbo->offset);
++ nvif_wr32(dev, NV_PVIDEO_OFFSET_BUFF(flip), nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_SIZE_IN(flip), src_h << 16 | src_w);
nvif_wr32(dev, NV_PVIDEO_POINT_IN(flip), src_y << 16 | src_x);
nvif_wr32(dev, NV_PVIDEO_DS_DX(flip), (src_w << 20) / crtc_w);
@@@ -174,7 -172,7 +174,7 @@@
if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
- nvbo->bo.offset + fb->offsets[1]);
- nv_fb->nvbo->offset + fb->offsets[1]);
++ nvbo->offset + fb->offsets[1]);
}
nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
@@@ -399,7 -396,7 +399,7 @@@ nv04_update_plane(struct drm_plane *pla
for (i = 0; i < 2; i++) {
nvif_wr32(dev, NV_PVIDEO_BUFF0_START_ADDRESS + 4 * i,
- nvbo->bo.offset);
-nv_fb->nvbo->offset);
++nvbo->offset);
nvif_wr32(dev, NV_PVIDEO_BUFF0_PITCH_LENGTH + 4 * i,
fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_BUFF0_OFFSET + 4 * i, 0);
diff --cc drivers/gpu/drm/nouveau/dispnv50/base507c.c
index 511258bfbcbc,b60aa987d7b4..
--- a/drivers/gpu/drm/nouveau/dispnv50/base507c.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/base507c.c
@@@ -274,9 -273,9 +274,9 @@@ base507c_new_(const struct nv50_wndw_fu
if (*pwndw = wndw, ret)
return ret;
- ret = nv50_dmac_create(>client.device, >disp->object,
+ ret = nv50_dmac_create(>client.device, >disp.object,
, head, , sizeof(args),
- disp50->sync->bo.offset, >wndw);
- disp->sync->offset, >wndw);
++ disp50->sync->offset, >wndw);
if (ret) {
NV_ERROR(drm, "base%04x allocation failed: %d\n", oclass, ret);
return ret;
diff --cc drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 99b9b681736d,ee0fd817185e..
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@@ -521,12 -507,11 +521,12 @@@ nv50_wndw_prepare_fb(struct drm_plane *
return PTR_ERR(ctxdma);
}
- asyw->image.handle[0] = ctxdma->object.handle;
+ if
Re: [PATCH 1/2] m68k: nommu: register start of the memory with memblock
Hi Mike,
On 17/6/20 10:33 pm, Greg Ungerer wrote:
Hi Mike,
On 17/6/20 4:53 pm, Mike Rapoport wrote:
From: Mike Rapoport
The m68k nommu setup code didn't register the beginning of the physical
memory with memblock because it was anyway occupied by the kernel. However,
commit fa3354e4ea39 ("mm: free_area_init: use maximal zone PFNs rather than
zone sizes") changed zones initialization to use memblock.memory to detect
the zone extents and this caused inconsistency between zone PFNs and the
actual PFNs:
BUG: Bad page state in process swapper pfn:20165
page:41fe0ca0 refcount:0 mapcount:1 mapping: index:0x0 flags: 0x0()
raw: 0100 0122
page dumped because: nonzero mapcount
CPU: 0 PID: 1 Comm: swapper Not tainted 5.8.0-rc1-1-g3a38f8a60c65-dirty #1
Stack from 404c9ebc:
404c9ebc 4029ab28 4029ab28 40088470 41fe0ca0 40299e21 40299df1 404ba2a4
00020165 41fd2c10 402c7ba0 41fd2c04 40088504 41fe0ca0 40299e21
40088a12 41fe0ca0 41fe0ca4 020a 0001 402ca000
41fe0ca0 41fd2c10 41fd2c10 402b2388 0001
400a0934 40091056 404c9f44 404c9f44 40088db4 402c7ba0 0001 41fd2c04
41fe0ca0 41fd2000 41fe0ca0 40089e02 4026ecf4 40089e4e 41fe0ca0
Call Trace:
[<40088470>] 0x40088470
[<40088504>] 0x40088504
[<40088a12>] 0x40088a12
[<402ca000>] 0x402ca000
[<400a0934>] 0x400a0934
Adjust the memory registration with memblock to include the beginning of
the physical memory and make sure that the area occupied by the kernel is
marked as reserved.
Signed-off-by: Mike Rapoport
Acked-by: Greg Ungerer
What path do you anticipate this taking into mainline?
I see it is still broken in 5.8-rc3.
Regards
Greg
---
arch/m68k/kernel/setup_no.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/kernel/setup_no.c b/arch/m68k/kernel/setup_no.c
index e779b19e0193..f66f4b1d062e 100644
--- a/arch/m68k/kernel/setup_no.c
+++ b/arch/m68k/kernel/setup_no.c
@@ -138,7 +138,8 @@ void __init setup_arch(char **cmdline_p)
pr_debug("MEMORY -> ROMFS=0x%p-0x%06lx MEM=0x%06lx-0x%06lx\n ",
__bss_stop, memory_start, memory_start, memory_end);
- memblock_add(memory_start, memory_end - memory_start);
+ memblock_add(_rambase, memory_end - _rambase);
+ memblock_reserve(_rambase, memory_start - _rambase);
/* Keep a copy of command line */
*cmdline_p = _line[0];
Re: [PATCH v4 11/23] ASoC: simple-card: Loop over all children for 'mclk-fs'
Hi Sameer > CPU/Codec in DPCM DAI links are connected as CPU<->Dummy and Dummy<->Codec. > Though mostly CPU won't use/require 'mclk-fs' property, looping over > 'np' (current child node in a DAI link) can help in cases where multiple > Codecs are defined. This further helps to get rid of 'codec' argument > from simple_dai_link_of_dpcm() function, which gets called for DPCM links. > > Signed-off-by: Sameer Pujar > --- (snip) > diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c > index 39cdc71..02d6295 100644 > --- a/sound/soc/generic/simple-card.c > +++ b/sound/soc/generic/simple-card.c > @@ -107,7 +107,9 @@ static void simple_parse_mclk_fs(struct device_node *top, > snprintf(prop, sizeof(prop), "%smclk-fs", prefix); > of_property_read_u32(node, prop, >mclk_fs); > of_property_read_u32(cpu, prop, >mclk_fs); > - of_property_read_u32(codec, prop, >mclk_fs); > + > + if (cpu != codec) > + of_property_read_u32(codec, prop, >mclk_fs); Maybe we want to have "cpu" in simple_dai_link_of_dpcm() side without using magical code in simple_parse_mclk_fs() side ? Thank you for your help !! Best regards --- Kuninori Morimoto
Re: [PATCH 2/2] block: add BLKSETDESCZONE ioctl for Zoned Block Devices
On 2020/06/29 8:01, Matias Bjorling wrote:
> The NVMe Zoned Namespace Command Set adds support for associating
> data to a zone through the Zone Descriptor Extension feature.
>
> To allow user-space to associate data to a zone, add support through
> the BLKSETDESCZONE ioctl. The ioctl requires that it is issued to
> a zoned block device, and that it supports the Zone Descriptor
> Extension feature. Support is detected through the
> the zone_desc_ext_bytes sysfs queue entry for the specific block
> device. A value larger than zero communicates that the device supports
> the feature.
>
> The ioctl associates data to a zone by issuing a Zone Management Send
> command with the Zone Send Action set as the Set Zone Descriptor
> Extension.
>
> For the command to complete successfully, the specified zone must be
> in the Empty state, and active resources must be available. On
> success, the specified zone is transioned to Closed state by the
> device. If less data is supplied by user-space then reported by the
> the Zone Descriptor Extension size, the rest is zero-filled. If more
> data or no data is supplied by user-space, the ioctl fails.
>
> To issue the ioctl, a new blk_zone_set_desc data structure is defined.
> It has following parameters:
>
> * the sector of the specific zone.
> * the length of the data to be associated to the zone.
> * any flags be used by the ioctl. None is defined.
> * data associated to the zone.
>
> The data is laid out after the flags parameter, and it is the caller's
> responsibility to allocate memory for the data that is specified in the
> length parameter.
>
> Signed-off-by: Matias Bjørling
> ---
> block/blk-zoned.c | 108 ++
> block/ioctl.c | 2 +
> drivers/nvme/host/core.c | 3 +
> drivers/nvme/host/nvme.h | 9 +++
> drivers/nvme/host/zns.c | 11
> include/linux/blk_types.h | 2 +
> include/linux/blkdev.h| 9 ++-
> include/uapi/linux/blkzoned.h | 20 ++-
> 8 files changed, 162 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-zoned.c b/block/blk-zoned.c
> index 81152a260354..4dc40ec006a2 100644
> --- a/block/blk-zoned.c
> +++ b/block/blk-zoned.c
> @@ -259,6 +259,50 @@ int blkdev_zone_mgmt(struct block_device *bdev, enum
> req_opf op,
> }
> EXPORT_SYMBOL_GPL(blkdev_zone_mgmt);
>
> +/**
> + * blkdev_zone_set_desc - Execute a zone management set zone descriptor
> + *extension operation on a zone
> + * @bdev:Target block device
> + * @sector: Start sector of the zone to operate on
> + * @data:Pointer to the data that is to be associated to the zone
> + * @gfp_mask:Memory allocation flags (for bio_alloc)
> + *
> + * Description:
> + *Associate zone descriptor extension data to a specified zone.
> + *The block device must support zone descriptor extensions.
> + *i.e., by exposing a positive zone descriptor extension size.
> + */
> +int blkdev_zone_set_desc(struct block_device *bdev, sector_t sector,
> + struct page *data, gfp_t gfp_mask)
struct page for the data ? Why not just a "void *" to allow for kmalloc/vmalloc
data ? And no length for the data ? This is a bit odd.
> +{
> + struct request_queue *q = bdev_get_queue(bdev);
> + sector_t zone_sectors = blk_queue_zone_sectors(q);
> + struct bio_vec bio_vec;
> + struct bio bio;
> +
> + if (!blk_queue_is_zoned(q))
> + return -EOPNOTSUPP;
> +
> + if (bdev_read_only(bdev))
> + return -EPERM;
You are not checking the zone_desc_ext_bytes limit here. You should.
> +
> + /* Check alignment (handle eventual smaller last zone) */
> + if (sector & (zone_sectors - 1))
> + return -EINVAL;
The comment is incorrect. There is nothing special for handling the last zone in
this test.
> +
> + bio_init(, _vec, 1);
> + bio.bi_opf = REQ_OP_ZONE_SET_DESC | REQ_SYNC;
> + bio.bi_iter.bi_sector = sector;
> + bio_set_dev(, bdev);
> + bio_add_page(, data, queue_zone_desc_ext_bytes(q), 0);
> +
> + /* This may take a while, so be nice to others */
> + cond_resched();
This is not a loop, so you do not need this.
> +
> + return submit_bio_wait();
> +}
> +EXPORT_SYMBOL_GPL(blkdev_zone_set_desc);
> +
> struct zone_report_args {
> struct blk_zone __user *zones;
> };
> @@ -370,6 +414,70 @@ int blkdev_zone_mgmt_ioctl(struct block_device *bdev,
> fmode_t mode,
> GFP_KERNEL);
> }
>
> +/*
> + * BLKSETDESCZONE ioctl processing.
> + * Called from blkdev_ioctl.
> + */
> +int blkdev_zone_set_desc_ioctl(struct block_device *bdev, fmode_t mode,
> +unsigned int cmd, unsigned long arg)
> +{
> + void __user *argp = (void __user *)arg;
> + struct request_queue *q;
> + struct blk_zone_set_desc zsd;
> + void *zsd_data;
> + int ret;
> +
> + if (!argp)
> + return -EINVAL;
>
Re: [PATCH v4 10/23] ASoC: simple-card: Wrong daifmt for CPU end of DPCM DAI link
Hi Sameer
> simple-audio-card,dai-link@xxx {
> format = "i2s";
> bitclock-master=<>;
> frame-master=<>;
>
> cpu1: cpu@0 {
> ...
> };
>
> codec@0 {
> ...
> };
>
> ...
> };
>
> In above case CPU is expected to be configured as a master and Codec as
> a slave device. But both CPU/Codec are being configured as slave devices.
> This happens because asoc_simple_parse_daifmt() uses Codec reference and
> sets up the 'dai_link->dai_fmt' accordingly while parsing both CPU and
> Codec.
I'm sorry but I don't 100% understand about this case...
asoc_simple_parse_daifmt() should work in this case
The reason why it needs codec node is that
SND_SOC_DAIFMT_CBx_CFx are "Codec" base Master/Slave.
Thank you for your help !!
Best regards
---
Kuninori Morimoto
Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly
On 6/29/20 8:37 AM, Lai Jiangshan wrote:
> On Mon, Jun 29, 2020 at 8:13 AM Bob Liu wrote:
>>
>> On 6/28/20 11:54 PM, Lai Jiangshan wrote:
>>> On Thu, Jun 11, 2020 at 6:29 PM Bob Liu wrote:
Current code always set 'Unbound && max_active == 1' workqueues to ordered
implicitly, while this may be not an expected behaviour for some use cases.
E.g some scsi and iscsi workqueues(unbound && max_active = 1) want to be
bind
to different cpu so as to get better isolation, but their cpumask can't be
changed because WQ_ORDERED is set implicitly.
>>>
>>> Hello
>>>
>>> If I read the code correctly, the reason why their cpumask can't
>>> be changed is because __WQ_ORDERED_EXPLICIT, not __WQ_ORDERED.
>>>
This patch adds a flag __WQ_ORDERED_DISABLE and also
create_singlethread_workqueue_noorder() to offer an new option.
Signed-off-by: Bob Liu
---
include/linux/workqueue.h | 4
kernel/workqueue.c| 4 +++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index e48554e..4c86913 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -344,6 +344,7 @@ enum {
__WQ_ORDERED= 1 << 17, /* internal: workqueue is
ordered */
__WQ_LEGACY = 1 << 18, /* internal:
create*_workqueue() */
__WQ_ORDERED_EXPLICIT = 1 << 19, /* internal:
alloc_ordered_workqueue() */
+ __WQ_ORDERED_DISABLE= 1 << 20, /* internal: don't set
__WQ_ORDERED implicitly */
WQ_MAX_ACTIVE = 512,/* I like 512, better ideas? */
WQ_MAX_UNBOUND_PER_CPU = 4, /* 4 * #cpus for unbound wq */
@@ -433,6 +434,9 @@ struct workqueue_struct *alloc_workqueue(const char
*fmt,
#define create_singlethread_workqueue(name)\
alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
+#define create_singlethread_workqueue_noorder(name)\
+ alloc_workqueue("%s", WQ_SYSFS | __WQ_LEGACY | WQ_MEM_RECLAIM | \
+ WQ_UNBOUND | __WQ_ORDERED_DISABLE, 1, (name))
>>>
>>> I think using __WQ_ORDERED without __WQ_ORDERED_EXPLICIT is what you
>>> need, in which case cpumask is allowed to be changed.
>>>
>>
>> I don't think so, see function workqueue_apply_unbound_cpumask():
>>
>> wq_unbound_cpumask_store()
>> > workqueue_set_unbound_cpumask()
>>> workqueue_apply_unbound_cpumask() {
>> ...
>> 5276 /* creating multiple pwqs breaks ordering guarantee */
>> 5277 if (wq->flags & __WQ_ORDERED)
>> 5278 continue;
>>
>> Here will skip apply cpumask if only __WQ_ORDERED
>> is set.
>
> wq_unbound_cpumask_store() is for changing the cpumask of
> *all* workqueues.
Isn't '/sys/bus/workqueue/devices//cpumask' using the same function to
change cpumask of
specific workqueue?
Am I missing something..
> I don't think it can be used to make
> scsi and iscsi workqueues bound to different cpu.
>
The idea is to register scsi/iscsi workqueues with WQ_SYSFS, and then they can
be bounded to different
cpu by writing cpu number to "/sys/bus/workqueue/devices//cpumask".
> apply_workqueue_attrs() is for changing the cpumask of the specific
> workqueue, which can change the cpumask of __WQ_ORDERED workqueue
> (but without __WQ_ORDERED_EXPLICIT).
>
>>
>> 5280 ctx = apply_wqattrs_prepare(wq, wq->unbound_attrs);
>>
>> }
>>
>> Thanks for your review.
>> Bob
>>
>>> Just use alloc_workqueue() with __WQ_ORDERED and max_active=1. It can
>>> be wrapped as a new function or macro, but I don't think>
>>> create_singlethread_workqueue_noorder() is a good name for it.
>>>
extern void destroy_workqueue(struct workqueue_struct *wq);
struct workqueue_attrs *alloc_workqueue_attrs(void);
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 4e01c44..2167013 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -4237,7 +4237,9 @@ struct workqueue_struct *alloc_workqueue(const char
*fmt,
* on NUMA.
*/
if ((flags & WQ_UNBOUND) && max_active == 1)
- flags |= __WQ_ORDERED;
+ /* the caller may don't want __WQ_ORDERED to be set
implicitly. */
+ if (!(flags & __WQ_ORDERED_DISABLE))
+ flags |= __WQ_ORDERED;
/* see the comment above the definition of WQ_POWER_EFFICIENT */
if ((flags & WQ_POWER_EFFICIENT) && wq_power_efficient)
--
2.9.5
>>
Re: [PATCH 1/2] kconfig: remove '---help---' support
On Wed, Jun 17, 2020 at 12:02 PM Masahiro Yamada wrote:
>
> The conversion is done. No more user of '---help---'.
>
> Cc: Ulf Magnusson
> Signed-off-by: Masahiro Yamada
Applied to linux-kbuild.
> ---
>
> scripts/checkkconfigsymbols.py | 2 +-
> scripts/kconfig/lexer.l| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/checkkconfigsymbols.py b/scripts/checkkconfigsymbols.py
> index 00a10a293f4f..1548f9ce4682 100755
> --- a/scripts/checkkconfigsymbols.py
> +++ b/scripts/checkkconfigsymbols.py
> @@ -34,7 +34,7 @@ REGEX_SOURCE_SYMBOL = re.compile(SOURCE_SYMBOL)
> REGEX_KCONFIG_DEF = re.compile(DEF)
> REGEX_KCONFIG_EXPR = re.compile(EXPR)
> REGEX_KCONFIG_STMT = re.compile(STMT)
> -REGEX_KCONFIG_HELP = re.compile(r"^\s+(help|---help---)\s*$")
> +REGEX_KCONFIG_HELP = re.compile(r"^\s+help\s*$")
> REGEX_FILTER_SYMBOLS = re.compile(r"[A-Za-z0-9]$")
> REGEX_NUMERIC = re.compile(r"0[xX][0-9a-fA-F]+|[0-9]+")
> REGEX_QUOTES = re.compile("(\"(.*?)\")")
> diff --git a/scripts/kconfig/lexer.l b/scripts/kconfig/lexer.l
> index 6354c905b006..4b7339ff4c8b 100644
> --- a/scripts/kconfig/lexer.l
> +++ b/scripts/kconfig/lexer.l
> @@ -105,7 +105,7 @@ n [A-Za-z0-9_-]
> "endchoice"return T_ENDCHOICE;
> "endif"return T_ENDIF;
> "endmenu" return T_ENDMENU;
> -"help"|"---help---"return T_HELP;
> +"help" return T_HELP;
> "hex" return T_HEX;
> "if" return T_IF;
> "imply"return T_IMPLY;
> --
> 2.25.1
>
--
Best Regards
Masahiro Yamada
Re: [PATCH 1/2] block: add zone_desc_ext_bytes to sysfs
On 2020/06/29 8:01, Matias Bjorling wrote:
> The NVMe Zoned Namespace Command Set adds support for associating
> data to a zone through the Zone Descriptor Extension feature.
>
> The Zone Descriptor Extension size is fixed to a multiple of 64
> bytes. A value of zero communicates the feature is not available.
> A value larger than zero communites the feature is available, and
> the specified Zone Descriptor Extension size in bytes.
>
> The Zone Descriptor Extension feature is only available in the
> NVMe Zoned Namespaces Command Set. Devices that supports ZAC/ZBC
> therefore reports this value as zero, where as the NVMe device
> driver reports the Zone Descriptor Extension size from the
> specific device.
>
> Signed-off-by: Matias Bjørling
> ---
> Documentation/block/queue-sysfs.rst | 6 ++
> block/blk-sysfs.c | 15 ++-
> drivers/nvme/host/zns.c | 1 +
> drivers/scsi/sd_zbc.c | 1 +
> include/linux/blkdev.h | 22 ++
> 5 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/block/queue-sysfs.rst
> b/Documentation/block/queue-sysfs.rst
> index f261a5c84170..c4fa195c87b4 100644
> --- a/Documentation/block/queue-sysfs.rst
> +++ b/Documentation/block/queue-sysfs.rst
> @@ -265,4 +265,10 @@ devices are described in the ZBC (Zoned Block Commands)
> and ZAC
> do not support zone commands, they will be treated as regular block devices
> and zoned will report "none".
>
> +zone_desc_ext_bytes (RO)
> +-
> +This indicates the zone description extension (ZDE) size, in bytes, of a
> zoned
> +block device. A value of '0' means that zone description extension is not
> +supported.
> +
> Jens Axboe , February 2009
> diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
> index 624bb4d85fc7..0c99454823b7 100644
> --- a/block/blk-sysfs.c
> +++ b/block/blk-sysfs.c
> @@ -315,6 +315,12 @@ static ssize_t queue_max_active_zones_show(struct
> request_queue *q, char *page)
> return queue_var_show(queue_max_active_zones(q), page);
> }
>
> +static ssize_t queue_zone_desc_ext_bytes_show(struct request_queue *q,
> + char *page)
> +{
> + return queue_var_show(queue_zone_desc_ext_bytes(q), page);
> +}
> +
> static ssize_t queue_nomerges_show(struct request_queue *q, char *page)
> {
> return queue_var_show((blk_queue_nomerges(q) << 1) |
> @@ -687,6 +693,11 @@ static struct queue_sysfs_entry
> queue_max_active_zones_entry = {
> .show = queue_max_active_zones_show,
> };
>
> +static struct queue_sysfs_entry queue_zone_desc_ext_bytes_entry = {
> + .attr = {.name = "zone_desc_ext_bytes", .mode = 0444 },
> + .show = queue_zone_desc_ext_bytes_show,
> +};
> +
> static struct queue_sysfs_entry queue_nomerges_entry = {
> .attr = {.name = "nomerges", .mode = 0644 },
> .show = queue_nomerges_show,
> @@ -787,6 +798,7 @@ static struct attribute *queue_attrs[] = {
> _nr_zones_entry.attr,
> _max_open_zones_entry.attr,
> _max_active_zones_entry.attr,
Which tree is this patch based on ? Not I have seen any patch introducing max
active zones.
> + _zone_desc_ext_bytes_entry.attr,
> _nomerges_entry.attr,
> _rq_affinity_entry.attr,
> _iostats_entry.attr,
> @@ -815,7 +827,8 @@ static umode_t queue_attr_visible(struct kobject *kobj,
> struct attribute *attr,
> return 0;
>
> if ((attr == _max_open_zones_entry.attr ||
> - attr == _max_active_zones_entry.attr) &&
> + attr == _max_active_zones_entry.attr ||
> + attr == _zone_desc_ext_bytes_entry.attr) &&
> !blk_queue_is_zoned(q))
> return 0;
>
> diff --git a/drivers/nvme/host/zns.c b/drivers/nvme/host/zns.c
> index 502070763266..5792d953a8f3 100644
> --- a/drivers/nvme/host/zns.c
> +++ b/drivers/nvme/host/zns.c
> @@ -84,6 +84,7 @@ int nvme_update_zone_info(struct gendisk *disk, struct
> nvme_ns *ns,
> blk_queue_flag_set(QUEUE_FLAG_ZONE_RESETALL, q);
> blk_queue_max_open_zones(q, le32_to_cpu(id->mor) + 1);
> blk_queue_max_active_zones(q, le32_to_cpu(id->mar) + 1);
> + blk_queue_zone_desc_ext_bytes(q, id->lbafe[lbaf].zdes << 6);
> free_data:
> kfree(id);
> return status;
> diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c
> index d8b2c49d645b..a4b6d6cf5457 100644
> --- a/drivers/scsi/sd_zbc.c
> +++ b/drivers/scsi/sd_zbc.c
> @@ -722,6 +722,7 @@ int sd_zbc_read_zones(struct scsi_disk *sdkp, unsigned
> char *buf)
> else
> blk_queue_max_open_zones(q, sdkp->zones_max_open);
> blk_queue_max_active_zones(q, 0);
> + blk_queue_zone_desc_ext_bytes(q, 0);
> nr_zones = round_up(sdkp->capacity, zone_blocks) >> ilog2(zone_blocks);
>
> /* READ16/WRITE16 is mandatory for ZBC disks */
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 3776140f8f20..2ed55055f68d 100644
> ---
RE: Re: [iproute2-next] action police: make 'mtu' could be set independently in police action
Hi Stephen,
> -Original Message-
> From: Stephen Hemminger
> Sent: 2020年6月29日 4:16
> To: Po Liu
> Cc: dsah...@gmail.com; linux-kernel@vger.kernel.org;
> net...@vger.kernel.org; da...@davemloft.net; j...@mojatatu.com;
> v...@buslov.dev; Claudiu Manoil ; Vladimir
> Oltean ; Alexandru Marginean
>
> Subject: Re: [iproute2-next] action police: make 'mtu' could be set
> independently in police action
>
> On Sun, 28 Jun 2020 09:46:02 +0800
> Po Liu wrote:
>
> > Current police action must set 'rate' and 'burst'. 'mtu' parameter set
> > the max frame size and could be set alone without 'rate' and 'burst'
> > in some situation. Offloading to hardware for example, 'mtu' could
> > limit the flow max frame size.
> >
> > Signed-off-by: Po Liu
> > ---
> > tc/m_police.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tc/m_police.c b/tc/m_police.c index a5bc20c0..89497f67
> > 100644
> > --- a/tc/m_police.c
> > +++ b/tc/m_police.c
> > @@ -161,8 +161,8 @@ action_ctrl_ok:
> > return -1;
> >
> > /* Must at least do late binding, use TB or ewma policing */
> > - if (!rate64 && !avrate && !p.index) {
> > - fprintf(stderr, "\"rate\" or \"avrate\" MUST be
> > specified.\n");
> > + if (!rate64 && !avrate && !p.index && !mtu) {
> > + fprintf(stderr, "\"rate\" or \"avrate\" or \"mtu\"MUST
> > + be specified.\n");
>
> Missing blank.
> Your message will come out as:
> "rate" or "avrate" or "mtu"MUST be specified.
Get it. Will correct.
Thanks!
>
>
> The quotes aren't adding to the readability, why not just remove them
> instead.
Will remove all quotes.
Br,
Po Liu
Re: [PATCH v4 08/23] ASoC: soc-core: Fix component name_prefix parsing
Hi Sameer
Thank you for your patch
# I guess there was ML registering magic until v3 ?
# This is 1st time for me to get this patch series...
> The "prefix" can be defined in DAI link node or it can be specified as
> part of the component node itself. Currently "sound-name-prefix" defined
> in a component is not taking effect. Actually the property is not getting
> parsed. It can be fixed by parsing "sound-name-prefix" property whenever
> "prefix" is missing in DAI link Codec node.
>
> Signed-off-by: Sameer Pujar
(snip)
> @@ -,8 +,10 @@ static void soc_set_name_prefix(struct snd_soc_card
> *card,
> struct snd_soc_codec_conf *map = >codec_conf[i];
>
> if (snd_soc_is_matching_component(>dlc, component)) {
> - component->name_prefix = map->name_prefix;
> - return;
> + if (map->name_prefix) {
> + component->name_prefix = map->name_prefix;
> + return;
> + }
> }
> }
This is nit-pick but it can be like this ?
if (snd_soc_is_matching_component(>dlc, component) &&
map->name_prefix) {
...
}
Thank you for your help !!
Best regards
---
Kuninori Morimoto
Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly
On Mon, Jun 29, 2020 at 8:13 AM Bob Liu wrote:
>
> On 6/28/20 11:54 PM, Lai Jiangshan wrote:
> > On Thu, Jun 11, 2020 at 6:29 PM Bob Liu wrote:
> >>
> >> Current code always set 'Unbound && max_active == 1' workqueues to ordered
> >> implicitly, while this may be not an expected behaviour for some use cases.
> >>
> >> E.g some scsi and iscsi workqueues(unbound && max_active = 1) want to be
> >> bind
> >> to different cpu so as to get better isolation, but their cpumask can't be
> >> changed because WQ_ORDERED is set implicitly.
> >
> > Hello
> >
> > If I read the code correctly, the reason why their cpumask can't
> > be changed is because __WQ_ORDERED_EXPLICIT, not __WQ_ORDERED.
> >
> >>
> >> This patch adds a flag __WQ_ORDERED_DISABLE and also
> >> create_singlethread_workqueue_noorder() to offer an new option.
> >>
> >> Signed-off-by: Bob Liu
> >> ---
> >> include/linux/workqueue.h | 4
> >> kernel/workqueue.c| 4 +++-
> >> 2 files changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
> >> index e48554e..4c86913 100644
> >> --- a/include/linux/workqueue.h
> >> +++ b/include/linux/workqueue.h
> >> @@ -344,6 +344,7 @@ enum {
> >> __WQ_ORDERED= 1 << 17, /* internal: workqueue is
> >> ordered */
> >> __WQ_LEGACY = 1 << 18, /* internal:
> >> create*_workqueue() */
> >> __WQ_ORDERED_EXPLICIT = 1 << 19, /* internal:
> >> alloc_ordered_workqueue() */
> >> + __WQ_ORDERED_DISABLE= 1 << 20, /* internal: don't set
> >> __WQ_ORDERED implicitly */
> >>
> >> WQ_MAX_ACTIVE = 512,/* I like 512, better ideas? */
> >> WQ_MAX_UNBOUND_PER_CPU = 4, /* 4 * #cpus for unbound wq */
> >> @@ -433,6 +434,9 @@ struct workqueue_struct *alloc_workqueue(const char
> >> *fmt,
> >> #define create_singlethread_workqueue(name)\
> >> alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
> >>
> >> +#define create_singlethread_workqueue_noorder(name)\
> >> + alloc_workqueue("%s", WQ_SYSFS | __WQ_LEGACY | WQ_MEM_RECLAIM | \
> >> + WQ_UNBOUND | __WQ_ORDERED_DISABLE, 1, (name))
> >
> > I think using __WQ_ORDERED without __WQ_ORDERED_EXPLICIT is what you
> > need, in which case cpumask is allowed to be changed.
> >
>
> I don't think so, see function workqueue_apply_unbound_cpumask():
>
> wq_unbound_cpumask_store()
> > workqueue_set_unbound_cpumask()
>> workqueue_apply_unbound_cpumask() {
> ...
> 5276 /* creating multiple pwqs breaks ordering guarantee */
> 5277 if (wq->flags & __WQ_ORDERED)
> 5278 continue;
>
> Here will skip apply cpumask if only __WQ_ORDERED
> is set.
wq_unbound_cpumask_store() is for changing the cpumask of
*all* workqueues. I don't think it can be used to make
scsi and iscsi workqueues bound to different cpu.
apply_workqueue_attrs() is for changing the cpumask of the specific
workqueue, which can change the cpumask of __WQ_ORDERED workqueue
(but without __WQ_ORDERED_EXPLICIT).
>
> 5280 ctx = apply_wqattrs_prepare(wq, wq->unbound_attrs);
>
> }
>
> Thanks for your review.
> Bob
>
> > Just use alloc_workqueue() with __WQ_ORDERED and max_active=1. It can
> > be wrapped as a new function or macro, but I don't think>
> > create_singlethread_workqueue_noorder() is a good name for it.
> >
> >> extern void destroy_workqueue(struct workqueue_struct *wq);
> >>
> >> struct workqueue_attrs *alloc_workqueue_attrs(void);
> >> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> >> index 4e01c44..2167013 100644
> >> --- a/kernel/workqueue.c
> >> +++ b/kernel/workqueue.c
> >> @@ -4237,7 +4237,9 @@ struct workqueue_struct *alloc_workqueue(const char
> >> *fmt,
> >> * on NUMA.
> >> */
> >> if ((flags & WQ_UNBOUND) && max_active == 1)
> >> - flags |= __WQ_ORDERED;
> >> + /* the caller may don't want __WQ_ORDERED to be set
> >> implicitly. */
> >> + if (!(flags & __WQ_ORDERED_DISABLE))
> >> + flags |= __WQ_ORDERED;
> >>
> >> /* see the comment above the definition of WQ_POWER_EFFICIENT */
> >> if ((flags & WQ_POWER_EFFICIENT) && wq_power_efficient)
> >> --
> >> 2.9.5
> >>
>
Re: [PATCH 0/6] Overhaul memalloc_no*
On Sat, Jun 27, 2020 at 09:09:09AM -0400, Mikulas Patocka wrote: > > > On Sat, 27 Jun 2020, Dave Chinner wrote: > > > On Fri, Jun 26, 2020 at 11:02:19AM -0400, Mikulas Patocka wrote: > > > Hi > > > > > > I suggest to join memalloc_noio and memalloc_nofs into just one flag that > > > prevents both filesystem recursion and i/o recursion. > > > > > > Note that any I/O can recurse into a filesystem via the loop device, thus > > > it doesn't make much sense to have a context where PF_MEMALLOC_NOFS is > > > set > > > and PF_MEMALLOC_NOIO is not set. > > > > Correct me if I'm wrong, but I think that will prevent swapping from > > GFP_NOFS memory reclaim contexts. > > Yes. > > > IOWs, this will substantially > > change the behaviour of the memory reclaim system under sustained > > GFP_NOFS memory pressure. Sustained GFP_NOFS memory pressure is > > quite common, so I really don't think we want to telling memory > > reclaim "you can't do IO at all" when all we are trying to do is > > prevent recursion back into the same filesystem. > > So, we can define __GFP_ONLY_SWAP_IO and __GFP_IO. Uh, why? Exactly what problem are you trying to solve here? > > Given that the loop device IO path already operates under > > memalloc_noio context, (i.e. the recursion restriction is applied in > > only the context that needs is) I see no reason for making that a > > global reclaim limitation > > I think this is a problem. > > Suppose that a filesystem does GFP_NOFS allocation, the allocation > triggers an IO and waits for it to finish, the loop device driver > redirects the IO to the same filesystem that did the GFP_NOFS allocation. The loop device IO path is under memalloc_noio. By -definition-, allocations in that context cannot recurse back into filesystem level reclaim. So either your aren't explaining the problem you are trying to solve clearly, or you're talking about allocations in the IO path that are broken because they don't use GFP_NOIO correctly... > I saw this deadlock in the past in the dm-bufio subsystem - see the commit > 9d28eb12447ee08bb5d1e8bb3195cf20e1ecd1c0 that fixed it. 2014? /me looks closer. Hmmm. Only sent to dm-devel, no comments, no review, just merged. No surprise that nobody else actually knows about this commit. Well, time to review it ~6 years after it was merged | dm-bufio tested for __GFP_IO. However, dm-bufio can run on a loop block | device that makes calls into the filesystem. If __GFP_IO is present and | __GFP_FS isn't, dm-bufio could still block on filesystem operations if it | runs on a loop block device. OK, so from an architectural POV, this commit is fundamentally broken - block/device layer allocation should not allow relcaim recursion into filesystems because filesystems are dependent on the block layer making forwards progress. This commit is trying to work around the loop device doing GFP_KERNEL/GFP_NOFS context allocation back end IO path of the loop device. This part of the loop device is a block device, so needs to run under GFP_NOIO context. IOWs, this commit just papered over the reclaim context layering violation in the loop device by trying to avoid blocking filesystem IO in the dm-bufio shrinker context just in case it was IO from a loop device that was incorrectly tagged as GFP_KERNEL. So, step forward 5 years to 2019, and this change was made: commit d0a255e795ab976481565f6ac178314b34fbf891 Author: Mikulas Patocka Date: Thu Aug 8 11:17:01 2019 -0400 loop: set PF_MEMALLOC_NOIO for the worker thread A deadlock with this stacktrace was observed. The loop thread does a GFP_KERNEL allocation, it calls into dm-bufio shrinker and the shrinker depends on I/O completion in the dm-bufio subsystem. In order to fix the deadlock (and other similar ones), we set the flag PF_MEMALLOC_NOIO at loop thread entry. PID: 474TASK: 8813e11f4600 CPU: 10 COMMAND: "kswapd0" #0 [8813dedfb938] __schedule at 8173f405 #1 [8813dedfb990] schedule at 8173fa27 #2 [8813dedfb9b0] schedule_timeout at 81742fec #3 [8813dedfba60] io_schedule_timeout at 8173f186 #4 [8813dedfbaa0] bit_wait_io at 8174034f #5 [8813dedfbac0] __wait_on_bit at 8173fec8 #6 [8813dedfbb10] out_of_line_wait_on_bit at 8173ff81 #7 [8813dedfbb90] __make_buffer_clean at a038736f [dm_bufio] #8 [8813dedfbbb0] __try_evict_buffer at a0387bb8 [dm_bufio] #9 [8813dedfbbd0] dm_bufio_shrink_scan at a0387cc3 [dm_bufio] #10 [8813dedfbc40] shrink_slab at 811a87ce #11 [8813dedfbd30] shrink_zone at 811ad778 #12 [8813dedfbdc0] kswapd at 811ae92f #13 [8813dedfbec0] kthread at 810a8428 #14 [8813dedfbf50] ret_from_fork at 81745242 PID: 14127 TASK: 881455749c00 CPU: 11
Re: [PATCH] fbtft-bus.c: Removing that prohibited space before ')'
Hi K,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v5.8-rc2 next-20200626]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c-Removing-that-prohibited-space-before/20200627-125315
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: ia64-randconfig-s031-20200624 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-dirty
# save the attached .config to linux build tree
make W=1 C=1 ARCH=ia64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/staging/fbtft/fbtft-bus.c:65:1: sparse: sparse: macro
>> "define_fbtft_write_reg" requires 4 arguments, but only 3 given
drivers/staging/fbtft/fbtft-bus.c:67:1: sparse: sparse: macro
"define_fbtft_write_reg" requires 4 arguments, but only 3 given
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at end of
declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got void
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ) in
function declarator
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got (
>> drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Trying to use
>> reserved word 'if' as identifier
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ) in
function declarator
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got =
>> drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Trying to use
>> reserved word 'for' as identifier
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at end of
declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got <
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at end of
declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got ++
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at end of
declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got +=
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at the
end of type declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got }
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at end of
declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got +=
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at the
end of type declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got }
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at end of
declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got +=
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at the
end of type declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got }
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at end of
declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got +=
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at the
end of type declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got }
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at the
end of type declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got }
>> drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Trying to use
>> reserved word 'do' as identifier
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at end of
declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got {
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at the
end of type declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got }
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at the
end of type declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got }
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ) in
function declarator
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got ->
>> drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Trying to use
>> reserved word 'if' as identifier
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at the
end of type declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got }
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: Expected ; at end of
declaration
drivers/staging/fbtft/fbtft-bus.c:66:1: sparse: sparse: got +=
RE: [PATCH v14 3/3] Input: new da7280 haptic driver
On Sat, June 27, 2020 12:56 AM, Uwe Kleine-König wrote: > On Fri, Jun 26, 2020 at 01:17:29PM +, Roy Im wrote: > > > On Fri, June 26, 2020 3:19 PM, Uwe Kleine-König wrote: > > > Hello, > > > from the PWM POV I'm happy now. Just a few minor comments that I noticed > > > while checking the PWM details. > > > > Many thanks for your comments. > > > > > > > > On Thu, Jun 25, 2020 at 01:59:29AM +0900, Roy Im wrote: > > > > + val = haptics->ps_seq_id << DA7280_PS_SEQ_ID_SHIFT | > > > > + haptics->ps_seq_loop << > > > > DA7280_PS_SEQ_LOOP_SHIFT; > > > > > > If you write this as: > > > > > > val = FIELD_PREP(DA7280_PS_SEQ_ID_MASK, haptics->ps_seq_id) | > > > FIELD_PREP(DA7280_PS_SEQ_LOOP_MASK, haptics->ps_seq_loop); > > > > > > you get some additional checks for free and can drop all defines for > > > ..._SHIFT . > > > > It is not difficult to update that as you advise, but I think having > > the shift there explicitly makes it more readable, so most of the > > drivers from my team have the defines(shift) up to now. I guess this > > is a kind of subjective thing. > > Do you think it is still necessary? Then I will update as you said. > > No, from my side it's not a hard requirement (and after all I'm not the one > who will take your commit). I personally like it better > with FIELD_PREP, but I can still sleep if you don't agree :-) > > What I don't like about having both ..._SHIFT and ..._MASK is that there is > some duplication as ..._SHIFT can be calculated > from ..._MASK: > > #define LALA_SHIFT (ffs(LALA_MASK) - 1) OK, I got it and I will update. > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | https://www.pengutronix.de/ |
Re: [PATCH 1/2] workqueue: don't always set __WQ_ORDERED implicitly
On 6/28/20 11:54 PM, Lai Jiangshan wrote:
> On Thu, Jun 11, 2020 at 6:29 PM Bob Liu wrote:
>>
>> Current code always set 'Unbound && max_active == 1' workqueues to ordered
>> implicitly, while this may be not an expected behaviour for some use cases.
>>
>> E.g some scsi and iscsi workqueues(unbound && max_active = 1) want to be bind
>> to different cpu so as to get better isolation, but their cpumask can't be
>> changed because WQ_ORDERED is set implicitly.
>
> Hello
>
> If I read the code correctly, the reason why their cpumask can't
> be changed is because __WQ_ORDERED_EXPLICIT, not __WQ_ORDERED.
>
>>
>> This patch adds a flag __WQ_ORDERED_DISABLE and also
>> create_singlethread_workqueue_noorder() to offer an new option.
>>
>> Signed-off-by: Bob Liu
>> ---
>> include/linux/workqueue.h | 4
>> kernel/workqueue.c| 4 +++-
>> 2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
>> index e48554e..4c86913 100644
>> --- a/include/linux/workqueue.h
>> +++ b/include/linux/workqueue.h
>> @@ -344,6 +344,7 @@ enum {
>> __WQ_ORDERED= 1 << 17, /* internal: workqueue is ordered
>> */
>> __WQ_LEGACY = 1 << 18, /* internal: create*_workqueue()
>> */
>> __WQ_ORDERED_EXPLICIT = 1 << 19, /* internal:
>> alloc_ordered_workqueue() */
>> + __WQ_ORDERED_DISABLE= 1 << 20, /* internal: don't set
>> __WQ_ORDERED implicitly */
>>
>> WQ_MAX_ACTIVE = 512,/* I like 512, better ideas? */
>> WQ_MAX_UNBOUND_PER_CPU = 4, /* 4 * #cpus for unbound wq */
>> @@ -433,6 +434,9 @@ struct workqueue_struct *alloc_workqueue(const char *fmt,
>> #define create_singlethread_workqueue(name)\
>> alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
>>
>> +#define create_singlethread_workqueue_noorder(name)\
>> + alloc_workqueue("%s", WQ_SYSFS | __WQ_LEGACY | WQ_MEM_RECLAIM | \
>> + WQ_UNBOUND | __WQ_ORDERED_DISABLE, 1, (name))
>
> I think using __WQ_ORDERED without __WQ_ORDERED_EXPLICIT is what you
> need, in which case cpumask is allowed to be changed.
>
I don't think so, see function workqueue_apply_unbound_cpumask():
wq_unbound_cpumask_store()
> workqueue_set_unbound_cpumask()
> workqueue_apply_unbound_cpumask() {
...
5276 /* creating multiple pwqs breaks ordering guarantee */
5277 if (wq->flags & __WQ_ORDERED)
5278 continue;
Here will skip apply cpumask if only __WQ_ORDERED is
set.
5280 ctx = apply_wqattrs_prepare(wq, wq->unbound_attrs);
}
Thanks for your review.
Bob
> Just use alloc_workqueue() with __WQ_ORDERED and max_active=1. It can
> be wrapped as a new function or macro, but I don't think>
> create_singlethread_workqueue_noorder() is a good name for it.
>
>> extern void destroy_workqueue(struct workqueue_struct *wq);
>>
>> struct workqueue_attrs *alloc_workqueue_attrs(void);
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index 4e01c44..2167013 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -4237,7 +4237,9 @@ struct workqueue_struct *alloc_workqueue(const char
>> *fmt,
>> * on NUMA.
>> */
>> if ((flags & WQ_UNBOUND) && max_active == 1)
>> - flags |= __WQ_ORDERED;
>> + /* the caller may don't want __WQ_ORDERED to be set
>> implicitly. */
>> + if (!(flags & __WQ_ORDERED_DISABLE))
>> + flags |= __WQ_ORDERED;
>>
>> /* see the comment above the definition of WQ_POWER_EFFICIENT */
>> if ((flags & WQ_POWER_EFFICIENT) && wq_power_efficient)
>> --
>> 2.9.5
>>
Re: [PATCH] kernel/trace: Add TRACING_ALLOW_PRINTK config option
On Sun, 28 Jun 2020 18:28:42 -0400
Steven Rostedt wrote:
> You create a bpf event just like you create any other event. When a bpf
> program that uses a bpf_trace_printk() is loaded, you can enable that
> event from within the kernel. Yes, there's internal interfaces to
> enabled and disable events just like echoing 1 into
> tracefs/events/system/event/enable. See trace_set_clr_event().
I just started playing with what the code would look like and have
this. It can be optimized with per-cpu sets of buffers to remove the
spin lock. I also didn't put in the enabling of the event, but I'm sure
you can figure that out.
Warning, not even compiled tested.
-- Steve
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 6575bb0a0434..aeba5ee7325a 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -31,6 +31,8 @@ ifdef CONFIG_GCOV_PROFILE_FTRACE
GCOV_PROFILE := y
endif
+CFLAGS_bpf_trace.o := -I$(src)
+
CFLAGS_trace_benchmark.o := -I$(src)
CFLAGS_trace_events_filter.o := -I$(src)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index dc05626979b8..01bedf335b2e 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -19,6 +19,9 @@
#include "trace_probe.h"
#include "trace.h"
+#define CREATE_TRACE_EVENTS
+#include "bpf_trace.h"
+
#define bpf_event_rcu_dereference(p) \
rcu_dereference_protected(p, lockdep_is_held(_event_mutex))
@@ -473,13 +476,29 @@ BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size,
u64, arg1,
fmt_cnt++;
}
+static DEFINE_SPINLOCK(trace_printk_lock);
+#define BPF_TRACE_PRINTK_SIZE 1024
+
+static inline void do_trace_printk(const char *fmt, ...)
+{
+ static char buf[BPF_TRACE_PRINT_SIZE];
+ unsigned long flags;
+
+ spin_lock_irqsave(_printk_lock, flags);
+ va_start(ap, fmt);
+ vsnprintf(buf, BPF_TRACE_PRINT_SIZE, fmt, ap);
+ va_end(ap);
+
+ trace_bpf_trace_printk(buf);
+ spin_unlock_irqrestore(_printk_lock, flags);
+}
+
/* Horrid workaround for getting va_list handling working with different
* argument type combinations generically for 32 and 64 bit archs.
*/
#define __BPF_TP_EMIT()__BPF_ARG3_TP()
#define __BPF_TP(...) \
- __trace_printk(0 /* Fake ip */, \
- fmt, ##__VA_ARGS__)
+ do_trace_printk(fmt, ##__VA_ARGS__)
#define __BPF_ARG1_TP(...) \
((mod[0] == 2 || (mod[0] == 1 && __BITS_PER_LONG == 64))\
diff --git a/kernel/trace/bpf_trace.h b/kernel/trace/bpf_trace.h
new file mode 100644
index ..09088bb92fe1
--- /dev/null
+++ b/kernel/trace/bpf_trace.h
@@ -0,0 +1,27 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM bpf_trace
+
+#if !defined(_TRACE_BPF_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_BPF_TRACE_H
+
+TRACE_EVENT(bpf_trace_printk,
+
+ TP_PROTO(bpf_string),
+
+ TP_ARGS(secs, err),
+
+ TP_STRUCT__entry(
+ __string(bpf_string, bpf_string)
+ ),
+
+ TP_fast_assign(
+ __assign_string(bpf_string, bpf_string);
+ ),
+
+ TP_printk("%s", __get_str(bpf_string))
+);
+
+#endif /* _TRACE_BPF_TRACE_H */
+
+/* This part must be outside protection */
+#include
Re: [RFC PATCH 0/4] DirectX on Linux
On Tue, May 19, 2020 at 2:36 PM Sasha Levin wrote: > > Hi Daniel, > > On Tue, May 19, 2020 at 09:21:15PM +0200, Daniel Vetter wrote: > >Hi Sasha > > > >So obviously great that Microsoft is trying to upstream all this, and > >very much welcome and all that. > > > >But I guess there's a bunch of rather fundamental issues before we > >look into any kind of code details. And that might make this quite a > >hard sell for upstream to drivers/gpu subsystem: > > Let me preface my answers by saying that speaking personally I very much > dislike that the userspace is closed and wish I could do something about > it. > > >- From the blog it sounds like the userspace is all closed. That > >includes the hw specific part and compiler chunks, all stuff we've > >generally expected to be able to look in the past for any kind of > >other driver. It's event documented here: > > > >https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements > > > >What's your plan here? > > Let me answer with a (genuine) question: does this driver have anything > to do with DRM even after we enable graphics on it? I'm still trying to > figure it out. > > There is an open source DX12 Galluim driver (that lives here: > https://gitlab.freedesktop.org/kusma/mesa/-/tree/msclc-d3d12) with open > source compiler and so on. > > The plan is for Microsoft to provide shims to allow the existing Linux > userspace interact with DX12; I'll explain below why we had to pipe DX12 > all the way into the Linux guest, but this is *not* to introduce DX12 > into the Linux world as competition. There is no intent for anyone in > the Linux world to start coding for the DX12 API. If that really is the case why is microsoft recommending developers to break compatibility with native Linux and use the DX12 API's here: https://devblogs.microsoft.com/directx/in-the-works-opencl-and-opengl-mapping-layers-to-directx/ Quote: "Make it easier for developers to port their apps to D3D12. For developers looking to move from older OpenCL and OpenGL API versions to D3D12, the open source mapping layers will provide helpful example code on how to use the D3D12 Translation Layer library." If developers of applications that use OpenCL and OpenGL API's were to follow this advice and transition to D3D12 their applications would no longer work on Linux systems unless using WSL2. Is Microsoft planning on creating a D3D12/DirectML frontend that doesn't depend on WSL2? > > This is why I'm not sure whether this touches DRM on the Linux side of > things. Nothing is actually rendered on Linux but rather piped to > Windows to be done there. > > >btw since the main goal here (at least at first) seems to be get > >compute and ML going the official work-around here is to relabel your > >driver as an accelerator driver (just sed -e s/vGPU/vaccel/ over the > >entire thing or so) and then Olof and Greg will take it into > >drivers/accel ... > > This submission is not a case of "we want it upstream NOW" but rather > "let's work together to figure out how to do it right" :) > > I thought about placing this driver in drivers/hyper-v/ given that it's > basically just a pipe between the host and the guest. There is no fancy > logic in this drivers. Maybe the right place is indeed drivers/accel or > drivers/hyper-v but I'd love if we agree on that rather than doing that > as a workaround and 6 months down the road enabling graphics. > > >- Next up (but that's not really a surprise for a fresh vendor driver) > >at a more technical level, this seems to reinvent the world, from > >device enumeration (why is this not exposed as /dev/dri/card0 so it > >better integrates with existing linux desktop stuff, in case that > >becomes a goal ever) down to reinvented kref_put_mutex (and please > >look at drm_device->struct_mutex for an example of how bad of a > >nightmare that locking pattern is and how many years it took us to > >untangle that one. > > I'd maybe note that neither of us here at Microsoft is an expert in the > Linux DRM world. Stuff might have been done in a certain way because we > didn't know better. > > >- Why DX12 on linux? Looking at this feels like classic divide and > > There is a single usecase for this: WSL2 developer who wants to run > machine learning on his GPU. The developer is working on his laptop, > which is running Windows and that laptop has a single GPU that Windows > is using. > > Since the GPU is being used by Windows, we can't assign it directly to > the Linux guest, but instead we can use GPU Partitioning to give the > guest access to the GPU. This means that the guest needs to be able to > "speak" DX12, which is why we pulled DX12 into Linux. > > >conquer (or well triple E from the 90s), we have vk, we have > >drm_syncobj, we have an entire ecosystem of winsys layers that work > >across vendors. Is the plan here that we get a dx12 driver for other > >hw mesa drivers from you guys, so this is all consistent and we have a > >nice linux platform? How
[PATCH 0/2] perf tools: minor fixes regarding macro usage
Hello, Here are some minor fixes for perf tools regarding *SEC_PER*SEC macro usage, found while reading the code. Patch 1 replaces a macro with a more suitable one (same value, different name). Patch 2 converts some hardcoded values (which seem appropriate IMHO) with their respective macros. Based on v5.8-rc3. No functionality change. The final perf binary is the same, before and after these patches. Thanks, Emmanouil Maroudas Emmanouil Maroudas (2): perf stat: use proper macro for time conversions perf tools: use *SEC_PER_*SEC macros tools/perf/builtin-record.c | 2 +- tools/perf/builtin-stat.c | 12 ++-- tools/perf/builtin-trace.c | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) -- 2.17.1
[PATCH 1/2] perf stat: use proper macro for time conversions
The values of interval and timeout are in msecs as documented in the
-I and --timeout options.
Use MSEC_PER_SEC instead USEC_PER_MSEC to convert to struct timespec.
Both macros have the same value 1000L (see tools/include/linux/time64.h).
No functional change intended.
Signed-off-by: Emmanouil Maroudas
---
tools/perf/builtin-stat.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 9be020e0098a..6aa866e2d512 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -613,11 +613,11 @@ static int __run_perf_stat(int argc, const char **argv,
int run_idx)
bool second_pass = false;
if (interval) {
- ts.tv_sec = interval / USEC_PER_MSEC;
- ts.tv_nsec = (interval % USEC_PER_MSEC) * NSEC_PER_MSEC;
+ ts.tv_sec = interval / MSEC_PER_SEC;
+ ts.tv_nsec = (interval % MSEC_PER_SEC) * NSEC_PER_MSEC;
} else if (timeout) {
- ts.tv_sec = timeout / USEC_PER_MSEC;
- ts.tv_nsec = (timeout % USEC_PER_MSEC) * NSEC_PER_MSEC;
+ ts.tv_sec = timeout / MSEC_PER_SEC;
+ ts.tv_nsec = (timeout % MSEC_PER_SEC) * NSEC_PER_MSEC;
} else {
ts.tv_sec = 1;
ts.tv_nsec = 0;
--
2.17.1
[PATCH 2/2] perf tools: use *SEC_PER_*SEC macros
builtin-stat.c: typecast macro to u64
see commit ea9eb1f456a0 ("perf stat: Fix duration_time value for higher
intervals")
No functional change intended.
Signed-off-by: Emmanouil Maroudas
---
tools/perf/builtin-record.c | 2 +-
tools/perf/builtin-stat.c | 4 ++--
tools/perf/builtin-trace.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index e108d90ae2ed..c3c7823966bc 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -249,7 +249,7 @@ static int record__aio_sync(struct mmap *md, bool sync_all)
{
struct aiocb **aiocb = md->aio.aiocb;
struct aiocb *cblocks = md->aio.cblocks;
- struct timespec timeout = { 0, 1000 * 1000 * 1 }; /* 1ms */
+ struct timespec timeout = { 0, NSEC_PER_MSEC * 1 }; /* 1ms */
int i, do_suspend;
do {
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 6aa866e2d512..2f4fe1aee865 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -305,7 +305,7 @@ static int read_single_counter(struct evsel *counter, int
cpu,
int thread, struct timespec *rs)
{
if (counter->tool_event == PERF_TOOL_DURATION_TIME) {
- u64 val = rs->tv_nsec + rs->tv_sec*10ULL;
+ u64 val = rs->tv_nsec + rs->tv_sec*(u64)NSEC_PER_SEC;
struct perf_counts_values *count =
perf_counts(counter->counts, cpu, thread);
count->ena = count->run = val;
@@ -471,7 +471,7 @@ static void process_interval(void)
}
init_stats(_nsecs_stats);
- update_stats(_nsecs_stats, stat_config.interval * 100ULL);
+ update_stats(_nsecs_stats, stat_config.interval *
(u64)NSEC_PER_MSEC);
print_counters(, 0, NULL);
}
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 4cbb64edc998..db0a2369e2f2 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -4043,7 +4043,7 @@ static int trace__run(struct trace *trace, int argc,
const char **argv)
perf_evlist__start_workload(evlist);
if (trace->opts.initial_delay) {
- usleep(trace->opts.initial_delay * 1000);
+ usleep(trace->opts.initial_delay * USEC_PER_MSEC);
evlist__enable(evlist);
}
--
2.17.1
[PATCH 1/2] block: add zone_desc_ext_bytes to sysfs
The NVMe Zoned Namespace Command Set adds support for associating
data to a zone through the Zone Descriptor Extension feature.
The Zone Descriptor Extension size is fixed to a multiple of 64
bytes. A value of zero communicates the feature is not available.
A value larger than zero communites the feature is available, and
the specified Zone Descriptor Extension size in bytes.
The Zone Descriptor Extension feature is only available in the
NVMe Zoned Namespaces Command Set. Devices that supports ZAC/ZBC
therefore reports this value as zero, where as the NVMe device
driver reports the Zone Descriptor Extension size from the
specific device.
Signed-off-by: Matias Bjørling
---
Documentation/block/queue-sysfs.rst | 6 ++
block/blk-sysfs.c | 15 ++-
drivers/nvme/host/zns.c | 1 +
drivers/scsi/sd_zbc.c | 1 +
include/linux/blkdev.h | 22 ++
5 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/Documentation/block/queue-sysfs.rst
b/Documentation/block/queue-sysfs.rst
index f261a5c84170..c4fa195c87b4 100644
--- a/Documentation/block/queue-sysfs.rst
+++ b/Documentation/block/queue-sysfs.rst
@@ -265,4 +265,10 @@ devices are described in the ZBC (Zoned Block Commands)
and ZAC
do not support zone commands, they will be treated as regular block devices
and zoned will report "none".
+zone_desc_ext_bytes (RO)
+-
+This indicates the zone description extension (ZDE) size, in bytes, of a zoned
+block device. A value of '0' means that zone description extension is not
+supported.
+
Jens Axboe , February 2009
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 624bb4d85fc7..0c99454823b7 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -315,6 +315,12 @@ static ssize_t queue_max_active_zones_show(struct
request_queue *q, char *page)
return queue_var_show(queue_max_active_zones(q), page);
}
+static ssize_t queue_zone_desc_ext_bytes_show(struct request_queue *q,
+ char *page)
+{
+ return queue_var_show(queue_zone_desc_ext_bytes(q), page);
+}
+
static ssize_t queue_nomerges_show(struct request_queue *q, char *page)
{
return queue_var_show((blk_queue_nomerges(q) << 1) |
@@ -687,6 +693,11 @@ static struct queue_sysfs_entry
queue_max_active_zones_entry = {
.show = queue_max_active_zones_show,
};
+static struct queue_sysfs_entry queue_zone_desc_ext_bytes_entry = {
+ .attr = {.name = "zone_desc_ext_bytes", .mode = 0444 },
+ .show = queue_zone_desc_ext_bytes_show,
+};
+
static struct queue_sysfs_entry queue_nomerges_entry = {
.attr = {.name = "nomerges", .mode = 0644 },
.show = queue_nomerges_show,
@@ -787,6 +798,7 @@ static struct attribute *queue_attrs[] = {
_nr_zones_entry.attr,
_max_open_zones_entry.attr,
_max_active_zones_entry.attr,
+ _zone_desc_ext_bytes_entry.attr,
_nomerges_entry.attr,
_rq_affinity_entry.attr,
_iostats_entry.attr,
@@ -815,7 +827,8 @@ static umode_t queue_attr_visible(struct kobject *kobj,
struct attribute *attr,
return 0;
if ((attr == _max_open_zones_entry.attr ||
-attr == _max_active_zones_entry.attr) &&
+attr == _max_active_zones_entry.attr ||
+attr == _zone_desc_ext_bytes_entry.attr) &&
!blk_queue_is_zoned(q))
return 0;
diff --git a/drivers/nvme/host/zns.c b/drivers/nvme/host/zns.c
index 502070763266..5792d953a8f3 100644
--- a/drivers/nvme/host/zns.c
+++ b/drivers/nvme/host/zns.c
@@ -84,6 +84,7 @@ int nvme_update_zone_info(struct gendisk *disk, struct
nvme_ns *ns,
blk_queue_flag_set(QUEUE_FLAG_ZONE_RESETALL, q);
blk_queue_max_open_zones(q, le32_to_cpu(id->mor) + 1);
blk_queue_max_active_zones(q, le32_to_cpu(id->mar) + 1);
+ blk_queue_zone_desc_ext_bytes(q, id->lbafe[lbaf].zdes << 6);
free_data:
kfree(id);
return status;
diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c
index d8b2c49d645b..a4b6d6cf5457 100644
--- a/drivers/scsi/sd_zbc.c
+++ b/drivers/scsi/sd_zbc.c
@@ -722,6 +722,7 @@ int sd_zbc_read_zones(struct scsi_disk *sdkp, unsigned char
*buf)
else
blk_queue_max_open_zones(q, sdkp->zones_max_open);
blk_queue_max_active_zones(q, 0);
+ blk_queue_zone_desc_ext_bytes(q, 0);
nr_zones = round_up(sdkp->capacity, zone_blocks) >> ilog2(zone_blocks);
/* READ16/WRITE16 is mandatory for ZBC disks */
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 3776140f8f20..2ed55055f68d 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -522,6 +522,7 @@ struct request_queue {
unsigned long *seq_zones_wlock;
unsigned intmax_open_zones;
unsigned intmax_active_zones;
+ unsigned intzone_desc_ext_bytes;
#endif /*
[PATCH 0/2] Zone Descriptor Extension for Zoned Block Devices
Hi, This patchset adds support for the Zone Descriptor Extension feature that is defined in the NVMe Zoned Namespace Command Set. The feature adds support for associating data to a zone that is in the Empty state. Upon successful completion, the specified zone transitions to the Closed state and further writes can be issued to the zone. The data is lost when the zone at some point transitions to the Empty state, the Read Only state, or the Offline state. For example, the lifetime of the data is valid until a zone reset is issued on the specific zone. The first patch adds support for the zone_desc_ext_bytes queue sysfs entry, and the second patch adds a ioctl to allow user-space to associate data to a specific zone. Support for the feature can be detected through the zone_desc_ext_bytes queue sysfs. A value larger than zero indicates support, and zero value indicates no support. Best, Matias Matias Bjørling (2): block: add zone_desc_ext_bytes to sysfs block: add BLKSETDESCZONE ioctl for Zoned Block Devices Documentation/block/queue-sysfs.rst | 6 ++ block/blk-sysfs.c | 15 +++- block/blk-zoned.c | 108 block/ioctl.c | 2 + drivers/nvme/host/core.c| 3 + drivers/nvme/host/nvme.h| 9 +++ drivers/nvme/host/zns.c | 12 drivers/scsi/sd_zbc.c | 1 + include/linux/blk_types.h | 2 + include/linux/blkdev.h | 31 +++- include/uapi/linux/blkzoned.h | 20 +- 11 files changed, 206 insertions(+), 3 deletions(-) -- 2.17.1
[PATCH 2/2] block: add BLKSETDESCZONE ioctl for Zoned Block Devices
The NVMe Zoned Namespace Command Set adds support for associating
data to a zone through the Zone Descriptor Extension feature.
To allow user-space to associate data to a zone, add support through
the BLKSETDESCZONE ioctl. The ioctl requires that it is issued to
a zoned block device, and that it supports the Zone Descriptor
Extension feature. Support is detected through the
the zone_desc_ext_bytes sysfs queue entry for the specific block
device. A value larger than zero communicates that the device supports
the feature.
The ioctl associates data to a zone by issuing a Zone Management Send
command with the Zone Send Action set as the Set Zone Descriptor
Extension.
For the command to complete successfully, the specified zone must be
in the Empty state, and active resources must be available. On
success, the specified zone is transioned to Closed state by the
device. If less data is supplied by user-space then reported by the
the Zone Descriptor Extension size, the rest is zero-filled. If more
data or no data is supplied by user-space, the ioctl fails.
To issue the ioctl, a new blk_zone_set_desc data structure is defined.
It has following parameters:
* the sector of the specific zone.
* the length of the data to be associated to the zone.
* any flags be used by the ioctl. None is defined.
* data associated to the zone.
The data is laid out after the flags parameter, and it is the caller's
responsibility to allocate memory for the data that is specified in the
length parameter.
Signed-off-by: Matias Bjørling
---
block/blk-zoned.c | 108 ++
block/ioctl.c | 2 +
drivers/nvme/host/core.c | 3 +
drivers/nvme/host/nvme.h | 9 +++
drivers/nvme/host/zns.c | 11
include/linux/blk_types.h | 2 +
include/linux/blkdev.h| 9 ++-
include/uapi/linux/blkzoned.h | 20 ++-
8 files changed, 162 insertions(+), 2 deletions(-)
diff --git a/block/blk-zoned.c b/block/blk-zoned.c
index 81152a260354..4dc40ec006a2 100644
--- a/block/blk-zoned.c
+++ b/block/blk-zoned.c
@@ -259,6 +259,50 @@ int blkdev_zone_mgmt(struct block_device *bdev, enum
req_opf op,
}
EXPORT_SYMBOL_GPL(blkdev_zone_mgmt);
+/**
+ * blkdev_zone_set_desc - Execute a zone management set zone descriptor
+ *extension operation on a zone
+ * @bdev: Target block device
+ * @sector:Start sector of the zone to operate on
+ * @data: Pointer to the data that is to be associated to the zone
+ * @gfp_mask: Memory allocation flags (for bio_alloc)
+ *
+ * Description:
+ *Associate zone descriptor extension data to a specified zone.
+ *The block device must support zone descriptor extensions.
+ *i.e., by exposing a positive zone descriptor extension size.
+ */
+int blkdev_zone_set_desc(struct block_device *bdev, sector_t sector,
+struct page *data, gfp_t gfp_mask)
+{
+ struct request_queue *q = bdev_get_queue(bdev);
+ sector_t zone_sectors = blk_queue_zone_sectors(q);
+ struct bio_vec bio_vec;
+ struct bio bio;
+
+ if (!blk_queue_is_zoned(q))
+ return -EOPNOTSUPP;
+
+ if (bdev_read_only(bdev))
+ return -EPERM;
+
+ /* Check alignment (handle eventual smaller last zone) */
+ if (sector & (zone_sectors - 1))
+ return -EINVAL;
+
+ bio_init(, _vec, 1);
+ bio.bi_opf = REQ_OP_ZONE_SET_DESC | REQ_SYNC;
+ bio.bi_iter.bi_sector = sector;
+ bio_set_dev(, bdev);
+ bio_add_page(, data, queue_zone_desc_ext_bytes(q), 0);
+
+ /* This may take a while, so be nice to others */
+ cond_resched();
+
+ return submit_bio_wait();
+}
+EXPORT_SYMBOL_GPL(blkdev_zone_set_desc);
+
struct zone_report_args {
struct blk_zone __user *zones;
};
@@ -370,6 +414,70 @@ int blkdev_zone_mgmt_ioctl(struct block_device *bdev,
fmode_t mode,
GFP_KERNEL);
}
+/*
+ * BLKSETDESCZONE ioctl processing.
+ * Called from blkdev_ioctl.
+ */
+int blkdev_zone_set_desc_ioctl(struct block_device *bdev, fmode_t mode,
+ unsigned int cmd, unsigned long arg)
+{
+ void __user *argp = (void __user *)arg;
+ struct request_queue *q;
+ struct blk_zone_set_desc zsd;
+ void *zsd_data;
+ int ret;
+
+ if (!argp)
+ return -EINVAL;
+
+ q = bdev_get_queue(bdev);
+ if (!q)
+ return -ENXIO;
+
+ if (!blk_queue_is_zoned(q))
+ return -ENOTTY;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EACCES;
+
+ if (!(mode & FMODE_WRITE))
+ return -EBADF;
+
+ if (!queue_zone_desc_ext_bytes(q))
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(, argp, sizeof(struct blk_zone_set_desc)))
+ return -EFAULT;
+
+ /* no flags is currently supported */
+ if (zsd.flags)
+ return
[char-misc-next] mei: bus: don't clean driver pointer
From: Alexander Usyskin It's not needed to set driver to NULL in mei_cl_device_remove() which is bus_type remove() handler as this is done anyway in __device_release_driver(). Actually this is causing an endless loop in driver_detach() on ubuntu patched kernel, while removing (rmmod) the mei_hdcp module. The reason list_empty(>p->klist_devices.k_list) is always not-empty. as the check is always true in __device_release_driver() if (dev->driver != drv) return; The non upstream patch is causing this behavior, titled: 'vfio -- release device lock before userspace requests' Nevertheless the fix is correct also for the upstream. Link: https://patchwork.ozlabs.org/project/ubuntu-kernel/patch/20180912085046.3401-2-...@canonical.com/ Cc: Cc: Andy Whitcroft Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler --- drivers/misc/mei/bus.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index 8d468e0a950a..f476dbc7252b 100644 --- a/drivers/misc/mei/bus.c +++ b/drivers/misc/mei/bus.c @@ -745,9 +745,8 @@ static int mei_cl_device_remove(struct device *dev) mei_cl_bus_module_put(cldev); module_put(THIS_MODULE); - dev->driver = NULL; - return ret; + return ret; } static ssize_t name_show(struct device *dev, struct device_attribute *a, -- 2.25.4
Re: [Nouveau] [PATCH v2] nouveau: fix page fault on device private memory
On Sat, 27 Jun 2020 at 07:04, Ralph Campbell wrote:
>
> If system memory is migrated to device private memory and no GPU MMU
> page table entry exists, the GPU will fault and call hmm_range_fault()
> to get the PFN for the page. Since the .dev_private_owner pointer in
> struct hmm_range is not set, hmm_range_fault returns an error which
> results in the GPU program stopping with a fatal fault.
> Fix this by setting .dev_private_owner appropriately.
>
> Fixes: 08da667b ("mm/hmm: check the device private page owner in
> hmm_range_fault()")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ralph Campbell
> Reviewed-by: Jason Gunthorpe
> ---
>
> This is based on Linux-5.8.0-rc2 and is for Ben Skeggs nouveau tree.
> It doesn't depend on any of the other nouveau/HMM changes I have
> recently posted.
>
> Resending to include sta...@vger.org and adding Jason's reviewed-by.
Thanks Ralph,
I've got the patch locally, and will push it out later on today.
Ben.
>
> drivers/gpu/drm/nouveau/nouveau_svm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_svm.c
> b/drivers/gpu/drm/nouveau/nouveau_svm.c
> index ba9f9359c30e..6586d9d39874 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_svm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_svm.c
> @@ -562,6 +562,7 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
> .end = notifier->notifier.interval_tree.last + 1,
> .pfn_flags_mask = HMM_PFN_REQ_FAULT | HMM_PFN_REQ_WRITE,
> .hmm_pfns = hmm_pfns,
> + .dev_private_owner = drm->dev,
> };
> struct mm_struct *mm = notifier->notifier.mm;
> int ret;
> --
> 2.20.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [PATCH] kernel/trace: Add TRACING_ALLOW_PRINTK config option
On Sun, 28 Jun 2020 15:02:09 -0700 Alexei Starovoitov wrote: > > > > Then do a bpf trace event and enable it when a bpf_trace_printk() is > > loaded. It will work the same for your users. > > I'm not sure I follow. How that would preserve the expectation > to see the output in /sys/kernel/debug/tracing/trace ? You create a bpf event just like you create any other event. When a bpf program that uses a bpf_trace_printk() is loaded, you can enable that event from within the kernel. Yes, there's internal interfaces to enabled and disable events just like echoing 1 into tracefs/events/system/event/enable. See trace_set_clr_event(). Then the data of that event will appear in the /sys/kernel/tracing/trace file just like the trace_printk does. The difference is, if something in the kernel decides to use that event, I can easily disable it from user space, where trace_printk() I can't. > > > > Hmm, so you are happier to bully and burn bridges with me to deprecate > > the trace_printk() interface, than to work with me and add an update to > > look into an instance for the print instead of the top level? That's > > not very collaborative. > > I'm seeing it differently. > I'm saying bpf users are complaining about misleading dmesg warning. > You're saying 'screw your users I want to keep that warning'. > Though the warning is lying with a straight face. The only thing happened > is few pages were allocated that will never be freed. The kernel didn't > suddenly become non-production. It didn't become slower. No debug features > were turned on. Come now Alexei. That banner was there from day one trace_printk() was added into the kernel. YOU used this knowing damn well that banner existed. If the bpf users should be upset with someone, it is you for not asking me for how to do this properly from the beginning. This is not a regression. trace_printk() always has shown this, and when I added trace_printk() I stated this is only for debugging a kernel, and not to be kept in mainline. That banner helped enforce that. If I didn't do that, there would be trace_printk()s all over the place, and there's no way to disable one without disabling all the others. This would have made trace_printk() become useless for debugging a kernel, as then you will have to deal with everyone's trace_printks() adding noise to what you want to debug. -- Steve
Re: [RFC 00/10] perf tools: Add support to reuse metric
On Sat, Jun 27, 2020 at 09:48:21AM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jun 26, 2020 at 02:57:59PM -0700, Andi Kleen escreveu: > > > The name could be a metric or an event, the logic for each is quite > > > > I would say collisions are unlikely. Event names follow quite structured > > patterns. > > And when introducing a new metric the build process can detect that > clash and fail. > > > > different. You could look up an event and when it fails assume it was > > > a metric, but I like the simplicity of this approach. > > > I don't think it's simpler for the user. > > Agreed. > > > > Maybe this > > > change could be adopted more widely with something like "perf stat -e > > > metric:IPC -a -I 1000" rather than the current "perf stat -M IPC -a -I > > > 1000". > > > > I thought about just adding metrics to -e, without metric: of course. > > Ditto. > > - Arnaldo > I guess I wanted to clearly separate other metrics from the expression, also running through the whole lists of metrics for each id did not seem good.. but it's actualy not that bad (compared to other things we do ;-), and if you guys prefer not using a prefix I think it's ok thanks, jirka
Linux 5.8-rc3
Well, we had a big merge window, and we have a fairly big rc3 here too. The calm period for rc2 is clearly over. That said, I don't think there's anything _particularly_ scary in here, and the size of this rc is probably simply a direct result of the fact that 5.8 is a big release. It's too early to say if this will mean that we'll have a longer rc period as a result, I'll just have to keep an eye out for how this all progresses. The stats all look fairly normal: about half is drivers (networking is a big chunk, but there's really a bit of everything in there: gpu, sound, usb, you name it). Outside of drivers, we have the usual suspects: arch updates (x86 and arm stand out), core networking, but also core kernel and VM updates. And a fair amount of tooling updates (mostly selftests, but also objtool and virtio). Go forth and test, Linus --- Aaron Plattner (1): ALSA: hda: Add NVIDIA codec IDs 9a & 9d through a0 to patch table Adam Ford (2): arm64: dts: imx8mm-beacon: Fix voltages on LDO1 and LDO2 drm/panel-simple: fix connector type for LogicPD Type28 Display Aditya Pakki (2): RDMA/rvt: Fix potential memory leak caused by rvt_alloc_rq usb: dwc3: pci: Fix reference count leak in dwc3_pci_resume_work Aiden Leong (1): GUE: Fix a typo Al Cooper (1): xhci: Fix enumeration issue when setting max packet size for FS devices. Alex Williamson (3): vfio/pci: Clear error and request eventfd ctx after releasing vfio/type1: Fix migration info capability ID vfio/pci: Fix SR-IOV VF handling with MMIO blocking Alexander Lobakin (11): net: ethtool: add missing NETIF_F_GSO_FRAGLIST feature string net: ethtool: add missing string for NETIF_F_GSO_TUNNEL_REMCSUM net: qed: fix left elements count calculation net: qed: fix async event callbacks unregistering net: qede: stop adding events on an already destroyed workqueue net: qed: fix NVMe login fails over VFs net: qed: fix excessive QM ILT lines consumption net: qede: fix PTP initialization on recovery net: qede: fix use-after-free on recovery and AER handling net: qed: reset ILT block sizes before recomputing to fix crashes net: qed: fix "maybe uninitialized" warning Alexander Popov (1): arm64: vdso: Don't use gcc plugins for building vgettimeofday.c Alexander Stein (1): spi: dt-bindings: amlogic, meson-gx-spicc: Fix schema for meson-g12a Alexander Usyskin (1): mei: me: add tiger lake point device ids for H platforms. Anand Moon (2): Revert "usb: dwc3: exynos: Add support for Exynos5422 suspend clk" Revert "usb: dwc3: exynos: Add support for Exynos5422 suspend clk" Andre Przywara (1): arm: dts: vexpress: Move mcc node back into motherboard node Andrew Lunn (1): net: ethtool: Handle missing cable test TDR parameters Andrii Nakryiko (3): bpf: Fix definition of bpf_ringbuf_output() helper in UAPI comments tools/bpftool: Add ringbuf map to a list of known map types bpf: bpf_probe_read_kernel_str() has to return amount of data read on success Andy Shevchenko (2): ARM: bcm2835: Fix integer overflow in rpi_firmware_print_firmware_revision() i2c: designware: Adjust bus speed independently of ACPI Aneesh Kumar K.V (1): powerpc/kvm/book3s64: Fix kernel crash with nested kvm & DEBUG_VIRTUAL Anson Huang (1): soc: imx8m: Correct i.MX8MP UID fuse offset Anton Eidelman (2): nvme-multipath: fix deadlock between ana_work and scan_work nvme-multipath: fix deadlock due to head->lock Ard Biesheuvel (4): efi/libstub: Fix missing-prototype warning for skip_spaces() efi/libstub: arm: Omit arch specific config table matching array on arm64 efi/libstub: arm: Print CPU boot mode and MMU state at boot net: phy: mscc: avoid skcipher API for single block AES encryption Arjun Roy (1): mm/memory.c: properly pte_offset_map_lock/unlock in vm_insert_pages() Arnd Bergmann (1): fpga: zynqmp: fix modular build Arseny Solokha (1): powerpc/fsl_booke/32: Fix build with CONFIG_RANDOMIZE_BASE Arvind Sankar (2): efi/x86: Fix build with gcc 4 efi/x86: Setup stack correctly for efi_pe_entry Axel Lin (1): regulator: mt6358: Remove BROKEN dependency Babu Moger (1): x86/resctrl: Fix memory bandwidth counter width for AMD Bartlomiej Zolnierkiewicz (1): video: fbdev: uvesafb: fix "noblank" option handling Bartosz Golaszewski (1): regmap: fix the kerneldoc for regmap_test_bits() Ben Widawsky (1): mm/memory_hotplug.c: fix false softlockup during pfn range removal Bernard Zhao (1): drm/amd: fix potential memleak in err branch Björn Töpel (1): i40e: fix crash when Rx descriptor count is changed Borislav Petkov (1): EDAC/amd64: Read back the scrub rate PCI register on F15h Brent Lu (1): ASoC: SOF: Intel: hda: Clear RIRB status before reading WP Briana
