nia100_probe_one(struct pci_dev *pdev,
>
> biosaddr = host->BIOScfg;
> biosaddr = (biosaddr << 4);
> - bios_phys = phys_to_virt(biosaddr);
> + phys_to_virt(biosaddr);
Does phys_to_virt() have side effects? If it doesn't, there's a lot
mo
fucking pedantic or what? */
> +/* Am I awful pedantic or what? */
You're right that this needs to go, but "awfully" is a better
replacement than "awful".
However it's likely that the entire comment can either be removed or
replaced with something more descriptive.
l a lot of places, like this, where placeholder
comments were written until the actual code that would have been here
was ready / reverse engineered.
That said, I believe the driver works well enough for all it's users
and has not seen any significant changes in a long time.
Thanks,
--
Julian Ca
ere. It looks, from the diffstat, that you've effectively
reduced 2 lines into 1. That isn't much of a saving.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
s sense than "defaultly". This comment needs to
be re-written by someone who knows what's going on here.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
e own may not
Same comments here as the previous patches:
"de-faultly" makes less sense than "defaultly". This comment needs to
be re-written by someone who knows what's going on here.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
es:
"de-faultly" makes less sense than "defaultly". This comment needs to
be re-written by someone who knows what's going on here.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi Bhaskar,
On Tue, Jan 5, 2021 at 9:48 PM Bhaskar Chowdhury wrote:
>
> On 21:33 Tue 05 Jan 2021, Julian Calaby wrote:
> >Hi Bhaskar,
> >
> >On Tue, Jan 5, 2021 at 9:19 PM Bhaskar Chowdhury
> >wrote:
> >>
> >> s/defautly/de-faulty/p
n may not
Same comments here as the previous patch:
"de-faultly" makes less sense than "defaultly". This comment needs to
be re-written by someone who knows what's going on here.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
+*descriptor de-faulty,and the own may not
Really? "de-faultly" isn't any better than "defaultly" and in fact
it's even worse as it breaks up the word "default".
This change doesn't make sense and the comment really needs to be
completely re-written
Hi Romain,
On Sun, Dec 20, 2020 at 8:26 PM Romain Dolbeau wrote:
>
> Le dim. 20 déc. 2020 à 09:54, Julian Calaby a écrit
> :
> > If I want to run them, assuming the hardware still works, I need to
> > netboot them as I cannot find working, compatible HDDs for them
distros that support it, and the kernel
code has probably bitrotted due to lack of testing.
As much as it pains me to say this, I think this code's time has come
and it's time to get rid of it.
If there were more people using it or more testing, or more distros
supporting it -
;user_scan_in->ssid_list[i].ssid, ssid_len);
Can ssid_len ever be 0 here?
If it can't, should we just set ssid_len to 1 unconditionally?
If it can, should we just skip the memcpy as it won't do anything?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
check section size - from line 2315
skip_size = cur_section->start - prev_end;
// check buffer size - from line 2339 - needs to account for the
skip size too.
// fill in the skip size amount - from line 2358 and 2304
// ath10k_sdio_read_mem - from line 2346
prev_end =
ing_num >= 3" comment is needed, how should this get
formatted? Maybe something like:
fallthrough; /* when ring_num >= 3 */
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
arc64_defconfig
> +++ b/arch/sparc/configs/sparc64_defconfig
> @@ -236,3 +236,6 @@ CONFIG_CRYPTO_TWOFISH=m
> CONFIG_CRC16=m
> CONFIG_LIBCRC32C=m
> CONFIG_VCC=m
> +CONFIG_ATA=y
> +CONFIG_PATA_CMD64X=y
> +CONFIG_PCNET32=y
FWIW the CMD640 is the IDE controller used on the U
ed in firmware anyway:
Should we tell the user their firmware needs to be upgraded if it
reports this regulatory domain instead of completely dropping support
for it?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
ash almost immediately.
Also, it might be worthwhile creating accessor functions for the
mptctl variables or using atomics, that way the locking doesn't need
to be right every time they're used.
Finally, what's the exact race condition here? Are the functions you
reference changing the values of the mptctl variables while other code
is using them? These functions appear to be setup functions, so why
are those variables being used before the device is fully set up?
Single usages of those variables shouldn't be subject to race
conditions, so you shouldn't need mutexes around those.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
t;= slew_rates[i])
> + cfg = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE(i);
> + else
> + break;
> + }
> +
> + if (cfg == 0xff) {
> + dev_err(axp20x->d
Hi Jernej,
On Sun, May 20, 2018 at 11:57 AM, Julian Calaby wrote:
> Hi Jernej,
>
> On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec
> wrote:
>> R40 display pipeline has a lot of possible configurations. HDMI can be
>> connected to 2 different TCONs (out of 4) and mi
_tcon *tcon,
> + const struct drm_encoder *encoder)
> +{
> + return sun8i_r40_tcon_tv_set_mux(tcon, encoder, 1);
> +}
Are TCON-TOPs going to be a common thing in new SoCs from Allwinner?
If so, maybe we should add an index to the TCO
- pll-0: parent of phy clock
> + - pll-1: second possible phy clock parent (A64 only)
Maybe split this into two:
H3 HDMI PHY ...
- pll-0: ...
A64 HDMI PHY ...
- pll-0: ...
- pll-1: ...
At the moment a quick reading implies that H3 needs pll-1.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
xtend the slot width to the
> + value specified. Min 8, Max 32.
> +
This sounds like something that would be useful for other I2S controllers.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi Maxime,
On Tue, Feb 27, 2018 at 6:07 PM, Maxime Ripard
wrote:
> On Tue, Feb 27, 2018 at 01:29:27PM +1100, Julian Calaby wrote:
>> Hi Jernej,
>>
>> On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec
>> wrote:
>> > Hi,
>> >
>> > Dne ponedel
ut
>> >
>> >4k.
>> >
>> >> If this code is compatible with the H2+, could you please add the
>> >> necessary bits and pieces to the h2-plus DTSs too?
>> >
>> >There are only 3 H2+ boards in kernel and none of them has HDMI
>> >connector, so
>>
>> BPi M2 Zero has miniHDMI connector.
>
> Ah, sorry, I missed that one. Since I don't have it (or any other board with
> H2+) I'm not really comfortable including such patch. If anyone will test it,
> I can include it in next revision.
I have one of those (this is why I'm interested in this patchset) so
I'm willing to test, however I can't guarantee I'll get to it quickly.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi Icenowy,
On Sun, Feb 25, 2018 at 7:43 PM, Icenowy Zheng wrote:
>
>
> 于 2018年2月25日 GMT+08:00 下午4:11:34, Julian Calaby 写到:
>>Hi Jernej,
>>
>>On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
>> wrote:
>>> Enable HDMI output on all boards which have HDM
+
> 8 files changed, 199 insertions(+)
As I understand it, the H2+ is just a slightly trimmed down H3. In
terms of HDMI support, the difference is that the H2+ can't output 4k.
If this code is compatible with the H2+, could you please add the
necessary bits and pieces to the
* properly declare and reference in the devicetree and is
> +* not implemented in any driver right now.
> +* If the clock core looks for the parent of that second
> +* missing clock, it can't one that is registered and
You've missed the word "find" between "it can't" and "one that is registered".
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
s variant around for compatibility
with existing device trees?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi Icenowy,
On Sat, Jan 20, 2018 at 2:10 PM, Icenowy Zheng wrote:
>
>
> 于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby 写到:
>>Hi Icenowy,
>>
>>On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng
>>wrote:
>>> Add option for Allwinner ARMv5 SoCs and a SoC
bool "Allwinner SoCs"
That name seems a little too generic. Maybe "Allwinner ARMv5 SoCs"?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
; + select PINCTRL
> + select RESET_CONTROLLER
> +
> +menuconfig ARCH_SUNXI_V7
> bool "Allwinner SoCs"
> depends on ARCH_MULTI_V7
> + select ARCH_SUNXI
> select ARCH_HAS_RESET_CONTROLLER
> select CLKSRC_MMIO
>
(2 << 5)
> #define AXP20X_CHRG_CTRL1_TGT_4_36V(3 << 5)
>
> +#define AXP813_CHRG_CTRL1_TGT_4_35V(3 << 5)
> +
> #define AXP22X_CHRG_CTRL1_TGT_4_22V(1 << 5)
> #define AXP22X_CHRG_CTRL1_TGT_4_24V(3 << 5)
Should these be "a
evice can DMA to RAM address 0x0 using address
>> 0x800.
>>
>> Identity would imply 0 == 0 etc.
>>
>> I think "bijective" is the correct term, but that's probably a bit
>> esoteric.
>
> OK, didn't know about the offset.
> Then "linear" is what we tend to use, right?
If this is indeed a linear mapping, can we just remove this and
replace it with the new "generic" mapping being introduced by this
patchset?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi Christoph,
On Fri, Dec 29, 2017 at 7:18 PM, Christoph Hellwig wrote:
> This frees the dma_direct_* namespace for a generic implementation.
Don't you mean "dma_nommu" not "dma_microblaze" in the subject line?
Thanks,
--
Julian Calaby
Email: julian.ca
& BIT(layer->id)) {
min_scale = 1;
max_scale = (1UL << 20) - 1;
}
However the compiler will probably sort it all out anyway, so it
probably doesn't matter that much, except for style.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
ning("couldn't prepare device to suspend");
"couldn't enable power saving"?
> - return ret;
> - }
> + if (ret < 0)
> + goto report_preparation_failure;
>
> /* flush any remaining work */
> wl1271_debug(DEBUG_MAC80211, "flushing remaining works");
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
Reviewed-by: Julian Calaby
However,
> ---
> drivers/net/wireless/ti/wlcore/main.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/
On Mon, Oct 30, 2017 at 7:13 AM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Sun, 29 Oct 2017 20:00:41 +0100
>
> Return directly after a call of the function "ieee80211_beacon_get"
> failed at the beginning.
>
> Signed-off-by: Markus Elfring
Revi
gt; complete_all(&wl->nvs_loading_complete);
> + return;
> +
> +power_off:
Name this "out_power_off" to match the other labels.
> + wl1271_power_off(wl);
> + goto out_free_nvs;
Why not put this in front of the out_free_nvs label? It looks w
e such unnecessary source code at the end of this function.
>
> Signed-off-by: Markus Elfring
Looks good to me.
Reviewed-by: Julian Calaby
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi Chen-Yu,
On Tue, Oct 10, 2017 at 2:19 PM, Chen-Yu Tsai wrote:
> On systems with 2 TCONs such as the A31, it is possible to demux the
> output of the TCONs to one encoder.
>
> Add support for this for the A31.
>
> Signed-off-by: Chen-Yu Tsai
Thanks!
FWIW this is:
Reviewed
Hi Chen-Yu,
On Sat, Sep 30, 2017 at 3:58 PM, Chen-Yu Tsai wrote:
> On Sat, Sep 30, 2017 at 1:35 PM, Julian Calaby
> wrote:
>> Hi Chen-Yu,
>>
>> On Fri, Sep 29, 2017 at 8:22 PM, Chen-Yu Tsai wrote:
>>> On Fri, Sep 29, 2017 at 6:20 PM, Maxime Ripard
>>&g
ed between
> the two TCONs. So there's no particular reason to look for TCON1 explicitly.
In that case: in the bizarre case where we're trying to use this mux
type and there is no TCON0, shouldn't we fail?
(Also, the code doesn't make sense if we have some TCON1 and TCON2 in
that order as it'll return TCON2)
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
n50i-h5-de2-clk";
> +};
> +
This is what I get for reviewing before reading the full patch set.
Shouldn't this be rolled into the previous patch?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
ranges;
>
> + display_clocks: clock@100 {
> + /* compatible is in per SoC .dtsi file */
I don't know device tree very well, but shouldn't this node be
disabled so that it doesn't do anything weird on H5? Or are nodes
without compatibles ign
y at least this one does not have any valid hardware
>> mac address, the hardware mac address is broken with all zeroes.
>>
>
> Looks like it is not really all zeros but rather 00:00:00:00:00:01.
> I wonder if it is just a one board issue or not...
It's 00:00:00:00:00:0
"Please use the calibrator tool to configure "
> + "your device.\n"
> + "When using a wl18xx device the nvs file can "
> + "be removed as a default mac address i
Hi Nitin,
On Fri, Jun 23, 2017 at 12:37 AM, Nitin Gupta wrote:
> Hi Julian,
>
>
> On 6/22/17 3:53 AM, Julian Calaby wrote:
>>
>> On Thu, Jun 22, 2017 at 7:50 AM, Nitin Gupta
>> wrote:
>>>
>>> The function assumes that each PMD points to head of a
_head(head);
Stupid question: shouldn't this go before the page calculation?
> do {
> VM_BUG_ON(compound_head(page) != head);
> pages[*nr] = page;
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
_sync_sg_for_cpu,
> .sync_sg_for_device = sbus_sync_sg_for_device,
> + .dma_supported = sbus_dma_supported,
> };
>
> static int __init sparc_register_ioport(void)
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
for HDMI */
PLL_VIDEO*1*_2X, right?
> /* The CPU clock is exported */
>
> #define CLK_AXI18
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi All,
On Fri, Mar 3, 2017 at 2:38 AM, Georgios Emmanouil wrote:
> Removed unnecessary 'if' statement and integrated the condition to the
> previous 'if' statement.
>
> Signed-off-by: Georgios Emmanouil
Reviewed-by: Julian Calaby
> ---
> drivers/
Hi All,
On Fri, Mar 3, 2017 at 2:37 AM, Georgios Emmanouil wrote:
> Fixed alignment to match open parenthesis.
>
> Signed-off-by: Georgios Emmanouil
Reviewed-by: Julian Calaby
> ---
> drivers/staging/wilc1000/host_interface.c | 2 +-
> 1 file changed, 1 insert
Hi All,
On Fri, Mar 3, 2017 at 2:35 AM, Georgios Emmanouil wrote:
> Removed unnecessary blank line.
>
> Signed-off-by: Georgios Emmanouil
Reviewed-by: Julian Calaby
> ---
> drivers/staging/wilc1000/host_interface.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff
Hi All,
On Fri, Mar 3, 2017 at 3:41 AM, Georgios Emmanouil wrote:
> Modified comment style to preferred kernel comment style.
>
> Signed-off-by: Georgios Emmanouil
Reviewed-by: Julian Calaby
> ---
> drivers/staging/wilc1000/wilc_sdio.c | 13 +
> 1 file cha
Hi All,
On Fri, Mar 3, 2017 at 3:14 AM, Georgios Emmanouil wrote:
> Modified the 'if-else' statement to make it more readable.
>
> Signed-off-by: Georgios Emmanouil
Again, I'm dubious if this is needed or helpful, but
Reviewed-by: Julian Calaby
> ---
> drivers
Hi All,
On Fri, Mar 3, 2017 at 4:07 AM, Georgios Emmanouil wrote:
> Added blank line after function and modified comment style.
>
> Signed-off-by: Georgios Emmanouil
Reviewed-by: Julian Calaby
> ---
> drivers/staging/wilc1000/wilc_spi.c | 7 ++-
> 1 file changed,
Hi All,
On Fri, Mar 3, 2017 at 4:06 AM, Georgios Emmanouil wrote:
> Fixed spelling error. 'unkmown' to 'unknown'.
>
> Signed-off-by: Georgios Emmanouil
Reviewed-by: Julian Calaby
> ---
> drivers/staging/wilc1000/wilc_spi.c | 8
> 1 file
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(-)
s Emmanouil
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/
lloc(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/
; - 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/
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
> #define TUN_MINOR 200
> #define CUSE_MINOR 203
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
he linked document
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
ty.)
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
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/
fic benefits for this 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 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/
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/
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
Than
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/
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 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 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 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
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 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
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/
le(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 flag for this in some
compatible specific config structure instead of checking
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
+ (regulators == axp809_regulators && i == AXP809_DCDC1) ||
> + (regulators == axp813_regulators && i == AXP813_DCDC1))
Ditto.
> of_property_read_string(rdev->dev.of_node,
>
;)
> Signed-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/
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 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
eve 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/
regulator-type = "voltage";
> +
> + gpios = <&r_pio 0 6 GPIO_ACTIVE_HIGH>;
> + states = <110 0x0
> + 130 0x1>;
> +
> + startup-delay-us = <10>;
> + enable
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/
regulator-type = "voltage";
> +
> + gpios = <&r_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/
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
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:
>>>
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 r
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
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 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 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 running it an
aintainers.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
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/
red into thread_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
1 - 100 of 256 matches
Mail list logo
