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
more stuff t
I 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.
Thanks,
es, 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 Calaby
Email: julian.
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/
s 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/
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 by someone who
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
s 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 - not just (theoretically?) working on it - then I'd be
fighting to keep it.
But there isn't.
I think it's time fo
;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/
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 = cur_secti
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/
y 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/
[i])
> + cfg = AXP20X_DCDC2_LDO3_V_RAMP_LDO3_RATE(i);
> + else
> + break;
> + }
> +
> + if (cfg == 0xff) {
> + dev_err(axp20x->dev, "unsupported ramp value %d",
> ramp);
> + return -EINVAL;
> + }
> +
> + cfg |= enable;
> + }
> +
> + return regmap_update_bits(axp20x->regmap, reg, mask, cfg);
> +}
> +
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
Hi Jernej,
On Sun, May 20, 2018 at 11:57 AM, Julian Calaby <julian.cal...@gmail.com> wrote:
> Hi Jernej,
>
> On Sun, May 20, 2018 at 4:31 AM, Jernej Skrabec <jernej.skra...@siol.net>
> wrote:
>> R40 display pipeline has a lot of possible configurations. HDMI can
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
}
> +
> +static int sun8i_r40_tcon_tv_set_mux_1(struct sun4i_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 Allwi
_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
+H3 and A64 HDMI PHY requires additional clocks:
>- 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 th
-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/
operty is present then the dai is
> + configured to extend 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/
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
<maxime.rip...@bootlin.com> 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 <jernej.skra...@siol.net>
>> w
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
.net> 写到:
>> >Hi Julian,
>> >
>> >Dne nedelja, 25. februar 2018 ob 09:11:34 CET je Julian Calaby
>> >
>> >napisal(a):
>> >> Hi Jernej,
>> >>
>> >> On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
>> >
>> &
t;> >
>> >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 <icen...@aosc.io> wrote:
>
>
> 于 2018年2月25日 GMT+08:00 下午4:11:34, Julian Calaby <julian.cal...@gmail.com> 写到:
>>Hi Jernej,
>>
>>On Sun, Feb 25, 2018 at 8:45 AM, Jernej Skrabec
>><jernej
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
lease add the
necessary bits and pieces to the h2-plus DTSs too?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
+
> 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 h2-p
om the codec side of the chip, which we
> +* 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
> +* m
* 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/
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 <icen...@aosc.io> wrote:
>
>
> 于 2018年1月20日 GMT+08:00 上午11:06:40, Julian Calaby <julian.cal...@gmail.com> 写到:
>>Hi Icenowy,
>>
>>On Sat, Jan 20, 2018 at 10:17 AM, Icenowy Zheng <icen...@aosc.io>
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
gt; +menuconfig ARCH_SUNXI_V5
> + 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/
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/
ONTROLLER
> select CLKSRC_MMIO
> select GENERIC_IRQ_CHIP
Shouldn't you remove all the common ARCH_SUNXI selects from ARCH_SUNXI_v7?
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
>
#define AXP22X_CHRG_CTRL1_TGT_4_24V(3 << 5)
Should these be "alphabetical", i.e. AXP20X, AXP22X, AXP813?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
(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
>> The address on the device side is sometimes (often?) offset from the CPU
>> address. So eg. the device can DMA to RAM address 0x0 using address
>> 0x800.
>>
>> Identity would imply 0 == 0 etc.
>>
>> I think "bijective" is the co
ice 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 <h...@lst.de> 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: ju
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.cal...@
ELPER_NO_SCALING;
if (layer->mixer->cfg->scaler_mask & 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/
; 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/
utex_unlock(>mutex);
>
> - if (ret < 0) {
> - wl1271_warning("couldn't prepare device to suspend");
"couldn't enable power saving"?
> - return ret;
> - }
> + if (ret < 0)
> + goto report_prepa
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/
tter
> reused at the end of this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
However,
> ---
> drivers/net/wireless/ti/w
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/
iled at the beginning.
>
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
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
_off(wl);
> + goto out_free_nvs;
Why not put this in front of the out_free_nvs label? It looks weird here.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
);
> complete_all(>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 weird here.
T
y without the specification of useful actions between.
> Thus remove such unnecessary source code at the end of this function.
>
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
Looks good to me.
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
--
Julia
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/
..@csie.org>
Thanks!
FWIW this is:
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
--
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 <w...@csie.org> wrote:
> On Sat, Sep 30, 2017 at 1:35 PM, Julian Calaby <julian.cal...@gmail.com>
> wrote:
>> Hi Chen-Yu,
>>
>> On Fri, Sep 29, 2017 at 8:22 PM, Chen-Yu Tsai <w...@csie.org>
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
rs,
> which
> are only available in TCON0. Other than that, there's nothing else
> shared 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/
tween
> 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/
compatible = "allwinner,sun50i-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/
k";
> +};
> +
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/
e-cells = <1>;
> 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 n
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 ignored?
Thanks,
>> Well clearly 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 0
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:01 bec
"be removed as a default mac address is "
> + "stored internally.\n");
> +
> + /* Use TI oui and a random nic */
> + oui = 0x080028;
Is there (or should there be) a constant for this?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
"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 <nitin.m.gu...@oracle.com> wrote:
> Hi Julian,
>
>
> On 6/22/17 3:53 AM, Julian Calaby wrote:
>>
>> On Thu, Jun 22, 2017 at 7:50 AM, Nitin Gupta <nitin.m.gu...@oracle.com>
>> wrote:
>>>
&g
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
gt; + if (PageTail(head))
> + head = compound_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/
_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/
nc_sg_for_cpu= sbus_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/
u,
> .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/
; -#define CLK_PLL_VIDEO1_2X 16
>
> +/* The PLL_VIDEO0_2X is exported 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/
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 <geo.em...@gmail.com> wrote:
> Removed unnecessary 'if' statement and integrated the condition to the
> previous 'if' statement.
>
> Signed-off-by: Georgios Emmanouil <geo.em...@gmail.com>
Reviewed-by: J
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/staging/wilc1000/hos
Hi All,
On Fri, Mar 3, 2017 at 2:37 AM, Georgios Emmanouil <geo.em...@gmail.com> wrote:
> Fixed alignment to match open parenthesis.
>
> Signed-off-by: Georgios Emmanouil <geo.em...@gmail.com>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
> -
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 <geo.em...@gmail.com> wrote:
> Removed unnecessary blank line.
>
> Signed-off-by: Georgios Emmanouil <geo.em...@gmail.com>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
> ---
> drivers/stag
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 <geo.em...@gmail.com> wrote:
> Modified comment style to preferred kernel comment style.
>
> Signed-off-by: Georgios Emmanouil <geo.em...@gmail.com>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
> -
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 <geo.em...@gmail.com> wrote:
> Modified the 'if-else' statement to make it more readable.
>
> Signed-off-by: Georgios Emmanouil <geo.em...@gmail.com>
Again, I'm dubious if this is needed or helpful, but
Revie
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/staging/wilc10
Hi All,
On Fri, Mar 3, 2017 at 4:07 AM, Georgios Emmanouil <geo.em...@gmail.com> wrote:
> Added blank line after function and modified comment style.
>
> Signed-off-by: Georgios Emmanouil <geo.em...@gmail.com>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
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 <geo.em...@gmail.com> wrote:
> Fixed spelling error. 'unkmown' to 'unknown'.
>
> Signed-off-by: Georgios Emmanouil <geo.em...@gmail.com>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
> ---
> dr
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 changed, 4 insertio
Hi All,
On Fri, Mar 3, 2017 at 4:05 AM, Georgios Emmanouil <geo.em...@gmail.com> wrote:
> Fixed alignment to match parenthesis.
>
> Signed-off-by: Georgios Emmanouil <geo.em...@gmail.com>
Reviewed-by: Julian Calaby <julian.cal...@gmail.com>
> ---
> driver
1 - 100 of 493 matches
Mail list logo
