On Wed, Nov 23, 2022 at 12:16:54PM -0800, Li Li wrote:
> From: Li Li
>
> An async transaction to a frozen process will still be successfully
> put in the queue. But this pending async transaction won't be processed
> until the target process is unfrozen at an unspecified time in the
> future. Pas
On Wed, Nov 23, 2022 at 10:58 AM Carlos Llamas wrote:
>
> This looks good. Could you rename the new op to signify the frozen
> scenario though? We might have some other instances of pending
> transactions in the future so might as well be specific here.
Done [1].
v3: rename BR_TRANSACTION_PENDIN
From: Li Li
An async transaction to a frozen process will still be successfully
put in the queue. But this pending async transaction won't be processed
until the target process is unfrozen at an unspecified time in the
future. Pass this important information back to the user space caller
by retur
scenario and avoid potential confusion
Li Li (1):
binder: return pending info for frozen async txns
drivers/android/binder.c| 32 +++--
drivers/android/binder_internal.h | 3 ++-
include/uapi/linux/android/binder.h | 7 ++-
3 files changed, 34 ins
On Thu, Nov 10, 2022 at 12:34:05PM -0800, Li Li wrote:
> From: Li Li
>
> An async transaction to a frozen process will still be successfully
> put in the queue. But this pending async transaction won't be processed
> until the target process is unfrozen at an unspecified time in the
> future. Pas
From: Li Li
An async transaction to a frozen process will still be successfully
put in the queue. But this pending async transaction won't be processed
until the target process is unfrozen at an unspecified time in the
future. Pass this important information back to the user space caller
by retur
ut in the queue of the target process, but it's
waiting for the target process to be unfrozen.
v1: checkpatch.pl --strict passed
v2: protect proc->is_frozen with lock, fix typo in comments
Li Li (1):
binder: return pending info for frozen async txns
drivers/android/binder.c
On Wed, Nov 9, 2022 at 2:43 PM Carlos Llamas wrote:
>
> On Thu, Nov 03, 2022 at 12:05:49PM -0700, Li Li wrote:
> > From: Li Li
> >
> > An async transaction to a frozen process will still be successsfully
>
> nit: sucessfully typo
Nice catch! Will remove the extra 's' in v2.
>
> > put in the que
On Thu, Nov 03, 2022 at 12:05:49PM -0700, Li Li wrote:
> From: Li Li
>
> An async transaction to a frozen process will still be successsfully
nit: sucessfully typo
> put in the queue. But this pending async transaction won't be processed
> until the target process is unfrozen at an unspecified
From: Li Li
An async transaction to a frozen process will still be successsfully
put in the queue. But this pending async transaction won't be processed
until the target process is unfrozen at an unspecified time in the
future. Pass this important information back to the user space caller
by retu
ut in the queue of the target process, but it's
waiting for the target process to be unfrozen.
v1: checkpatch.pl --strict passed
Li Li (1):
binder: return pending info for frozen async txns
drivers/android/binder.c| 23 ---
drivers/android/binder_interna
*This message was transferred with a trial version of CommuniGate(r) Pro*
Dear Sir,
Business Proposal
Firstly, I must solicit your confidence in this transaction; this is by virtue
of its nature as being utterly
confidential and top secret. Though I know that a transaction of thi
*This message was transferred with a trial version of CommuniGate(r) Pro*
Dear Sir,
Business Proposal
Firstly, I must solicit your confidence in this transaction; this is by virtue
of its nature as being utterly
confidential and top secret. Though I know that a transaction of thi
The 'delay_usecs' field is no longer present on the spi_transfer struct.
This change updates the doc to mention the usage of the (relatively) new
'delay' field.
Signed-off-by: Alexandru Ardelean
---
Documentation/spi/spi-summary.rst | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
d
from v4l2 pixformat */
static inline int sun6i_csi_get_bpp(unsigned int pixformat)
{
+ const struct v4l2_format_info *info;
+ unsigned int i;
+ int bpp = 0;
+
+ /* Handle special cases unknown to V4L2 format info first. */
switch (pixformat) {
- case V4L2_PIX_
from v4l2 pixformat */
static inline int sun6i_csi_get_bpp(unsigned int pixformat)
{
+ const struct v4l2_format_info *info;
+ unsigned int i;
+ int bpp = 0;
+
+ /* Handle special cases unknown to V4L2 format info first. */
switch (pixformat) {
- case V4L2_PIX_
from v4l2 pixformat */
static inline int sun6i_csi_get_bpp(unsigned int pixformat)
{
+ const struct v4l2_format_info *info;
+ unsigned int i;
+ int bpp = 0;
+
+ /* Handle special cases unknown to V4L2 format info first. */
switch (pixformat) {
- case V4L2_PIX_
On Sat, Nov 28, 2020 at 03:28:24PM +0100, Paul Kocialkowski wrote:
> V4L2 has a common helper which can be used for calculating the number
> of stored bits per pixels of a given (stored) image format.
>
> Use the helper-returned structure instead of our own switch/case list.
> Note that a few form
*/
static inline int sun6i_csi_get_bpp(unsigned int pixformat)
{
+ const struct v4l2_format_info *info;
+ unsigned int i;
+ int bpp = 0;
+
+ /* Handle special cases unknown to V4L2 format info first. */
switch (pixformat) {
- case V4L2_PIX_FMT_SBGGR8:
-
We don't really need to know that the LED pin reset successfully.
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm
This patch convert dprintk(info) to pci_info (or pci_dbg if the message
is not important).
Signed-off-by: Corentin Labbe
---
drivers/staging/media/zoran/zoran_card.c | 46 +++---
drivers/staging/media/zoran/zoran_device.c | 27 -
drivers/staging/media/zoran
We don't really need to know that the LED pin reset successfully.
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm
We don't really need to know that the LED pin reset successfully.
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm
This patch convert dprintk(info) to pci_info (or pci_dbg if the message
is not important).
Signed-off-by: Corentin Labbe
---
drivers/staging/media/zoran/zoran_card.c | 46 +++---
drivers/staging/media/zoran/zoran_device.c | 27 -
drivers/staging/media/zoran
On 2020-09-03 19:31, Alex Dewar wrote:
We don't really need to know that the LED pin reset successfully.
Ping?
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm355
We don't really need to know that the LED pin reset successfully.
Signed-off-by: Alex Dewar
---
drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
b/drivers/staging/media/atomisp/i2c/atomisp-lm
On Sun, Aug 16, 2020 at 11:57:17AM +0900, Benjamin Poirier wrote:
On 2020-08-15 00:06 +0800, Coiby Xu wrote:
The related code are not necessary because,
- Device status and general registers can be obtained by ethtool.
- Coredump can be done via devlink health reporter.
- Structure related to th
On 2020-08-15 00:06 +0800, Coiby Xu wrote:
> The related code are not necessary because,
> - Device status and general registers can be obtained by ethtool.
> - Coredump can be done via devlink health reporter.
> - Structure related to the hardware (struct ql_adapter) can be obtained
> by crash o
The related code are not necessary because,
- Device status and general registers can be obtained by ethtool.
- Coredump can be done via devlink health reporter.
- Structure related to the hardware (struct ql_adapter) can be obtained
by crash or drgn.
Signed-off-by: Coiby Xu
---
drivers/stagin
If the ACPI DSDT tables provide _CRS for the camera, the
GPIO core code should be able to handle them automatically.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/atomisp/pci/atomisp_gmin_platform.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/media/at
This reverts commit 0d64e9420583cbc3c4a3f949ebe38fd8f7769281.
As gmin_subdev_add() now takes the ACPI handle directly,
we can deprecate the code that were doing this inside each
I2C driver.
PS.: This also reverts commit c03496b3bd92 ("media: atomisp: add a notice about
possible leak resources")
Add prefix "erofs_" to these functions and print
sb->s_id as a prefix to erofs_{err, info} so that
the user knows which file system is affected.
Reported-by: Christoph Hellwig
Signed-off-by: Gao Xiang
---
fs/erofs/data.c | 10 +++--
fs/erofs/decompressor.c | 5 +--
f
As Christoph said [1], "That is some very verbose
debug info. We usually don't add that and let
people trace the function instead. "
[1] https://lore.kernel.org/r/20190829101545.gc20...@infradead.org/
Reported-by: Christoph Hellwig
Signed-off-by: Gao Xiang
---
fs/er
Hi Christoph,
On Mon, Sep 02, 2019 at 05:14:24AM -0700, Christoph Hellwig wrote:
> On Sun, Sep 01, 2019 at 01:51:21PM +0800, Gao Xiang wrote:
> > From: Gao Xiang
> >
> > As Christoph said [1], "That is some very verbose
> > debug info. We usually don't
On Sun, Sep 01, 2019 at 01:51:21PM +0800, Gao Xiang wrote:
> From: Gao Xiang
>
> As Christoph said [1], "That is some very verbose
> debug info. We usually don't add that and let
> people trace the function instead. "
Note that this applies to most of the inf
From: Gao Xiang
As Christoph said [1], "That is some very verbose
debug info. We usually don't add that and let
people trace the function instead. "
[1] https://lore.kernel.org/r/20190829101545.gc20...@infradead.org/
Reported-by: Christoph Hellwig
Signed-off-by: Gao Xiang
On Mon, 27 May 2019 15:56:47 +0300
Beniamin Bia wrote:
> The device dependent options which are going to be different for devices
> which will be supported in the future by this driver,
> were moved in chip info for a more generic driver. This patch allows
> supporting more de
The device dependent options which are going to be different for devices
which will be supported in the future by this driver,
were moved in chip info for a more generic driver. This patch allows
supporting more devices by the driver. Also, it is an intermediate
step of adding support for ad7616
On Sat, 18 May 2019 11:04:49 +0100
Jonathan Cameron wrote:
> On Thu, 16 May 2019 17:32:04 +0300
> Beniamin Bia wrote:
>
> > The device dependent options which are going to be different for devices
> > which will be supported in the future by this driver,
> > were mo
On Thu, 16 May 2019 17:32:04 +0300
Beniamin Bia wrote:
> The device dependent options which are going to be different for devices
> which will be supported in the future by this driver,
> were moved in chip info for a more generic driver. This patch allows
> supporting more de
The device dependent options which are going to be different for devices
which will be supported in the future by this driver,
were moved in chip info for a more generic driver. This patch allows
supporting more devices by the driver. Also, it is an intermediate
step of adding support for ad7616
comedi comedi0: Wrong number of endpoints
ni6501 1-1:0.233: driver 'ni6501' failed to auto-configure device.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 585 Comm: kworker/0:3 Not tainted
: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
vmk80xx 1-1:0.117: driver 'vmk80xx' failed to auto-configure device.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validat
iptor??
vmk80xx 3-1:0.134: driver 'vmk80xx' failed to auto-configure device.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
Hardwa
ze of the array.
>
> Oversampling options are now defined in chip info
> structure and they are loaded at probe.
>
> Has_Oversampling attribute was removed because oversampling_num was added
> and it is not needed anymore.
>
> The purpose of this patch is to deal with the scale_ava
From: Stefan Popa
Available oversampling ratios and scales can be shown by calling a
common ad7606_show_avail function which takes as parameters the array
which stores the values, together with the size of the array.
Oversampling options are now defined in chip info
structure and they are
On Thu, Oct 25, 2018 at 4:30 PM Stefan Wahren wrote:
>
> In order to have this more consistent between the vc04 services move
> the module information to the end of the file.
>
> Signed-off-by: Stefan Wahren
Reviewed-by: Peter Robinson
Tested-by: Peter Robinson
Tested with a v2 camera module.
On Mon, Dec 17, 2018 at 08:16:09PM +, Dexuan Cui wrote:
fc96df16a1ce is good and can already fix the "return stack garbage" issue,
but let's also improve hv_ringbuffer_get_debuginfo(), which would silently
return stack garbage, if people forget to check channel->state or
ring_info->ring_buff
fc96df16a1ce is good and can already fix the "return stack garbage" issue,
but let's also improve hv_ringbuffer_get_debuginfo(), which would silently
return stack garbage, if people forget to check channel->state or
ring_info->ring_buffer, when using the function in the future.
Having an error c
In order to have this more consistent between the vc04 services move
the module information to the end of the file.
Signed-off-by: Stefan Wahren
Reviewed-by: Nicolas Saenz Julienne
---
.../staging/vc04_services/bcm2835-camera/bcm2835-camera.c| 12 ++--
1 file changed, 6 insertions(+
at 11:49:26AM +0100, Sergio Paracuellos wrote:
> >> >> This patch series parse remaining port info from device tree storing
> >> >> it in mt7621_pcie_port struct created for this. It also performs a lot
> >> >> of cleanups to get the driver in a good sh
On Mon, Nov 12 2018, Sergio Paracuellos wrote:
> On Mon, Nov 12, 2018 at 08:40:10AM +1100, NeilBrown wrote:
>> On Sun, Nov 11 2018, Greg KH wrote:
>>
>> > On Sun, Nov 04, 2018 at 11:49:26AM +0100, Sergio Paracuellos wrote:
>> >> This patch series parse
On Mon, Nov 12, 2018 at 08:40:10AM +1100, NeilBrown wrote:
> On Sun, Nov 11 2018, Greg KH wrote:
>
> > On Sun, Nov 04, 2018 at 11:49:26AM +0100, Sergio Paracuellos wrote:
> >> This patch series parse remaining port info from device tree storing
> >> it in mt7621_pci
On Sun, Nov 11 2018, Greg KH wrote:
> On Sun, Nov 04, 2018 at 11:49:26AM +0100, Sergio Paracuellos wrote:
>> This patch series parse remaining port info from device tree storing
>> it in mt7621_pcie_port struct created for this. It also performs a lot
>> of cleanups to get
On Sun, Nov 04, 2018 at 11:49:26AM +0100, Sergio Paracuellos wrote:
> This patch series parse remaining port info from device tree storing
> it in mt7621_pcie_port struct created for this. It also performs a lot
> of cleanups to get the driver in a good shape to give it a try to get
&g
On Wed, 2018-11-07 at 16:49 -0200, Giuliano Belinassi wrote:
> This patch allows further checking of whatever the chip is (ad778x or
> ad717x).
Hey,
The patch looks good overall.
I only have one nitpick for this patch. See inline.
And you can squash this patch with patch `[PATCH 2/3] staging: ii
This patch allows further checking of whatever the chip is (ad778x or
ad717x).
Signed-off-by: Giuliano Belinassi
---
drivers/staging/iio/adc/ad7780.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index 91e016d534ed..6
This patch series parse remaining port info from device tree storing
it in mt7621_pcie_port struct created for this. It also performs a lot
of cleanups to get the driver in a good shape to give it a try to get
mainlined. All of this changes are only compile-tested.
Cleanups performed here
This patch set adds scale info to ad2s90's single channel, improve
error handling in it's functions and fix a possible race condition
issue.
The goal with this patch set is to address the points discussed in the
mailing list in an effort to move ad2s90.c out of staging.
Changes in v3:
On Sun, Oct 28, 2018 at 1:52 PM Jonathan Cameron wrote:
>
> On Fri, 26 Oct 2018 22:59:59 -0300
> Matheus Tavares wrote:
>
> > This patch set adds scale info to ad2s90's single channel, improve
> > error handling in it's functions and fix a possible race conditio
On Fri, 26 Oct 2018 22:59:59 -0300
Matheus Tavares wrote:
> This patch set adds scale info to ad2s90's single channel, improve
> error handling in it's functions and fix a possible race condition
> issue.
>
> The goal with this patch set is to address the points discus
This patch set adds scale info to ad2s90's single channel, improve
error handling in it's functions and fix a possible race condition
issue.
The goal with this patch set is to address the points discussed in the
mailing list in an effort to move ad2s90.c out of staging.
Changes in v2
This patch set adds scale info to ad2s90's single channel, improve
error handling in it's functions and fix a possible race condition
issue.
The goal with this patch set is to address the points discussed in the
mailing list in an effort to move ad2s90.c out of staging.
Matheus
In order to have this more consistent between the vc04 services move
the module information to the end of the file.
Signed-off-by: Stefan Wahren
---
.../staging/vc04_services/bcm2835-camera/bcm2835-camera.c| 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drive
On Thu, 18 Oct 2018 15:32:35 +
Michael Kelley wrote:
> From Olaf Hering Sent: Thursday, October 18, 2018 8:20 AM
> >
> > > This extends existing vmbus related sysfs structure to provide per-channel
> > > state information. This is useful when diagnosing issues with multiple
> > > queues in
On Thu, 18 Oct 2018 17:19:53 +0200
Olaf Hering wrote:
> Am Sun, 17 Sep 2017 20:54:18 -0700
> schrieb k...@exchange.microsoft.com:
>
> > This extends existing vmbus related sysfs structure to provide per-channel
> > state information. This is useful when diagnosing issues with multiple
> > queues
>From Olaf Hering Sent: Thursday, October 18, 2018 8:20 AM
>
> > This extends existing vmbus related sysfs structure to provide per-channel
> > state information. This is useful when diagnosing issues with multiple
> > queues in networking and storage.
>
> > +++ b/drivers/hv/vmbus_drv.c
> > +stat
Am Sun, 17 Sep 2017 20:54:18 -0700
schrieb k...@exchange.microsoft.com:
> This extends existing vmbus related sysfs structure to provide per-channel
> state information. This is useful when diagnosing issues with multiple
> queues in networking and storage.
> +++ b/drivers/hv/vmbus_drv.c
> +stati
From: Haiyang Zhang
Date: Mon, 15 Oct 2018 19:06:15 +
> From: Haiyang Zhang
>
> The VF device's serial number is saved as a string in PCI slot's
> kobj name, not the slot->number. This patch corrects the netvsc
> driver, so the VF device can be successfully paired with synthetic
> NIC.
>
>
On Mon, 15 Oct 2018 19:06:15 +
Haiyang Zhang wrote:
> From: Haiyang Zhang
>
> The VF device's serial number is saved as a string in PCI slot's
> kobj name, not the slot->number. This patch corrects the netvsc
> driver, so the VF device can be successfully paired with synthetic
> NIC.
>
> F
From: Haiyang Zhang
The VF device's serial number is saved as a string in PCI slot's
kobj name, not the slot->number. This patch corrects the netvsc
driver, so the VF device can be successfully paired with synthetic
NIC.
Fixes: 00d7ddba1143 ("hv_netvsc: pair VF based on serial number")
Reported-
This patch series parse remaining port info from device tree storing
it in mt7621_pcie_port struct created for this.
Also minor cleanups are performed here:
- Remove not used macros.
- Use kernel reset_control functions.
- Remove unused code.
Changes in v5:
- Patch 18 removed
uznets
> Subject: Re: [PATCH net-next, v2] hv_netvsc: fix vf serial matching with pci
> slot
> info
>
> On Fri, 12 Oct 2018 20:55:15 +
> Haiyang Zhang wrote:
>
> Thanks for fixing this.
>
>
> > + if (kstrtou32(kobject_name(&pdev->slot->kobj), 1
On Fri, 12 Oct 2018 20:55:15 +
Haiyang Zhang wrote:
Thanks for fixing this.
> + if (kstrtou32(kobject_name(&pdev->slot->kobj), 10, &serial)) {
> + netdev_notice(vf_netdev, "Invalid vf serial:%s\n",
> + pdev->slot->kobj.name);
> + retur
From: Haiyang Zhang
The VF device's serial number is saved as a string in PCI slot's
kobj name, not the slot->number. This patch corrects the netvsc
driver, so the VF device can be successfully paired with synthetic
NIC.
Fixes: 00d7ddba1143 ("hv_netvsc: pair VF based on serial number")
Reported-
Subject: Re: [PATCH net-next] hv_netvsc: fix vf serial matching with pci slot
> info
>
> On Thu, Oct 11, 2018 at 08:14:34PM +, Haiyang Zhang wrote:
> > From: Haiyang Zhang
> >
> > The VF device's serial number is saved as a string in PCI slot's kobj
&
On Thu, Oct 11, 2018 at 08:14:34PM +, Haiyang Zhang wrote:
> From: Haiyang Zhang
>
> The VF device's serial number is saved as a string in PCI slot's
> kobj name, not the slot->number. This patch corrects the netvsc
> driver, so the VF device can be successfully paired with synthetic
> NIC.
>
vkuznets ;
>> de...@linuxdriverproject.org; linux-ker...@vger.kernel.org
>> Subject: [PATCH net-next] hv_netvsc: fix vf serial matching with pci slot
>> info
>>
>> From: Haiyang Zhang
>>
>> The VF device's serial number is saved as a string in PCI slo
x-ker...@vger.kernel.org
> Subject: [PATCH net-next] hv_netvsc: fix vf serial matching with pci slot info
>
> From: Haiyang Zhang
>
> The VF device's serial number is saved as a string in PCI slot's kobj name,
> not
> the slot->number. This patch corrects th
From: Haiyang Zhang
The VF device's serial number is saved as a string in PCI slot's
kobj name, not the slot->number. This patch corrects the netvsc
driver, so the VF device can be successfully paired with synthetic
NIC.
Fixes: 00d7ddba1143 ("hv_netvsc: pair VF based on serial number")
Signed-of
04/13]: Fixes various function prototypes and "const"
> > variable
> > declarations as per Ian's suggestions.
>
> I'm not sure if this is a glitch in my email copy of the patch, but I
> got a "trailing whitespace error" on one line wh
f the patch, but I
got a "trailing whitespace error" on one line when applying this patch
with "git am":
Applying: staging: comedi: ni_routing: Add NI signal routing info
.git/rebase-apply/patch:8112: trailing whitespace.
NI_CtrGate(0),
warning:
On Mon, Oct 1, 2018 at 5:17 AM Ian Abbott wrote:
>
> On 27/09/18 20:27, Spencer E. Olson wrote:
> > See README for a thorough discussion of this content.
> >
> > Adds tables of all register values for routing various signals to various
> > terminals on National Instruments hardware. This informat
On 27/09/18 20:27, Spencer E. Olson wrote:
See README for a thorough discussion of this content.
Adds tables of all register values for routing various signals to various
terminals on National Instruments hardware. This information is directly
compared to and taken from register-level programmi
On 26/09/18 02:49, Spencer Olson wrote:
On Tue, Sep 25, 2018 at 6:26 AM Ian Abbott wrote:
I never noticed that you sort the data on module load. You also have an
exported function 'ni_sort_device_routes()' called internally by
'ni_sort_all_device_routes()' when the "ni_routes" module is loaded
On Tue, Sep 25, 2018 at 6:26 AM Ian Abbott wrote:
>
> On 25/09/18 05:47, Spencer E. Olson wrote:
>
> [N.B. top-posting is frowned upon on the kernel mailing lists.]
Sorry :-)
>
> > These static arrays are
> >(1) not expressed with as much "const"ness as suggested
> >(2) included into one
On 25/09/18 05:47, Spencer E. Olson wrote:
[N.B. top-posting is frowned upon on the kernel mailing lists.]
These static arrays are
(1) not expressed with as much "const"ness as suggested
(2) included into one compile unit
because
- ni_device_routes.routes and ni_route_set.src are sorted
These static arrays are
(1) not expressed with as much "const"ness as suggested
(2) included into one compile unit
because
- ni_device_routes.routes and ni_route_set.src are sorted at module
load time using the kernel sort(...) routine.
- ni_device_routes.n_route_sets and ni_route_set.n_s
Hi Chengguang,
On 2018/9/25 7:41, Chengguang Xu wrote:
> As a read only filesystem, it's better to show available
> inode num as 0 in statfs.
>
> Signed-off-by: Chengguang Xu
> ---
> drivers/staging/erofs/super.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/driv
As a read only filesystem, it's better to show available
inode num as 0 in statfs.
Signed-off-by: Chengguang Xu
---
drivers/staging/erofs/super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/erofs/super.c b/drivers/staging/erofs/super.c
index 51b0762559
On 19/09/18 17:38, Spencer E. Olson wrote:
See README for a thorough discussion of this content.
Adds tables of all register values for routing various signals to various
terminals on National Instruments hardware. This information is directly
compared to and taken from register-level programmi
This patch series parse remaining port info from device tree storing
it in mt7621_pcie_port struct created for this.
Also minor cleanups are performed here:
- Remove not used macros.
- Use kernel reset_control functions.
- Remove unused code.
Changes in v4:
- Some patches of this
In order to make use of array info obtained from gpiod_get_array() and
speed up processing of arrays matching single GPIO chip layout, that
information must be passed to get/set array functions. Extend the
functions' API with that additional parameter and update all users.
Pass NULL if a
g argument
3 of 'gpiod_set_array_value_cansleep' from incompatible pointer type
[-Werror=incompatible-pointer-types]
ddata->cmd_gpios->info, values);
^
In file included from drivers/phy/motorola/phy-mapphone-mdm6600.c:16:0:
include/linux/gpio/consum
error=incompatible-pointer-types]
reset_gpios->info, value_bitmap);
^~~
In file included from drivers/mmc/core/pwrseq_simple.c:18:0:
include/linux/gpio/consumer.h:417:20: note: expected 'int *' but argument is
of type '
Hi Janusz,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.19-rc2 next-20180831]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-c
Fixes to use correct index to free the allocated memory for ies
information. The check was done using 'last_scanned_cnt' index and its
not correct, so use the correct index ('i') to check for before freeing
the allocated memory.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfg
On Sun, Sep 2, 2018 at 2:01 PM Janusz Krzysztofik wrote:
> In order to make use of array info obtained from gpiod_get_array() and
> speed up processing of arrays matching single GPIO chip layout, that
> information must be passed to get/set array functions. Extend the
> functions&#x
In order to make use of array info obtained from gpiod_get_array() and
speed up processing of arrays matching single GPIO chip layout, that
information must be passed to get/set array functions. Extend the
functions' API with that additional parameter and update all users.
Pass NULL if a
In order to make use of array info obtained from gpiod_get_array() and
speed up processing of arrays matching single GPIO chip layout, that
information must be passed to get/set array functions. Extend the
functions' API with that additional parameter and update all users.
Pass NULL if a
1 - 100 of 301 matches
Mail list logo
