Hi All,
On Fri, Mar 3, 2017 at 4:05 AM, Georgios Emmanouil wrote:
> Fixed alignment to match parenthesis.
>
> Signed-off-by: Georgios Emmanouil
Reviewed-by: Julian Calaby
> ---
> drivers/staging/wilc1000/wilc_spi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
; Signed-off-by: Georgios Emmanouil <geo.em...@gmail.com>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
> ---
> drivers/staging/wilc1000/wilc_spi.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
--
Julian Calaby
Email: julian.cal...@gmail.com
Profil
anouil
Reviewed-by: Julian Calaby
> ---
> drivers/staging/wilc1000/wilc_spi.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
return PTR_ERR(nvmem);
>>
>> - randomness = kzalloc(sizeof(u8) * (size), GFP_KERNEL);
>> + randomness_size = max(size, SUNXI_SID_MAX_RANDOMNESS_SIZE);
>> + randomness = kzalloc(sizeof(u8) * (randomness_size), GFP_KERNEL);
>
> Why is that change needed?
According to the definition of SUNXI_SID_MAX_RANDOMNESS_SIZE, only the
first 16 bytes of the SID data region are sufficiently non-zero to be
used for randomness.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
sizeof(u8) * (size), GFP_KERNEL);
>> + randomness_size = max(size, SUNXI_SID_MAX_RANDOMNESS_SIZE);
>> + randomness = kzalloc(sizeof(u8) * (randomness_size), GFP_KERNEL);
>
> Why is that change needed?
According to the definition of SUNXI_SID_MAX_RANDOMNESS_SIZE, only the
first 16 bytes of the SID data region are sufficiently non-zero to be
used for randomness.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
}
> - size = (1 << (size + 1));
> -
> - return size;
> + return (1 << (size + 1));
Is the size variable used elsewhere? If not, it's declaration should
probably be removed.
Also, there should be a blank line before the return statement.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
return size;
> + return (1 << (size + 1));
Is the size variable used elsewhere? If not, it's declaration should
probably be removed.
Also, there should be a blank line before the return statement.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
184
> +#define D7S_MINOR 193
I was going to say "why not change the name to something more
descriptive" however they're all very abbreviated, so maybe consider a
second patch series to describe what each of these is for?
> #define VFIO_MINOR 196
to say "why not change the name to something more
descriptive" however they're all very abbreviated, so maybe consider a
second patch series to describe what each of these is for?
> #define VFIO_MINOR 196
> #define TUN_MINOR 200
> #define CUSE_MINOR 203
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
nter dereference.
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
null
> pointer deference when accessing adapter->dev. This fix checks
> for a null adapter at the start of the function and to exit
> without the need to up the semaphore and we also skip the debug
> to avoid the null pointer dereference.
>
> Signed-off-by: Colin Ian King
not attached
3. Improve the subject as described in the linked document
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
he linked document
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.)
Moving four assignments because you think they might improve stuff is
just annoying people.
>> He's not another Nick Krause.
>
> Are you going to remember me under an other nickname anyhow?
Nick Krause submitted patches that make yours look good. At least yours compile.
Thanks
nk they might improve stuff is
just annoying people.
>> He's not another Nick Krause.
>
> Are you going to remember me under an other nickname anyhow?
Nick Krause submitted patches that make yours look good. At least yours compile.
Thanks,
--
Julian Calaby
Email: juli
tle more than moving stuff around pointlessly.
I really wish he'd concentrate on the former rather than the latter.
He's not another Nick Krause.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
pointlessly.
I really wish he'd concentrate on the former rather than the latter.
He's not another Nick Krause.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
software module.
What benefits? You have not proved that this change produces any
useful benefits.
>> and wasting everyone's time in the process.
>
> I assume that a few contributors can take the presented ideas for further
> considerations.
> Will their value evolve a bit more
You have not proved that this change produces any
useful benefits.
>> and wasting everyone's time in the process.
>
> I assume that a few contributors can take the presented ideas for further
> considerations.
> Will their value evolve a bit more later?
I am subscribed to four fairly high traffic mailing lists and I read
hundreds of patches each week. You are the only person proposing
changes like these ones as you are (as far as I know) the only person
who thinks they have any value.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
;> at the top of the file then ok,
>
> I see another software design option where the transformation result might be
> looking
> more pleasing for you again.
>
>
>> but why all the way down here?
>
> * How do you think about the reason I gave in the short commit me
en ok,
>
> I see another software design option where the transformation result might be
> looking
> more pleasing for you again.
>
>
>> but why all the way down here?
>
> * How do you think about the reason I gave in the short commit message?
Does this change improve the r
things, there is absolutely no reason to take them as-is - you are
making the code longer and more difficult to read for no benefit and
wasting everyone's time in the process.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
eason to take them as-is - you are
making the code longer and more difficult to read for no benefit and
wasting everyone's time in the process.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
T <christophe.jail...@wanadoo.fr>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi All,
On Mon, Aug 8, 2016 at 5:39 PM, Christophe JAILLET
wrote:
> This patch should be a no-op. It just simplifies code by using the name of
> a variable instead of its type when calling 'sizeof'.
>
> Signed-off-by: Christophe JAILLET
Reviewed-by: Julian Calaby
Thanks,
--
J
) {
> u8 seen_or_pass0 = (pass == 0) ? (SEEN_XREG | SEEN_DATAREF |
> SEEN_MEM) : seen;
This is utterly pointless, why?
If you were moving the assignments on declaration onto separate lines
at the top of the file then ok, but why all the way down here?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
is is utterly pointless, why?
If you were moving the assignments on declaration onto separate lines
at the top of the file then ok, but why all the way down here?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
hes <j...@perches.com>
This all looks correct to me. I wish you'd put the code changes in a
separate patch, however it's all noted in the commit log, so...
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
t to me. I wish you'd put the code changes in a
separate patch, however it's all noted in the commit log, so...
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi All,
On Sun, Aug 28, 2016 at 9:28 PM, Colin King <colin.k...@canonical.com> wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Revie
Hi All,
On Sun, Aug 28, 2016 at 9:28 PM, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http:/
Hi All,
On Sun, Sep 4, 2016 at 2:43 AM, Colin King <colin.k...@canonical.com> wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> Trivial fix to spelling mistakes in dev_dbg message.
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Revie
Hi All,
On Sun, Sep 4, 2016 at 2:43 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistakes in dev_dbg message.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http:/
Hi All,
On Sat, Aug 27, 2016 at 4:08 AM, Colin King <colin.k...@canonical.com> wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> Trivial fix to spelling mistake in ath10k_warn message.
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Revie
Hi All,
On Sat, Aug 27, 2016 at 4:08 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in ath10k_warn message.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.co
right to me.
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi All,
On Tue, Aug 23, 2016 at 4:35 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in dev_err message.
>
> Signed-off-by: Colin Ian King
Looks right to me.
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.co
Hi Chen-Yu,
On Sun, Aug 21, 2016 at 12:11 PM, Chen-Yu Tsai <w...@csie.org> wrote:
> The X-Powers AXP809 is a new PMIC that is paired with Allwinner's A80
> SoC, along with a master AXP809 PMIC.
The first "AXP809" should be "AXP806".
Thanks,
--
Julian Calaby
Hi Chen-Yu,
On Sun, Aug 21, 2016 at 12:11 PM, Chen-Yu Tsai wrote:
> The X-Powers AXP809 is a new PMIC that is paired with Allwinner's A80
> SoC, along with a master AXP809 PMIC.
The first "AXP809" should be "AXP806".
Thanks,
--
Julian Calaby
Email: julian.cal.
goto out;
> - } else if (ap_ioctl)
> + else if (ap_ioctl)
> ret = 0;
> }
>
> - out:
Does this change make any difference to the compiled code?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
ret = 0;
> }
>
> - out:
Does this change make any difference to the compiled code?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
TES;
>
> platform_set_drvdata(pdev, host);
>
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun6i-a31-spdif")) {
Given how much Allwinner likes to shuffle stuff around with each SoC
generation, would it make sense to add a f
ev->dev.of_node,
> + "allwinner,sun6i-a31-spdif")) {
Given how much Allwinner likes to shuffle stuff around with each SoC
generation, would it make sense to add a flag for this in some
compatible specific config structure instead of checking again
micro-optimisation: kfree(NULL) is perfectly valid
and buff is either malloc'd memory or NULL when it's called.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
ntain a pointer
> for a valid data item.
>
> Improve this implementation detail by the introduction of another
> jump label.
>
> Signed-off-by: Markus Elfring
This is pointless micro-optimisation: kfree(NULL) is perfectly valid
and buff is either malloc'd memory or NULL when it's ca
mp;& i == AXP809_DCDC1))
> + (regulators == axp809_regulators && i == AXP809_DCDC1) ||
> + (regulators == axp813_regulators && i == AXP813_DCDC1))
Ditto.
> of_property_read_string(rdev->dev.of_node,
>
(regulators == axp809_regulators && i == AXP809_DCDC1) ||
> + (regulators == axp813_regulators && i == AXP813_DCDC1))
Ditto.
> of_property_read_string(rdev->dev.of_node,
> "regulator-name",
> _name);
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
> interface")
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
Looks correct to me as Dan Carpenter submitted the same fix.
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
gned-off-by: Javier Martinez Canillas
Looks correct to me as Dan Carpenter submitted the same fix.
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
sely
Patches that you send must be signed off by you, not ack'd by you.
I.e.
From: Random Developer <random.develo...@company.com>
.
Signed-off-by: Random Developer <random.develo...@company.com>
Signed-off-by: Patch Sender <patch.sen...@company.com>
Thanks,
--
t you send must be signed off by you, not ack'd by you.
I.e.
From: Random Developer
.
Signed-off-by: Random Developer
Signed-off-by: Patch Sender
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi All,
On Wed, Jun 29, 2016 at 1:37 PM, Masanari Iida <standby2...@gmail.com> wrote:
> This patch fix spelling typos found in drivers/net/wireless/realtek.
>
> Signed-off-by: Masanari Iida <standby2...@gmail.com>
Looks right to me.
Reviewed-by: Julian Calaby <julian.c
Hi All,
On Wed, Jun 29, 2016 at 1:37 PM, Masanari Iida wrote:
> This patch fix spelling typos found in drivers/net/wireless/realtek.
>
> Signed-off-by: Masanari Iida
Looks right to me.
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Prof
t driver.
I believe the Ultra 10 uses the same motherboard so it's likely also
affected. I believe these were in the first generation of "PC" like
SPARC workstations.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
0 uses the same motherboard so it's likely also
affected. I believe these were in the first generation of "PC" like
SPARC workstations.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
t;130>;
> + regulator-boot-on;
> + regulator-type = "voltage";
> +
> + gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
> + states = <110 0x0
> + 130 0x1>;
> +
> + startu
egulator-type = "voltage";
> +
> + gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
> + states = <110 0x0
> + 130 0x1>;
> +
> + startup-delay-us = <10>;
> + enable-active-
--
> 4 files changed, 98 insertions(+), 22 deletions(-)
Shouldn't the .dtsi changes be in a separate patch?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
ns(-)
Shouldn't the .dtsi changes be in a separate patch?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
t;130>;
> + regulator-boot-on;
> + regulator-type = "voltage";
> +
> + gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
> + states = <110 0x0
> + 1300000 0x1>;
> +
> + start
egulator-type = "voltage";
> +
> + gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
> + states = <110 0x0
> + 130 0x1>;
> +
> + startup-delay-us = <10>;
> + enable-active-high;
Don't you need to reference the new pinctl node in this one?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
right to me.
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi All,
On Thu, Jun 23, 2016 at 11:14 PM, Colin King wrote:
> From: Colin Ian King
>
> trivial fix to spelling mistake in dev_err messages
>
> Signed-off-by: Colin Ian King
Looks right to me.
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gm
Hi Luis,
On Fri, Jun 24, 2016 at 9:50 AM, Luis de Bethencourt
<lui...@osg.samsung.com> wrote:
> On 24/06/16 00:15, Julian Calaby wrote:
>> Hi Joe,
>>
>> On Fri, Jun 24, 2016 at 5:24 AM, Joe Perches <j...@perches.com> wrote:
>>> On Thu, 2016-06-23
Hi Luis,
On Fri, Jun 24, 2016 at 9:50 AM, Luis de Bethencourt
wrote:
> On 24/06/16 00:15, Julian Calaby wrote:
>> Hi Joe,
>>
>> On Fri, Jun 24, 2016 at 5:24 AM, Joe Perches wrote:
>>> On Thu, 2016-06-23 at 18:57 +0100, Luis de Bethencourt wrote:
>>>
Maybe I should send a hit to the
>> kernelnewbies mailing list :)
>
> Or not.
>
> really_long_identifiers™ makes using 80 columns silly.
>
> The hungarian could probably be converted though.
The main developers of this driver are slowly working through the
driver's style issu
I should send a hit to the
>> kernelnewbies mailing list :)
>
> Or not.
>
> really_long_identifiers™ makes using 80 columns silly.
>
> The hungarian could probably be converted though.
The main developers of this driver are slowly working through the
driver's style issues, which is part of the reason
Hi Luis,
On Thu, Jun 23, 2016 at 9:25 PM, Luis de Bethencourt
<lui...@osg.samsung.com> wrote:
> On 23/06/16 02:29, Julian Calaby wrote:
>> Hi All,
>>
>> On Wed, Jun 22, 2016 at 10:39 PM, Luis de Bethencourt
>> <lui...@osg.samsung.com> wrote:
>>> T
Hi Luis,
On Thu, Jun 23, 2016 at 9:25 PM, Luis de Bethencourt
wrote:
> On 23/06/16 02:29, Julian Calaby wrote:
>> Hi All,
>>
>> On Wed, Jun 22, 2016 at 10:39 PM, Luis de Bethencourt
>> wrote:
>>> The common format to check if a function returned an error poin
returning -EINVAL instead of -1 is more
> appropriate.
These two changes could be argued to be separate changes deserving of
their own patches.
> Signed-off-by: Luis de Bethencourt <lui...@osg.samsung.com>
However if everyone else is ok with that, this is:
Reviewed-by: Julian Calaby <
f -1 is more
> appropriate.
These two changes could be argued to be separate changes deserving of
their own patches.
> Signed-off-by: Luis de Bethencourt
However if everyone else is ok with that, this is:
Reviewed-by: Julian Calaby
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail
Hi Joe,
On Fri, Jun 17, 2016 at 1:04 PM, Joe Perches <j...@perches.com> wrote:
> On Fri, 2016-06-17 at 12:44 +1000, Julian Calaby wrote:
>> Hi Joe,
>
> rehi Julian.
(I always put a salutation on my emails and always finish them with
"Thanks," =) )
>>
Hi Joe,
On Fri, Jun 17, 2016 at 1:04 PM, Joe Perches wrote:
> On Fri, 2016-06-17 at 12:44 +1000, Julian Calaby wrote:
>> Hi Joe,
>
> rehi Julian.
(I always put a salutation on my emails and always finish them with
"Thanks," =) )
>> On Fri, Jun 17, 2016
Hi Joe,
On Fri, Jun 17, 2016 at 12:33 PM, Joe Perches <j...@perches.com> wrote:
> On Fri, 2016-06-17 at 12:18 +1000, Julian Calaby wrote:
>> ./scripts/get_maintainers.pl -f drivers/scsi/vmw_pvscsi.c
>
> just fyi: the script name is not plural
Thanks, must have typo
Hi Joe,
On Fri, Jun 17, 2016 at 12:33 PM, Joe Perches wrote:
> On Fri, 2016-06-17 at 12:18 +1000, Julian Calaby wrote:
>> ./scripts/get_maintainers.pl -f drivers/scsi/vmw_pvscsi.c
>
> just fyi: the script name is not plural
Thanks, must have typo'd it between runnin
si/vmw_pvscsi.c
or
./scripts/get_maintainers.pl patchfile.patch
Thanks,
Julian Calaby
>
> Thanks!
> Arvind
> ________
> From: Julian Calaby <julian.cal...@gmail.com>
> Sent: Thursday, June 16, 2016 6:48 PM
> To: Jim Gill
> Cc: j...@linu
iners.pl patchfile.patch
Thanks,
Julian Calaby
>
> Thanks!
> Arvind
> ________
> From: Julian Calaby
> Sent: Thursday, June 16, 2016 6:48 PM
> To: Jim Gill
> Cc: j...@linux.vnet.ibm.com; Martin K. Petersen; Arvind Kumar;
> pv-driv...@v
1301
> USA.
> *
> - * Maintained by: Arvind Kumar <arvindku...@vmware.com>
> + * Maintained by: Jim Gill <jg...@vmware.com>
Shouldn't you update MAINTAINERs too? And isn't having this
information in these files redundant?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
tained by: Jim Gill
Shouldn't you update MAINTAINERs too? And isn't having this
information in these files redundant?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
put the kernel version this applies to below the "---".
> Signed-off-by: Hisashi Kanda <hika...@zlab.co.jp>
>
> ---
i.e. here.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
read_info->flag's TI_FAULT_ADDR in user_rtt_fill_fixup.
> This is a mistake. If fault address has FAULT_CODE_ITLB and
> FAULT_CODE_DTLB bits, BUG() may occur in do_sparc64_fault().
>
> The patch for this bug is the following.
> Kernel version is Linux 4.7-rc3.
You should put the kernel version t
Hi Michal,
On Tue, Jun 14, 2016 at 4:35 PM, Michal Suchanek <hramr...@gmail.com> wrote:
> Hello,
>
> On 14 June 2016 at 07:45, Julian Calaby <julian.cal...@gmail.com> wrote:
>> Hi Michal,
>>
>> On Tue, Jun 14, 2016 at 3:28 PM, Michal Suchanek <hramr...@g
Hi Michal,
On Tue, Jun 14, 2016 at 4:35 PM, Michal Suchanek wrote:
> Hello,
>
> On 14 June 2016 at 07:45, Julian Calaby wrote:
>> Hi Michal,
>>
>> On Tue, Jun 14, 2016 at 3:28 PM, Michal Suchanek wrote:
>>> On 14 June 2016 at 06:47, Julian Calaby wrote:
&
Hi Michal,
On Tue, Jun 14, 2016 at 3:28 PM, Michal Suchanek <hramr...@gmail.com> wrote:
> On 14 June 2016 at 06:47, Julian Calaby <julian.cal...@gmail.com> wrote:
>> Hi Michal,
>>
>> On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek <hramr...@gmail.com> wr
Hi Michal,
On Tue, Jun 14, 2016 at 3:28 PM, Michal Suchanek wrote:
> On 14 June 2016 at 06:47, Julian Calaby wrote:
>> Hi Michal,
>>
>> On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek wrote:
>>> Hello,
>>>
>>> On 14 June 2016 at 01:43, Julian
Hi Michal,
On Tue, Jun 14, 2016 at 2:40 PM, Michal Suchanek <hramr...@gmail.com> wrote:
> On 14 June 2016 at 01:45, Julian Calaby <julian.cal...@gmail.com> wrote:
>> Hi Michal,
>>
>> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> wr
Hi Michal,
On Tue, Jun 14, 2016 at 2:40 PM, Michal Suchanek wrote:
> On 14 June 2016 at 01:45, Julian Calaby wrote:
>> Hi Michal,
>>
>> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote:
>>> Signed-off-by: Michal Suchanek
>>> ---
>>
Hi Michal,
On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek <hramr...@gmail.com> wrote:
> Hello,
>
> On 14 June 2016 at 01:43, Julian Calaby <julian.cal...@gmail.com> wrote:
>> Hi Michal,
>>
>> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@
Hi Michal,
On Tue, Jun 14, 2016 at 2:34 PM, Michal Suchanek wrote:
> Hello,
>
> On 14 June 2016 at 01:43, Julian Calaby wrote:
>> Hi Michal,
>>
>> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote:
>>> The drivers are very similar and share multiple f
nterrupts = <11>;
> - clocks = <_gates 21>, <_clk>;
> +spi1: spi@01c69000 {
> + compatible = "allwinner,sun6i-a31-spi";
> + reg = <0x01c69000 0x1000>;
> + interrupts = <0 66 4>;
> + clocks = <_gates 21&
es 21>, <_clk>;
> +spi1: spi@01c69000 {
> + compatible = "allwinner,sun6i-a31-spi";
> + reg = <0x01c69000 0x1000>;
> + interrupts = <0 66 4>;
> + clocks = <_gates 21>, <_clk>;
> clock-names = "
,
> + )) {
> + pr_err(", %s", str);
> + i++;
> + }
> + }
> + ret = -EINVAL;
> + goto err_free_master;
> + }
> +
> master->max_speed_hz = 100 * 1000 * 1000;
> master->min_speed_hz = 3 * 1000;
> master->set_cs = sunxi_spi_set_cs;
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
)) {
> + pr_err(", %s", str);
> + i++;
> + }
> + }
> + ret = -EINVAL;
> + goto err_free_master;
> + }
> +
> master->max_speed_hz = 100 * 1000 * 1000;
> master->min_speed_hz = 3 * 1000;
> master->set_cs = sunxi_spi_set_cs;
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
0x1c
> #define SUNXI_FIFO_STA_RF_CNT_MASK 0x7f
My gut feeling on this is that we have a lot of cases of a definition
of a register offset, then definitions of the bits in that register
with that register encoded into the constant's name. You appear to be
throwing a lot of that information away which makes me worry.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
0x7f
My gut feeling on this is that we have a lot of cases of a definition
of a register offset, then definitions of the bits in that register
with that register encoded into the constant's name. You appear to be
throwing a lot of that information away which makes me worry.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi Charles,
On Mon, Jun 13, 2016 at 9:40 PM, Charles Chiou <ch1102ch...@gmail.com> wrote:
> Hi Julian,
>
>
> On 06/10/2016 08:10 AM, Julian Calaby wrote:
>>
>> Hi Charles,
>>
>> On Mon, Jun 6, 2016 at 5:53 PM, Charles Chiou <ch1102ch...@gmail.com
Hi Charles,
On Mon, Jun 13, 2016 at 9:40 PM, Charles Chiou wrote:
> Hi Julian,
>
>
> On 06/10/2016 08:10 AM, Julian Calaby wrote:
>>
>> Hi Charles,
>>
>> On Mon, Jun 6, 2016 at 5:53 PM, Charles Chiou
>> wrote:
>>>
>>> From: Charle
e unrelated whitespace changes.
> before = jiffies;
> while (hba->ccb[tag].req_type & PASSTHRU_REQ_TYPE) {
> if (time_after(jiffies, before + ST_INTERNAL_TIMEOUT * HZ)) {
> @@ -1821,24 +1954,29 @@ static void stex_remove(struct pci_dev *pdev)
> scsi_host_put(hba->host);
>
> pci_disable_device(pdev);
> +
> + unregister_reboot_notifier(_notifier);
Again, not P3 specific.
> }
>
> static void stex_shutdown(struct pci_dev *pdev)
> {
> struct st_hba *hba = pci_get_drvdata(pdev);
> -
> - if (hba->supports_pm == 0)
> + if (hba->supports_pm == 0) {
> stex_hba_stop(hba, ST_IGNORED);
> - else
> + } else if (hba->supports_pm == 1 && S6flag) {
> + unregister_reboot_notifier(_notifier);
> + stex_hba_stop(hba, ST_S6);
> + } else
Also not P3 specific.
> stex_hba_stop(hba, ST_S5);
> }
>
> -static int stex_choice_sleep_mic(pm_message_t state)
> +static int stex_choice_sleep_mic(struct st_hba *hba, pm_message_t state)
> {
> switch (state.event) {
> case PM_EVENT_SUSPEND:
> return ST_S3;
> case PM_EVENT_HIBERNATE:
> + hba->msi_lock = 0;
> return ST_S4;
> default:
> return ST_NOTHANDLED;
> @@ -1864,6 +2003,13 @@ static int stex_resume(struct pci_dev *pdev)
> stex_handshake(hba);
> return 0;
> }
> +
> +static int stex_halt(struct notifier_block *nb, unsigned long event, void
> *buf)
> +{
> + S6flag = 1;
> + return NOTIFY_OK;
> +}
> +
And again.
Why is this needed?
> MODULE_DEVICE_TABLE(pci, stex_pci_tbl);
>
> static struct pci_driver stex_pci_driver = {
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Q_TYPE) {
> if (time_after(jiffies, before + ST_INTERNAL_TIMEOUT * HZ)) {
> @@ -1821,24 +1954,29 @@ static void stex_remove(struct pci_dev *pdev)
> scsi_host_put(hba->host);
>
> pci_disable_device(pdev);
> +
> + unregister_reboot_notifier(_notifier);
Again, not P3 specific.
> }
>
> static void stex_shutdown(struct pci_dev *pdev)
> {
> struct st_hba *hba = pci_get_drvdata(pdev);
> -
> - if (hba->supports_pm == 0)
> + if (hba->supports_pm == 0) {
> stex_hba_stop(hba, ST_IGNORED);
> - else
> + } else if (hba->supports_pm == 1 && S6flag) {
> + unregister_reboot_notifier(_notifier);
> + stex_hba_stop(hba, ST_S6);
> + } else
Also not P3 specific.
> stex_hba_stop(hba, ST_S5);
> }
>
> -static int stex_choice_sleep_mic(pm_message_t state)
> +static int stex_choice_sleep_mic(struct st_hba *hba, pm_message_t state)
> {
> switch (state.event) {
> case PM_EVENT_SUSPEND:
> return ST_S3;
> case PM_EVENT_HIBERNATE:
> + hba->msi_lock = 0;
> return ST_S4;
> default:
> return ST_NOTHANDLED;
> @@ -1864,6 +2003,13 @@ static int stex_resume(struct pci_dev *pdev)
> stex_handshake(hba);
> return 0;
> }
> +
> +static int stex_halt(struct notifier_block *nb, unsigned long event, void
> *buf)
> +{
> + S6flag = 1;
> + return NOTIFY_OK;
> +}
> +
And again.
Why is this needed?
> MODULE_DEVICE_TABLE(pci, stex_pci_tbl);
>
> static struct pci_driver stex_pci_driver = {
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
xists, has that number, takes arguments
in that format and works?
Thanks,
Julian Calaby
> On Wed, Jun 8, 2016 at 8:16 PM, Valo, Kalle <kv...@qca.qualcomm.com> wrote:
>> Prasun Maiti <prasunmait...@gmail.com> writes:
>>
>>> No. I did not any test for that cas
101 - 200 of 493 matches
Mail list logo
