* Re: [PATCH 2/2] staging: sm750fb: add spaces around operator
From: Dan Carpenter @ 2015-11-08 6:35 UTC (permalink / raw)
To: Othmar Pasteka
Cc: sudipm.mukherjee, teddy.wang, sudip, greg, devel, linux-fbdev,
linux-kernel
In-Reply-To: <dff05f0aaa83ddedafd5f061548dc2ba75486fd3.1446942955.git.pasteka@kabsi.at>
If it's a one line fix then just send it as a single patch.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 2/2] staging: sm750fb: add spaces around operator
From: Othmar Pasteka @ 2015-11-08 7:33 UTC (permalink / raw)
To: Dan Carpenter
Cc: sudipm.mukherjee, teddy.wang, sudip, greg, devel, linux-fbdev,
linux-kernel
In-Reply-To: <20151108063508.GM18797@mwanda>
On Sun, Nov 08, 2015 at 09:35:08AM +0300, Dan Carpenter wrote:
> If it's a one line fix then just send it as a single patch.
It was two things, hence I made it a two-parter.
Should I send a new version or is it a note for next time?
Thanks,
Othmar Pasteka
^ permalink raw reply
* Re: [PATCH 0/3] Hisilicon graphic driver
From: Hanjun Guo @ 2015-11-08 7:55 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BLU437-SMTP248CA33D65A31EAE12675CC32B0@phx.gbl>
On 2015/11/3 21:54, Rongrong Zou wrote:
> From: Rongrong Zou <rongrongchau@163.com>
>
> Hi1710 chip have a graphic modue with 2d acceleration, this driver support
> the graphic module.
>
> Rongrong Zou (3):
> Hisilicon graphic driver: add fbdev support to hisilicon hi1710
> graphic chip
> Hisilicon graphic driver: add hardware cursor support to hisilicon
> hi1710 graphi chip
> Hisilicon graphic driver: add 2d acceleration to hisilicon hi1710
> graphic chip
Fixed the conflicts and tested on lemon board, and it works as expected,
queue up for next hulk release.
Thanks
Hanjun
>
> MAINTAINERS | 7 +
> drivers/video/fbdev/Kconfig | 14 +
> drivers/video/fbdev/Makefile | 2 +-
> drivers/video/fbdev/hisilicon/Makefile | 6 +
> drivers/video/fbdev/hisilicon/hisi_accel.c | 382 ++++++++
> drivers/video/fbdev/hisilicon/hisi_accel.h | 62 ++
> drivers/video/fbdev/hisilicon/hisi_chip.c | 131 +++
> drivers/video/fbdev/hisilicon/hisi_chip.h | 62 ++
> drivers/video/fbdev/hisilicon/hisi_cursor.c | 121 +++
> drivers/video/fbdev/hisilicon/hisi_cursor.h | 11 +
> drivers/video/fbdev/hisilicon/hisi_drv.c | 1326 +++++++++++++++++++++++++++
> drivers/video/fbdev/hisilicon/hisi_drv.h | 181 ++++
> drivers/video/fbdev/hisilicon/hisi_help.h | 64 ++
> drivers/video/fbdev/hisilicon/hisi_hw.c | 314 +++++++
> drivers/video/fbdev/hisilicon/hisi_hw.h | 95 ++
> drivers/video/fbdev/hisilicon/hisi_mode.c | 286 ++++++
> drivers/video/fbdev/hisilicon/hisi_mode.h | 39 +
> drivers/video/fbdev/hisilicon/hisi_power.c | 106 +++
> drivers/video/fbdev/hisilicon/hisi_power.h | 18 +
> drivers/video/fbdev/hisilicon/hisi_reg.h | 418 +++++++++
> 20 files changed, 3644 insertions(+), 1 deletion(-)
> create mode 100644 drivers/video/fbdev/hisilicon/Makefile
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_accel.c
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_accel.h
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_chip.c
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_chip.h
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_cursor.c
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_cursor.h
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_drv.c
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_drv.h
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_help.h
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_hw.c
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_hw.h
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_mode.c
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_mode.h
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_power.c
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_power.h
> create mode 100644 drivers/video/fbdev/hisilicon/hisi_reg.h
>
^ permalink raw reply
* Re: [PATCH 0/3] Hisilicon graphic driver
From: Hanjun Guo @ 2015-11-08 8:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BLU437-SMTP248CA33D65A31EAE12675CC32B0@phx.gbl>
Hi All,
Obviously this is a noise, really sorry, please ignore it.
Thanks
Hanjun
On 2015/11/8 15:55, Hanjun Guo wrote:
> On 2015/11/3 21:54, Rongrong Zou wrote:
>> From: Rongrong Zou <rongrongchau@163.com>
>>
>> Hi1710 chip have a graphic modue with 2d acceleration, this driver support
>> the graphic module.
>>
>> Rongrong Zou (3):
>> Hisilicon graphic driver: add fbdev support to hisilicon hi1710
>> graphic chip
>> Hisilicon graphic driver: add hardware cursor support to hisilicon
>> hi1710 graphi chip
>> Hisilicon graphic driver: add 2d acceleration to hisilicon hi1710
>> graphic chip
> Fixed the conflicts and tested on lemon board, and it works as expected,
> queue up for next hulk release.
>
> Thanks
> Hanjun
>
>> MAINTAINERS | 7 +
>> drivers/video/fbdev/Kconfig | 14 +
>> drivers/video/fbdev/Makefile | 2 +-
>> drivers/video/fbdev/hisilicon/Makefile | 6 +
>> drivers/video/fbdev/hisilicon/hisi_accel.c | 382 ++++++++
>> drivers/video/fbdev/hisilicon/hisi_accel.h | 62 ++
>> drivers/video/fbdev/hisilicon/hisi_chip.c | 131 +++
>> drivers/video/fbdev/hisilicon/hisi_chip.h | 62 ++
>> drivers/video/fbdev/hisilicon/hisi_cursor.c | 121 +++
>> drivers/video/fbdev/hisilicon/hisi_cursor.h | 11 +
>> drivers/video/fbdev/hisilicon/hisi_drv.c | 1326 +++++++++++++++++++++++++++
>> drivers/video/fbdev/hisilicon/hisi_drv.h | 181 ++++
>> drivers/video/fbdev/hisilicon/hisi_help.h | 64 ++
>> drivers/video/fbdev/hisilicon/hisi_hw.c | 314 +++++++
>> drivers/video/fbdev/hisilicon/hisi_hw.h | 95 ++
>> drivers/video/fbdev/hisilicon/hisi_mode.c | 286 ++++++
>> drivers/video/fbdev/hisilicon/hisi_mode.h | 39 +
>> drivers/video/fbdev/hisilicon/hisi_power.c | 106 +++
>> drivers/video/fbdev/hisilicon/hisi_power.h | 18 +
>> drivers/video/fbdev/hisilicon/hisi_reg.h | 418 +++++++++
>> 20 files changed, 3644 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/video/fbdev/hisilicon/Makefile
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_accel.c
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_accel.h
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_chip.c
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_chip.h
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_cursor.c
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_cursor.h
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_drv.c
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_drv.h
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_help.h
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_hw.c
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_hw.h
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_mode.c
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_mode.h
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_power.c
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_power.h
>> create mode 100644 drivers/video/fbdev/hisilicon/hisi_reg.h
>>
^ permalink raw reply
* Re: [PATCH 2/2] staging: sm750fb: add spaces around operator
From: Dan Carpenter @ 2015-11-08 8:17 UTC (permalink / raw)
To: Othmar Pasteka
Cc: sudipm.mukherjee, teddy.wang, sudip, greg, devel, linux-fbdev,
linux-kernel
In-Reply-To: <20151108073315.GA22116@tron.local>
On Sun, Nov 08, 2015 at 08:33:16AM +0100, Othmar Pasteka wrote:
> Should I send a new version or is it a note for next time?
Send a new version.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] staging: sm750fb: fix style for if clause
From: Othmar Pasteka @ 2015-11-08 10:58 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, sudip, greg
Cc: devel, linux-fbdev, linux-kernel, Othmar Pasteka
Fix for checkpatch.pl complaints:
ERROR: that open brace { should be on the previous line
CHECK: spaces preferred around that '+' (ctx:VxV)
Signed-off-by: Othmar Pasteka <pasteka@kabsi.at>
---
drivers/staging/sm750fb/sm750_cursor.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
index 3b7ce92..0a41585 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -143,8 +143,7 @@ void hw_cursor_setData(struct lynx_cursor *cursor,
iowrite16(data, pbuffer);
/* assume pitch is 1,2,4,8,...*/
- if ((i+1) % pitch = 0)
- {
+ if ((i + 1) % pitch = 0) {
/* need a return */
pstart += offset;
pbuffer = pstart;
--
2.5.3
^ permalink raw reply related
* [PATCH] video: constify geode ops structures
From: Julia Lawall @ 2015-11-08 21:34 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: kernel-janitors, Tomi Valkeinen, linux-geode, linux-fbdev,
linux-kernel
These geode ops structures are never modified, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/fbdev/geode/display_gx1.c | 2 +-
drivers/video/fbdev/geode/display_gx1.h | 2 +-
drivers/video/fbdev/geode/geodefb.h | 4 ++--
drivers/video/fbdev/geode/video_cs5530.c | 2 +-
drivers/video/fbdev/geode/video_cs5530.h | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/geode/display_gx1.c b/drivers/video/fbdev/geode/display_gx1.c
index 926d53e..b383eb9 100644
--- a/drivers/video/fbdev/geode/display_gx1.c
+++ b/drivers/video/fbdev/geode/display_gx1.c
@@ -208,7 +208,7 @@ static void gx1_set_hw_palette_reg(struct fb_info *info, unsigned regno,
writel(val, par->dc_regs + DC_PAL_DATA);
}
-struct geode_dc_ops gx1_dc_ops = {
+const struct geode_dc_ops gx1_dc_ops = {
.set_mode = gx1_set_mode,
.set_palette_reg = gx1_set_hw_palette_reg,
};
diff --git a/drivers/video/fbdev/geode/display_gx1.h b/drivers/video/fbdev/geode/display_gx1.h
index 671c055..e1cc41b 100644
--- a/drivers/video/fbdev/geode/display_gx1.h
+++ b/drivers/video/fbdev/geode/display_gx1.h
@@ -18,7 +18,7 @@
unsigned gx1_gx_base(void);
int gx1_frame_buffer_size(void);
-extern struct geode_dc_ops gx1_dc_ops;
+extern const struct geode_dc_ops gx1_dc_ops;
/* GX1 configuration I/O registers */
diff --git a/drivers/video/fbdev/geode/geodefb.h b/drivers/video/fbdev/geode/geodefb.h
index ae04820..e2e0793 100644
--- a/drivers/video/fbdev/geode/geodefb.h
+++ b/drivers/video/fbdev/geode/geodefb.h
@@ -31,8 +31,8 @@ struct geodefb_par {
int panel_y;
void __iomem *dc_regs;
void __iomem *vid_regs;
- struct geode_dc_ops *dc_ops;
- struct geode_vid_ops *vid_ops;
+ const struct geode_dc_ops *dc_ops;
+ const struct geode_vid_ops *vid_ops;
};
#endif /* !__GEODEFB_H__ */
diff --git a/drivers/video/fbdev/geode/video_cs5530.c b/drivers/video/fbdev/geode/video_cs5530.c
index 649c394..8806132 100644
--- a/drivers/video/fbdev/geode/video_cs5530.c
+++ b/drivers/video/fbdev/geode/video_cs5530.c
@@ -186,7 +186,7 @@ static int cs5530_blank_display(struct fb_info *info, int blank_mode)
return 0;
}
-struct geode_vid_ops cs5530_vid_ops = {
+const struct geode_vid_ops cs5530_vid_ops = {
.set_dclk = cs5530_set_dclk_frequency,
.configure_display = cs5530_configure_display,
.blank_display = cs5530_blank_display,
diff --git a/drivers/video/fbdev/geode/video_cs5530.h b/drivers/video/fbdev/geode/video_cs5530.h
index 56cecca..c843348 100644
--- a/drivers/video/fbdev/geode/video_cs5530.h
+++ b/drivers/video/fbdev/geode/video_cs5530.h
@@ -15,7 +15,7 @@
#ifndef __VIDEO_CS5530_H__
#define __VIDEO_CS5530_H__
-extern struct geode_vid_ops cs5530_vid_ops;
+extern const struct geode_vid_ops cs5530_vid_ops;
/* CS5530 Video device registers */
^ permalink raw reply related
* Re: [PATCH] video: constify geode ops structures
From: Dan Carpenter @ 2015-11-08 22:16 UTC (permalink / raw)
To: Julia Lawall
Cc: Jean-Christophe Plagniol-Villard, kernel-janitors, Tomi Valkeinen,
linux-geode, linux-fbdev, linux-kernel
In-Reply-To: <1447018493-20631-1-git-send-email-Julia.Lawall@lip6.fr>
Cool. So, in grsec they use a GCC plugin to make these const
automatically since they only contain function pointers. There about
100 struct types marked as __no_const. Kees would like to adopt the
grsec pluggin approach I expect. Do you have an idea how many structs
only contain function pointers or how many consts we would have to add
to get the same effect without the plugin?
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] video: constify geode ops structures
From: Julia Lawall @ 2015-11-08 22:24 UTC (permalink / raw)
To: Dan Carpenter
Cc: Julia Lawall, Jean-Christophe Plagniol-Villard, kernel-janitors,
Tomi Valkeinen, linux-geode, linux-fbdev, linux-kernel
In-Reply-To: <20151108221624.GP18797@mwanda>
On Mon, 9 Nov 2015, Dan Carpenter wrote:
> Cool. So, in grsec they use a GCC plugin to make these const
> automatically since they only contain function pointers. There about
> 100 struct types marked as __no_const. Kees would like to adopt the
> grsec pluggin approach I expect. Do you have an idea how many structs
> only contain function pointers or how many consts we would have to add
> to get the same effect without the plugin?
My list has 373 type names. In the list there are counts for good
(already const) and bad (not const). The sum of the bad values is 2467.
The list is below.
julia
cpuidle_ops: good: 0, bad: 1
xen_pci_frontend_ops: good: 0, bad: 1
pch_dev_ops: good: 0, bad: 1
s3c_ide_platdata: good: 0, bad: 1
bfin_cpu_pm_fns: good: 0, bad: 1
meta_type_ops: good: 0, bad: 1
bnx2x_func_sp_drv_ops: good: 0, bad: 1
hfi1_filter_array: good: 0, bad: 1
ttusbdecfe_config: good: 0, bad: 1
au1k_irda_platform_data: good: 0, bad: 1
dao_rsc_ops: good: 0, bad: 1
mic_hw_intr_ops: good: 0, bad: 1
mic_smpt_ops: good: 0, bad: 1
scpi_ops: good: 0, bad: 1
fmc_operations: good: 0, bad: 1
geode_dc_ops: good: 0, bad: 1
superhyway_ops: good: 0, bad: 1
vsock_transport: good: 0, bad: 1
ti_clk_ll_ops: good: 0, bad: 1
enclosure_component_callbacks: good: 0, bad: 1
dai_rsc_ops: good: 0, bad: 1
cfs_psdev_ops: good: 0, bad: 1
x86_msi_ops: good: 0, bad: 1
intel_sst_ops: good: 0, bad: 1
nf_ct_event_notifier: good: 0, bad: 1
geode_vid_ops: good: 0, bad: 1
menelaus_platform_data: good: 0, bad: 1
mipi_dsim_master_ops: good: 0, bad: 1
in_cache_ops: good: 0, bad: 1
ste_modem_dev_cb: good: 0, bad: 1
kernfs_syscall_ops: good: 0, bad: 1
amixer_rsc_ops: good: 0, bad: 1
nes_cm_ops: good: 0, bad: 1
radio_tea5777_ops: good: 0, bad: 1
x86_cpuinit_ops: good: 0, bad: 1
hpc_ops: good: 0, bad: 1
vexpress_config_bridge_ops: good: 0, bad: 1
x86_platform_ops: good: 0, bad: 1
powercap_zone_ops: good: 0, bad: 1
as102_priv_ops_t: good: 0, bad: 1
lpc32xx_slc_platform_data: good: 0, bad: 1
src_rsc_ops: good: 0, bad: 1
pxafb_layer_ops: good: 0, bad: 1
ds278x_battery_ops: good: 0, bad: 1
hnae_buf_ops: good: 0, bad: 1
mcp_ops: good: 0, bad: 1
nfnl_ct_hook: good: 0, bad: 1
xpc_interface: good: 0, bad: 1
vpbe_device_ops: good: 0, bad: 1
stmp3xxx_wdt_pdata: good: 0, bad: 1
cosm_hw_ops: good: 0, bad: 1
fm10k_iov_ops: good: 0, bad: 1
s3fwrn5_phy_ops: good: 0, bad: 1
tc6387xb_platform_data: good: 0, bad: 1
visorchipset_busdev_responders: good: 0, bad: 1
csio_hw_chip_ops: good: 0, bad: 1
visorchipset_busdev_notifiers: good: 0, bad: 1
concap_device_ops: good: 0, bad: 1
stv6110x_devctl: good: 0, bad: 1
powercap_zone_constraint_ops: good: 0, bad: 1
eg_cache_ops: good: 0, bad: 1
trace_lock_handler: good: 0, bad: 1
gnttab_ops: good: 0, bad: 1
ldlm_valblock_ops: good: 0, bad: 1
rtl_btc_ops: good: 0, bad: 1
max197_platform_data: good: 0, bad: 1
qla_tgt_func_tmpl: good: 0, bad: 1
arm_pmu_platdata: good: 0, bad: 1
amd_sched_backend_ops: good: 0, bad: 1
da903x_chip_ops: good: 0, bad: 1
hnae_ae_ops: good: 0, bad: 1
ds2404_chip_ops: good: 0, bad: 1
cardbus_type: good: 0, bad: 1
sh_mobile_lcdc_sys_bus_ops: good: 0, bad: 1
ieee802154_llsec_ops: good: 0, bad: 1
kvm_mips_callbacks: good: 0, bad: 1
nf_exp_event_notifier: good: 0, bad: 1
usb_mon_operations: good: 0, bad: 1
nlmsvc_binding: good: 0, bad: 1
cleancache_ops: good: 0, bad: 1
bfa_fcs_mod_s: good: 0, bad: 1
dac_ops: good: 0, bad: 1
sst_block_ops: good: 0, bad: 1
lane2_ops: good: 0, bad: 1
llog_operations: good: 0, bad: 1
concap_proto_ops: good: 0, bad: 1
x86_io_apic_ops: good: 0, bad: 1
od_ops: good: 0, bad: 1
omap_mcbsp_ops: good: 0, bad: 1
cpuidle_exynos_data: good: 0, bad: 1
pci_platform_pm_ops: good: 0, bad: 1
lpc32xx_mlc_platform_data: good: 0, bad: 1
dw_spi_dma_ops: good: 0, bad: 1
mmp_overlay_ops: good: 0, bad: 1
iommu_table_group_ops: good: 0, bad: 1
md_cluster_operations: good: 0, bad: 1
cpu_pm_ops: good: 0, bad: 1
mxl111sf_demod_config: good: 0, bad: 1
srcimp_rsc_ops: good: 0, bad: 1
dca_ops: good: 0, bad: 1
mcfqspi_cs_control: good: 0, bad: 1
skl_dsp_fw_ops: good: 0, bad: 1
iser_reg_ops: good: 0, bad: 2
saa7146_use_ops: good: 0, bad: 2
qlcnic_dcb_ops: good: 0, bad: 2
fm10k_mac_ops: good: 0, bad: 2
v3020_chip_ops: good: 0, bad: 2
intel_mid_ops: good: 0, bad: 2
wlcore_ops: good: 0, bad: 2
au1200fb_platdata: good: 0, bad: 2
mxr_layer_ops: good: 0, bad: 2
ocfs2_stack_operations: good: 0, bad: 2
kvm_pmu_ops: good: 0, bad: 2
hdmi_phy_ops: good: 0, bad: 2
rtl_intf_ops: good: 0, bad: 2
mxc_extra_irq: good: 0, bad: 2
hwicap_driver_config: good: 0, bad: 2
dev_power_governor: good: 0, bad: 2
ptlrpc_ctx_ops: good: 0, bad: 2
olpc_ec_driver: good: 0, bad: 2
xpc_arch_operations: good: 0, bad: 2
cal_chipset_ops: good: 0, bad: 2
mal_commac_ops: good: 0, bad: 2
mmc_pwrseq_ops: good: 0, bad: 2
mem_access: good: 0, bad: 2
fd_dma_ops: good: 0, bad: 2
mvumi_instance_template: good: 0, bad: 2
imx_pwm_data: good: 0, bad: 2
nfc_llc_ops: good: 0, bad: 2
amba_pl010_data: good: 0, bad: 2
emitter: good: 0, bad: 2
fc_rport_operations: good: 0, bad: 2
adfs_dir_ops: good: 0, bad: 2
mpt_pci_driver: good: 0, bad: 2
gpio_methods: good: 0, bad: 2
s5p_mfc_hw_cmds: good: 0, bad: 2
bfin_sport_transfer_ops: good: 0, bad: 2
ct_timer_ops: good: 0, bad: 2
cmac_ops: good: 0, bad: 2
vio_driver_ops: good: 0, bad: 2
dummy_timer_ops: good: 0, bad: 2
mdesc_mem_ops: good: 0, bad: 2
uprobe_xol_ops: good: 0, bad: 2
dcon_platform_data: good: 0, bad: 2
vmci_transport_notify_ops: good: 0, bad: 2
w100_tg_info: good: 0, bad: 2
knav_range_ops: good: 0, bad: 2
drm_dp_mst_topology_cbs: good: 0, bad: 2
snd_rawmidi_global_ops: good: 0, bad: 2
s5p_mfc_codec_ops: good: 0, bad: 2
hwbus_ops: good: 0, bad: 2
ufs_qcom_phy_specific_ops: good: 0, bad: 2
nfc_digital_ops: good: 0, bad: 2
alpha_agp_ops: good: 0, bad: 2
ath_ps_ops: good: 0, bad: 2
hmcdrv_ftp_ops: good: 0, bad: 2
spu_context_ops: good: 0, bad: 2
snd_i2c_ops: good: 0, bad: 2
md_ops: good: 0, bad: 2
sunhv_ops: good: 0, bad: 2
uartlite_reg_ops: good: 0, bad: 2
ptlrpc_sec_sops: good: 0, bad: 2
pci_bios_ops: good: 0, bad: 2
microcode_ops: good: 0, bad: 2
s5p_mfc_hw_ops: good: 0, bad: 2
of_pdt_ops: good: 0, bad: 2
wl1271_if_operations: good: 0, bad: 2
otg_fsm_ops: good: 0, bad: 2
nfsd4_callback_ops: good: 0, bad: 2
abx500_ops: good: 0, bad: 2
m48t86_ops: good: 0, bad: 2
ptlrpc_sec_cops: good: 0, bad: 2
mbus_hw_ops: good: 0, bad: 2
fcoe_sysfs_function_template: good: 0, bad: 2
smp_ops: good: 1, bad: 1
pv_time_ops: good: 1, bad: 1
wl1251_if_operations: good: 1, bad: 1
pv_init_ops: good: 1, bad: 1
xfs_nameops: good: 1, bad: 1
ixgbe_mbx_operations: good: 1, bad: 1
dm_space_map: good: 0, bad: 3
at91_pinctrl_mux_ops: good: 0, bad: 3
ipmi_user_hndl: good: 0, bad: 3
brcmf_bus_ops: good: 0, bad: 3
ixgbe_eeprom_operations: good: 0, bad: 3
fsi_stream_handler: good: 0, bad: 3
xgene_mac_ops: good: 0, bad: 3
sbc_ops: good: 0, bad: 3
snd_vx_ops: good: 0, bad: 3
go7007_hpi_ops: good: 0, bad: 3
ixgbe_phy_operations: good: 0, bad: 3
sh_irda_xir_func: good: 0, bad: 3
matrox_switch: good: 0, bad: 3
qlcnic_hardware_ops: good: 0, bad: 3
btrfs_free_space_op: good: 0, bad: 3
snd_compr_ops: good: 0, bad: 3
xgene_port_ops: good: 0, bad: 3
nfsd4_client_tracking_ops: good: 0, bad: 3
samsung_gpio_pm: good: 0, bad: 3
drbg_state_ops: good: 0, bad: 3
nilfs_sc_operations: good: 0, bad: 3
snd_i2c_bit_ops: good: 0, bad: 3
snd_midi_op: good: 0, bad: 3
fatent_operations: good: 0, bad: 3
mwifiex_if_ops: good: 0, bad: 3
pci_port_ops: good: 0, bad: 3
portals_handle_ops: good: 0, bad: 3
logfs_block_ops: good: 0, bad: 3
nfc_hci_ops: good: 0, bad: 3
ace_reg_ops: good: 0, bad: 3
cx2341x_handler_ops: good: 0, bad: 3
conf_printer: good: 0, bad: 3
ui_progress_ops: good: 0, bad: 3
trace_sched_handler: good: 0, bad: 3
perf_error_ops: good: 0, bad: 3
perf_guest_info_callbacks: good: 0, bad: 3
aes_ops: good: 0, bad: 3
xfrm_replay: good: 0, bad: 3
pccard_resource_ops: good: 0, bad: 3
qtree_fmt_operations: good: 0, bad: 3
ui_helpline: good: 0, bad: 3
machine_ops: good: 1, bad: 2
bpf_verifier_ops: good: 2, bad: 1
sn_pcibus_provider: good: 0, bad: 4
sas_function_template: good: 0, bad: 4
cfs_hash_hlist_ops: good: 0, bad: 4
io_pgtable_init_fns: good: 0, bad: 4
rproc_ops: good: 0, bad: 4
fb_tile_ops: good: 0, bad: 4
sst_ops: good: 0, bad: 4
usb_phy_io_ops: good: 0, bad: 4
raw3270_fn: good: 0, bad: 4
radeon_audio_basic_funcs: good: 0, bad: 4
qlcnic_nic_template: good: 0, bad: 4
board_ops: good: 0, bad: 4
irda_platform_data: good: 0, bad: 4
drm_encoder_slave_funcs: good: 0, bad: 4
rchan_callbacks: good: 0, bad: 4
hppa_dma_ops: good: 0, bad: 4
nfcmrvl_if_ops: good: 0, bad: 4
iommu_gather_ops: good: 0, bad: 4
cm_ll_data: good: 0, bad: 4
plat_sci_port_ops: good: 0, bad: 4
sas_domain_function_template: good: 0, bad: 4
ib_dma_mapping_ops: good: 0, bad: 4
psc_ops: good: 0, bad: 4
z8530_irqhandler: good: 0, bad: 4
prm_ll_data: good: 0, bad: 4
ixgbe_mac_operations: good: 1, bad: 3
v4l2_subdev_sensor_ops: good: 1, bad: 3
of_bus: good: 1, bad: 3
e1000_mac_operations: good: 3, bad: 1
mipi_dsi_host_ops: good: 3, bad: 1
rpc_xprt_ops: good: 0, bad: 5
ep93xx_spi_chip_ops: good: 0, bad: 5
item_operations: good: 0, bad: 5
page_ext_operations: good: 0, bad: 5
bcache_ops: good: 0, bad: 5
ocfs2_extent_tree_operations: good: 0, bad: 5
ion_heap_ops: good: 0, bad: 5
svc_xprt_ops: good: 0, bad: 5
clkdm_ops: good: 0, bad: 5
nfc_ops: good: 0, bad: 5
pwrdm_ops: good: 0, bad: 5
megasas_instance_template: good: 0, bad: 5
esp_driver_ops: good: 4, bad: 1
exynos_drm_crtc_ops: good: 4, bad: 1
lu_device_operations: good: 4, bad: 1
e1000_nvm_operations: good: 4, bad: 1
cl_device_operations: good: 4, bad: 1
ins_ops: good: 0, bad: 6
exynos_drm_ipp_ops: good: 0, bad: 6
snd_tea575x_ops: good: 0, bad: 6
intel_dvo_dev_ops: good: 0, bad: 6
cfs_hash_lock_ops: good: 0, bad: 6
hid_ll_driver: good: 0, bad: 6
ftdi_sio_quirk: good: 0, bad: 6
e1000_phy_operations: good: 5, bad: 1
mbox_chan_ops: good: 5, bad: 1
kset_uevent_ops: good: 5, bad: 1
crypt_iv_operations: good: 0, bad: 7
sa1100_port_fns: good: 0, bad: 7
radeon_audio_funcs: good: 0, bad: 7
rsc_ops: good: 0, bad: 7
dma_ops: good: 0, bad: 7
nfc_phy_ops: good: 0, bad: 7
fsnotify_ops: good: 6, bad: 1
cl_lock_operations: good: 6, bad: 1
pcie_host_ops: good: 0, bad: 8
action_ops: good: 0, bad: 8
cpu_user_fns: good: 0, bad: 8
snd_info_entry_ops: good: 0, bad: 8
cfs_hash_ops: good: 0, bad: 8
sparc32_cachetlb_ops: good: 5, bad: 3
virtio_config_ops: good: 6, bad: 2
xfs_item_ops: good: 7, bad: 1
msi_domain_ops: good: 0, bad: 9
plat_lcd_data: good: 0, bad: 9
rtl_hal_ops: good: 0, bad: 9
ttm_bo_driver: good: 0, bad: 10
usbhs_pkt_handle: good: 0, bad: 10
usb_protocol_ops: good: 0, bad: 10
clkops: good: 6, bad: 4
drm_bridge_funcs: good: 7, bad: 3
fence_ops: good: 9, bad: 1
omap_dss_driver: good: 0, bad: 11
dma_buf_ops: good: 5, bad: 6
thermal_zone_of_device_ops: good: 7, bad: 4
mmu_notifier_ops: good: 8, bad: 3
kvm_io_device_ops: good: 10, bad: 1
ttm_backend_func: good: 0, bad: 12
access_method: good: 0, bad: 12
event_trigger_ops: good: 0, bad: 12
stacktrace_ops: good: 10, bad: 2
isp_operations: good: 0, bad: 13
hv_ops: good: 11, bad: 2
ftrace_probe_ops: good: 0, bad: 14
v4l2_m2m_ops: good: 2, bad: 12
thermal_cooling_device_ops: good: 7, bad: 7
plat_smp_ops: good: 0, bad: 15
clk_hw_omap_ops: good: 14, bad: 1
videobuf_queue_ops: good: 1, bad: 15
drm_plane_helper_funcs: good: 15, bad: 1
pccard_operations: good: 0, bad: 17
mii_phy_ops: good: 0, bad: 18
radeon_asic_ring: good: 0, bad: 19
drm_fb_helper_funcs: good: 18, bad: 1
reset_control_ops: good: 0, bad: 20
ide_dma_ops: good: 18, bad: 2
thermal_zone_device_ops: good: 0, bad: 21
drm_framebuffer_funcs: good: 15, bad: 6
drm_plane_funcs: good: 18, bad: 4
lcd_ops: good: 0, bad: 24
intel_uncore_ops: good: 0, bad: 24
export_operations: good: 24, bad: 2
drm_mode_config_funcs: good: 25, bad: 2
header_ops: good: 26, bad: 3
iio_buffer_setup_ops: good: 29, bad: 1
usb_gadget_ops: good: 31, bad: 2
mmc_host_ops: good: 21, bad: 13
drm_crtc_funcs: good: 28, bad: 6
rfkill_ops: good: 29, bad: 5
drm_crtc_helper_funcs: good: 30, bad: 4
usb_ep_ops: good: 18, bad: 18
tty_port_operations: good: 33, bad: 4
configfs_group_operations: good: 0, bad: 38
v4l2_subdev_internal_ops: good: 37, bad: 1
configfs_item_operations: good: 0, bad: 44
platform_suspend_ops: good: 41, bad: 4
snd_ac97_bus_ops: good: 0, bad: 49
pinctrl_ops: good: 40, bad: 9
dentry_operations: good: 52, bad: 1
pci_error_handlers: good: 46, bad: 9
snd_rawmidi_ops: good: 0, bad: 68
drm_connector_helper_funcs: good: 50, bad: 18
drm_encoder_funcs: good: 61, bad: 14
drm_connector_funcs: good: 56, bad: 20
drm_encoder_helper_funcs: good: 65, bad: 12
vb2_ops: good: 20, bad: 59
snd_soc_ops: good: 2, bad: 85
snd_device_ops: good: 0, bad: 93
v4l2_subdev_video_ops: good: 81, bad: 32
pci_ops: good: 0, bad: 121
rtc_class_ops: good: 117, bad: 31
v4l2_ctrl_ops: good: 198, bad: 6
inode_operations: good: 209, bad: 5
snd_soc_dai_ops: good: 226, bad: 18
ethtool_ops: good: 239, bad: 11
regulator_ops: good: 15, bad: 237
snd_pcm_ops: good: 7, bad: 278
clk_ops: good: 257, bad: 71
seq_operations: good: 328, bad: 1
dev_pm_ops: good: 337, bad: 19
^ permalink raw reply
* [PATCH] video:fbdev:core:Allocate the memory for video mode after the validation of edid.
From: Shailendra Verma @ 2015-11-09 8:15 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
Greg Kroah-Hartman
Cc: linux-kernel, vidushi.koul
In-Reply-To: <1446205073-23830-1-git-send-email-shailendra.v@samung.com>
From: Shailendra Verma <shailendra.v@samsung.com>
In this function "fb_create_modedb" the memory for video mode is getting
allocated before the edid validation.If the validation of edid fails
then we are freeing the allocated memory for the video mode and returning.
So moving the memory allocation part after the edid validation.There is no
need to allocate the memory before edid validation check and freeing if
validation gets failed.
Signed-off-by: Shailendra Verma <shailendra.v@samsung.com>
---
drivers/video/fbdev/core/fbmon.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 47c3191..476a5fd 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -620,16 +620,16 @@ static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize,
int num = 0, i, first = 1;
int ver, rev;
- mode = kzalloc(50 * sizeof(struct fb_videomode), GFP_KERNEL);
- if (mode = NULL)
- return NULL;
-
if (edid = NULL || !edid_checksum(edid) ||
!edid_check_header(edid)) {
- kfree(mode);
return NULL;
}
+ mode = kzalloc(50 * sizeof(struct fb_videomode), GFP_KERNEL);
+ if (mode = NULL)
+ return NULL;
+
+
ver = edid[EDID_STRUCT_VERSION];
rev = edid[EDID_STRUCT_REVISION];
--
1.9.1
^ permalink raw reply related
* [PATCH] video:fbdev:core:Allocate the memory for video mode after the validation of edid.
From: Shailendra Verma @ 2015-11-09 8:16 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
Greg Kroah-Hartman
Cc: linux-kernel, vidushi.koul, shailendra.v
In-Reply-To: <1446205073-23830-1-git-send-email-shailendra.v@samung.com>
From: Shailendra Verma <shailendra.v@samsung.com>
In this function "fb_create_modedb" the memory for video mode is getting
allocated before the edid validation.If the validation of edid fails
then we are freeing the allocated memory for the video mode and returning.
So moving the memory allocation part after the edid validation.There is no
need to allocate the memory before edid validation check and freeing if
validation gets failed.
Signed-off-by: Shailendra Verma <shailendra.v@samsung.com>
---
drivers/video/fbdev/core/fbmon.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 47c3191..476a5fd 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -620,16 +620,16 @@ static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize,
int num = 0, i, first = 1;
int ver, rev;
- mode = kzalloc(50 * sizeof(struct fb_videomode), GFP_KERNEL);
- if (mode = NULL)
- return NULL;
-
if (edid = NULL || !edid_checksum(edid) ||
!edid_check_header(edid)) {
- kfree(mode);
return NULL;
}
+ mode = kzalloc(50 * sizeof(struct fb_videomode), GFP_KERNEL);
+ if (mode = NULL)
+ return NULL;
+
+
ver = edid[EDID_STRUCT_VERSION];
rev = edid[EDID_STRUCT_REVISION];
--
1.9.1
^ permalink raw reply related
* [PATCH] video:fbdev:core:Calculate the size for colormap only after the validation of length for col
From: Shailendra Verma @ 2015-11-09 8:18 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev,
Greg Kroah-Hartman
Cc: linux-kernel, vidushi.koul, shailendra.v
From: Shailendra Verma <shailendra.v@samsung.com>
While allocating the memory for color map, the memory size for colors
is being calculated before the validation of length for color map.
Moved the size calculation part after the validation of color map length.
Signed-off-by: Shailendra Verma <shailendra.v@samsung.com>
---
drivers/video/fbdev/core/fbcmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcmap.c b/drivers/video/fbdev/core/fbcmap.c
index f89245b..45ad567 100644
--- a/drivers/video/fbdev/core/fbcmap.c
+++ b/drivers/video/fbdev/core/fbcmap.c
@@ -91,7 +91,7 @@ static const struct fb_cmap default_16_colors = {
int fb_alloc_cmap_gfp(struct fb_cmap *cmap, int len, int transp, gfp_t flags)
{
- int size = len * sizeof(u16);
+ int size;
int ret = -ENOMEM;
if (cmap->len != len) {
@@ -99,6 +99,7 @@ int fb_alloc_cmap_gfp(struct fb_cmap *cmap, int len, int transp, gfp_t flags)
if (!len)
return 0;
+ size = len * sizeof(u16);
cmap->red = kmalloc(size, flags);
if (!cmap->red)
goto fail;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] video: constify geode ops structures
From: Kees Cook @ 2015-11-09 21:20 UTC (permalink / raw)
To: Dan Carpenter
Cc: Julia Lawall, Jean-Christophe Plagniol-Villard, kernel-janitors,
Tomi Valkeinen, linux-geode, linux-fbdev, LKML
In-Reply-To: <20151108221624.GP18797@mwanda>
On Sun, Nov 8, 2015 at 2:16 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Cool. So, in grsec they use a GCC plugin to make these const
> automatically since they only contain function pointers. There about
> 100 struct types marked as __no_const. Kees would like to adopt the
> grsec pluggin approach I expect. Do you have an idea how many structs
> only contain function pointers or how many consts we would have to add
> to get the same effect without the plugin?
Just to remind everyone: while we certainly want to clean these up in
the code where possible, we still want to make the constification
plugin part of the regular builds. We want to provide a
secure-by-default build, even when vendors are adding their own
out-of-tree code when producing Linux-based products. So, we'll always
want to have the plugin as a back-stop for out-of-tree code, or places
where const was accidentally missed upstream.
-Kees
>
> regards,
> dan carpenter
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* RE: [PATCH] video: fbdev: fsl: Split DIU initialization entry
From: Wang Dongsheng @ 2015-11-10 2:37 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1444709355-8905-1-git-send-email-dongsheng.wang@freescale.com>
SGkgVGltdXIsDQoNCj4gSGkgVGltdXIsDQo+IA0KPiA+IE9uIE1vbiwgT2N0IDEyLCAyMDE1IGF0
IDExOjA5IFBNLCBEb25nc2hlbmcgV2FuZyA8ZG9uZ3NoZW5nLndhbmdAZnJlZXNjYWxlLmNvbT4N
Cj4gPiB3cm90ZToNCj4gPiA+ICsgICAgICAgcmV0ID0gZnNsX2RpdV9wZXJwYXJlKCk7DQo+ID4g
PiArICAgICAgIGlmIChyZXQpDQo+ID4gPiArICAgICAgICAgICAgICAgZ290byBvdXRfZGl1X3Bl
cnBhcmU7DQo+ID4NCj4gPiBJIHRoaW5rIHlvdSBtZWFuICJwcmVwYXJlIg0KPiA+DQo+ID4gVGhh
bmtzIGZvciBwb3N0aW5nIHRoaXMgcGF0Y2guICBJIHdpbGwgdHJ5IHRvIHJldmlldyBpdCBtb3Jl
IHRob3JvdWdobHkgbGF0ZXIuDQo+IA0KPiBEbyB5b3UgaGF2ZSBhbnkgb3RoZXIgY29tbWVudHMg
YWJvdXQgdGhpcyBwYXRjaD8gVGhhbmtzIGZvciB5b3VyIHJldmlldy4NCj4gDQoNCkNvdWxkIHlv
dSBoZWxwIG1lIHRvIHJldmlldyB0aGlzIHBhdGNoPw0KDQpSZWdhcmRzLA0KLURvbmdzaGVuZw0K
^ permalink raw reply
* Re: [PATCH] video: fbdev: fsl: Split DIU initialization entry
From: Timur Tabi @ 2015-11-10 3:13 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1444709355-8905-1-git-send-email-dongsheng.wang@freescale.com>
Dongsheng Wang wrote:
> From: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> Split diu initialize from fsl_diu_init into diu probe function, because
> it should be initialized when get the diu device tree node, not always
> do initialization.
>
> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
I only have time now for a quick review, ...
>
> diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
> index b335c1a..1969863 100644
> --- a/drivers/video/fbdev/fsl-diu-fb.c
> +++ b/drivers/video/fbdev/fsl-diu-fb.c
> @@ -1687,6 +1687,104 @@ static ssize_t show_monitor(struct device *device,
> return 0;
> }
>
> +#ifndef MODULE
> +static int __init fsl_diu_setup(char *options)
> +{
> + char *opt;
> + unsigned long val;
> +
> + if (!options || !*options)
> + return 0;
> +
> + while ((opt = strsep(&options, ",")) != NULL) {
> + if (!*opt)
> + continue;
> + if (!strncmp(opt, "monitor=", 8)) {
> + monitor_port = fsl_diu_name_to_port(opt + 8);
> + } else if (!strncmp(opt, "bpp=", 4)) {
> + if (!kstrtoul(opt + 4, 10, &val))
> + default_bpp = val;
> + } else {
> + fb_mode = opt;
> + }
> + }
> +
> + return 0;
> +}
> +#endif
> +
> +static int fsl_diu_perpare(void)
prepare, not perpare.
> +{
> +#ifdef CONFIG_NOT_COHERENT_CACHE
> + struct device_node *np;
> + const u32 *prop;
> +#endif
> +#ifndef MODULE
> + char *option;
> +#endif
> +
> + if (!diu_ops.set_pixel_clock)
> + return -ENODEV;
> +
> +#ifndef MODULE
> + /*
> + * For kernel boot options (in 'video=xxxfb:<options>' format)
> + */
> + if (fb_get_options("fslfb", &option))
> + return -ENODEV;
> + fsl_diu_setup(option);
> +#else
> + monitor_port = fsl_diu_name_to_port(monitor_string);
> +#endif
> + pr_info("Freescale Display Interface Unit (DIU) framebuffer driver\n");
> +
> +#ifdef CONFIG_NOT_COHERENT_CACHE
> + np = of_find_node_by_type(NULL, "cpu");
> + if (!np) {
> + pr_err("fsl-diu-fb: can't find 'cpu' device node\n");
> + return -ENODEV;
> + }
> +
> + prop = of_get_property(np, "d-cache-size", NULL);
> + if (!prop) {
> + pr_err("fsl-diu-fb: missing 'd-cache-size'\n");
> + of_node_put(np);
> + return -ENODEV;
> + }
> +
> + /*
> + * Freescale PLRU requires 13/8 times the cache size to do a proper
> + * displacement flush
> + */
> + coherence_data_size = be32_to_cpup(prop) * 13;
> + coherence_data_size /= 8;
> +
> + pr_debug("fsl-diu-fb: coherence data size is %zu bytes\n",
> + coherence_data_size);
> +
> + prop = of_get_property(np, "d-cache-line-size", NULL);
> + if (!prop) {
> + pr_err("fsl-diu-fb: missing 'd-cache-line-size'\n");
> + of_node_put(np);
> + return -ENODEV;
> + }
> + d_cache_line_size = be32_to_cpup(prop);
> +
> + pr_debug("fsl-diu-fb: cache lines size is %u bytes\n",
> + d_cache_line_size);
> +
> + of_node_put(np);
> + coherence_data = vmalloc(coherence_data_size);
> + if (!coherence_data) {
> + pr_err("fsl-diu-fb: could not allocate coherence data\n");
> + pr_err("coherence_data_size=%zu)\n", coherence_data_size);
> + return -ENOMEM;
> + }
> +
> +#endif
> + return 0;
> +}
Split this function into two functions, one for coherent cache and one
for non-coherent cache. And then in fsl_diu_probe, use the compatible
property to differentiate between then, instead of using "#ifdef
CONFIG_NOT_COHERENT_CACHE". We want to eliminate that #ifdef and just
probe on the right compatible property.
> +
> static int fsl_diu_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> @@ -1697,10 +1795,16 @@ static int fsl_diu_probe(struct platform_device *pdev)
> unsigned int i;
> int ret;
>
> + ret = fsl_diu_perpare();
> + if (ret)
> + goto out_diu_perpare;
> +
> data = dmam_alloc_coherent(&pdev->dev, sizeof(struct fsl_diu_data),
> &dma_addr, GFP_DMA | __GFP_ZERO);
If you call dmam_alloc_cohernet() first, before you call
fsl_diu_prepare(), then you won't need out_diu_prepare.
> - if (!data)
> - return -ENOMEM;
> + if (!data) {
> + ret = -ENOMEM;
> + goto out_diu_perpare;
> + }
> data->dma_addr = dma_addr;
>
> /*
> @@ -1826,6 +1930,11 @@ error:
>
> iounmap(data->diu_reg);
>
> +out_diu_perpare:
> +#if defined(CONFIG_NOT_COHERENT_CACHE)
> + if (coherence_data)
> + vfree(coherence_data);
> +#endif
> return ret;
> }
>
> @@ -1844,34 +1953,12 @@ static int fsl_diu_remove(struct platform_device *pdev)
>
> iounmap(data->diu_reg);
>
> +#if defined(CONFIG_NOT_COHERENT_CACHE)
> + vfree(coherence_data);
> +#endif
> return 0;
> }
>
> -#ifndef MODULE
> -static int __init fsl_diu_setup(char *options)
> -{
> - char *opt;
> - unsigned long val;
> -
> - if (!options || !*options)
> - return 0;
> -
> - while ((opt = strsep(&options, ",")) != NULL) {
> - if (!*opt)
> - continue;
> - if (!strncmp(opt, "monitor=", 8)) {
> - monitor_port = fsl_diu_name_to_port(opt + 8);
> - } else if (!strncmp(opt, "bpp=", 4)) {
> - if (!kstrtoul(opt + 4, 10, &val))
> - default_bpp = val;
> - } else
> - fb_mode = opt;
> - }
> -
> - return 0;
> -}
> -#endif
> -
> static struct of_device_id fsl_diu_match[] = {
> #ifdef CONFIG_PPC_MPC512x
> {
> @@ -1898,88 +1985,12 @@ static struct platform_driver fsl_diu_driver = {
>
> static int __init fsl_diu_init(void)
> {
> -#ifdef CONFIG_NOT_COHERENT_CACHE
> - struct device_node *np;
> - const u32 *prop;
> -#endif
> - int ret;
> -#ifndef MODULE
> - char *option;
> -
> - /*
> - * For kernel boot options (in 'video=xxxfb:<options>' format)
> - */
> - if (fb_get_options("fslfb", &option))
> - return -ENODEV;
> - fsl_diu_setup(option);
> -#else
> - monitor_port = fsl_diu_name_to_port(monitor_string);
> -#endif
> - pr_info("Freescale Display Interface Unit (DIU) framebuffer driver\n");
> -
> -#ifdef CONFIG_NOT_COHERENT_CACHE
> - np = of_find_node_by_type(NULL, "cpu");
> - if (!np) {
> - pr_err("fsl-diu-fb: can't find 'cpu' device node\n");
> - return -ENODEV;
> - }
> -
> - prop = of_get_property(np, "d-cache-size", NULL);
> - if (prop = NULL) {
> - pr_err("fsl-diu-fb: missing 'd-cache-size' property' "
> - "in 'cpu' node\n");
> - of_node_put(np);
> - return -ENODEV;
> - }
> -
> - /*
> - * Freescale PLRU requires 13/8 times the cache size to do a proper
> - * displacement flush
> - */
> - coherence_data_size = be32_to_cpup(prop) * 13;
> - coherence_data_size /= 8;
> -
> - pr_debug("fsl-diu-fb: coherence data size is %zu bytes\n",
> - coherence_data_size);
> -
> - prop = of_get_property(np, "d-cache-line-size", NULL);
> - if (prop = NULL) {
> - pr_err("fsl-diu-fb: missing 'd-cache-line-size' property' "
> - "in 'cpu' node\n");
> - of_node_put(np);
> - return -ENODEV;
> - }
> - d_cache_line_size = be32_to_cpup(prop);
> -
> - pr_debug("fsl-diu-fb: cache lines size is %u bytes\n",
> - d_cache_line_size);
> -
> - of_node_put(np);
> - coherence_data = vmalloc(coherence_data_size);
> - if (!coherence_data) {
> - pr_err("fsl-diu-fb: could not allocate coherence data "
> - "(size=%zu)\n", coherence_data_size);
> - return -ENOMEM;
> - }
> -
> -#endif
> -
> - ret = platform_driver_register(&fsl_diu_driver);
> - if (ret) {
> - pr_err("fsl-diu-fb: failed to register platform driver\n");
> -#if defined(CONFIG_NOT_COHERENT_CACHE)
> - vfree(coherence_data);
> -#endif
> - }
> - return ret;
> + return platform_driver_register(&fsl_diu_driver);
> }
>
> static void __exit fsl_diu_exit(void)
> {
> platform_driver_unregister(&fsl_diu_driver);
> -#if defined(CONFIG_NOT_COHERENT_CACHE)
> - vfree(coherence_data);
> -#endif
> }
>
> module_init(fsl_diu_init);
>
^ permalink raw reply
* RE: [PATCH] video: fbdev: fsl: Split DIU initialization entry
From: Wang Dongsheng @ 2015-11-10 3:32 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1444709355-8905-1-git-send-email-dongsheng.wang@freescale.com>
Hi Timur,
Thanks for your review.
> -----Original Message-----
> From: Timur Tabi [mailto:timur@tabi.org]
> Sent: Tuesday, November 10, 2015 11:13 AM
> To: Wang Dongsheng-B40534
> Cc: tomi.valkeinen@ti.com; Wood Scott-B07421; linux-fbdev@vger.kernel.org
> Subject: Re: [PATCH] video: fbdev: fsl: Split DIU initialization entry
>
> Dongsheng Wang wrote:
> > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> >
> > Split diu initialize from fsl_diu_init into diu probe function,
> > because it should be initialized when get the diu device tree node,
> > not always do initialization.
> >
> > Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
>
> I only have time now for a quick review, ...
>
> >
> > diff --git a/drivers/video/fbdev/fsl-diu-fb.c
> > b/drivers/video/fbdev/fsl-diu-fb.c
> > index b335c1a..1969863 100644
> > --- a/drivers/video/fbdev/fsl-diu-fb.c
> > +++ b/drivers/video/fbdev/fsl-diu-fb.c
> > @@ -1687,6 +1687,104 @@ static ssize_t show_monitor(struct device *device,
> > return 0;
> > }
> >
> > +#ifndef MODULE
> > +static int __init fsl_diu_setup(char *options) {
> > + char *opt;
> > + unsigned long val;
> > +
> > + if (!options || !*options)
> > + return 0;
> > +
> > + while ((opt = strsep(&options, ",")) != NULL) {
> > + if (!*opt)
> > + continue;
> > + if (!strncmp(opt, "monitor=", 8)) {
> > + monitor_port = fsl_diu_name_to_port(opt + 8);
> > + } else if (!strncmp(opt, "bpp=", 4)) {
> > + if (!kstrtoul(opt + 4, 10, &val))
> > + default_bpp = val;
> > + } else {
> > + fb_mode = opt;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +#endif
> > +
> > +static int fsl_diu_perpare(void)
>
> prepare, not perpare.
>
> > +{
> > +#ifdef CONFIG_NOT_COHERENT_CACHE
> > + struct device_node *np;
> > + const u32 *prop;
> > +#endif
> > +#ifndef MODULE
> > + char *option;
> > +#endif
> > +
> > + if (!diu_ops.set_pixel_clock)
> > + return -ENODEV;
> > +
> > +#ifndef MODULE
> > + /*
> > + * For kernel boot options (in 'video=xxxfb:<options>' format)
> > + */
> > + if (fb_get_options("fslfb", &option))
> > + return -ENODEV;
> > + fsl_diu_setup(option);
> > +#else
> > + monitor_port = fsl_diu_name_to_port(monitor_string);
> > +#endif
> > + pr_info("Freescale Display Interface Unit (DIU) framebuffer
> > +driver\n");
> > +
> > +#ifdef CONFIG_NOT_COHERENT_CACHE
> > + np = of_find_node_by_type(NULL, "cpu");
> > + if (!np) {
> > + pr_err("fsl-diu-fb: can't find 'cpu' device node\n");
> > + return -ENODEV;
> > + }
> > +
> > + prop = of_get_property(np, "d-cache-size", NULL);
> > + if (!prop) {
> > + pr_err("fsl-diu-fb: missing 'd-cache-size'\n");
> > + of_node_put(np);
> > + return -ENODEV;
> > + }
> > +
> > + /*
> > + * Freescale PLRU requires 13/8 times the cache size to do a proper
> > + * displacement flush
> > + */
> > + coherence_data_size = be32_to_cpup(prop) * 13;
> > + coherence_data_size /= 8;
> > +
> > + pr_debug("fsl-diu-fb: coherence data size is %zu bytes\n",
> > + coherence_data_size);
> > +
> > + prop = of_get_property(np, "d-cache-line-size", NULL);
> > + if (!prop) {
> > + pr_err("fsl-diu-fb: missing 'd-cache-line-size'\n");
> > + of_node_put(np);
> > + return -ENODEV;
> > + }
> > + d_cache_line_size = be32_to_cpup(prop);
> > +
> > + pr_debug("fsl-diu-fb: cache lines size is %u bytes\n",
> > + d_cache_line_size);
> > +
> > + of_node_put(np);
> > + coherence_data = vmalloc(coherence_data_size);
> > + if (!coherence_data) {
> > + pr_err("fsl-diu-fb: could not allocate coherence data\n");
> > + pr_err("coherence_data_size=%zu)\n", coherence_data_size);
> > + return -ENOMEM;
> > + }
> > +
> > +#endif
> > + return 0;
> > +}
>
> Split this function into two functions, one for coherent cache and one for non-
> coherent cache. And then in fsl_diu_probe, use the compatible property to
> differentiate between then, instead of using "#ifdef CONFIG_NOT_COHERENT_CACHE".
> We want to eliminate that #ifdef and just probe on the right compatible property.
>
Ok.
Regards,
-Dongsheng
^ permalink raw reply
* Re: [PATCH] video: constify geode ops structures
From: Christoph Hellwig @ 2015-11-10 6:38 UTC (permalink / raw)
To: Kees Cook
Cc: Dan Carpenter, Julia Lawall, Jean-Christophe Plagniol-Villard,
kernel-janitors, Tomi Valkeinen, linux-geode, linux-fbdev, LKML
In-Reply-To: <CAGXu5jJp4hQKWyQhu5fqgnvAEgeWDAKtaDm2norVM19n=+qigQ@mail.gmail.com>
On Mon, Nov 09, 2015 at 01:20:12PM -0800, Kees Cook wrote:
> Just to remind everyone: while we certainly want to clean these up in
> the code where possible, we still want to make the constification
> plugin part of the regular builds. We want to provide a
> secure-by-default build, even when vendors are adding their own
> out-of-tree code when producing Linux-based products. So, we'll always
> want to have the plugin as a back-stop for out-of-tree code, or places
> where const was accidentally missed upstream.
Who is 'we'? While a plugin like this that warns would be very ueful
I strongly disagree with bloating the kernel tree with any infrastructure
primarily aimed at out of tree code.
^ permalink raw reply
* [GIT PULL] fbdev changes for 4.4
From: Tomi Valkeinen @ 2015-11-10 11:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-fbdev, linux-kernel@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]
Hi Linus,
Please pull fbdev changes for 4.4.
Tomi
The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde:
Linux 4.3-rc2 (2015-09-20 14:32:34 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-4.4
for you to fetch changes up to 08bfb453f0458dd353f37737d80475ff13868d9c:
radeonfb: Deinline large functions (2015-10-08 12:24:12 +0300)
----------------------------------------------------------------
fbdev changes for 4.4
* omap: fix hdmi audio configuration issue
* ssd1307fb: add ssd1309 support
* tridentfb: support DDC
* gxt4500: enable support for non-PPC platforms
----------------------------------------------------------------
Andrzej Hajda (1):
video/omap: remove invalid check
Denys Vlasenko (1):
radeonfb: Deinline large functions
Jyri Sarha (1):
OMAPDSS: hdmi: Reconfigure and restart audio when display is enabled
Olliver Schinagl (2):
fbdev: ssd1307fb: alphabetize headers
fbdev: ssd1307fb: add ssd1309 support
Ondrej Zary (7):
fb_ddc: Allow I2C adapters without SCL read capability
tridentfb: Add DDC support
gxt4500: enable on non-PPC architectures
gxt4500: fix 16bpp 565 mode
gxt4500: fix color order
gxt4500: Use arch_phys_wc_* for framebuffer
gxt4500: enable panning
.../devicetree/bindings/video/ssd1307fb.txt | 3 +-
drivers/video/fbdev/Kconfig | 7 +-
drivers/video/fbdev/aty/radeon_base.c | 133 ++++++++++++++-
drivers/video/fbdev/aty/radeonfb.h | 144 ++--------------
drivers/video/fbdev/core/fb_ddc.c | 28 ++--
drivers/video/fbdev/gxt4500.c | 25 ++-
drivers/video/fbdev/omap/omapfb_main.c | 5 -
drivers/video/fbdev/omap2/dss/hdmi.h | 9 +-
drivers/video/fbdev/omap2/dss/hdmi4.c | 66 ++++++--
drivers/video/fbdev/omap2/dss/hdmi5.c | 75 +++++++--
drivers/video/fbdev/ssd1307fb.c | 21 ++-
drivers/video/fbdev/tridentfb.c | 182 ++++++++++++++++++++-
12 files changed, 506 insertions(+), 192 deletions(-)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Hisilicon graphic driver
From: Tomi Valkeinen @ 2015-11-10 11:38 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <BLU437-SMTP248CA33D65A31EAE12675CC32B0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
Hi,
On 03/11/15 15:54, Rongrong Zou wrote:
> From: Rongrong Zou <rongrongchau@163.com>
>
> Hi1710 chip have a graphic modue with 2d acceleration, this driver support
> the graphic module.
I'm not merging new fbdev drivers if there are no special reasons for it
(fb for non-MMU platforms is the only reason I know).
Instead, please write a DRM driver.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4] pwm-backlight: Avoid backlight flicker when probed from DT
From: Heiko Stuebner @ 2015-11-10 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1446483356-14338-1-git-send-email-p.zabel@pengutronix.de>
Hi Philipp,
Am Montag, 2. November 2015, 17:55:56 schrieb Philipp Zabel:
> If the driver is probed from the device tree, and there is a phandle
> property set on it, and the enable GPIO is already configured as output,
> and the backlight is currently disabled, keep it disabled.
> If all these conditions are met, assume there will be some other driver
> that can enable the backlight at the appropriate time.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
this patch improves the white screen when booting a veyron chromebook
a lot. I still see a small white flash, but that can probably come from
the WIP edp driver.
Tested-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v4] pwm-backlight: Avoid backlight flicker when probed from DT
From: Thierry Reding @ 2015-11-10 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3447562.c3gSANEMio@phil>
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
On Tue, Nov 10, 2015 at 03:18:10PM +0100, Heiko Stuebner wrote:
> Hi Philipp,
>
> Am Montag, 2. November 2015, 17:55:56 schrieb Philipp Zabel:
> > If the driver is probed from the device tree, and there is a phandle
> > property set on it, and the enable GPIO is already configured as output,
> > and the backlight is currently disabled, keep it disabled.
> > If all these conditions are met, assume there will be some other driver
> > that can enable the backlight at the appropriate time.
> >
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
>
> this patch improves the white screen when booting a veyron chromebook
> a lot. I still see a small white flash, but that can probably come from
> the WIP edp driver.
Some panels require a couple of frames before they actually enable. You
may want to look at the datasheet of your panel to see if it has some
specific requirement and update the panel driver with that.
From a high-level view the way that this is supposed to work is that
your encoder driver (e.g. eDP) "prepares" the panel, then starts sending
frames and finally "enables" the panel. With something like the simple
panel driver you can influence this by setting the delay.enable field in
the panel descriptor.
See struct panel_desc in drivers/gpu/drm/panel/panel-simple.c
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 00/12] pwm: add support for atomic update
From: Thierry Reding @ 2015-11-10 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2341981.a79ioYM9Es@diego>
[-- Attachment #1: Type: text/plain, Size: 917 bytes --]
On Mon, Oct 19, 2015 at 12:12:12PM +0200, Heiko Stübner wrote:
> Hi Thierry,
>
> Am Montag, 21. September 2015, 11:33:17 schrieb Boris Brezillon:
> > Hello,
> >
> > This series adds support for atomic PWM update, or IOW, the capability
> > to update all the parameters of a PWM device (enabled/disabled, period,
> > duty and polarity) in one go.
>
> is anything more blocking this series? It's now sitting on the lists for
> nearly a month and everybody seems happy with it, so it would be really nice
> to have in mainline :-) .
>
> Especially as this also makes it possible for Rockchip Chromebooks to actually
> control the logic-regulator that is implemented as pwm-regulator there.
Last time I tried to put this into linux-next I got immediately
bombarded by a number of build failures, so I backed things out. The
current plan is to give this another try after v4.4-rc1.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v3 00/12] pwm: add support for atomic update
From: Boris Brezillon @ 2015-11-10 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20151110173416.GB21727@ulmo>
Hi Thierry,
On Tue, 10 Nov 2015 18:34:16 +0100
Thierry Reding <thierry.reding@gmail.com> wrote:
> On Mon, Oct 19, 2015 at 12:12:12PM +0200, Heiko Stübner wrote:
> > Hi Thierry,
> >
> > Am Montag, 21. September 2015, 11:33:17 schrieb Boris Brezillon:
> > > Hello,
> > >
> > > This series adds support for atomic PWM update, or IOW, the capability
> > > to update all the parameters of a PWM device (enabled/disabled, period,
> > > duty and polarity) in one go.
> >
> > is anything more blocking this series? It's now sitting on the lists for
> > nearly a month and everybody seems happy with it, so it would be really nice
> > to have in mainline :-) .
> >
> > Especially as this also makes it possible for Rockchip Chromebooks to actually
> > control the logic-regulator that is implemented as pwm-regulator there.
>
> Last time I tried to put this into linux-next I got immediately
> bombarded by a number of build failures, so I backed things out. The
> current plan is to give this another try after v4.4-rc1.
Could you paste the build failures (I didn't receive any notification)?
BTW, I just rebased my branch on pwm/for-next and it seems to compile
correctly, but maybe you're compiling on more platforms (or different
drivers than I do).
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH] video: constify geode ops structures
From: Kees Cook @ 2015-11-10 20:34 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dan Carpenter, Julia Lawall, Jean-Christophe Plagniol-Villard,
kernel-janitors, Tomi Valkeinen, linux-geode, linux-fbdev, LKML
In-Reply-To: <20151110063821.GA31014@infradead.org>
On Mon, Nov 9, 2015 at 10:38 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Mon, Nov 09, 2015 at 01:20:12PM -0800, Kees Cook wrote:
>> Just to remind everyone: while we certainly want to clean these up in
>> the code where possible, we still want to make the constification
>> plugin part of the regular builds. We want to provide a
>> secure-by-default build, even when vendors are adding their own
>> out-of-tree code when producing Linux-based products. So, we'll always
>> want to have the plugin as a back-stop for out-of-tree code, or places
>> where const was accidentally missed upstream.
>
> Who is 'we'? While a plugin like this that warns would be very ueful
I understand "we" here to mean people interested in the proactive
defense of the Linux kernel, and by extension the Linux kernel
community as a whole. :)
> I strongly disagree with bloating the kernel tree with any infrastructure
> primarily aimed at out of tree code.
It's not "primarily aimed at out of tree code", that is simply an
additional side-effect (though the need must be recognized: a billion
android devices, and none of them are running a stock kernel). What it
gets us is _coverage_. We can't make everything work just by static
analyzers and checkpatch.pl runs (meaning the "backstop" comment
above).
Additionally, having the plugin infrastructure gets us the ability to
do things that aren't presently possible (see the thread on the
initify plugin, which can't be done in source alone).
-Kees
--
Kees Cook
Chrome OS Security
^ permalink raw reply
* Re: [PATCH] video: constify geode ops structures
From: Joe Perches @ 2015-11-10 20:49 UTC (permalink / raw)
To: Kees Cook, Christoph Hellwig
Cc: Dan Carpenter, Julia Lawall, Jean-Christophe Plagniol-Villard,
kernel-janitors, Tomi Valkeinen, linux-geode, linux-fbdev, LKML
In-Reply-To: <CAGXu5j+59jPqd5QWq38KH--i=gBzq2d5j_Z0c2ygG=pfr2+tzw@mail.gmail.com>
On Tue, 2015-11-10 at 12:34 -0800, Kees Cook wrote:
> We can't make everything work just by static
> analyzers and checkpatch.pl runs (meaning the "backstop" comment
> above).
>
> Additionally, having the plugin infrastructure gets us the ability to
> do things that aren't presently possible (see the thread on the
> initify plugin, which can't be done in source alone).
#define __do_const __attribute__((do_const))
...
#ifndef __do_const
#define __do_const
#endif
I think it's always better for the reader to know that a
const struct declaration is used over a non-const struct
when the compiler, via plug-in extension, could convert
the declaration to const.
Is there a warning/info message produced by gcc and the
plug-in when a non-const declaration is converted to
const because of this attribute?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox